The flow of work


Traditionally, organisations have command-and-control hierarchical structures, where work instruction flows down the functional chain. But this is at odds with the cross-functional, value-creating networked relationships that are needed in an empowered customer-centric company.  In Leadership Tensions, we explore the continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together across the company, to deliver increasing value to customers.

In an earlier post we’ve outlined how engineering teams can work together, in small teams (aka squads), now we need to understand how their work flows to them.

Although each Squad has the autonomy to decide what to build, in practice the Product Owner looks at what User Stories are in the Product Backlog, and the whole team make a joint commitment on what they can complete in the upcoming 2-week Sprint.  This flow is a network where organisational initiatives are decomposed into the necessary capabilities (which become the Products), which in turn decompose into the functional components of the product (its Features) and the granular expression of the feature (the Stories).

Workflow


Initiatives are the the big things an organisation does. Such as a new securities trading proposition or developing a range of medical products, or a new clothing line, or launching ecommerce. Initiatives enact an organisation’s strategy. Customers, while at the receiving end, are not necessarily aware of an initiative, nor would they care.

Capabilities are what deliver value to end-users, and consequently to the business. Users care because this is where their needs are met, gains and pains are addressed. So this may be a trading system, software for an MRI imaging system, or a CI/CD pipeline for delivering software for the latter, or an ecommerce website for a clothing retailer.

Features are the functional components that make up a capability (aka product). A feature might be a website service page, the product search, the shopping basket, credit card payment or Paypal integration.

A User Story is a granular expression of how a piece of functionality (part of a feature) to be implemented. Its purpose is to inform how it is built. As such, the story should be sufficiently small so it can be easily implemented (usually within a couple of days) and/but scoped so that it provides user value and is testable.

Bureaucratic to Agile

Bureaucratic to Agile

Work flows smoothly and continuously.  Instead of major programmes of work requiring significant capital investment, we move to a whole company agile way of working where we continually respond to customer needs, and deliver increasing customer value. We move from a hierarchical structure to an informal, value creation set of relationships.

Roles & Responsibilities


Company Executives decide what initiatives will be pursued.

The Enterprise Architect and a Business Product Manager identify and prioritise product capabilities.

A Technology Product Manager (Tribe Leader) and a Technical Analyst identify and specify the functional components - the features.

A Product Owner manages the Product Backlog of User Stories

A Squad consisting of a variable number of people with cross-functional teams builds the features it is responsible for, based on the user stories, and they are integrated with other Squad’s features by the Tribe Leader.

Each Squad has a Squad Master, a servant-leader, who steers people without having formal authority over them. Squad members are all asked to contribute equally to the collective committment of the team.

Everyone in technology becomes an engineer.  No-one just picks up the phone and passes the problem onto an appropriate 'resolver group'. Each person is capable to solving the challenge and does so.

Work is continuous, products are regularly improved to add value


In a customer-centric organisation, major capital investment is no longer needed to refresh the company's commercial offerings or corporate infrastructure. Cross-functional skills are networked together to constantly understand how the market is responding to the products and services on offer and small-teams iterate through minor improvements and A/B optioning to keep the products, and the company, relevant in today's market.

People, as well as cloud-based computing resource, become entirely on-demand and are paid for as operational expenditure, the number of Squads sized according to the capabilities that the company wants to offer in the market place and which provide an ongoing return on investment to match corporate ambition.

If you'd like help understanding how work flows across a network of empowered, self-organising teams. then we'd be pleased to have an introductory call.

Get in touch

Next:

We look at each of the Three Laws in more detail in separate posts:

The Law of the Customer
Customers no longer line up meekly at our shop door, impatient to buy what you have to offer. You need a team who are constantly alert to discussions about your brand or products on third-party sites or social networks, and who build connections and understand what customers truly want to buy.
The Law of the Small Team
Small teams are essential to create a customer-centric company. With self-organising leadership and alignment to the overall product roadmap, they are given the autonomy to decide what to build, how to build it, and how to work together while building it.

In Leadership Tensions we explore the continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.

Leadership Tensions
Most workers today would agree that org charts cannot even remotely describe the reality of working life. Hierarchy works for setting up corporate contracts and paying taxes. Over-emphasis on formal structures reduces effectiveness and inhibits innovation. There are alternate structures.