Improve your questions, and help your team
Hey!
Welcome back to another week of musings! I've been knee-deep in a migration project and haven't gotten enough sleep. But I do hope that you had a refreshing weekend!
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I recently came across this article from Camille Fournier about Why it is so hard to decide to buy.
- I would also recommend listening to her interview on Lenny's Podcast.
- ByteByteGo How do you design a system like YouTube? I've been into reading books about system interviews, as I've run a few in the past months. I also picked up this one, Acing the System Design Interview.
As time passes, you change your approach to working with teams. In most cases, I bring value to conversations, not by being the one who can code faster or solve complex problems, but rather by bringing clarity to conversations, mainly in the form of questions.
Most of the time, when your organization is past a certain size, you'll need to "align incentives," "break down silos," and make a "win-win situation" for all parties involved. I use quotes because those phrases mean, in practice, that you need to deal with the bureaucracy created by the size and breakdown of teams. Sometimes, you need to work with a team that might own something like the "communications platform," and they report entirely to another leader. The only point where the leadership converges is at the CEO level.
Bureaucracy translates into meetings, team meetings, 1:1s, etc. If your company doesn't have a great meeting culture, setting up agendas, creating action items, sending meeting notes to a broader audience, etc., will result in a series of meetings where the same topics are repeated.
There are never enough Why's
Many people start with the 5-Why's as a "framework" for asking clarifying questions. I tend not to like this method; in most cases, the project has already started, some rough idea of the solution might have already been decided upon, etc. So you won't attend a third meeting and ask, "Why are we tackling this problem?" unless you can backlog the project. Otherwise, asking such general questions might raise a defensive position from the meeting attendees. Or they might be too general: "Why do we want to increase MRR (https://stripe.com/resources/more/what-is-monthly-recurring-revenue) from X type of user?" which might derail the whole conversation.
The goal is laudable, but this might not be the right approach in most cases.
Increase concreteness
One straightforward approach to asking better clarifying questions is to change them to be either What? Or How? questions. Instead of asking, "Why do we want to increase MRR from X type of user?" we could do more like, "How does user type X behave differently from the other users?"
This helps teams or the meeting attendees provide clearer and concise answers, which can lead to more productive conversations.
Course correct
Other times, the meetings might be getting nowhere because people have different ideas about the project, like the problem or solution, trade-offs to choose from, or even losing track of the goal. You need to help the team see the bigger picture in those cases. For example, one of the constraints might be time, so we might prefer a solution that would get us out the door faster; other times, we start brainstorming earlier, or we might have more time and would prefer a more scalable solution.
Other times, I've seen engineers overly focused on the "right" technical solution and not really address the customer's problems. The best outcome is being good at getting the people on the right track and having a shared understanding of the goal and the solution we're choosing to pursue.
You'll want to ask clear questions: What does success look like for this project? What outcome do we expect the customer to achieve? What data indicate the customer problem? Is there a "root cause" of the customer problem? What are the next steps for this solution? Is there an alternative, given our constraints?
Have everyone in sync.
I've attended meetings where people seem to be not only asking questions but also offering solutions, and other people seem to be thinking that another solution is the right one. In those cases, it's better to have everyone in sync in terms of brainstorming, refining a chosen solution, and knowing the problem, or they're further distilling a chosen solution.
Having people pursue their own goals derails meetings and delays in solving customer problems overall. So, you need to be there for them to navigate this space.
Asking better questions here might be a bit hard; first, you need to understand where the team is actually on its problem-solving journey. Are they brainstorming ideas? Are they refining a solution? Are they missing the forest for the trees? Are they exploring the next steps for their solution?
After that, you can help the team navigate in the right direction. For example, if you're still brainstorming, you might want to ask questions like, " What does our customer value most about this?" or "What blocks this possible solution?"
Your turn!
Have you ever considered the type of questions you ask in meetings? Maybe you've always asked the questions you need answered, or maybe you thought about others present and asked questions to clarify the answer for the room.
I would suggest reading Humble Inquiry (affiliate link), a great book on asking questions.
Happy coding!
website | twitter | github | linkedin | mastodon | among others