July 6, 2019 · 3 min read
My curse in life is to always make the opposite mistake that everyone else makes.
I don’t know why. Maybe it’s because I read too much advice, and I take it to heart before I understand the full context it came from. I think that’s what happened the first time I became a manager.
My first management experience was at Amazon circa 2005. I was starting a new team, not taking over an existing one, so I started with only a few engineers. And I had heard for a long time that one of the hardest things for new managers to do was to learn to delegate. New managers, I heard, tend to want to do everything themselves. The best managers rarely if ever have to step in and handle things themselves, because they’ve hired great people and trained them and set them up to be autonomous.
So the moment I became a manager, I delegated everything. I did nothing myself; at least, no engineering, because that’s what I had people to do (I still had plenty of work making the roadmap, managing projects, recruiting, etc.) I thought, of course, that I was following best practices. Ahead of the curve.
The problem was that I was disconnected from the actual work going on. Not only was I not doing the engineering work my team was doing, I had never done it. I wasn’t familiar with the part of the system they were working on. On one major project, I didn’t even know the programming language being used.
As a result, I was helpless in a number of ways. I couldn’t do code reviews. I couldn’t help with tech design, or even debugging. I couldn’t anticipate what kinds of problems my team would encounter, or help them work through them. I couldn’t help them estimate project schedules, and I couldn’t call out when their estimates were off. I couldn’t appreciate the challenges my engineers might be having with their development environment or the codebase, and so I couldn’t coach them very well on how to be more productive, or help them identify and assess technical debt. And I couldn’t really evaluate their performance directly. In effect, I had the handicap of a non-technical manager, even though I had a CS degree and solid programming experience. I was too far from the details for that general knowledge to be very useful.
In retrospect, I was taking as my model a high-level executive, and trying to apply it to a team lead of three engineers. But just as a startup is not a smaller version of a large company, a team lead is not a scaled-down version of an exec. They’re different jobs, and they need to be approached in a different way. (And probably many execs need to get more into the details than they do—but that’s for another post.)
If I could go back and give myself some advice, I would say: Before you get fully occupied with “management”, get intimiately familiar with the details of the day-to-day engineering work. Starting a new team in a new area, especially with only one or two engineers, spend the first few weeks as a full-time engineer yourself. Set up your development environment, take on engineering tasks, learn the codebase. As you build the team and get more busy with project management, back off from that, but keep doing code review. Never get too far removed from what your team is doing every day. If you find that you don’t understand what’s going on with a project, do a deep dive to learn it, whatever that takes—whether that’s just asking a lot of questions, doing a thorough code walkthrough, or even getting in there and writing more code yourself.
That would have eliminated the handicap I had given myself, and it would have done something else almost more important: it would have helped me earn the full respect of my team. It’s possible for a non-technical manager to gain the respect of a technical team, but it’s much harder. The most basic way to show your team that you understand them, care about them, and are qualified to direct and evaluate them, is to show that you can do their job at least as well as they can.
So, managers: Roll up your sleeves and do the work.
These days I do most of my writing at The Roots of Progress. If you liked this essay, check out my other work there.
Copyright © Jason Crawford. Some rights reserved: CC BY-ND 4.0