Rationale

The kata as a learning format arrived in software in 2003, when Dave Thomas introduced Code Katas as a way to give developers what musicians and athletes already had: a short, repeatable exercise designed to build fluency through repetition.

Mike Rother carried the same format into management in Toyota Kata, and Ted Neward adapted it for software architecture. The format has been in continuous use in the industry for more than twenty years, across very different domains, and the underlying idea has not changed: focused, repeated practice of a specific behavior.

The specificity is what does the work. A kata that asks you to communicate more clearly gives you nothing to do in the moment. A kata that asks you to write three sentences before you send a message, and remove any word the reader would need to look up, gives you something to do right now.

Each kata in this catalogue follows that second pattern. It targets one behavior, attaches it to one triggering moment, and asks you to practice it when that moment arrives.

Most leadership development happens away from the work, in workshops, courses, and books. People engage with the material, return to their jobs, and behave largely as they did before. The gap between learning and doing is where most development quietly disappears.

The research points in the same direction. Lacerenza et al. studied 335 leadership training programs and found that practice-based methods and immediate application were among the strongest predictors of success. Hughes et al. found that peer support at work accounted for more of the variance in whether training sustained than either supervisor support or organizational support did.

The katas are designed to run inside the work, not alongside it. The trigger is a moment you are already in. The behavior is narrow enough to focus on deliberately. The kata constrains the action, not the situation around it.

Patrick Kua interviewed more than thirty-five tech leads for Talking with Tech Leads, and the same pattern surfaces throughout the conversations. Engineers in leadership roles invest disproportionately in technical skills because those skills are familiar, and systematically underinvest in people and process skills.

Not because they lack the capacity, but because the environment does not develop those skills the way it develops technical ones.

Gergely Orosz makes a related point in The Software Engineer’s Guidebook. The tech lead role requires risk identification, stakeholder management, and the distribution of decisions rather than the making of them. A common failure mode is the quiet assumption that when a decision needs to be made, you are the one to make it.

Without signal from the environment, engineers default to what worked before. They code when they should delegate. They answer when they should ask. They avoid conflict because the cost of raising it is immediate and visible, while the cost of silence is diffuse and delayed.

Each kata names one of these defaults and specifies the alternative. The closing check is a prompt to notice what happened. It is not a substitute for external feedback, but it is more than the environment provides on its own.

The steps in each kata do not change, and this is a deliberate choice.

Mike Rother’s work on Toyota’s management practices found that fixed behavioral routines, repeated until they became habitual, produced more durable change than ad hoc responses to similar situations. The steps stay the same so that the cognitive overhead of deciding how to respond in the moment is removed. The decision has already been made. You execute.

Wallo, Lundqvist, and Coetzer’s review of learning-oriented leadership reaches a related conclusion from a different direction. The leaders who most effectively developed their teams were not the ones who taught the most. They were the ones who structured work so that learning happened as a byproduct of doing.

General principles require judgment at the moment of application, which is exactly the moment when judgment is most expensive and least available. Fixed steps give you something specific to do instead. Over time, the steps become the response.

• Hughes, A.M., Zajac, S., Woods, A.L., and Salas, E. (2020). The role of work environment in training sustainment: a meta-analysis. Human Factors, 62(1).
• Kua, P. (2015). Talking with Tech Leads.
• Lacerenza, C.N., Reyes, D.L., Marlow, S.L., Joseph, D.L., and Salas, E. (2017). Leadership training design, delivery, and implementation: a meta-analysis. Journal of Applied Psychology, 102(12).
• Neward, T. Architectural Katas.
• Orosz, G. (2023). The Software Engineer’s Guidebook.
• Rother, M. (2009). Toyota Kata.
• Thomas, D. (2003). Code Kata.
• Wallo, A., Lundqvist, D., and Coetzer, A. (2024). Learning-oriented leadership in organizations: an integrative review of qualitative studies. Human Resource Development Review, 23(2).