What Ways of Working Actually Means

Ways of working is one of those phrases that gets used so loosely it risks meaning nothing. Let's be precise. Ways of working refers to the specific, observable behaviours and practices that determine how a team operates - how they plan work, how they communicate, how they make decisions, how they handle blockers, and how they learn from what they have done.

It is not a methodology. Scrum is a methodology. Kanban is a method. Ways of working are what you actually do on a Tuesday afternoon, which may or may not resemble whatever methodology you claim to follow.

This distinction matters because teams frequently adopt the vocabulary and ceremonies of Agile while operating in ways that are fundamentally waterfall in nature. They have sprints, but the backlog is dictated from above. They have retrospectives, but nothing changes. They have standups, but those standups are status reports to a manager rather than coordination between peers. The label does not describe the reality.

Effective engineering leaders develop the ability to see their teams' actual ways of working - not the espoused version, but the version that shows up in practice.

The Spectrum from Prescribed to Emergent

Ways of working sit on a spectrum. At one end, everything is prescribed - the process, the ceremonies, the tools, the workflows, the escalation paths. At the other end, teams are entirely self-organising and determine their own ways of working from first principles.

Neither extreme is right. Fully prescribed ways of working eliminate the flexibility teams need to adapt to their specific context. Fully emergent ways of working create inconsistency, reinvent wheels, and make cross-team coordination difficult.

The right position on this spectrum depends on:

• Team maturity - newer teams often benefit from more structure until they develop shared norms
• Work type - exploratory research work and production incident response require very different rhythms
• Organisation size - larger organisations need more consistency for coordination, not more prescription
• Risk tolerance - safety-critical systems warrant tighter process controls than internal tooling

Most engineering organisations sit too far toward the prescribed end, not because it produces better outcomes, but because prescription feels like control. Managers who are uncomfortable with uncertainty often reach for process as a substitute for trust.

How to Audit Your Current Ways of Working

Before you can improve your team's ways of working, you need to see them clearly. That requires active investigation rather than assumption.

Observation

Sit in your team's ceremonies without facilitating them. Watch what actually happens in standup - are people talking to each other or reporting to you? Watch sprint planning - who is doing the talking? Watch retrospectives - are action items being followed up on?

Data

Look at your team's actual flow. What is the average cycle time for a piece of work from start to delivery? Where does work sit and wait? How often is work returned for rework? These signals tell you about the process even when people cannot articulate the dysfunction themselves.

Conversation

Talk to individuals, not groups. In groups, people describe the official version. In one-to-ones, they describe the real one. Ask what frustrates them about how work gets done. Ask what they wish was different. Ask what they avoid doing because the process makes it too painful.

Common Failure Modes

Cargo-Culting Scrum

The most common failure mode in software teams. The team adopts the ceremonies of Scrum - standups, sprints, planning, retros - without adopting the underlying principles. The ceremonies become rituals without meaning. Sprints become mini-waterfalls. Retrospectives become complaint sessions with no follow-through.

The solution is not to abandon Scrum but to go back to first principles. What is each ceremony for? What problem does it solve? Is it solving that problem for your team?

Ceremony Accumulation

Teams add new ceremonies over time - a weekly sync here, a monthly review there, a cross-team standup that nobody can justify removing. Over time the team spends more time in meetings than doing work.

Audit your calendar. Every recurring meeting should be able to answer the question: what decision or coordination happens here that cannot happen asynchronously or through another existing ceremony?

Process as Blame Deflection

When things go wrong, organisations often respond by adding process. A production incident leads to a new approval gate. A missed commitment leads to a new weekly review. Over time, process accumulates not because it improves outcomes but because it provides somewhere to point when things go wrong.

Process added in response to failure is often the wrong response. The question is not "what process would have prevented this?" but "what condition led to this outcome and how do we address the condition?"

What Good Looks Like

Good ways of working share a set of characteristics regardless of the methodology label attached to them:

They are owned by the team. The people doing the work have genuine input into how the work gets done. This is not consultation theatre - it is actual agency.

They are visible. Everyone on the team understands the process and can see the state of work at any point.

They are regularly examined. The team has a regular mechanism for reflecting on how they are working and making deliberate changes. Not just retros - genuine systemic examination.

They are proportionate. The amount of process is proportionate to the complexity and risk of the work. Internal tooling teams should not operate under the same process burden as teams building safety-critical systems.

They reduce friction. Good ways of working make it easier to do the right thing than the wrong thing. If engineers are regularly working around the process, the process is wrong.

Different Team Types Need Different Approaches

A discovery team exploring a new product space needs very different ways of working to a platform team maintaining a high-availability service. A feature team in a stable domain needs different rhythms to a team rebuilding a legacy system under active use.

One of the most common mistakes engineering leaders make is applying a single way of working across teams with fundamentally different contexts. Consistency is valuable, but not at the cost of fit. Understand the work type before prescribing the process.

Starting the Conversation

Changing how a team works is hard. It involves challenging habits, surfacing discomforts, and asking people to give up practices they have invested in. The conversation needs to start with observation and curiosity rather than diagnosis and prescription.

Start with questions: what is working well and why? What is not working and what is the cost? What would it look like if this was easier? Then move to experiments rather than mandates. Try a different format for standup for two weeks. Reduce the sprint length. Remove one ceremony entirely and see what is missed.

Ways of working evolve. The goal is to build a team that continuously improves how they operate, not one that reaches a fixed state and stops. That is the real work.