Lessons from a year as an engineering manager
Note: This post is also available on Medium.
I entered the world of engineering management by accident. You could say I fell into it. I never sought to become a “manager,” — or even a leader per se — I just wanted to do good work. I wanted to make things of quality, things that people would find useful and valuable. Things that people would love.
No matter where you are, if you do this kind of good work long enough, and it gains traction and starts to get noticed, inevitably you may find yourself in a kind of “creator’s dilemma”: taking on more and more responsibility until you no longer find yourself doing the creative work that got you into the position in the first place. Here you face the threshold of one of the most important decisions you will ever make: let go and embrace the opportunity to lead, or dive back in and continue doing what you already know and love. There is no right decision, but you must make one.
To do good work in the world of software, you have to build a team of people who want to do it with you. After that, you have to enable your team to help you define what good work — both for you and them — even means. And, finally, you have to put the systems and support structure in place so that your team can actually do it. When you’re hyper-focused on doing good work—almost to the point of near-myopic dedication — all of this can happen so gradually, so naturally, that the creation of your own making sneaks up on you. And next thing you know, you have the word “manager” in your title, not because you ever sought to become a manager, but because it just happened. It was the natural outcome of doing what you felt needed to be done. All because you wanted to do good work.
Anyway, this is what happened to me. One day I woke up and found myself leading a small team of developers on an admittedly small, but high-profile project. Not long after that, I was being offered the official title for a job that I was mostly already doing. I accepted the offer because it felt like the natural thing to do — a new opportunity for growth, a new way to challenge myself and push myself outside of my comfort zone.
A year has since passed, our team has now tripled in size, I’ve hired developers and, admittedly, lost developers, and learned so much about myself and the job in the process.
As a software developer, I honestly didn’t understand what managers even did on a day-to-day basis. Before I started working in a large organization, I held an admittedly cynical view of middle management — mostly as the people who took credit (and compensation) for work done by others. This is, of course, what bad managers actually do — ruthlessly build empires, absorb credit and pass on blame. Unfortunately, for this reason bad management is also highly visible, whereas good management often goes unnoticed. In this way, you could say that management is a bit like plumbing: when it works well nobody thinks about it, but when it breaks down it becomes a huge problem for everyone.
What follows are just a few of the lessons I’ve learned over the past year in my management adventures. I share them with the hopes that others — particularly other engineers becoming managers, or perhaps those just contemplating the move — might find them of value.
Engineering management is not engineering.
The two jobs are drastically different, and the earlier you come to this realization the better off you will be. Not accepting this fact was probably my first big mistake. Long after my title officially changed I still found myself occupied with building features and writing code. Yet, because my time was now split with managerial duties, I was less than half as productive a programmer as my former self. Instead of delegating important features or tasks to others on my team, I continued to pile them on my own plate. I justified this by saying to myself that I understood the architecture best and would be the quickest to produce quality results. The truth is that I was robbing other developers on my team of the opportunity to grow and contribute, while simultaneously blocking them with my significantly slower pace. Don’t do this.
Stay connected to the craft.
On the surface, this may appear to be the exact opposite advice of the lesson above. But the truth is that, while I don’t believe a manager should spend all of his or her days programming, I do believe managers should continue to write code and maintain their technical prowess. First, keeping on top of your game will help you be a better technical interviewer. You will be able to better weed out candidates whose resumes might be riddled with technical jargon, but can’t back their surface claims with deep understanding. Second, it will help you maintain “street cred” with your team. Being a good developer is likely part of the reason you became a manager, and software development — being a meritocracy — is founded on respect. Don’t lose it. Last, and most importantly, maintaining your technical skills will help you build and maintain empathy. You will be better situated to understand the hidden nuances of the challenges your team faces on a daily basis.
I’ve discovered two ways in which I can continue to write code while not being a hinderance to anyone else on the team. The first, and most obvious, is just to continue working on side-projects at home. I set aside a few evenings a week — and a few hours each weekend — to write small experimental projects and learn new technologies.
The second, and more valuable, way in which I continue to write code is by contributing to “non-essential” projects that boost the productivity of the rest of the team. Typically, these are small tools, libraries and utilities that just help make everyone’s job a little easier. I can take my time with this projects and feel comfortable that I’m not blocking the rest of the team, and when complete I still get that “hit” of satisfaction for having made something new.
Hiring is one of the most important things you do.
It also takes a lot of time! You will hear this advice re-iterated again and again, but I suppose it can’t be overstated. A diverse team full of skilled, creative and mostly self-managed developers can achieve greatness — and almost entirely on its own! The cost for building such a team is a significant investment of time and energy on your part. Be prepared to make that investment.
When I first started as a manager, our hiring process was not nearly as organized or documented as I would have liked it to be. Over the course of several months and many interviews, my team and I diligently documented, streamlined and defined our process. We wrote down everything in an internal GitHub wiki, from phone screening questions to the questions and problems we agreed to ask during technical interviews to the qualities and skills we might look for in prospective candidates. Our process is now much better than it once was, but I like to think of hiring as a kaizen-style practice; there is always room for improvement.
In the course of the past year, there are two pieces of hiring advice I’ve found most valuable. Both have to do with developing and trusting your intuition. The first I stole from my years as a single man in the dating scene: If it’s not a “hell yes,” then it’s a “no.” If you and you’re team are not excited — nay, ecstatic — about the prospect of working with someone, don’t hire that person. You will regret it, and getting out of that relationship is a much more difficult process than getting in. The second piece of advice I stole from something I once read about Mark Zuckerberg’s hiring process: If the tables were turned and you found yourself interviewing to work for the candidate, would you want to do it? If the answer to this is “no,” it’s a non-hire.
Respect your team members’ time.
For instance, be the front line in your hiring process. I make it a point to do all of the phone screening and reviewing of resumes myself. I might even start doing much of the first-round interviewing myself as well. I don’t believe it’s worth the time of the other developers to bother them with these tasks. They already have a lot of work to do, and the more meetings they have the fewer unpunctuated blocks of time they have to stay focused and productive in actual software development. I believe my team’s time is both more valuable — and more fragile — than my own. As any developer knows, a single 5-minute interruption can wreak havoc on an entire morning’s productivity.
Instead, I believe there is plenty of time later in the interview process to bring in the rest of the team. This allows them to focus on choosing from only the best candidates.
Everyone’s motivations are different.
It’s your job to figure out what they are. Most developers are not that highly motivated by money. Bonuses and pay raises — while necessary — are probably insufficient to keep most members of your team happy. Instead, developers tend to be the kind of people who have an absolutely fundamental need to be continually learning, growing and building new things. How this manifests itself, however, can vary greatly between people. Some developers are product people; they want to feel that they are building software that thousands or millions of people will use every day. Some developer’s developers; they want the recognition and collaboration opportunities of contributing to highly-visible open-source projects. Some are mad scientists; they want to be constantly learning and experimenting with the most bleeding-edge programming languages and technologies. Some are natural leaders; they yearn to be team leads, architects, or even managers themselves one day. And some are collaborators; they just want to feel the family-like camaraderie that comes from being a member on a high-performing team working towards a unified objective.
One area in which I know I can use improvement is my ability to get my team to readily share their hidden motivations. Many software developers, including myself, are natural introverts. They may say things are “fine” even when they’re not, mostly out of reluctance to share their true feelings. I honestly believe I lost a great developer this way, because I didn’t dig deep enough to see that things were not as fine for this person as they seemed. I’m not sure I could have prevented the loss even if I had known, but at least it would have come as less of a surprise.
One-on-ones are the most important meetings on your calendar.
Use them to listen, listen, listen! One thing I like to reiterate to my teammates is that our one-on-one meetings are their meetings, not mine. They own that time and they can set the agenda. My job is to listen. I can’t say I’ve always made each of these meetings “feel” that way, but I continue to strive for it. This is also why I never try to cancel a 1:1 (unless I’m out of the office), because I truly believe it’s not my meeting to cancel.
I try to prepare ahead of time for my 1:1s and take good notes. Some days this is easier than others, and I’ve occasionally let my preparedness fall by the wayside. But, again, I try not to. Keeping a private record of what was said in 1:1s and then observing over time whether this record is changing for the better is one of the best indicators of whether I’m doing my job right.
A good 1:1 meeting is where the truth is laid bare. If you follow an agile process, then sprint retrospectives might be another time and place where this happens, but often people are more comfortable sharing their true feelings in a private setting. Use the time wisely!
Trying to be a good manager is not easy. Some days I wish I could just dive in and go back to straight-up programming. One day I might just do that. But for now, I’m grateful for the opportunity to learn, grow, serve and just try to be a better person. Ultimately, that’s what I think leadership is all about.