Saying “use the right tool for the job” is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.

But that’s all part of the work.

And if you “just use Go” or “just use React” or “just use Postgres” for every problem that crosses your keyboard, you’re just not putting in the work.

I’ve only worked in agencies my entire professional career, and that work has honed two important traits of a good engineer: curiousity and agility.

Being curious gives you the ability to explore new tools and understand how they work.

Being agile (not in the project management sense, but the “moving freely and quickly” sense) gives you the ability to deploy those tools to solve increasingly complex problems.

It’s not that I don’t have a standard set of tools I reach for when solving a wide swatch of problems (Rails, Postgres, etc.), but as I get older, I’m finding that I am more willing to engage with newer tech.

I come from a background of writing Javascript by hand, but I'm starting to play more with Vue and React, and I can see why people like these tools.

Same thing with CI/CD pipelines. I always thought they were more fiddle-y and brittle than they were worth, but that's because I've generally been a lone wolf. In a team context, they are extremely useful.

If you keep hearing noise about a new technology, it's probably worth taking a look over the fence to see how that tool could be used.

Managers: If your job ladder doesn’t require that your senior people have glue work skills, think about how you were expecting that work to get done.

Glue people: Push back on requests to do more than your fair share of non-promotable work, and put your effort into something you want to get good at.

Our skills aren’t fixed in place. You can be good and lots of things. You can do anything.

1. Do I have the time?

2. Do I have the mental space?

3. Is this project aligned with my values and the change I want to create in the world?

4. Will it energize me?

I posted these questions here for a quick reminder to my future self, but you should read the whole thing to get clarity around how to answer these questions.

I read Good to Great a few years ago, but I admittedly never finished it. After hearing this interview though, you'd better believe I'm gonna go back and pour over it.

This interview with Jim Collins was absolutely awe-inspiring. Among the nuggets I took away from this episode:

• You should strive to be a "Level 5 Leader", which means you are simultaneously headstrong and humble. You have to put your organization before any personal gain.

• Jim organizes his time according to the 50/30/20 rule, which means he spends 50% of his time in a given 365 day period on creative activities, 30% of his time teaching, and 20% of his time on everything else.

• On that same vein, Jim has a spreadsheet where he tracks how many hours a day he gets creative pursuits, and in any given 365 day period, he has to have over 1000 total hours. He also tracks what he did on a given day, as well as a rating from +2 to -2 for how he felt on that day. I've been trying to do something similar with tracking the big three things I need to get done each day, and I think I should expand that out a little bit to include these variables.

• You should not do what you’re good at, but do what you’re coded for. This really struck a chord with me, because I think I'm pretty good at developing, but I'm pretty sure I'm coded to be a leader.

• There was a lot mentioned around the flywheel principle, and I think this is something we're just starting to see happen with our own business pursuits.

There's a ton in this episode, so I'm going to stop writing in order to let you start listening.

I had to laugh out loud when Ryan said, "Oh shoot, I'm giving away my entire playbook here," to which Kurt replied, "Don't worry, nobody listens to this show."

This episode of The Schmidt List (which you aught to subscribe to, by the way) was particularly timely as we are working to hire our first full-time employee at The Jed Mahonis Group that wasn't already a good friend of ours.

Some of the key interview questions I will (shamelessly) borrow and use in our upcoming interviews include:

What gets you excited to go to work every day?

You're looking for something other than "co-workers". Something related to the job itself is ideal.

What do you think of automated testing?

As Kurt put it, this is essentially an updated "tabs vs. spaces" question. The aim is to get the developer to walk you through their reasoning for one thing or the other, and regardless of their answer, the big takeaway is whether they can justify their position.

What are you excited about in tech?

This is in lieu of the classic "what is your current side project" question, which I've never really been a fan of for the reasons they mention in the episode. Instead, this question allows you to see if they are keeping up with the industry and have thoughts on its direction.

In addition to these hiring nuggets of wisdom, the rest of the episode is a fantastic resource for anyone who is going to be moving into a role of managing developers. Two thoughts I took away:

1) Empathy, above all else, is what makes a team flow. A manager needs to be empathetic to the struggles that an employee may be going through (including changing requirements, stresses outside of work, etc.). Equally important is ensuring team members are empathetic to the struggles that their manager may be going through (including changing requirements, stresses outside of work, etc.).

2) Giving negative feedback to reports is important, and it's time to stop being Minnesota Nice about it. Not giving negative feedback is simply narcissistic and selfish.