Recently, when reviewing my old presentations, I went back down memory lane to my times as an Engineering Manager (well, technically the role was called a Tech Lead, but the responsibilities were closer to managing the team).
Now, as an Engineering Director, I've distilled that experience into ten core principles that have consistently brought me and my teams success.
The Context
In engineering management, there are some general good practices, but not all of them will work in every organization. It depends very much on the company's size, maturity, culture, and many other factors.
Before I share my working methods, here's the landscape I was in a few years ago when I worked as an Engineering Manager.
Back then, the company had a size of around 100-200 (during the growth period), with a total headcount of 30-40 in the engineering team. The company operated from a few countries, but all developers were co-located, working in an office-first culture. The product team worked from another country, so most of our processes were remote anyway.
I managed a team of 8-12 people and transitioned from a siloed group (one product, one backlog) to feature teams, where my engineers worked in three different domains, delivering their functionalities to a single application.
There was still a strong startup culture, so engineers could do some Operations work, copywriting, UI/UX design, and other non-engineering tasks. The hiring budget was limited, so the only way to grow the team was through intern or junior positions that evolved into senior roles over time (usually 1-2 years). Some people worked part-time, others were students who contributed during unusual hours. It was tough, but overall a great experience of async work, trust, knowledge sharing, and collective accountability.
Here are the principles that helped me to manage the team and make them successful, both internally and later in their careers outside the company.
Top 10 Principles for Running the Team as an Engineering Manager
1 - 1:1s
If I could pick only one critical practice for running engineering teams, that would be 1:1s. The team and I were very serious about these meetings. From the time perspective, I can say that if you do a great job here, you are already light years ahead of those who either don't do 1:1s or use them only for reporting purposes. You'll be surprised at how many companies and leaders neglect this practice.
Here are a few of my rules:
~45min meeting, once a week, with an absolutely-no-skip policy (in critical cases, reschedule it). Timing may change depending on people later on. But if you start with 30 minutes every other week, it's too short for a meaningful discussion and too infrequent to cover all the important things.
Reporting (how the task is going, when it will be done, etc.) is the last thing to discuss. You have JIRA, Asana, or daily stand-ups for that.
At minimum, ask for "three good things and three bad things." There is always something they appreciate, like, dislike, or need help with.
Ultimately, focus on their growth goals and how you can help them reach these.
An agenda is a must. I maintained a private 1:1 document shared with each teammate. We put things to discuss, important notes, and action points from each discussion there. It's great for discussion continuity.
When running our 1:1s, I shared a principle with my teammates: Make our 1:1s so good, full of feedback and quality discussions, that we don't need extra performance reviews. In a company that conducted such assessments every six months, this was a game-changer for me and the team.
My 1:1s were also an inspiration for creating a workbook: First Ten 1:1s for Engineering Leaders.
2 - Feedback for Leader
Even though I asked for feedback about my work during one-on-ones, it was always helpful to make a more official feedback request. I usually did that every half a year. No extra tools needed - it was usually either a Google Form or an email request from the Head of HR.
The key part in such a request is not to start with "feel free to share your feedback."
No, it's not optional; it's a mandatory task that each of your teammates is obligated to do.
The entire article and PDF/Notion/doc templates are available only for paid subscribers. You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!