With today’s complex business landscapes and rapidly evolving technologies, having a well-defined “way of working” is crucial for software teams to execute effectively. Most organisations adopt processes, frameworks, and methods that they believe will deliver software projects successfully within their constraints.

But how often do teams step back and ask – how well does our method actually work for us? How much have we actively built and shaped it based on our own learning? How much of what we’ve learned about how to build software do we apply to building our method(s)?

The Reality

The reality is most teams inherit an existing software development method or cargo-cult the latest hype they read about. They don’t consciously architect the foundations defining the collective work. Much like constructing a building without an intentional blueprint – the result is disjointed work patterns built piecemeal over time.

This leads to confusion, frustration, and quarterbacking* when team members operate on conflicting assumptions and mental models of how work actually flows. People spin their wheels questioning why things happened when lacked shared reasoning of how decisions get made.

That’s why teams dedicated to continuous improvement migh choose to prioritise Building Method. This means deliberately designing an optimal way of working given your realities – then updating the blueprint as you learn from experience.

Key Steps

Key steps for Building Method include:

• Surfacing the needs of all the Folks That Matter re: the Build Method (old skool: requirements analysis)
  
• Facilitating deep conversations about current practices, the good and the bad, what to keep and what to reject
• Mapping out flows – where value gets created and lost
• Defining decision rights giving clarity yet freedom
• Distilling guiding principles for tracking outcomes vs needs
• Envisioning the ideal configuration of people, process, tools
• Inspecting then rewiring suboptimal current conditions
• Embedding rituals allowing reflection and adaptation
• Surfacing and reflecting on governing shared assumptions and beliefs about how work should work

While external benchmarks provide useful perspective, real transformation occurs when teams consciously architect agreements uniquely tailored for the Needsscape. By investing energy into Building Method you construct a living blueprint that evolves intentionally vs. accidentally over time.

Invitation to Contribute

What does your team’s current method look like – and how intentionally was it built? I welcome perspectives on elevating teams capabilities for effectively Building Method. Please share your experiences in the comments.

Aside

*Quarterbacking is when one person on a team takes on an overly directive role and excessively tells other members what to do, rather than allowing for collaborative decision-making and self-organisation.

The term comes from American football’s quarterback position – the player who calls out plays and commands the offense on each down. Calling someone a “quarterback” on a software team implies they are dominating discussions, assigning tasks, and tightly controlling the work in an ineffective way.

Quarterbacking can emerge when team members lack a shared understanding of role clarity, decision rights, working agreements, and processes. Without clear method or structure, an informal hierarchy forms with the most vocal directing others and disempowering the team.

The alternative is facilitating peer-to-peer collaboration where everyone has agency in creatively solving problems. Avoiding quarterbacking means intentionally designing team interactions that enable decentralised leadership, autonomy, and leverage collective intelligence.

So in summary, quarterbacking refers to overly directive and disempowering behaviour that stems from lack of clarity, structure, and self-organisation on a team. The solution is co-creating method that empowers the broader team.

Commitment to the Folks That Matter Drives Satisfaction and Delight

Henry Ford once said,

It is not the employer who pays the wages; employers only handle the money. It is the customer who pays the wages.

This statement reinforces the Hagakure’s guidance on unwavering allegiance to one’s master. In modern product development, our true master becomes all the Folks That Matter. Engaging fully with their needs and objectives doesn’t just improve the work; it also ensures outcomes align with the needs of those footing the bill.

Unwavering allegiance to one’s master is at the heart of Hagakure. In our setting, the Folks That Matter become the ‘master.’ To be truly committed means not just doing the work but understanding the why behind it. Are you meeting the needs  that matter to all the Folks That Matter? Are you adding features that bring them value? Such targeted engagement ensures that your contributions align with the needs and objectives of those who actually pay your wage.

Loyalty: Team, Code, Customer?

Loyalty in the Hagakure transcends any transient obligation; it manifests as a lasting allegiance to your cause and your ‘master,’ in this case, The Folks That Matter. How does this loyalty manifest in the workplace? It’s about becoming a reliable team member, adhering to standard work, and actively participating . This goes beyond your immediate team, extending to all the Folks That Matter. After all, a robust and reliable product directly impacts folks’ satisfaction.

Courage: Risk for Reward?

Courage isn’t merely about overcoming fear; it’s a calculated action despite fear. The Hagakure praises the courage to make difficult but crucial decisions. In business, this courage manifests when facing hard choices. Maybe the current path for the product isn’t viable, or perhaps a much-loved feature doesn’t fit the broader objectives. Making these tough decisions serves the long-term interests of The Folks That Matter, who, as Henry Ford pointed out, are the actual wage payers.

Honour: More Than a Virtue?

The notion of honour is deeply ingrained in the Hagakure’s teachings. This isn’t about an abstract moral high ground but about tangible actions that uphold your integrity and reputation. What does it look like in practice? Treating teammates with respect, attending to their needs, ensuring ethical working practices, and being transparent in all interactions. These actions don’t just impact internal team dynamics; they resonate with the needs of all the Folks That Matter, thus fostering a level of trust and respect that builds long-term relationships.

