How I Led Teams As Engineering Manager
My Top Ten Principles for Running the Team
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.
3 - Public Goals for Teammates
At that time, the company didn't have a clear goal management system, OKRs, or a cascading structure from the top down to each individual. With that in mind, I wanted to create a clear career progression for each of my teammates to help them grow, be successful, and perform at a high level.
The system was simple - I came with the proposition of 3-4 personal goals that somehow aligned with the team's and organization's success. And I asked people to bring their 3-4 propositions as well. Out of this pool, we decided what the 3-5 goals for the next half a year would be.
The crucial thing was that goals were written down in a public document, accessible to every employee in the organization. There was no complex tooling behind that—just a Google Doc, with clear bullet points and some rationale.
The goals were reviewed during our 1:1s in the context of how I could help people achieve them, what blocked them, what support they needed, etc. Making the document public was like a commitment to achieving them.
4 - KPIs
Over the years, the team had different goals and metrics, but we also tried to keep track of KPIs - key performance indicators that guided us through the entire journey.
We had three of them:
Crash-free, later SLIs/SLOs
Number of releases per month/week
First contribution time - the time it takes for a new team member to push changes to production.
The rule was simple. Once we optimized one of our KPIs, the others couldn't decline. When moving the team from bi-weekly to weekly or on-demand releases, our crash-free rate couldn't fall below 99.9%.
Why these KPIs? They drove the culture we wanted to build: quick iterations, high quality, and team flexibility. These were strengths the team was proud of, and they allowed us to be a good partner for the product organization.
5 - We Release Whenever We Want
In motivating the team, there should always be something that makes them feel unique. Our KPIs were partially that. But we also needed a true differentiator, something that made us feel special.
In a slowly transitioning QA culture from Quality Control to Shift-Left / Quality Assurance, we made a bold move: "From now on, we will release on Fridays." Did it make sense? Yes, no, maybe...
From a time perspective, this half-joke, half-crazy idea evolved into something truly game-changing. Our processes hardened, self-confidence went up, and accountability settled in for good within the team.
Not only did our crash-free KPIs remain stable, but the team also introduced better telemetry, controlled rollout processes, feature flags, and other improvements. This opened the door for future continuous delivery and on-demand release processes.
This was very much aligned with the Product Operating Model and changing the way the product is delivered, as described here.
6 - Data First: Understanding Product Usage
In the company, we had a dedicated BI team, some analysts, and our product managers were fluent in using all analytics tools.
Yet we introduced a rule - everyone in the team must possess basic knowledge about how to use Mixpanel (our primary product analytics tool back then), and no matter if it was specified in a task or not, we were all expected to bring some basic telemetry to the products we built.
Every time engineers built something, they added basic events, such as screen launches, button clicks, conversions, errors, and some custom events. In addition, each of them was tasked with building simple dashboards to visualize the data behind their tasks.
We simply wanted to understand our product more quickly. And we wanted to know that before analysts and product managers. For me, there was nothing more exciting than seeing the first 10, 100, 1000 customers using the functionality I built. Later on, this became a cultural cornerstone within our team.
Such an approach helped us shift the mindset from "I build features" to "I solve customer problems." It wasn't just understanding the value we deliver. It also empowered the team to turn off features if the data showed something other than expected, or to be okay with removing features that had taken months to deliver but brought zero or negative value.
Inspired by my team's culture, I wrote Product Analytics for Engineering Leaders.
7 - Data First: Tracking Technical Excellence
I always loved observing data dashboards and using the insights to drive my decisions. Product analytics is just the tip of the iceberg. The team was also expected to monitor SLIs/SLOs and other technical telemetry.
In team management, the true game-changer for me was Data Studio (now known as Looker Studio) from Google. It's a super simple concept - you have a data dashboard with various data sources, including CSV, database, Google Sheets, and many others.
My teams and I used it for most of our goals and KPIs. We tracked things like:
Crash-free ratio
Language migration process
Scoring of meetings
Number of QA issues
Number of releases to production
Time to react to incidents
Testing flakiness
Cloud costs
and many others
Depending on the case, data was imported as a CSV file from external systems, read directly from the BigQuery Database, or manually managed in Google Sheets.
Dashboards were reviewed weekly, during Guild meetings, team meetings, or during one-on-one conversations.
We also presented them to senior leadership during monthly All-Hands meetings.
These experiences inspired me to write Practical Solutions to Track Your Goals.
8 - Public Education of Tech Stuff
Working with data and our understanding of the product, tech, and team's goals pushed us into a new landscape. Since most of these things weren't just opinions but real facts, we started sharing them openly with non-technical stakeholders.
Our dashboards were presented during monthly reviews. We wanted people to know not only how the migration from one language to another was progressing, but also why we were doing this.
Such a shift changed the narrative, especially when it came to technical tasks. Instead of begging for an additional day for tech debt work, the team presented the current situation, including progress, risks, rationale, and its impact on the company.
The more senior management knew about our challenges, the more it became a business decision to invest in working on technical debt.
This is how a significant portion of our “tech work” ended up in regular product backlogs. This also inspired me to write Optimizing Your "20% Time for Technical Debt".
9 - Quality Comes First
I'm not sure if this is just my experience, but discussions about priorities are often unclear. On the one hand, it's clear what's important for the organization. Still, usually at the lowest levels of management or among individual contributors, there is always some uncertainty about what should take priority.
There are team priorities, dependent team priorities, critical changes, last-minute changes, incidents, and others. There is also a common belief that if it's not clear what the #1 priority is, people will buckle up and solve multiple things at once.
To solve this issue, as a team, we made it clear: no matter what, quality-related work comes first. Meaning, if our error budget of 99.9% ran out, we stopped product work and started fixing. If our KPI said "we cannot have more than 10 QA issues open," we focused on that first. If there was an incident - we did the same.
Easy to say, hard to execute. That's why all teammates received clear instructions: "In case of pushback, blame it on me." This gave the team enough authority to focus on what mattered most. Side note: I saw multiple issues addressed this way, and in my decade-long experience, there was no single PM or any other business stakeholder coming to me and complaining about it. 😉
10 - Principles-Driven Leadership
Most of the things described in this article were actual principles, repeated over and over again:
We release whenever we want.
Educate on your tech stuff until the CEO starts asking you about how it's going.
1:1s are for you.
Quality Comes First.
Data-Driven Culture.
Measure what you build.
1-week onboarding.
Not all of these are universal. Even in our case, some needed to change over time as the company matured or when the org's culture was in complete contradiction.
Still, the important part was building a set of values that gave the team guidance, empowerment, and a feeling of uniqueness. I truly believe that such clarity is something that can elevate you and your team to the next level.
I also wrote about principled leadership in the past.
Final Thoughts
These ten principles weren't just management techniques—they became the foundation of a team culture that produced results and developed engineers who continued to thrive in their careers.
What are the principles you use to run your engineering team? I'll be thrilled to hear your story - let me know in the comments or via direct message.
You can also share your thoughts here, as the article on Practical Engineering Management. Look for the other leaders’ stories for inspiration.
Complementary Articles to Help You with Creating Your Principles
Here are more articles from Practical Engineering Management that can aid you in implementing the Leader-Leader model: