The first practice of the CTO: going to the gemba ! (1/2)

The CTO alone in his tower

During my early years as CTO, I noticed how easy it was to lose touch with reality on the ground. Everything contributes to this. You move up the ranks, gradually distancing yourself from development, working on reporting, KPIs, OKRs… You take on a leadership role to work on strategic issues.

However, this loss of connection with the field is not without consequences. It distances the CTO from the real problems encountered by individual contributors and isolates them in their decision-making. In addition, the CTO also finds themselves further removed from the difficulties encountered by customers and end users.

How can we stay connected to operations and make informed decisions? How can we ensure that people can learn and improve their practices from competent leaders?

There is a valuable practice that comes to us from Lean: gemba. This Japanese wordmeans “The workplace, where value is created”.

Gemba in the world of software engineering

Although initially invented in the industrial sector, gemba is universal and applies to all professions. I practice it in software engineering with IT teams: developers, testers, architects, Ops, DevOps, etc.

The principle may seem simple: it involves going out into the field to meet an individual contributor and observing them in real conditions, » avoiding any « interference » that could cloud the observation. This is not a « live my life » exercise, as it is not a question of doing the developper’s job, but rather of keeping a distance in order to observe. Initially, I do this without the middle managers, while informing them of my approach and inviting them to join if they wish. However, it is essential to train direct managers in gemba over the long term. They are the ones who will ensure this connection to the field by becoming aware of the difficulties encountered by people and coaching them to solve the problems they encounter.

The gemba process follows a fairly strict protocol.

❶ Freeing up time – The first challenge in the CTO’s busy schedule! Personally, I visit the gemba twice a week when I start a new job, then once a week thereafter.

➋ Identify the person – When I take on a new role as tech leader, I favor people who feel confident and are more open to experimentation. This practice will inevitably be talked about, discussed, and challenged among colleagues. It’s best to start with a success with people who are more curious and inclined to share and be transparent. Current events are also a good criterion: a project that is just starting, a delivery delay, quality or stability issues, etc.

➌ Clearly announce your approach In general – I visit the person in person (at the beginning) or send a Slack message three days in advance explaining the approach in a few lines.

➍ The gemba itself – On the day, I conduct the gemba walk in three parts (total approx. 1 hour 15 minutes).

• 5 min – ice breaker
• 55 min – observation
• 15 min – debrief and acknowledgments

Ice breaker: we are safe

The practice of gemba is not widespread in tech, so it is important to give meaning to this practice. But above all, it can be intimidating or unsettling for an individual contributor to have their line manager or senior manager standing next to them for an hour. It is therefore important to reassure the person and establish a framework of trust and security. Gemba is also a way for managers to show employees genuine interest in their work; it is a form of respect.

So I take a few minutes to provide some context and remind him of the purpose of my approach. This is the icebreaker:

It’s really important to me because it helps me make informed decisions and get out of my ivory tower.

I’m interested in better understanding what you do and the obstacles you face on a daily basis.

It’s a valuable opportunity to exchange ideas, take a step back, and improve our practices.

Thank you for your trust. I couldn’t do what you do… / I’d be in big trouble if I had to do it myself.

Observation: the five senses awakened

Once the reassuring framework is in place, we move on to the main phase: observation. However, a framework must be provided for the observation to be useful. In general, I simply ask them to work on the task or activity they would have done if I hadn’t been there:

• a feature under development,
• a bug to fix,
• a test case to write,
• an architecture to set up…

By analogy with the industrial world, this work to be done is called « the work unit« .

My role is to observe how this work unit arrives in the hands of the collaborator (materials = ticket, specification, user story, etc.), how they transform it ( = code, etc.), and how they deliver it to the next collaborator.

So I start by looking at the materials, what they received as input:

What are you working on? Can you show me the Jira ticket, the specification, the architecture file… that we provided you with?

Then I move on to a little context information and why he is working on this particular work unit:

Who is the requester or client?

What is it going to be used for, or why is it important to spend time on it?

Do you have all the information you need to do the job?

These few questions allow me to quickly understand whether the person will carry out a task that they understand the importance and implications of for the client.

I suggest that they work « normally, » « as if I weren’t there. » I try not to interrupt too much, but when I don’t understand what’s going on, I ask one or two open-ended questions. My goal is to better understand when the employee is creating value (when coding, when testing, etc.) and when they are facing waste (when they are stuck, when they repeat the same operation, when they hesitate or don’t understand, etc.).

When obstacles arise, it is tempting to immediately try to provide the person with a solution. This is not a good idea! In this case, I prefer to try to assess the impact:

Not an easy situation, and how many times a day does this happen? Why?

Why is this hindering your mission?

The God of gemba is with you!

After a few minutes of observation, the magic happens. Obstacles reveal themselves before our eyes and highlight the real problems encountered by people of my team, including those they no longer see:

• The specifications are incomplete.
• We don’t know how to deploy it.
• The contributor doesn’t know how to modify the existing code because they haven’t been trained on this part.
• The contributor is stuck but doesn’t dare ask for help.

These moments are particularly interesting, and that’s why we go out into the field!

What we are looking for with gemba is to understand the real obstacles that contributors are currently facing, those that need to be resolved immediately and that are preventing the delivery of the long-awaited change…

Very often, at this stage my preconceived ideas are shattered.

Immediate debriefing

Once the observation is complete, it is important to have a quiet moment to talk with the person for several reasons: first, to reassure them (everything went well!) and thank them for their trust, and then to discuss the lessons learned from this observation (call to action).

Indeed, this gemba practice must be sustained over time to help people:

• identify the right problems, those that are important and have an impact on their daily lives
• give them the legitimacy to solve them themselves.

I usually start the debriefing with a big smile and a few open-ended questions:

So, it wasn’t too awful, was it 🙂 ? How did it go?

Then I ask what obstacles or difficulties (waste) they encountered.

What bothered you? Where did you waste time? What was difficult?

Could we try to change certain things?

How can I help you?

I then take the floor to share my observations. While highlighting moments of value creation, I also revisit any waste observed (rephrased as « time wasted, » « blockages, » etc.). Regarding the latter, I try to dig deeper into the causes: why are we in this situation? And I take the opportunity to ask the person if they have any ideas for countermeasures to try to prevent this from happening again. My goal is, of course, to encourage them to try to make improvements, with or without my help.

Finally, I always end the gemba with a thank you for the trust placed in me:

“Thank you so much for your trust. It was really interesting for me to gain a deeper understanding of what you do and the obstacles you face.”

As well as a thank you the next day:

The following weeks will give me the opportunity to check:

Will the person see the improvement through to the end? Do they need support?

How can they share this experiment with their colleagues?

Pitfalls to avoid

As you can see, kindness is essential during a gemba visit, as it can be a stressful experience for employees. Certain behaviors can be particularly counterproductive:

• Coming to « inspect » rather than observe

• Criticizing employees or showing irritation/impatience

• Immediately proposing/imposing your solution

Despite the leader’s desire to get things moving quickly, it is much more important to seek to develop people’s expertise through this type of coaching.

In the next article on the CTO’s practice of gemba, I will illustrate with some examples from my personal experience to highlight the lessons I have learned and and the impact of improvement actions..

How do you connect with your teams and become aware of the real problems encountered in the field every day?

Thanks a lot to Thomas Larzillière, Natacha Rimbon, Philippe Fenot, Elodie Atlan and Marek Kalnik for their help and inspiration!