The 3 systems I always use to manage my team
3 Frameworks that help me manage my team more efficiently.
Gut-Feel Leadership isn’t enough
Are you relying on gut feelings to manage your team? Intuition is important, but it shouldn't be the main driver for how a team functions or how decisions are made.
When engineers need to make a technical decision, they create ADRs (Architectural Decision Records), discuss the pros and cons, and ultimately select the best option.
But what about Engineering Managers? While we have metrics to monitor (e.g., DORA metrics), they don't always tell the full story, and not everyone is exactly a fan of them.
In this article, I share three frameworks that have helped me manage teams more effectively, regardless of the team's size or the company I was working in.
Create an SSOT for everything
How often has part of your team had discussions about project changes with other teams or your PM without documenting them?
Changes that should be shared with the entire team, or even people outside the team.
This has happened far too many times when I started out as a manager and it was really frustrating.
So I introduced what I call the Single Source of Truth (SSOT). For everything.
Ways of working, our projects, our team formation. If it’s something the team needs to know (and it’s not documented as part of the code), in my opinion there should be documentation that the team owns and maintains.
Now, I know documentation is hard to maintain, so what I mention here is aspirational and not always feasible for everything, BUT there are some cases that I consider non-negotiable:
Team Charter: Who’s on the team, who does what, our vision, and mission.
Ways of Working: How we work as a team. This should be agreed upon, documented, and revisited every six months. If we need to change something, we hold a “Ways of Working” session.
Project Proposals: A simple one-page document with requirements, scope, risks, and the "why" behind the project. This is shared with the team before any work begins.
Roadmap: A 6-week or quarterly plan outlining what the team will work on and deliver.
Create a predictable rhythm for team execution
I used to be a basketball player before my knees gave up and I got into engineering.
Our team was very low on budget but extremely competitive. We managed to get to the top 16 of the best European teams, and let me tell you it was not by accident.
We had an extremely rigid routine and schedule. Each day everyone knew what we needed to achieve, when our practices were, when our meals would be, and so on.
That allowed us as players to focus on getting ready for them and executing. There was rarely a conversation about when we’ll have a practice. At the start of the year we were told what is the plan and every now and then we adjusted it depending on the needs.
You see where I am going with this. I aspire for the people in my team to know in advance when they’re expected to be in meetings, what they need to do to be ready for them, and what times they can allocate to focus on their tasks.
In my opinion the actual cadence is not as important as having a cadence to create that rhythm of execution and delivery.
Below is an example of how this can look like as a starting point, documented in your WoW SSOT and revisited every few months.
Create a RACI for it
I was working at a startup where we had too many “chefs in the kitchen”. Everyone, from the CEO, our CTO, our Product Manager, to each and every engineer had strong opinions about what we should be working on.
This is a great challenge to have, I did not complain one bit, but we had to find a way to make decisions and at the same time make sure that people understood the extent of their involvement.
Another instance at that same company was that we as a team had certain expectations of another team, which were not being fulfilled and we were finding it hard to keep that team accountable to commitments we were both making to achieve our goals.
The same solution solved both these challenges. A RACI document.
For each major task that had to be delivered we clarified who is Responsible (does the work), Accountable (ensures the task is done), Consulted (provides input), and Informed (needs to know).
At that company, we also required it to be signed off by our CEO to create that extra commitment to it, but of course it doesn’t need to be a CEO, any more senior leader overseeing the project/task can do.
This document allows every stakeholder to know exactly how they’re expected to be involved, what their responsibilities are and have an explicit agreement on that with the rest of the team.
TL;DR
Create an SSOT for everything: Centralize information to reduce confusion and avoid scattered communication.
Predictable Cadence: Build a consistent rhythm for meetings, work, and feedback to create stability and improve performance.
RACI: Clearly define roles and responsibilities to avoid confusion and improve decision-making.
💡 Enjoyed this post? Subscribe for more leadership tips!
🎉 CodeCrafters which helps you become a better Software Engineer using my favourite method! Build your own Redis, Git, Kafka and more from scratch. Use my partner link if you want to get 40% off.
🚀 Check out my Leadership Accelerator program. Let’s set up a free intro call and chat about how I can help you thrive in your role.