When to Kick Managers Out and Call Them Back Later
Trusting the Team to Drive Their Own Changes
This article is part of Maarten’s summer guest writer series. During my summer break from writing, I want to shine a spotlight on great content written by others.
My client has a major product refresh that’s scheduled for early next year. The date is set because their academic customers’ buying schedules are defined by the school year. We’re a few months out and they’re already worried that development is falling behind.
They asked me to find new ways of developing this product. They know it’s going to be hard to hit the deadline if they continue to use the same product development flows they’ve used in the past; the hope is that as an outside consultant specializing in product operations, I will help them figure out ways to work differently and break old paradigms.
My approach: kick management out of the room and lock the door behind them. Creating some space between the people doing the work and their managers removes some of the pressure from a team that’s already got a lot on their shoulders.
I’m working exclusively with the people who are “hands on keyboards” – product, design, engineering, QA. I have told their managers and product development leadership that I will report out to them, but they don’t have a direct role in our process.
We’re going to run rapid experimentation coupled with tight feedback loops around how we work. Nothing is off limits; the team can change who does what, how they work, what they build.
We’re not worrying about what flavor of agile to run. The only requirements are to build the right thing for our users, track our progress, and report on what we’re learning.
This approach doesn’t align with the standard change management advice. Usually I spend a lot of effort in discovery, consensus-building, workshops, and partnering with leadership to create organizational change. And that’s what I generally advise others to do.
In this case gathering broad buy-in wouldn’t fit the product needs, timeline requirements, and organizational dynamics. If I went with a more standard change management approach, I would likely get stuck negotiating between many passionate opinions. The deadline would zoom by. We would end up with negotiated half-measures instead of a new way of working.
Different Techniques For Different Circumstances
Change management leaders commonly advise to craft a plan, communicate broadly, gain buy-in, and roll it out step-by-step. This is my most common operating model.
I usually build consensus for solutions through a series of workshops, craft a pilot to test the solution, and do a broader step-by-step rollout. It’s reliable and repeatable.
How do I know when to throw all that advice out the window? (first I locked the doors, now I’m throwing things out the window…sheesh!) I look at four situational factors:
First is how much we know about the potential solution space. If I have a decent theory of what the right answer to a problem is, I’m all for the traditional approach.
In this case, I am not equipped to hypothesize about the solutions. I know product management well, but the solutions in this case will touch engineering, design, and dev ops. I don’t know what we need buy-in for. We don’t yet know what is going to work.
Second, I look at the interpersonal dynamics and politics in play. In this particular case, I’ve heard a lot of opinions from management about what to do. The people actually doing the work haven’t been involved in many conversations.
By running an experimentation group, I am trying to create a space for the people on the team to problem solve as a group without worrying about what their managers might think. I become a firewall between them and the outside world.
Third, because I’ve been in those opinionated meetings, I know that some people feel very passionately about how to solve this challenge. If their hypothesis is right, I’ll have tremendous support to roll a change out more broadly. But if we find a solution that doesn’t align with their expectations, I’ll need to have data to show why this is the right direction.
The small group experimentation allows us to quickly gather data to demonstrate which solutions may work and why. What we figure out will be the first prototype of new ways for the organization to operate.
Fourth, there’s a need for urgency. Building consensus and going top-down takes time. I can start working with the team in days and figure out what works or doesn’t within weeks.
Since the top priority is this one product and deadline, it makes sense to ignore the other teams for now and just work with the group that’s getting the most concern.
This can be imperfectly illustrated in a chart. It shows the four factors I take into account to choose which techniques to use, and what other change management techniques I might choose otherwise.
There’s a lot of nuance behind each of these questions – don’t pick your technique exclusively based on this chart. Use it as one input into your decision to decide what to do, and combine it with your own knowledge of the company and the situation.
Small group experimentation can only be run with a small number of teams at a time; it isn’t scalable. But it can be the best option to help find solutions when there are too many opinions and a need to move fast.
If there’s alignment around a solution and time, running a pilot allows the team to prototype new changes with just a team or two before offering the solution to more parts of the organization.
When there’s value from more consistency across ways of working, consensus-building and workshopping go hand in hand. Workshops can be used to better understand the solution space, while meetings, documentation, and other techniques to gain buy-in can help gather momentum around the next steps. That type of diplomatic approach is likely to be time-consuming.
Think about where the organization is at on this particular issue at this particular time and pick the change technique that best matches. As that technique wins some hearts and minds, expand to some of the change techniques that target larger groups until you’ve got the right level of buy-in and clarity on a path forward.
Designers Need To Take Big Risks
I have little idea what a good path forward will be for this particular problem. This group’s mission will be to discover that path. Everyone in the group will be a solution designer.
My job is to facilitate their discovery of how to improve the way the team is collaborating. Since I am not doing the work, I will not be a designer. I can suggest ideas, but it’s up to the group to decide if they should try them or not.
Good experimentation involves both finding wins and failures. If everything we try works, we probably are making only incremental progress towards our goals.
The Experimentation Process
We follow a simple agile process to run our experiments. By using a short sprint cycle and high-frequency communication, it allows us to get data quickly, adjust on the fly, and create more organizational nimbleness.
One of the critical advantages of locking the door is to create psychological safety. Hierarchies and reporting structures by nature reduce psychological safety. It’s much harder to suggest a radical idea that might fail if there’s fear that it will show up in your annual review.
Our weekly process:
Define an experiment and document it
Run the experiment
Check-in daily to tweak the experiment
Retro to evaluate
Document results
Repeat
This process has an additional (massive) benefit: it sets the team on a path to become self-improving. Even after we wrap up, the team should be better equipped to solve their own problems in the future.
Do Thing That Don’t Scale to Learn What Works
This isn’t a very repeatable way to solve organizational problems. I had to spend a large amount of political capital with the CPO to lock that door. In the long run, I’ll want to help them build the capacity for managers and the team to collaborate on process improvements themselves.
Even though it doesn’t scale, it’s an effective way to break old habits and create new ones. It can demonstrate new ways of working and be a powerful lever to kick off broader changes. It can help craft new culture, and culture scales beautifully.
Joel Tosi recently did the same thing with a team he’s partnering with. As he put it:
“Working with a wonderful team that is going to modernize some seriously gnarly code and do it in less than a quarter of the time expected if a 'contracting firm did a lift of old code and put it on a new platform'.
How is this possible? Easy - small steps at a time. Those small steps compound. As you make a small step, you learn more what to do next (as well as what you shouldn't do).
Trust your teams, take small steps, learn as you go. It's simple, and pretty fun.” (source)
Once we find some answers, I will use some of the other techniques mentioned above. Run a pilot of the new process with a second team to test if it works. Conduct a workshop to refine it further. Build consensus and buy-in. Figure out if we need to implement new infrastructure.
Even though we’ve just started, there’s already shifts in how the team is working. QA mentioned that they were unsure what to be getting ready. Product brought up a whole list of planned updates and QA will be getting ahead of the work instead of waiting for it to come to them. It’s a small change, but it’s a first step.
When I choose a change management strategy, I always remember to take into account how clear we are on a solution, if there are complex interpersonal dynamics that might be interfering with finding the best solution, if passionate personalities are pushing for particular answers, and if there’s a need for urgency.
The goal is always to find the best solution for that company and help it gain adoption.
Sometimes the best thing you can do is enable the people who are actually doing the work to find their own way and trust that they know best.
Jenny is an entrepreneur and product operations consultant who helps product teams trying to make dramatic changes and make them stick. She helps companies through fractional VP of Product services, coaching, and her course, Product Operations and Infrastructure. For more articles from Jenny on leading product teams through change, sign up for her newsletter.
 | A guest post by
|