Six lessons from my first six(ish) months of engineering management
I made a significant career change last March: I switched into engineering management. I’d been an individual contributor for seven years and needed a new challenge. I soon realized, though, that there was a significant gap between my assumptions for the role and reality. Here are some of the major lessons I’ve learned. I hope you’ll find them useful if you decide to transition into management.
Lesson 1: Effective technical writing scales
The best way for front-line managers to expand their influence and demonstrate impact is effective communication. At first, I imagined myself negotiating with my bosses to green-light engineering projects, but that has been rare. My most important communications have been one-to-two-page documents that helped my team and larger groups solve problems autonomously.
A clear, shared understanding of the problem empowers teams to maximize group intelligence and converge on an optimal solution quickly. Collective intelligence and psychological safety are two necessary prerequisites for developing high-performing teams.
So, how do you write an effective document? I follow these principles:
- Know your audience
- Communicate context through the 5 W’s (Who, What, Where, When, Why)
- Keep it short and simple
- Give yourself time to iterate
Know your audience
Technical detail should be appropriate for the stakeholders and the problem. Start by asking yourself, “What is the purpose of this document?” Is it to inform a group of a technical decision, to convince a decision-maker, or to solicit advice from a peer? If you actively think about your audience and their interests, you’ll encourage more productive and focused discussions.
Communicate context through the 5 W’s (Who, What, Where, When, Why)
I answer the 5 W’s early in my documents because they often answer the reader’s most pressing questions. Determining who, what, where, when, and why (and “how,” when appropriate) summarizes even the most difficult problems — especially for stakeholders who may not be familiar with the details.
Keep it short and simple
No one wants to read a 15-page document when two pages would suffice … and they won’t. Most people scan a document when they first open it, calculating whether they should read the whole thing. I try to maximize my chances of success by making it as concise as possible. I’ve struggled to keep my documents succinct, but I found Brianne Hughes’ short talk to be helpful as a framework for the writing process. When in doubt, follow the design principle: Keep it simple, stupid!
Give yourself time to iterate
Most documents I write start as a messy brain dump of all my thoughts. I then write in chunks and make incremental improvements as I flesh out ideas, organizing my main points into a clear structure. Along the way, I clarify my pitch in one-on-ones with teammates and in other informal settings, taking time to rewrite and polish according to their feedback. I make my writing process a deliberate endeavor and allocate adequate time for it.
Lesson 2: The process is more valuable than the result
The effort spent writing a good document is even more valuable than the document itself, because clear writing encourages clear thinking. The focus and critical reasoning I use to produce a concise document gives me insight that helps me and my team make better decisions.
Avoid relying on slide decks to summarize important information, as this shortcut leads to a superficial understanding of the problem.
https://twitter.com/paulg/status/1462073230932549634?s=21
Corollary: Revisiting your roadmap often is the key to a consistent workload for your team
Arguably, the most valuable document that managers can produce is the roadmap. A roadmap is crucial for tying together the higher level vision to the strategy the team will take to get there. It’s the yardstick your team’s performance will be measured by.
“What is the team working on in the next six months? How will they hit their milestones? What is the impact of project X?” Your roadmap should answer these questions.
But plans change all the time as new information propagates across the organization. A new competitor has entered the market, a key business opportunity has been identified, or the company is changing its priorities — whatever the reason, often your original plan will be made obsolete.
Embrace change as your only constant. You’ll need to adapt by discarding parts of your roadmap, reprioritizing projects, and creating new line items. I plan ahead for multiple scenarios, preparing hypothetical decision trees and sequencing the projects the team will commit to if some potential event occurs.
A great manager once told me, “Our job is to have a backup plan for the backup plan for the original plan.” You don’t want to be scrambling at the last second; otherwise, you’ll negatively impact team morale and focus.
Lesson 3: Be generous with your estimates.
On the theme of roadmapping, one of the bigger mistakes I’ve made is not adding adequate buffer to project estimates.
Here is a painful example: Our team was about to reach a milestone in a complex engineering project. After we started the sprint, two unexpected things happened. First, a senior engineer on the team was tapped into an on-call support rotation, making them unavailable to work on sprint tasks. Second, the subject matter expert needed to take emergency leave. Other details had escaped my attention: The remaining engineers were new to the team, our division was having a full-day offsite, and some staff were taking planned vacations in subsequent sprints. The result? We missed our deadline.
While you could dismiss that as simply bad luck, the fault rested solely on my shoulders. Managers must prepare for the unexpected; by not accounting for worst-case scenarios, we weren’t meeting our commitments for the project and I jeopardized the credibility of my hard-working team.
It’s tempting to give optimistic estimates when presenting the roadmap to a wider audience — people will be excited by the promise of what’s to come. But if you can’t deliver on those commitments, you’ll simultaneously disappoint your bosses and burn out your team. Learn to “underpromise and over-deliver.”
How much buffer is necessary? It varies based on the team’s capabilities and your accuracy in accounting for unknowns in risk management, but I generally add about a 40–60% buffer until I’m confident that the team will hit the deadline.
Lesson 4: Don’t “peanut-butter” your resources
Be mindful of how many commitments your team is juggling. I was put in charge of a team of senior engineers — a luxury that few first-time managers have. Working with a highly skilled team makes it easy to deploy engineers to different problems and spread them thin.
Delegating multiple tasks to each engineer forces them to context-switch frequently, which we all know is expensive. The act of delegation assigns responsibility to that person. If they become overwhelmed by too many tasks, their sense of responsibility can make it hard for them to ask for help. No one wants to feel like they can’t do the work, so the engineers will try and slog through it in isolation, despite not being aware that they’re exhausted and slowing their pace.
As a manager, you’ll need to observe your team’s energy levels and calibrate the incoming workload accordingly. To break down silos, you’ll need to encourage your team to use their voice and have them drive what work can get done and how. The team needs to be able to discuss the scope of remaining work, delegate tasks to one another, pair program through thorny problems, and push back on you if the workload is unrealistic. Building a team that takes ownership and holds each other accountable keeps them cohesive and focused, providing a set of necessary checks and balances to prevent you from encumbering them with too many tasks.
Lesson 5: Don’t delay in giving critical feedback
This lesson was the hardest one for me to learn, because it forced me to realize that not every interaction or decision we make as managers will be a positive or a pleasant one.
I’m someone who doesn’t like to be micromanaged or nit-picked. As a manager, I externalized this by waiting until I saw enough instances of a problem or growth area that I could classify it as a pattern. Only then would I bring it up with a direct report. This was a mistake — although it wasn’t clear to me at first.
The longer you wait to discuss a specific action or event with your direct report, the harder it will be for them to draw a connection back to the problem and work on fixing it. It’s important to be compassionate and respectful because it’s a delicate matter, but we owe it to each other to be honest. Timely, meaningful feedback is necessary so we can course-correct and improve in our work.
Giving feedback about self-directed work can be tricky. When you give your team freedom in how they execute, you must establish particularly clear rubrics about what you want them to achieve. I’ve learned the best way to help people grow is to be upfront about my expectations, observe and assist while they execute, and discuss my observations in regularly scheduled one-on-ones. Some things can’t wait for a regular meeting, though: If some disruptive event occurs (a bad client call, or skipping steps to resolve a P1, for example), I quickly schedule a meeting to discuss and reflect, so I can help get us back on track.
Note: I didn’t figure this out entirely by myself. Carta’s new manager accelerator program gave me a curated set of Udemy courses and access to a leadership coach via PlatoHQ, and paired me with other managers to practice conflict management and coaching. It was a fantastic experience that set me up for success, and it’s a major reason why I think Carta is a great company to work for.
Lesson 6: Always be recruiting
Early on, a senior manager offered advice that felt mysterious but proved to be prescient. When asked how best to grow a team, he taught us his mantra: “Always. Be. Recruiting.”
Setting up a recruiting pipeline is a significant undertaking, and can take anywhere from 10 to 40% of a manager’s time, depending on the company. Here’s my own breakdown of tasks to illustrate:
- Identifying skill gaps and the immediate / long-term needs of the team
- Requesting and getting approval for headcount at the requisite level
- Drafting, posting, and publicizing job descriptions
- Building a queue of candidates via sourcing and direct outreach
- Training the team to calibrate and give fair interviews
- Interviewing candidates via a phone screen
- Working with recruiting to schedule candidates for the onsite, and handling delays
- Final round onsite interviews
- Preparing hiring packets and getting approvals from the hiring committee
- Waiting for candidates to finish interviewing with other companies
- Completing final negotiations with candidates and determining start dates
- Building a 90-day onboarding plan and ironing out last minute wrinkles
Given such a list, it’s imperative to start sourcing before you get the headcount approved. If you wait until you have the official headcount, you’ll waste valuable time in the initial stages of building the pipeline. Since the job market is so hot right now, it can take months to recruit a single high-potential candidate. It’s significantly easier to keep an active pipeline warm than it is to start from scratch every time.
In addition, understand that headcount allocations will change to reflect shifts in business priorities. In other words, if you don’t use it, you lose it. In my case, I took too long to get my pipeline started, and by the time I was ready to close on a few candidates, my headcount was re-allocated to a team which had greater need.
These are the biggest lessons I’ve learned in my tenure as a first-time engineering manager. I’m excited to grow and learn new lessons in the next six months, and build a great product with my team while I’m at it. If you’re interested in switching into management, check us out!
Note: I’ve reposted this article to my personal blog. If you’ve enjoyed my writing, check out some of my other posts!
