When talking about running a business unit or a department, I always end up being asked what is the difference between doing it for a single team and multiple teams? Well, to manage multiple teams has nothing to do with being a team leader (for 1 team). You need to be a leader, but different.
How different? Well, for me the most important topics where:
- understanding the difference between micro and macro-management
- choosing the right structure for the teams
- adopting the appropriate management style
Difference between micro and macro management
This translates into this simple quote: “from small to big“. For the sake of this argument let’s presume that you have experience as a team leader.
For me, to manage multiple teams meant to drop most of the concepts that I got as a team leader, change my perspective, and the way I set objectives and milestones. It took me over a year to grasp all of these and to be honest, I am still learning new stuff every day!
The most important differences are:
No more go-to guy. The age when you knew everything and was able to assist or fix every little small detail has passed. It is impossible to do that now, especially when your unit has more than 10 people. And if you decide to do it, well tough luck, you will never have time to do what you are supposed to: be the unit manager, draw the path.
I manage over 20 people right now so keeping tabs on everything is impossible. What is not impossible and what actually a unit manager should do is to be sure that all the teams understand the end goal, what are the milestones, what principles we follow when doing development, and so on.
Trust your teams! If you think you are the brightest tool in the shed and only you can come up with the perfect solution then you will never be able to manage multiple teams, honestly, it will be hard to manage just one. You need to have vision and provide the milestone and they need to do the work to achieve it. Yes, a high overview is needed and yes, from time to time you need to remind them and offer you guidance. Push it only if you see they are drifting away.
Protect your teams! I’ve done this as a team leader also, but I see that as a unit manager you need to do it more. Your teams need to follow, adopt, and deliver your vision and milestones. So, people coming from outside and mending around or disturbing them will make them forget the above mentioned. Outside requests should come to you, or to a dedicated person with this specific role never to the team lead or worse, to the developer directly.
Provide policies, not processes or procedures! Don’t tell them how to do their job cause it will backfire, trust me! Tell the teams that they need to follow a set of principles, for example, tell them that “all applications need to be auto-scalable and self-healing” not “use Kubernetes”. You provide the guidelines that are mandatory, they need to come up with the solution for it. Not only they will feel good about doing something, they will actually learn what auto scalability and self-healing applications mean. Win-Win!
As a small note here: You should know what the fuck auto-scalable and self-healing applications mean and you should have a back-up solution in your mind in case they fuck up and ignore the policy. Coming up next:
Good job – Post Mortem. Reward the teams and acknowledge their performance and accomplishments not only internal but external also. It’s they’re doing and they deserve it!
Also, get them in the room and explain all their fuck-ups and missed milestones and assure they put in place everything needed to not happen again. More like good cop bad cop, with you in both roles.
What is the best structure to manage multiple teams?
None or all I would say! There is no silver bullet, don’t chase an idea that you got from books or what others did. Think and understand!
First of all, for me, it was extremely important to understand the business model and to draft, from it, milestones and end goals. Once you manage this, you can say you have an overview of what needs to happen and how to proceed with your teams.
Let’s say you are taking over a development unit for a e-commerce white-label solution. So the business model is to have a solid platform, with multiple features that can be sold multiple times to various customers with various businesses.
You need to understand what you have. What is the status of the product/products that your teams should develop? Is it live? Does it work right (like 99.99% uptime)? Is it established in the market as a solid product?
Most of you would say that you don’t need that information, that is business, product owner, or whatever role does it problem. Yes and no, mostly NO. You will never be able to choose the right structure for your teams unless you understand what the hell you need to provide.
Getting back to white-label e-commerce example:
The platform is live but has issues with uptime in peak traffic situations. Also, in terms of customizations, the clients are not able to change the colors from the CMS, thus all the CTAs are grey. In the CMS you can create as many custom pages as you want but you are not able to set them as landing pages, and also the menu is hard coded. The roadmap is clear, fix the uptime issue, continue the development in the CMS to be able to offer clients the ability to do styling and make the app more mobile-friendly as it is old.
Now, the tech part: Is it a monolith from 10+ years ago or is it a nice new micro-service approach? What development skills are present in the current composition and what roles do those people have? Who handles the servers that hold the app? And so on and so on, I think I could add more than 2 pages of tech stuff you need to know before taking over. Well, get the big picture, remember, macro!
Continuing my example:
The application is written in .NET and it was done over 5+ years ago by 2 freelancers that never worked in the team. Is a monolith for which we run a script to deploy, on our laptops. Also, the app is adaptive, not responsive, and for some new mobile devices, it loads the desktop version.
The team consists of 10 .NET developers (all levels of seniority) 2 MQAs, 2 SYS admins, and 1 PO.
How I would split them:
- a DevOps team composed of the 2 sysadmins and 1 or 2 .NET mid-level that will handle automation for deploys and fix all uptime issues.
- split the rest of the developers between 2 teams, one that handles the CMS part and one that does the code for the shop itself.
- different team for QAs and PO
By doing this, I try to mitigate from start the core problems that the product has and draw a path for development pipelines. I would hire also another PO and also more QAs, but that is just me :D.
What style to adopt when you manage multiple teams?
One that fits all the teams. How? Well, get to know them!
This is not something you will be able to define from the start. It requires polishing along the road or even a 180 degrees swap. Not only those teams will get a new boss, that most will start changing their way of work, but to get also an extremely rigid control freak may make things worse.
You need to adapt your management style to specific situations. You should have a general overview approach for everyone, like when you participate in demos or sprint retros. Be the calm, observing unit manager, that always analyses and provides feedback. Apply a different tactic when you have your 1 on 1 with the team leaders.
To manage multiple teams you need to fully understand the people you are working with and what makes them click. Some will want you to be hands-on and help, some will want to talk to you only monthly. Understand that you need to be versatile and take the appropriate actions so that, in the end, the milestones are hit and your vision is followed.
As an ending, I will add that from time to time you will need to remind everyone who is in charge. Not by enforcing it, don’t put your foot on the table, but be smart and assure that regardless of the work environment, each one has a defined role, you the unit manager and them the doers.