Building self-managed teams sounds way too optimistic to be a viable strategy.
Or does it?
Imagine this: a team where you don’t have to hold anybody’s hand. A team that delivers results with you only minimally getting involved in the frontline work.
This isn’t so unrealistic.
Wouldn’t you put yourself out of your job, though?
The short answer is no.
We bring you the long answer and all the tips and tricks you need to know to make your team self-managing from Mike Seavers, former CTO at Riot Games. He’s working hard to implement the lessons he’s learned over the years, which you get to learn too from this blog post. Interviewed by Karolina Toth on episode 42 of the Level-up Engineering podcast.
This post covers:
Mike Seavers has three passions in life: technology, leadership and video games.
He started coding on his Atari 800 at 10 years old, and he instantly fell in love with software engineering and video games. Soon after he joined the workforce, he started leading software teams as a project manager and an engineering manager. Eventually, he joined Riot Games and helped grow the company to about 3,000 employees.
He’s learned a lot along the way, and his mission in leadership is to help others avoid his past mistakes.
There are different ways to define and measure performance.
One measurement that makes a big difference is how much the team is dependent on its leader. When the leader makes all the decisions, it limits the team’s potential.
You can measure the effectiveness of leaders when they leave either for a short time or permanently. If team performance declines, it’s a sign that the leader didn’t create the conditions for the team to manage themselves.
We can learn from the top-performing teams in the world, like sports teams, for example.
The coach isn’t on the field during the game to make all the decisions. Coaches do most of their work before and after the game. They give feedback, share insight, give advice, and prepare their players for the next game.
Ideally, a coaching relationship teases the best performance out of people.
Inexperienced managers often have a desire to work on the front lines. They get impatient, and take coding tasks off their direct reports’ plates rather than watch them stumble and coach them to improve.
The role of a leader is to get the best performance out of the team and to make the vision and the goals clear, not to make all the decisions and write the code.
One of the first things I look at when I take over a team is the way they make decisions. The leader approving or making every decision is an obvious sign that the team has room to improve.
In a self-managed team, even the most junior employee is empowered to make a meaningful decision that affects the team’s performance. They’re not dependent on management to make all the decisions. No winning team requires the coach to explain how to kick the ball; the coaching happens before and after the game.
Leadership’s job is to make the vision and the goals clear. In my one-on-one meetings, I always ask these questions from my reports:
If they don’t understand this, you can’t build an autonomous team. Everybody has to understand what’s a win for the team.
Once you have this in place, you can start coaching.
This often happens in software teams: an engineer comes to you and asks, “Which direction should I take in design?” I respond by asking, “What’s the goal we’re trying to accomplish? Which direction do you think would serve our vision and our goals better?”
Managers often make the decision for the person because it’s faster. Then the same engineer goes and does what the boss suggested without taking the time to think it through.
I often tell these engineers to think through the vision, the goals and the trade-offs, and to feel free to ask me to clarify these if they want to. Once they’ve done that, they come back and tell me which one they’d pick and why.
The job of the coach isn’t to say whether they’re right or wrong. The coach has to point out potential flaws in their thinking. Maybe they made inaccurate assumptions, used flawed data, or didn’t use any data to inform their decision.
The coach’s job is to teach that person how to think about these complex matters.
If you’re doing this right, your team members will stop coming to you immediately to make decisions for them. Instead, they will consider the vision, the goals and the data, and they come to you saying, “I’m thinking about making this decision. I’ve done the analysis, these are the trade-offs, and this is the design I would choose. What do you think?”
This is a win for you. When your engineers do this, you can coach them to solve the problem, rather than solve it for them.
Sometimes there are hard deadlines, and you making the decision saves time. I have done this too. Just acknowledge that you take a learning opportunity away from the team by doing this.
Even after you make a decision for your team, you can sit down with them and explain the reasoning behind the decision. It’s an opportunity to let them know that, ideally, you wouldn’t make these decisions, but they’d make them for you.
It’s worth investing time into, because if everybody on the team thinks autonomously, you’re going to move faster. If they get your input before making any decision, you turn yourself into a potential blocker and your team is going to move slower in the long run.
My main metric for a manager’s performance is whether they can build a team that delivers results. When looking at managers, I want to see them get results through other people.
At one point, I worked with a leader, and he was doing well with a team of about six to eight engineers. They had a clear mission and vision, they had good performance metrics, and they delivered results. The team was doing well by every account.
Eventually, we needed to scale up the team, and it wasn’t long before we started seeing the cracks. The team started missing deadlines, and we had outages.
We were consistently giving this manager feedback for hiring junior employees. Hiring junior engineers is okay, but a team consisting almost exclusively of juniors can’t be highly autonomous. Ask the question: “Are you hiring people to delegate tasks to, or are you hiring to have a functioning team with high performance that doesn’t require you to hold their hands?”
We started a company-wide initiative led by the manager of this team. This forced him to rely more on his team to deliver results and to hit deadlines. Things quickly went from bad to worse.
The team didn’t have direction, they didn’t know what to work on, they were frustrated, and turnover increased. I talked to everybody on the team, and many said that they need their manager to make all the decisions, but he’s not around because he’s running another project.
The manager created this situation. He didn’t pay attention to balancing junior and senior engineers to provide guidance and direction. He didn’t make sure that the vision and the goals were clear so the team would always know what to do.
It took 18 months to turn around his underachieving team. We had to make personnel changes, transfer people to other parts of the organization, bring in senior talent, clarify the vision, and reset the goals.
This manager didn’t build a team that could produce results. He took on too much of the frontline work, and made too many decisions himself. The team started failing without him, which was a reflection of his performance.
You have a number of tools to see how your teams work as a leader.
Skip level meetings are essential when managing managers. This gives you a chance to talk to individual contributors. I tend to ask the same skip level meeting questions every time:
A failure often reveals what’s happening inside a team.
Failures happen on every team, so don’t be too harsh before exposing the root causes. As you dig into what happened and why, you’ll often find a lack of clarity on the vision and goals and a lack of empowerment on the team, because the manager takes on too much responsibility.
A manager being overloaded with work may be another warning sign. Managers should delegate more responsibility to their team and let them own it autonomously.
Pay attention to how often the team comes to you to make a decision for them. Write it in your notebook every time somebody asks you one of these questions:
These are words of authority, not empowerment. You need this sometimes, for example, managers have to approve people’s vacations and similar things. But when it comes to things they should be able to decide for themselves, you have to be careful not to do the thinking for them just to move faster.
Typically, you’ll find that only certain people do this on your team.
The next step is to stop making decisions for them, unless you have to.
When they come to you with these questions, ask this in return, “What would you do in my place?” Get them to think through the problem. After you’ve done that a few times, they tend to realize that they can’t just get a decision from you.
Alternatively, you can have a conversation with that person and say, “I’m trying to help you to not be dependent on me. I want you to think for yourself. Take some risks, make decisions, and be okay to make mistakes because that’s how you’re going to become a better engineer.”
Building self-managed teams was an integral part of the engineering culture at Riot Games. The idea was to hire smart people and expect them to solve the problems.
During my time at Riot Games, the company experienced hypergrowth and engineering went from 300 people to over 1.000. With 300 people, we didn’t have many directors, but as we grew, many frontline managers needed to start managing managers. We saw many leaders having trouble with this transition; the failure rate was high.
We spent a lot of time investigating why that was happening. We talked to managers and to the teams, and we learned that many managers had a hard time breaking away from directing the day-to-day work of the team.
When you’re a director, the managers you lead want autonomy in running their team. Telling them how to run a team doesn’t work; you need to teach them. This is how we started grappling with this idea of managers being coaches, and creating the atmosphere for success, as opposed to dictating what success has to look like for everyone in the organization.
At this time, I read a book called Turn the Ship Around! The theme of the book is this: too many things depending on the commander causes poor performance for the crew. To turn this around, the commander taught the crew members to say, “I intend to do this...” instead of asking for permission.
My entire leadership team read this book, and we made this a part of our vocabulary. I made sure my team started doing this as well. When they came to me with an idea, I went into coach mode and asked:
The more I make this a part of how I lead and coach people, the more I find that it works.
It’s a difficult task, especially if you like to help others. When your employees ask for your help, it takes a lot of mental presence to consider whether you want to make that decision for them or if you should encourage them to make their own decision. I still struggle with this.
Think about how you’ve learned to lead, to manage, or anything else throughout your career. Growth happens when somebody gives you a shot saying, “I need this outcome, and I trust you to make it happen.” You need space and support to deliver a stretch goal.
When I asked for permission, and my managers told me what to do and how to do it, I didn’t grow. I aim to create the conditions for my direct reports where they can develop, rather than take the easy way out and make all the decisions myself. This is the difference between a good manager and a great manager.
A good manager can get results. A great manager can get results and grow their people, so they can do the same for others.
Making it a part of your company culture makes it easier. Make it a thing everybody’s involved in and make it fun.
Every time we sat down to go through the past quarter and plan the next one at Riot Games, we came up with a leadership theme for the quarter. For example, we weren’t going to make decisions for others for a month. This put all of us on the same page, and we got everyone to think about it and talk about it.
When my direct report came to me asking, “Can I do this thing?” It was easy for me to say, “I’m not going to answer that question. You know the theme of the quarter, so you need to at least think it through before I give you an opinion.”
Your team may lack this level of camaraderie, but it’s a fair expectation. Just be straightforward about it.
For example, say, “My expectation is for you to think for yourself and to make decisions for yourself. I’m going to help you and support you in that. When you ask me to make a decision for you that I think you could make on your own, I’m going to ask you to think about it and make a proposal. I’m happy to help if you get stuck and want to talk through it, but you’re going to make the decision.”
In my experience, most people are open to and grateful for these opportunities. They can see this helps them grow.
I spent the first few months making sure everybody in the company understood our vision and our goals. This is a necessary precondition for employees to make their own decisions. It’s still a work in progress.
I’ve been talking to the team regularly, coaching the leaders to make decisions for themselves. But it doesn’t happen overnight. It takes a lot of time and practice to build this into a culture - nobody becomes an Olympic champion team overnight.
Some people don’t want to work in a self-managed team, while entrepreneurial engineers usually love autonomy. They may lack the skills, the mindset, or they just don’t want to be empowered to make decisions; instead, they prefer to let others think for them. Each organization has to decide for themselves whether this is okay for them.
I’d say, allowing this mindset lowers your potential performance.
You have to start at the top. Leadership by example is essential; people tend to model their leader’s behavior. If you teach senior leadership how to build self-managed teams, they’ll teach their team of leaders, who will teach their teams of managers. Eventually, it permeates the organization.
The middle management layers are the most difficult with directors and senior managers. Going from manager to leader is a difficult transition because you need to learn to coach managers.
I’ll give you an example from the time I was CTO at Riot Games. I had accidentally overheard engineers about three to five layers removed from me that they were doing something “because Mike wants it.” This happened a few times in the span of a few weeks.
This was frustrating for me. I went to my leadership team and said, “I’m going to be honest, it bothers me that the engineers on the front lines think that the reason they’re doing something is because I want it.” I explained that I’d prefer if they understood the vision and the goals, and management explained to them why the decisions matter, rather than just saying that I want to do this.
Appealing to authority is the lazy way out. Authority doesn’t empower people or teach them how to think for themselves. Somewhere in the leadership chain there was a manager who didn’t take the time to explain to these people why we made a decision, why it was important, and that they stand behind it.
You need to pay attention to why your employees do what they’re doing, and how decisions are made. If you follow this thread, you’ll be able to determine if you have a culture of empowerment or a culture that appeals to authority.
In an organization this size, you can get on a stage and tell everybody what behavior you want to integrate into your culture, but you can only create change in one-on-one conversations. This was a coaching opportunity for a couple of managers. We made sure to coach them about communicating the vision and the goals instead of appealing to authority.
There is a book by Simon Sinek, Start with Why. It makes an invaluable point: if people don’t understand the reason behind their actions, they can’t make the best decisions.
As CTO at Riot Games, I had the closest insight into the company’s vision, direction, and goals, but I had the least context about the daily problems of the teams. I was in the best position to communicate how the team’s work connected to the vision and the goals, but I was in the worst position to make decisions about dealing with frontline issues. This is why appealing to authority bothers me.
Leaders are often the worst people to make decisions about the frontline work. Their job is to clarify the goals and the mission to help the individual contributors make the right decisions. They often make better decisions, but not always, and that’s where coaching comes in.
As a rule of thumb, more brains are better than your brain.
Building self-managed teams takes time, and not every team can make the transition.
To teach a person to drive a car, they need to have the necessary skills in place already. They need to be old enough, have the motor skills, and know the basics about cars. Then you can teach them by first making them watch you drive, then you watch them drive, and eventually, you let them drive on their own.
I suggest you take the time to evaluate your team and make sure they’re capable before you expect them to work autonomously. You may have to replace some people, but building a team of leaders empowered to make good decisions makes your life a lot better.
This leadership style works with a certain kind of mindset with at least a basic skill level and critical thinking. I’ve had teams in the past where I had to make decisions for them because they didn’t have the experience to critically think for themselves.
This sounds terrible, but you can’t teach everybody how to think and make good decisions. Some people are worth the investment, because they’ll learn it and become autonomous, while others won’t. A growth mindset is essential for this.
Whether it’s possible for you to turn your team into a self-managed team largely depends on your team members.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.