More thoughts about management.

I wrote this as my answer to an application question for a remote company a few years back. It’s a bit outdated, but I thought I’d share it anyway.

In a broad sense, to me management is about people and the things that stop them from achieving what’s important at an individual, team and company level.

It’s about understanding and helping solve the issues stopping a team from being in their A-game, which starts with the individuals and ends with the company as a whole. If a team has issues because people are distracted thinking about how bad their CI solution is, or someone is blocked every morning because they aren’t getting the information they need from another department, it’s a manager’s job to find out and help the team come to a solution. The best solutions come from the people closest to the work, but the responsibility of finding and facilitating the resolution of those issues is on the manager; sometimes that means just supporting the team on a decision they made, and sometimes it means solving it yourself in one way or another.

I believe one of the best things you can do as a manager is becoming skilled and comfortable at delegation and facilitation, and always pushing yourself to delegate larger and more important work to the people who demonstrate they can do it. It means you are comfortable looking from outside, coaching people to excel at their assignments, and being accountable for work that you had very little to do with in the day to day.

It’s about delegating authority, rather than only tasks.

You have to be comfortable saying no often and explaining your rationale as needed, but you also have to be able to check yourself and reevaluate If someone comes to you with a concern about a decision you made.

Understanding and communicating the value of what we’re doing so that others have the context to make smart decisions is one of the most high value things you can do as a manager. People deserve to understand why their work actually matters, and they produce much better work when they do.

An effective manager should be comfortable switching between coach and the person being coached, being able to put yourself in a position to ask questions to get to the root of a problem without letting your ego get in the way.

Being a decent manager can mean being aware that you have very little control and still owning up to whatever the team is achieving or not. It’s finding the time to be connected to the work that the team is doing and being able to facilitate decisions, but not letting yourself hide from problems in the comfort of coding. It’s also remembering that your work touches real people with real lives.

Ensuring new tech leads get a chance to succeed

When assigning technical leads, take care to put them in a situation where they will succeed easily, especially if this is their first time with a tech lead role. The tech lead role is one of the most challenging roles to go into because you live in a sort of limbo where you are still mostly doing IC work but have much more responsibility.

If it goes badly the first time, you might lose a high potential IC over a project that was doomed from the beginning. Try your best to set up all your new tech leads for success, and eventually you might just get lucky and find your replacement in one of them (you know, for when you’re hit by a bus or a bike or something).

Engineering Management feels slow sometimes.

The rewards come slowly compared to individual contributor work, but they tend to be more interesting to me because I can see the impact of my work on people and projects in a more global way. It can be someone finally getting that promotion they have been working hard to get, features shipping with a reasonable cadence when you were struggling to get things out before, or realizing the risk you took 3 months ago by firing someone had a large positive impact on your team’s productivity and happiness.

Engineering management is extremely rewarding, and even though you don’t see things changing on the day to day as much as you do when you’re an individual contributor, you can usually look back a month and find something you influenced that impacted your team and/or your company.

Pragmatic engineering management.

I tend to approach engineering management decisions as I do software development: small adjustments most of the time, big refactors only when the potential long term rewards are worth the risks and there’s no other viable solution.

Like in software engineering, the context in which we make decisions matters. The strategies that make sense in a small, 3 dev team don’t really scale for a larger group. The decisions we make to create an initial prototype to prove an idea are different from what we’d do for production applications, but it’s important to remember that doesn’t make them invalid, it makes them good decisions for the context in which they were made. The same goes for teams. The way you manage a 3-person team is not the same as with a 20-person team, and that’s ok.

Engineering Management is like Debugging

Engineering management is a lot like debugging and bug-fixing at times.

Sometimes you don’t know much about a failure except that it happened. Sometimes the solution is clear but risky in some way, and sometimes you just know what needs to be done and wonder why you didn’t do it earlier.

More often than not, there’s a problem coming up that you didn’t expect and don’t fully understand. As with code, those bugs are hard to figure out, but when you do, it’s extremely rewarding.