Transitioning from Developer to Manager
Making the change from coder to coordinator
There are two moments that I consider milestones in my career as a web developer. The first was the day, during my post-graduate studies, that I realized I am a horrible designer. I’d never heard the phrase at the time, but I knew I should just focus on front-end development (horribly oversimplified as the code that the user sees in their browser). The second came six years later while managing a team of developers at the Obama campaign. I already intellectually knew this one, but it hadn’t become real yet.
Sitting at my desk, one of my developers came to chat with me. I was beginning work on some software (the exact project escapes me now). The developer lets me show off how the work is going, then tells me something that triggered a change in how I approached running a team: if I’m not going to be able to finish this project myself, someone else should do it from the start.
Now, I had good reasons to have taken on this project personally. We were in the final stretch of the campaign and the team’s bandwidth was over capacity. Someone needed to work on this, but no one was really available. Plus, this was mission critical stuff. If it didn’t work right, there could be serious consequences that I’d always feel responsible for. But he was right. It would be worse to put one of our team in a position to finish something like this when it was half finished. We worked out a plan to hand it off to someone else with me supporting their work.
I didn’t say anything at the time, but I knew then that I had to stop being a developer. Sure, I still wrote code. Mostly Python scripts that helped automate repetitive tasks we did regularly. (There was a running joke that Python was one of our senior developers.) I made a pretty simple, yet useful, dashboard that showed the health of our critical systems. I did bug fixes on the software I’d already created for us. But I was done doing big projects myself. “Developer” was one the major ways I’d defined myself for so long. It was really tough to let go. Nevertheless, it was the right decision.
Earlier in my career I’d run a (much smaller) team at a web design agency. Notwithstanding my illustrious stint as a McDonald’s manager in high school and an attempt to manage punk rock bands while I deferred college, I’d never really overseen a group of people for a long stretch. As I prepped to hire my first team members—yes I’d put been in charge of a team that consisted of me—my bosses Andy Montgomery, Rob Righter and I had a chat about how to best hire people. One thing that’s stuck with me was the observation that there are basically two kinds of managers. One hires people that know less than they do and will need to rely on the manager to be successful. This, among other things, keeps the manager at the center of the team. The other type brings in people who are smarter than they are. Their job is to coordinate the team, creating a collaborative environment where everyone can learn from everyone else. I can say that I’ve always tried to go with the second approach.
The reality of hiring smarter people than you is that you should be deferring the hardest work to them. Sure, you help out and bring your experience and expertise to what they’re doing, but if you’re writing the bulk of the code then your stakeholders aren’t getting the best work they could.
Sometimes it’s easy to make the calculus that you could fix a problem or tackle a project faster than someone else could, and you could even be correct in thinking that. Yet, run that out at scale. If you keep that knowledge to yourself, then you’ll always be the only one that can handle it. Teaching your team how to do it may take up more time initially, but over the long run the team gets more productive. Isn’t that really what the job of development manager is? The real kicker is, opening the work up to other people might actually produce a better solution than you had in mind.
In all but the largest companies, a development manager who doesn’t write code isn’t feasible. It should not, however, be one’s primary duty. Pick the projects where you can most be of benefit. Internally useful work is a really good area to focus on. Sounds like making the team more efficient, doesn’t it. No matter what the project, use it as a way to spread knowledge around. If you do that enough, you might just have to stop thinking of yourself as a developer, too.
