Building Method: Creating Shared Understanding of How We Work

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.