Presence: A Cornerstone for Satisfaction?

Being present in every undertaking is a key lesson from the Hagakure. This principle isn’t just philosophical; it has practical implications. In a world filled with distractions, giving your complete attention to the task at hand might be more challenging but it’s also more rewarding. This focus allows you to tackle issues more effectively, craft better features, and ultimately provide a product that better serves the needs of the Folks That Matter.

In summary, combining the ancient wisdom of the Hagakure with Henry Ford’s insights results in a fresh, yet rooted, approach to work. Embodying commitment, loyalty, courage, honour, and presence ensures a strong alignment with the needs and values of The Folks That Matter, effectively reminding us who really pays the wages.

I recently posted a quickie repeating Phil Crosby’s Four Absolutes of Quality.

I accept that many folks find his choice of vocabulary less than clear. So, here’s a reframing of his four absolutes, reframed in the Antimatter Principle vocabulary (a reframing which you may or may not find more helpful).

1. The definition of quality is meeting everyone’s needs, NOT “goodness”.
2. The behaviour that causes quality to happen is paying attention to folks’ needs, NOT inspection.
3. The performance standard for quality is “all needs met, for all the Folks that Matter”, NOT “that’s good enough”.
4. The measurement of quality is the cost of focus, NOT indices.

– Bob

A sample chapter excerpted from my new book “Quintessence“ – book available now on Leanpub (free sample also available).

Note: Each of the eighty-odd chapters in Part II of the book takes a specific meme, and describes the collective beliefs and assumptions that quintessential organisations hold in regard to the meme. By taking all the memes in toto, we can understand the way quintessential software development organisations see the world of work – and what makes them so effective. This particular sample meme is about who matters.

Chapter 15. Who Matters

Quintessentially

Quintessential organisations regard the needs of their customers, staff, managers, investors, etc. as central to the way the work works. Collectively, these folks are sometimes called The Folks That Matter. These organisations invest much effort in:

• Identifying the various constituencies and the people who belongs to these constituencies.
• Tracking the set of constituencies, and the changing membership of these constituencies, over time. 

“Understand stakeholder symmetry: Find the appropriate balance of competing claims by various groups of stakeholders.”

~ Warren G. Bennis

The quintessential organisation exhibits the following (collective) attitudes and feelings towards the Folks That Matter:

• A keen urge to understand and track the needs of all the Folks That Matter.
• Inviting folks to come up with explicit policies for defining and tracking membership of the set of all Folks That Matter.
• Practices to both discover and attend to these needs.
• Defining organisational success in terms of needs met.

Quintessential organisations recognise the major costs and other risks arising from missing out key members from the set of all Folks That Matter. These risks receive their continuous scrutiny – both in terms of accurately identifying members and in terms of ensuring these members’ needs are attended to, and ultimately, met. All work of the organisation is geared towards meeting the needs of the Folks That Matter. Maximising the amount of work NOT done is achieved by cautious (risk-aware) exclusion of insignificant groups and individuals from the set of the Folks that Matter, whilst striving to drive towards zero the instances of omission of significant groups and individuals from the set of the Folks that Matter.

Stakeholders

Quintessential organisations recognise the distinction between stakeholders and The Folks That Matter. The needs of some stakeholders sometimes don’t much matter, and some of The Folks That Matter aren’t actually seen as stakeholders (employees, for example).  Given these distinctions, choosing different terms helps communication and, more significantly perhaps, improves Cost of Focus.

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.

Indeed, getting “requirements” straight necessitates such discussions.

The wolf in question for this post being “Requirements”. 

In a recent Quickie I presented Phil Crosby’s Four Absolutes of Quality. The first of these four absolutes being:

1. The definition of quality is: conformance to requirements.

Let’s unpack what Phil meant by “requirements”. His meaning was very different from developers’ and software folks’ typical understanding of the term.

Suppliers and Customers All Down the Line

In Phil Crosby’s world, everyone is both a supplier and a customer. “Upstream” folks supply parts, information or other things to their most immediate downstream customer(s). Each such supplier/customer relationship is mediated by a mutual understanding of, and agreement on, what the customer needs, and thus what the supplier recognises they must provide. Hence “Quality”.

And, by the way, reflecting the mental model of an organisation – stretching back upstream into the organisation’s supply chain, and downstream into its distributors and customers – as a “braided river” of value streams (see the image accompanying this post).

Mutually Agreed Interface Standards

It’s this mutual understanding that Phil calls “requirements”. Not some massive document with screeds of tedious detail. Not some specification of the supplier/customer “interface” written and imposed by some more-or-less clueless third party.

Fear

In my travels, I’ve seen folks of every stripe run a country mile from “requirements”.

Senior management don’t like the idea because they fear their freedom of action being constrained by such things. (Untrue, by the way).

Developers don’t like the idea because they fear being dumped-on by some requirements weenie who has a different – and often erroneous – idea of what the customer needs.

And most folks fear being corralled by a set of requirements that, even when accurately reflecting the needs of a customer, hem-in their freedom to supply what they like, rather than what’s needed. 

How do the folks in your organisation regard the idea of requirements? Do “requirements” in your organisation look anything like the Crosby definition?

– Bob