How It Started
When I got my first ever management gig, I overloaded on anything I could find around Agile. Looking back now, this wasn’t because I wanted to understand the difference between Scrum and Kanban but likely because it was the first thing that popped into Google when I started to do my research on how to run effective teams.
My career to that point had been filled with managers of different styles. Some were “old school” micromanagers who assigned me to work personally and consistently checked up on me and my progress. Some were the opposite, slightly more laid back and looking for someone else in the team to do that role with the hope that we were doing the right things because they, in turn, hadn’t heard anything negative from their boss.
Therefore, armed with this knowledge, my initial first few months of being a manager consisted of me stumbling upon subjects like Kanban, limiting WIP, splitting user stories and the various other tools of the Agile toolbelt. It set me up to have a 10 year history of dicussing topics about Lean and Agile, but I always felt like something was missing.
When delving deeper into the Agile rabbithole, one area that stuck with me the most was servant leadership. Servant leadership wasn’t something I had seen a lot of in-person, so naturally wanting to be different, I felt quite strongly that it would lead me to become a better manager. How can you go wrong when the main ethos of something was to empower people and help them perform to their maximum.
However, after being a “boss” for over 10+ years I’ve realised you can’t be a servant leader 100% of the time. It just doesn’t work and doesn’t lead to building successful teams.
Which begs the question; what basic boss formula do you follow?
As a manager, you need to adapt your style to whatever situation you may have gotten yourself or your team into. If you are leaning 100% into one particular style, you leave yourself open to not being able to fully execute on a huge amount of manager problems that are likely to come your way. In my opinion, one of the biggest blockers to a new manager not growing is the lack of appreciation for the fact that there are a number of tools a manager must be able to use to solve problems.
Let’s take three, somewhat common, engineering examples and see how we would collectively act in these circumstances.
The team that is struggling 😣
You’ve noticed one of your best squads, Watermelon, is starting to struggle in their weekly sprints. They aren’t confident in delivering consistently as they keep getting caught off guard by unknown unknowns.
How would you handle that as their manager? Would you call an emergency meeting and run them the riot act? Would you give them some ear time to understand what is worrying them? Would you leave them alone?
The high performing engineering manager 🚀
Sally is crushing it. Her team is one of the most consistent in the company and although they do have their tough times, they are consistent when it comes to getting work done and delivered to the customer. She has plans for all of her direct reports and she is looking at promotion to the next level within the next 6 months. She is a star.
How would you handle that as her manager? Would you spoon-feed work to her that is well-formed so that she knocks it out the park? Do you throw the messy and ambiguous tasks her way to help her grow? Would you leave her alone?
The newly promoted engineering manager ⭐️
Franc has dabbled in management in the past but this is his first full-time management gig. He has a solid head on his shoulders but you know that the team he is taking over has a few challenges. Your first few 1-1s with him are positive, but after checking in with the team they aren’t enjoying it as much as he thinks.
How would you handle that as a manager? Would you throw Franc some books and tell him to get on with it? Do you sit with Franc during 1-1s and talk about certain JIRA tickets you need to be done? Would you find Franc a mentor of someone who has been through this same thing recently so they can bounce ideas off of? Would you leave him alone?
Three simple examples; hundreds of possibilities in how you could handle those situations.
Giving the Watermelon squad some ear time may lead to tempers being lost and trust eroding right in front of your eyes. Leaving Sally alone as she is a high performer may lead her to plateau and becoming bored; so she leaves. Sitting with Franc and going through JIRA tickets could lead to him being dependant on you to get stuff done in the team.
Those are just three examples of different challenges that managers get on a daily/weekly basis. So while a basic boss formula will not solve all of those challenges for you… what it might give you is an operating model for you and your team to refer to during challenges.
So, what is this suggested formula?
25% - You are the boss.
50% - You are the peer.
25% - You work for them.
Think about a direct report you may have (if you don’t have direct reports…think about your relationship with your manager) and think about your working week with that person.
25% of the time you are their boss; what does that mean? What that means is you are asking them to do work. To be crystal clear it means that you, the manager, are specifically asking your direct report to do “stuff”. That could be a wide number of things in your org but it needs to be explicit that this work is coming from the manager to the report.
In my experience, some managers shy away from this 25% as they see it as being a micromanager, reducing autonomy or becoming a pointy haired boss. You get paid to get stuff done and it needs to be made clear to your team that sometimes to get stuff done you will need to ask for tasks, stories, projects or any other currency of work to be done to move the company forward.
Don’t shy away from being their boss.
50% of the time you are their peer; what does that mean? You are both likely working in the same field but you have different experiences of orgs, systems and products that you have built over your professional years. Share your problems with each other. Open up a Miro board and begin drawing with each other. Ask challenging questions to each other and work on solutions to problems; together.
This is the most fun part for me, as someone who has imposter syndrome quite regularly. I learn from you and you learn from me. What’s not awesome about that?
Don’t forget that you can learn off your reports as much as they can from you.
25% of the time you work for them; what does that mean? You can phrase this in whatever way you like but the simple fact is this is the biggest taboo area of your relationship with your direct report and it’s completely down to miscommunication and how you, a leader, appear to your team.
Simon works in your org and has a problem around how to best design a new service. He probably needs help from one of the Principal Engineers in the company but as he is new, he wants to try and solve the problem first. Three days pass and finally he asks you for help. Why does he wait three days to ask for help? He assumes you are “busy”. It’s your job, as a leader, to make sure you are clear that you are there to also do work for them.
Don’t let your team think you are too “busy” to solve problems for them.
OK. With that basic boss formula, I am massively oversimplifying the common day to day problems within an engineering managers life. For example, this may work for folks who report to you but how about your skip levels? What mode should you operate under when working or having 1-1s with folks who work for your direct report?
The answer is never clear with management, and that’s the amazing thing about it. You can work for 15+ years and think you have got it all down and then someone pings you on Slack and you are stumped on how you can help them.
Having this discussion, open and honestly with the folks you work with clears up so many unspoken rules, assumptions and opens up so many conversations that will benefit you are your team.
Just be prepared to make some calendar space for all that extra work your direct reports are about to give you.
The original 25 / 50 / 25 in this article came from a podcast I was listening to with the CTO of Shopify, Jean Michel-Lemieux. The formula resonated with me so much that I’ve repeated it numerous times to folks I work with and have actually sat down to understand if I am in fact close to this three-tiered approach.