When someone asks if you “need” something, there’s an implicit weight to that word. Need suggests dependency, maybe even weakness. It’s the difference between someone offering you food and asking if you’re hungry. One feels generous; the other feels like you have to admit to a deficit.

So I changed the question: “What’s the most important thing I can help you with this week?”

Noting this for the future.

This doesn’t just apply to the workplace, either. I’m in an era where my friends are having their second (or third+) child, and adding more burden on them by making them decide how I can help them with their burdens feels counterproductive.

Another case: my wife’s been busy with graduation at her school. Instead of asking her how I can help her deal with organizing the caps, gowns, diplomas, and tassels for 600+ students, I should have asked her what’s the most important thing I can help with.¹

This talk helped me articulate a few key arguments that I can use to counter myself when in the throes of impostor syndrome-related attacks from my inner monologue.

Basically, a “staff-plus engineer” is anyone in a technical role that is higher than a senior engineer. These are sometimes referred to as principal engineers, staff engineers, etc.

The big difference between staff-plus and individual contributor path is that an IC role is one you go down when you truly want to contribute as an individual, often acquiring such an expertise in a specific domain that you just do your thing alone.

A staff-plus role requires collaboration, often leading teams, but always being the lynchpin which helps be the voice of technical leadership across multiple teams.

The responsibilities of a staff-plus role include (probably) writing and (definitely) reviewing code, providing technical direction, mentoring and sponsoring other engineers, providing engineering context to non-technical people, and being involved in strategic projects which aren’t shiny but are critical to the success of an organization.

I think I came across this talk at a timely point in my career. I have been tasked with doing staff-plus engineering work ever since starting my first company, and it’s honestly the stuff I love the most.

I’m not a developer who loves to write code. I love writing code because it results in a tool that makes someone’s life easier. What brings me joy is in doing the discovery work needed to clearly articulate the problem and charting a course that’ll lead us to a solution.

I saw Simon Willison share this article and thought it was too good not to share it myself.

We respect wildlife in the wilderness because we’re in their house. We don’t fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we can’t always predict what outcomes our interactions with nature might have.

In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. It’s super common for a new leader to come in, see something they see as “useless”, and get rid of it – without understanding the implications. Good leaders make sure they understand before they mess around.

Or, as the footnote succinctly puts it: “find out, then fuck around.”

This article also taught me about Chesterton’s fence, a principle that says “don’t destroy what you don’t understand”.

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.