Twenty questions for your one-on-ones / Transcript of my speech from OPEX Week
Double chapter edition!
Shani Mwechalo! (“Hello World” in Bemba)
Thanks to all who took advantage of the anniversary sale for my book last month. Lower pricing is still in place for non-Amazon stores; links to those stores are on itdependsbook.net.
Once I finish serializing the book in the newsletter, I’ll have a few bonus newsletters to answer some of the questions I’ve received. If you’d like to send me a question, send it to contact@itdependsbook.net.
About this issue’s chapters
Because I’m trying to have both the podcast and newsletter finish serializing the book at the same time, I’m including two chapters here. (Some may remember that I accidentally sent the same chapter twice last year.) These are two very different chapters: one focused on better one-on-ones and one focused on the intersection of Operational Excellence and Agile. The juxtaposition of the two may be somewhat jarring, but we’re into the last few chapters, so the options were somewhat slim 😊.
About Twenty questions for your one-on-ones
The great thing about one-on-one meetings with your reports is that they get uninterrupted time with their boss. It is a chance to connect and get to know each other better (especially if you don’t work in the same location). It bothers me when that meeting consistently runs short. It is a missed opportunity for connection, mentorship, and better understanding. I developed the list of questions included here so that I have something to discuss when silence falls and my mind is blank.
This chapter was shared on the podcast in August of 2024.
This is chapter 18 of It Depends.
Twenty questions for your 1:1s
Originally published on May 17, 2021
You sit down for a chat with someone on your team. You get through the pleasantries, the small talk, the status, and you run out of things to say. It happens to even the most curious and high-EQ people. It happens to me, and I have probably had 10,000 one-on-one meetings in my career.
When you hit that moment where neither of you has anything to say, it is very tempting just to say, “Ok then! Let’s talk next week.” giving you both time back into your day. If this happens occasionally, it is not a severe problem. However, if you find it happening more often than you would like, it is good to keep some prompts handy to move into deeper topics that might prompt a valuable conversation.
Here are twenty questions that you might find helpful if you get stuck at the surface level or run out of things to discuss in your one-on-ones:
What is more challenging in your day-to-day work than it should be?
What is the most fulfilling thing that has happened this week?
Who on the team has impressed you lately?
What are you looking forward to in the next six months? Why?
What haven’t you told me that I probably should know?
What is one thing that you miss from your last job/team?
Who on the team are you most worried about?
If there is one thing I could change about your role today, what would it be?
Who on another team do you most enjoy working with?
What do you wonder about?
How would you change the company’s strategy?
What is the product or feature that we should build next?
When do you feel the most satisfied at work?
What is your least favorite part of your job?
What percentage of your work time do you think you are in a flow state?
What is the one meeting that you would add to your calendar?
What is the one meeting that you would remove from your calendar?
What do you wish that I did differently?
What should I keep doing?
When am I the most helpful?
If you don’t like any of these questions, you can create your own list in a few minutes. You are looking for a question that gets the other person to think, share a bit more with you, and hopefully give you an avenue for deeper discussion.
About Transcript of my speech from OPEX Week
I have to admit it. In the past, I’ve often had a laugh at the expense of the Six-Sigma blackbelt crowd; the GE origin story, and the cooption of the karate ranking system. For someone coming from the world of agile software development (often in startups), Six-Sigma seemed arcane, corporate, and rigid.
Then something happened: I was invited to speak at one Operational Excellence conference and then another. I attended out of curiosity. I wasn’t even sure why they wanted to hear from someone like me.
I went and listened to the other speakers and talked with attendees over breaks and meals, and I came to a much better understanding of the problems they were trying to solve and how they had a lot more overlap with Agile than I had expected. For the second OPEX conference, I was asked to give a speech to the entire assembled conference. Given what I had learned from the first conference I had attended, I sought to inspire the attendees to find the common-ground with us agilists to help each group improve using the lessons from the other.
This chapter was shared on the podcast in November of 2024.
This is chapter 25 of It Depends.
Transcript of my speech from OPEX Week Summer 2018
Originally published on August 28, 2018
Author’s note 2023: For a brief period, I found myself welcomed into the operational excellence community. It was a fascinating insight into a world related to my work, but one where efficiency and failure avoidance were the overriding goals instead of speed and innovation. We agilists sometimes like to deride the Six-Sigma crowd, but we owe them a debt, and I appreciated learning more about their work.
In the software industry today, we can change our product daily in response to direct, instantly measured customer feedback. We can trivially give different versions of our products to different customers to see which they like more. We have figured out how to reduce the time from idea to customer value to revenue from years to days or even hours.
Some of you are thinking, “That would be great to be able to do that in my industry.” Some of you are thinking: “What a nightmare, how do you plan, track and manage in that environment?”
The thing is that when I started in the software industry, it didn’t work this way. We would spend months designing and planning, then we would build the new product, then we would ship it to customers, and then we would start on the next product. It would take years. If we misjudged our customers' needs, it would take us years to find out and correct the issue.
For software, the revolution of the internet allowed us to break free of our old industrial manufacturing paradigms. It was a two-edged sword because the platform that enabled us to become leaner and more efficient also lowered the bar to competition. The speed of innovation is now a critical aspect of success and survival. Easy access to investment has reduced the value of efficiency to less than zero. Companies can lose money indefinitely if they can show continued growth. If we, the market leaders, become complacent, a much smaller competitor can come from nowhere and take our market away instantly. The barriers to entry are now lowered significantly.
What I am describing may seem interesting, academic, or even obvious to some of you. “That’s nice for you” or “Too bad for you over in software,” you might be thinking, “but my industry is different.” Tell that to the taxis, the automotive manufacturers, or retail.
Just as we in software improved our agile and lean software development processes by learning from TPS, Deming, and the established OPEX practices and literature, we can share what we have learned back with the larger OPEX community today.
This talk is short, so I will focus on one way we’ve found to improve innovation velocity: an authentic autonomy culture.
For me, an autonomy culture starts with Toyota and its’ Kaizen.
Kaizen pushes responsibility for improvement through the whole organization and puts the decision-making closer to where the knowledge is. However, the companies I know and have spoken to usually use kaizen to make efficiency improvements to the process, not the product itself.
If you want to bring more innovation into the product, you must find how to bring autonomy to more levels of the organization
Empowering teams with access to the customer
Giving them the ability to perform low-risk experiments to validate their hypotheses
Using data to inform their decision-making and measure their effectiveness
You are changing the model of the organization from plan/command/control to inform/inspire/measure. It’s a fundamental culture shift. Leadership sets the direction and high-level strategy, and each team in the levels below figures out how they should approach their part of achieving that strategy with increasing levels of specificity.
The inform/inspire/measure model was how we worked at Spotify, it was how we evolved to function at Avvo, and this will be how we work at AstrumU as we grow.
If hiring smart people, you should take advantage of their intelligence and creativity. If you are not hiring intelligent people, you must consider why you can’t trust the people you hire.
For your teams to be successful, they need access to their customers. They need data. Find ways to instrument your product to give data on real-world use back to your teams. If that isn’t possible, share the data from your user research, industry and market trends, user testing, competitive analysis, and product focus groups with your whole organization.
Data can also help establish accountability. Work with your teams to develop objective data-driven business metrics for which they can be uniquely accountable. Avoid vanity metrics or non-objective ones. Every team should be able to tie what they do back to the company's core business, even if what they do is support the other teams. Empowering other groups to be more efficient will help drive your core business outcomes.
If your company isn’t data-driven today, you may need to train your teams to understand and utilize data. This training will not be a wasted effort.
At Avvo, we created a data-driven decision framework. We trained everyone in the company in its use. It was our version of a Kaizen card. It required the employee to validate their thinking with data and validate their decision’s success or failure with data as well. Data became a central part of our processes and discussions as a deliberate side-effect of this effort.
Teams armed with the context they need to make intelligent decisions and tools they can use to measure outcomes objectively against the broader business goals can be given more autonomy.
One more thing is needed, though, before the organization can truly embrace this model: ways to limit the risk of failure.
Innovation requires failure. You can’t do something genuinely new without making mistakes along the way. If we want our companies to be more innovative, we must reduce the risk of failure. Data reduces risk, but it alone isn’t the answer.
You need to find areas where your teams can experiment in the market in limited ways with actual customers. With rapid prototyping tools and limited run manufacturing capabilities, this has become increasingly easy over the last decade. Giving teams this ability lets them experiment and learn rapidly by giving them the knowledge they need. In turn, they can innovate without putting the whole company at risk.
What of governance, compliance, oversight, quality, and process control? These things are still as vital as ever, but how they function will need to evolve in an autonomous enterprise. They must be integrated and intrinsic, part of the DNA so that teams naturally incorporate them into their experiments. For the areas where this is most critical, the groups may need that expertise integrated into the team structure instead of externally applied.
I discuss this with you as a thought exercise, a different way of approaching innovation in your organization. It is working wonders for us in the software industry. I have spoken with high street banks in the UK, large department stores in the Netherlands, multi-national financial institutions, heavy equipment manufacturers, personal grooming appliance makers, and others looking into these ideas of autonomous teams to bring more innovation into their practices.
If it is possible for them, then it is entirely possible for you.
Thank you
The Latest Podcast
The latest episode of the podcast is titled “Lessons From Creating The Spotify Technology Career Steps.” This is the final part of the three-part series discussing how we built Spotify’s first career pathing framework for technology and the lessons we learned along the way. This episode contains lessons learned from the process, the mistakes, and the practical things we did.
If you're building a tech team that needs to scale while preserving culture, these three episodes offer practical lessons from our journey at Spotify. I shared this chapter in the newsletter last September.
You can download the episode from Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you listen to podcasts (see pod.link for a more extensive list).
About this newsletter
What makes this newsletter unique is that every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March of last year. These chapters are not sequential; each is a standalone piece. In addition, a podcast serializes the audiobook in order, released alternate weeks from this newsletter.
Reader Survey
I’m thinking about what happens to this newsletter and the podcast after we complete the book. I want your help! Please complete a very quick and anonymous survey to help me out.
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores