Engineering Leadership Principles
I have been working as an Engineering Leader for many years now. Here are the principles I developed over time that helped the teams I worked with to get things done
I love reading and learning about engineering leadership.
I've read many books on engineering management, programming techniques, and product development in the past two years. I'm always trying out different techniques to help the teams I lead work efficiently and effectively.
Thanks for reading Software Engineering! Subscribe for free to receive new posts.
In this article, I've shared my thoughts on what's important and what isn't. While my ideas aren't all new, I've combined what I've learned with my own experiments to create something original.
I hope that my approach can help others who are currently working in engineering leadership or those who aspire to start.
Great Product Teams are composed of a Product Manager, a Designer, and Engineers with a total size between 4 and 6.
Single-threaded leaders (STL) are a crucial ingredient for high-performing engineering teams.
Teams are small, stable, and long-lived, allowing team members the time and space to develop their working patterns and dynamics.
Each team has a clear purpose and a bounded context. The team owns everything inside the bounded context from end to end → Problem → Conception → Design → Development → Monitoring & Results.
Make sure the team is learning what they did wrong and how they can improve moving forward every week. They should have the autonomy to change almost everything they work to improve.
You only get value from projects when they finish. To make progress, you must ensure that you are completing your projects.
Waiting on feedback from others is one of the most considerable delays in workflow. Look up for “waiting” columns in Kanban (Waiting for Review, Waiting for QA, etc …). Those are usually the most obvious places to optimize your workflow.
It's possible (and I recommend it) to ship something every week.
Multitasking is a very effective way to get less done.
One of the best predictors of short lead times is the small batch sizes of work.
Subject to every company stage, but, revenue-protection work is equal to or more important than revenue-generating work. Ensure the team is working on the system’s stability and long-term health.
Before starting a new project, ensure everyone is aligned on the problem, goals, and a rough solution idea. Every detail about that project should be concentrated in a single place. Some call them “PRD”s.
An MVP isn't a product with 100 unfinished features. It's a product with only three features but done perfectly.
Feature flags and canary releases are among the best and cheapest enablers for frequent and safe releases.
Each “feature” should have a goal that can be measured. Iterate on a recurrent basis if it's on track or not. Take action if it doesn't. Kill the feature if necessary.
If you are not shipping features that are constantly improved over time, you're too slow or working on things that are too big.
One of the best sources of new ideas is the engineers from the team working on that specific domain. Encourage them to share their ideas and offer some space so they can help design new features.
If you don't have a formalized incident management and support rotation process, the engineers in your team will probably have a miserable life.
As a leader, you must encourage engineers to list and rank the most important tech debts that require work. You must find space for them to work on those tech debts. It's a collaborative effort between you and the product manager.
Code Reviews can be extremely useful or extremely harmful if the team is not aligned with why they're doing code reviews.
Daily Meetings are overrated. The most important thing is to ensure the team is communicating daily. The how is up to them. Enabling this communication is the engineering leader's responsibility.
Pair programming, mob programming, or team swarming are among the most effective ways to ship great quality software faster than you think.
A product team must own the system or subsystems they are responsible for. Instead of structuring teams according to technical know-how or activities, organize teams according to business domain areas.
RFCs are a great way to share knowledge and ensure alignment among multiple teams.
If engineers spend more than 2h a week in meetings, something is very wrong and can be improved.
Teams working on multiple domains lack ownership and the mental space to understand and keep the corresponding systems healthy.
Adding people to a team disrupts that team's gelling process. I prefer rapidly growing a team to the desired size instead of adding new individuals slowly. The org will never stop growing, but each team will.
I prefer shifting the scope instead of moving people around. This avoids re-gelling costs and preserves system behavior.
Being a Manager
As a manager, 1:1 is one of (if not the) most important meetings you have. Be prepared for each one. A shared 1:1 document makes it easy to recap what you discussed previously and helps with your direct report goals.
1:1s are among the most misunderstood and poorly handled types of meetings. It's all about making a human connection with your teammate. Everything else can be adjusted and doesn't require a strict format. Ensure you're meeting with everyone frequently and listening to what they say.
Ensuring everyone in your team is aligned with the team goals will be one of your job's most important and difficult parts. Every time you think everyone is on the same page, communicate again, just in case.
Being a manager will be extra difficult for you if you're not an organized person. It's good to have weekly time to plan what you're doing, what you should review, and who you should talk to.
Performance reviews do take a lot of time. Plan to spend 4 to 6 hours for each direct report. When done correctly, it helps to set direction and clear expectations and support your direct reports career while simplifying work to be done when advocating for someone's promotion.
Encourage your team to communicate using a public team channel instead of private chats. Lead by example by avoiding sending messages privately unless it's necessary.
Minimize team distractions during the workweek by limiting meetings, reducing emails, assigning a dedicated team or person to support queries, etc.
“Minimize cognitive load for others” is one of the most valuable heuristics for good software development.
Send an email/message to the team and the leadership sharing what your team did the past 1-2 weeks, your plans for the next period, blockers & lessons learned.
For now, that's it. I'm in the hope this is valuable to someone. I'll continue learning and changing what I think is worth doing.
I would love to hear about your principles to be a better leader!
Usually, one Product Manager, Product Designer, and 2~4 Software Engineers. For me, that's the ideal size for a high-performing team.
A single-threaded leader is a leader who is 100% dedicated and accountable to a specific product, such as a mobile application, customer account, or search capability in an e-commerce store. The single-threaded leader is responsible for turning strategy into actual results, and they are empowered to do so.
This is usually achieved in the form of a retrospective that you should do every two weeks or even every week. I would start twice a month and improve until you can do a retro in 20 minutes.
Recommended: The Wall of Technical Debt
Recommended: Code Review
Recommended: Swarming as a Kanban Team
Meetings as pre-planned and/or recurrent meetings. In a remote environment, I strongly encourage pair programming, but those are not meetings. This is quality time working. In that 2 hours cap, I include dailies, weekly meetings, reviews, retros, etc. Anything that is recurrent. Engineers should have time to work, and meetings completely kill momento.
Recommended: Event Loops for Managers