There are many books and lecture series about creating high-performing teams that work well together, work hard for each other, and produce tremendous results. That’s nice. In real life, you, the manager, don’t get to create high-performing teams. You inherit low- to average-performing teams and are expected to transform them while delivering everything your predecessors overpromised without slipping the schedule. Yeah, good luck with that.
In fairyland, you’re granted a compelling charter, plenty of headcount, and a reasonable timeline to build a cohesive team of strong talent. Back on earth, you’re hired to manage an existing team with an existing charter and a boatload of existing issues. After all, if everything were perfect, the management position wouldn’t be open.
How do you transform an existing team without seeming like the flavor of the month? How do you build identity, trust, and camaraderie when you appear to be a hulking, hideous, hairball of change? How do you maintain momentum and ship on schedule while swapping out charters, people, and approaches as you go? Read on—this is going to be fun.
What’s going on?
There are two types of elite sports coaches: the ones with an innovative system that they foist onto whoever their players are, and the ones that develop an innovative system based on the players that they have that season. Both types can be competitive at an elite level, but it’s the coaches who adapt their systems to their talent that consistently win championships. The same is true for managers.
Your first step as a new manager of an existing team is to learn who you have and what their strengths and weaknesses are. How do you do this when everyone expects you to lead the moment you arrive?
- Talk to your boss, peers, and team members about your new team before you start. What are the concerns and hopes? What are some short-term wins and long-term expectations? It’s the same approach I described in The new guy, but in the context of a whole team, not just your role. Before you can effectively makes changes, you must first listen and understand the current situation.
- Bring your new team members together and introduce them to who you are, what’s important to you, and how you view the success of the team. The key concerns of anyone with a new boss are “Who is she?” “How do I avoid pissing her off?” and “Can I succeed on her team?” By providing your background (just facts, no hubris), your management philosophy (short and sweet), and your vision of success, you answer these questions immediately.
- Reassure your team members that nothing is changing immediately or without their input. Change is the last big concern your team will have. By telling your team to continue doing what they’re doing, everyone feels reassured. By telling team members that they’ll be consulted, they’ll feel respected and acknowledged—the building blocks of trust. Sure, you’ll probably make changes eventually, but first you must learn what you have.
Here’s how I describe my expectations when I take on a new team:
- Meet your commitments (the daily ones).
- Never compromise the quality bar. (This implies we have one.)
- Win as a team (no cowboys or cowgirls).
- Love your customers and partners. (We can’t succeed without them.)
- Attend team meetings and one-on-ones.
- Do a few things well.
- Deliver bad news early. (I save this one for last so I can spend time emphasizing it.)
Who are we and why are we here?
For your team members to function as a team, they must know who they are and why they are here. As soon as you’ve spoken to enough people to understand the team dynamics, it’s time to establish your new team’s identity and aspirations. Ideally, you’d introduce these at that first team meeting. However, often you need to brainstorm your vision and mission as a team or leadership triad after you’ve already joined it.
Your vision is a short description of how the future will be when your team is successful (“landing a man on the moon and returning him safely to the earth”). Your team will likely only play a role in achieving that vision. That role is described in your team’s mission (“develop alternate liquid and solid fuel boosters”). Your vision and mission help your team members prioritize, make decisions, and get themselves out of bed each morning excited to make progress.
While your team’s vision and mission provide the team’s objectives and help define its identity, you also need more tangible ways to reinforce a sense of team. Regular team meetings and morale events are easy and essential for this purpose (read One to one and many to many). You can also decorate your space, and even occasionally your people, with symbols of the team’s identity. Don’t just get t-shirts—assign a special day or morale event when everyone wears the same shirt. Put banners on the walls. Select fun team names. Celebrate being a unit that succeeds together and looks out for each other.
Who do we have?
The next aspects of your new team to examine are:
- The people and organizational structure
- The approach and toolset
- The current and planned work
There is no right order to review these—it depends on where the team is struggling most. Remember, your boss and overall group unreasonably expect immediate results, so go for the most impactful and quick wins first. For now, let’s start with people and org structure.
Once you’ve had a chance to talk one-on-one with all your team members (at least your direct reports and your skip-level reports, if any) and ask them about their current challenges, it will be obvious if there are personnel issues. People usually aren’t shy with the new guy.
If the people situation is of primary concern on the team, act quickly. Don’t kid yourself if someone clearly isn’t a fit. You’ll find that the easiest time to deliver tough messages is during your first few months on the job (no strong ties yet, fewer hard feelings).
However, personality and performance issues aren’t usually the dominant people concerns. The more common problem is not having the right people to achieve your mission. Sometimes you have too many thinkers and not enough doers. Sometimes it’s the opposite. Sometimes your org structure isn’t matched to your mission. Once you understand who you have and what you are trying to accomplish, it’s much easier to slot the right people into the right places (including onto other teams), and then write job descriptions for the roles that are vacant.
If you were promoted from within your team into your leadership role, it may become difficult to deal with your former peers as their manager. The biggest help I’ve found is clearly differentiating your roles as you’re talking: “As your peer, I’d say …, but as your manager I’d say ….” That way, you remind people that you’re the same person, but now have a different role.
What are we doing?
Often the biggest issues involve your team’s approach and toolset. You’ve got good people targeting the right work, but they are dysfunctional and inefficient. People are fixing issues or fighting fires instead of innovating and enhancing products. When they are working on features, there is too much talking and meeting and not enough doing. The tools don’t help, or actually make things worse, by treating symptoms instead of addressing the root cause. Ugh.
To address these issues, focus your team on three things:
- Define “done.” Ensure your team knows what “done” means. No shortcuts. Have a realistic quality bar and stick to it. It’s your best means to corral the cowboys and cowgirls and reward doing things correctly.
- Think. Expect your team to prioritize, perform root cause analysis, and constantly improve. (One of the reasons why folks like Scrum and Kanban is that they enforce this behavior.) Expect team members to discuss their designs and design changes in advance—proceeding with confidence instead of reckless abandon. Sure, reckless abandon is fun and romantic, but that’s for prototyping time, not the production implementation. Most importantly, give your team time to think by building a schedule based on past success, not fantasy.
- Shorten cycle time. The less time it takes your team to go from feature spec’ing to feature “done” the higher your feature quality will be, the more responsive you’ll be to customers (and plan changes), and the more productive your team will become. So, determine the length of your feature cycle, find what steps are taking too long, and fix them. Common culprits are long build times (shoot for under 30 minutes for partial builds), long test times (shoot for under 10 minutes for BVTs), too many environments (dev and prod are all you need), too many manual steps (automate everything possible), people sitting too far apart, or teams using outdated methods (instead of feature crews or other lean methods that work on one feature at a time until it’s done).
As I said in Don’t be a tool, tools serve us, not the other way around. Focus on people and what they are actually trying to accomplish (delivering value to customers), and then streamline everything around that work.
Key point: People are limited in how much change they can handle. Ideally, you only change one major tool or method at a time—certainly no more than three at once. Any more than that, and people will get confused and fail. What’s worse is that they’ll associate their failure with the whole package of changes, poisoning chances for future improvement. Always go one step at a time, focusing on the area of biggest impact.
For more on reducing cycle time, read Cycle time—the soothsayer of productivity. For more on reducing your environments, read There’s no place like production. As for my favorite approach to software development, read Too much of a good thing? Enter Kanban.
Where are we?
The biggest issues with your new team may not involve people or approach. Your team could be focused on the wrong work or stuck chasing the emergency du jour. You need to review current and planned work.
You’ll get a sense of your team’s current work from your initial meetings with team members. If it sounds truly discombobulated, then you’ll need a quick fix. The easiest way is to focus on your customers. Bring in marketing, product planning, customer support, and/or user research, and have them discuss the customer and market at a team meeting. If you can bring in real customers too, that’s even better. Have your team write ideas for improvement areas on post-it notes during the discussion. Then brainstorm and prioritize the improvement areas with an affinity exercise. Now you’ve got a basic plan that your team helped construct.
However, a basic plan won’t give you the full picture—for that you’ll need deep dives. Schedule an hour or two to review each area your team covers. Don’t have your folks spend time preparing presentations. Instead, have your team experts describe their areas in detail at the whiteboard while you and other team members ask questions (the meetings should be open for anyone to attend, but only the experts and triad are required). Take pictures of the whiteboard and post them in the team OneNote notebook. Now you know where you are.
Where are we going?
Once you know where you are, it’s easier to discuss where you’re going. For that you need strategic planning. The problem with planning is that plans change. The problem with no planning is that you have no idea where you’re headed. A nice compromise is lightweight planning.
Have each of your teams brainstorm a list of improvement areas (based on customer information, as before). Then have the teams place those items in a table according to each improvement’s dimensions of execution and market risk. The less confidence the team has that it can ship the improvement, the further toward the top it goes. The less confidence the team has that customers will like the improvement, the further toward the right it goes. You end up with a table like this.
Items in the lower left are your core business—you know how to ship them and you know customers like them. Items in the upper right are big bets and game changers—high risk, but high potential reward. You want your plans to be balanced. Not enough focus on the core and you lose your current business; not enough risk and you lose your future business.
Schedule an hour for each area your team covers, and have folks in that area present their plan (just a filled out table). Provide feedback and discuss priorities. Then go over a combined plan with the entire team. Now you know where you’re headed with a plan that can be easily adjusted as situations change.
I learned about the execution and market uncertainty strategic planning table from Ian MacMillan. You can find it in Ian MacMillan and Rita McGrath’s book, The Entrepreneurial Mindset: Strategies for Continuously Creating Opportunity in an Age of Uncertainty.
Are we there yet?
That’s it. You’ve listened to your boss, peers, and team. You’ve established a team identity and aspiration. You’ve resolved people issues and aligned your org structure to your mission. Your team is using an efficient approach and productive tools. You know where you are and where you’re going. Most importantly, you’ve made these improvements by involving all your team members, building trust with you and with each other. Guess what? You’ve got a high-performing team.
Some of these team areas may have been fine from the start. Maybe you started with good people who were properly organized. Maybe they’ve been using lean methods for years. Maybe your organization’s planning was already clearly laid out for you. The key is to understand what you have, see the biggest opportunities for improvement, and then address them patiently at a rate people can handle, a step at a time.
Because you focused on your team’s biggest needs and didn’t change too much at once, your team sees the improvement and feels part of that success. You aren’t a randomizer—you’re a leader and part-time miracle worker. As a leader, it is your job to serve your team. There is no better way to serve your team than by being a thoughtful leader who listens, addresses the team’s most pressing needs, and provides a smooth transition.
For the basics on being a good day-to-day manager, read I can manage.
In the "What are we doing?" section, it's very important to look and the incentives and rewards that are currently in place. Are developers rewarded for checking in code regardless of the quality level? What happens if they don't write tests? What happens if they check in code with bugs? Do they have time to do a quality job, or do they feel they are rushed? What constraints do they have?
In many cases, what looks like poor craftsmanship is just the development team doing their best to be successful under the team's current definition of success.
Many managers reward hard work without determining what was the cause of hard work. A dev who write sloppy code can do well by being a hero and fixing lots of bugs, where the dev who writes great unit tests and never stands out gets left behind.
"No Heroes" is one of my rules. If team members are having to be heroes, it means that something is wrong. Fix the wrong thing rather than rewarding heroism.