How a simple phrase “What do you think?” can help build a stronger and more independent team
When I became an engineering manager at Microsoft three years ago, I anticipated some hurdles. My most prominent worry was the delegation of work; I have worked on challenging problems for years and I imagined it would be hard to let others take the reigns. I was right…to an extent. The most difficult part was not handing off the programming itself, but delegating the decision making.
A manager’s role is not to make all the decisions. This is hard to resist since making the decisions feels good. Every time I make the final call I feel like Jean-Luc Picard. However, doing so thwarts the growth of the team, leads to worse decisions and worse performance. There are several reasons for this:
- Bottlenecking
Being the team’s “decision maker” is a bottleneck. A team waiting for the manager’s say before making progress is wasteful. What if the manager is sick or busy? A high performing team needs to function well without the manager around.
2. Skill Building
Like any skill, decision-making take practice and learning from failures to get better. You can’t learn to ride a bike without falling off sometimes? (I don’t have a source for this, just trust me).
3. Trust
A manager making or swaying every decision demonstrates a lack of trust in the team. Strong teams are built on trust. Engineers who know their manager trusts them are much more likely to internalize the successes of the team and take on responsibility for making things happen.
4. Better Decisions
Better decisions are made when more view points and perspectives are involved. An inner circle of just manager and senior engineers closes off the ability to find new and unique solutions. Teams perform better when everyone feels they can contribute and help determine the direction of the product.
Opening up the conversation
For a while, I was quickly providing my opinion on all questions presented to me and often deciding right away which option to go with. When I realized the cost of doing this I changed strategies. When approached with a question or asked for my opinion, I resist the temptation to spurt it out immediately and instead respond with “What do you think?”.
A manager is in a position of authority (for better or worse) and this makes their opinion overly important. Just giving an opinion early in the decision process can shut down other ideas or thoughts. Responding with “What do you think?” gives the team member a chance to explain themselves and their thinking. It gives the manager a chance to listen and question their own opinions. In essence, this is a way for the manager to adopt a learner mindset over a knower mindset. When I first started using this question I was surprised by how many times the opinion that sat on the tip of my tongue turned out to be ill-informed or sub-optimal.
After the team member finishes their thoughts, start probing and asking follow up questions but resist phrases like “No” or “Won’t work”. These shut down conversations. Instead, try “Explain how it will work in this [situation]?” or “How would you handle this [potential complication]”? This leads everyone to conclude together whether this option is the right one to go with and encourages an open conversation.
When the conversation is over, put the final call in the team member’s hands. “Given our discussion, what do you think?”. Let them weigh the options and make a call.
Supporting the decision
“Every time a hypothesis fails, I gain 15 IQ points.” — Danny Kahneman
A decision is made and it’s time for the code to be implemented. During this process it is important to support the engineer who made the call. As the team moves forward, issues & complications may likely arise. Now is the time to re-open the conversation and assess if changes have to be made. It is important that the engineer knows it is acceptable to alter course, regardless of how far they have come down a certain path. Just because a lot of time is invested in a change doesn’t make it right. Changing your decision is not failure; this is how you learn, adapt and improve your decision-making skills.
Before I was a manager, I was tasked with fixing problems with the identity handling for work items in VSTS. I worked with some difficult constraints like a bad data shape and supporting years of back-compat. When starting this problem I didn’t appreciate how difficult satisfying those constraints would be. In fact, it took me a month building my preferred design to realize I had to make concessions.
At this point, I setup a meeting with my manager to propose a new design. I was anxious that she would admonish me for making the wrong initial choice. But instead, she was supportive and eagerly listened to my rationale for the change. My new design wasn’t as pure as the original but still solved many of the problems, while respecting the legacy baggage. She asked follow up questions on the trade-offs but left the final call with me. I left this meeting not feeling like I failed but feeling that I learned and was empowered to (with a deeper understanding) tackle the problem.
This is the kind of experience I want to provide for all the engineers on my team. Every time they make a decision and and learn from the results they add another tool to their tool belt. Every misstep or success in a new situation adds another tool. Collect enough tools and you are a strong, competent decision-maker ready to tackle new problems as they arise.
A team of engineers with full tool-belts is a strong, confident and independent team.
So … What do you think?