Solving Problems Across Three Systems.

As software has “eaten the world”, our ambitions as its creators have become grander. Any processes may be open to automation or disruption; any decision may be augmented or replaced by Artificial Intelligence inference. As software is introduced into these domains, more data is available, our understanding changes, and the processes and decisions themselves evolve.

The increase in software’s reach has resulted in an increase in expectations. Commercial customers subscribing to online services expect to see tangible value in return for their fees, and businesses demand return on their investment in a software product or computer-augmented process. Meanwhile, software’s impact on society is coming under increasing scrutiny, as law and policymakers grapple with ethics and access issues.

Simultaneously, the landscape changes independent of our actions. New technology emerges and its impact on our products must be considered. Competing products are introduced. People joining and leaving our organisation change its capabilities, its dynamics, and its culture. All of these affect the context into which we want to succeed with our product.

Software engineering is no longer simply the business of designing and building a digital artefact to run on a computer. Rather, success in software engineering means understanding three complex systems: the organisation making the software, the software itself, and the people and society using and impacted by the software system.

Pick Any Two?

Many techniques that already exist and give tangible benefits to software engineering organisations only focus on one or two of the three systems. Their blindness to the third system introduces very real limitations to their results; limitations that are felt in contemporary software engineering teams.


Scrum, and related methodologies that attempt to encapsulate the principles of Agile software development into a project management framework, consider the interface between the Team and the Software. While the agile manifesto and principles talk about all three systems, the usual meaning of agile “as practised” is a process for steady improvements of velocity while delivering iterative, incremental updates to a software system. It describes how the team come together (through stand-ups, retrospectives, and other rituals) to work on the software (through user stories, t-shirt size estimates, and definitions of done).

An organisation that focuses exclusively on these two systems can easily find itself going nowhere—or in the wrong direction—fast. This can manifest as early wins failing to translate into growth to scale. Why? Because the environment moves on, and the team doesn’t. They’re still iteratively improving the solution to a problem their customers no longer have, or need solving. They’re completing story points on their on-premises product when their competitors are offering a cheaper cloud-based solution. They’re adding features that people can’t—or won’t—use.

Design Thinking

Exploring the interface between the Team and Society at large, Design Thinking methodologies encourage identification of a problem, empathy with the people who face this problem and exploration of what they would want from a solution. Through the creation of ridiculously simple prototypes that rely on a Wizard of Oz-style ignorance of “the person behind the curtain”, they quickly let you try out different ideas on target users.

Without considering the Software your team is making, the prototypes you create with design thinking processes may not be amenable to productionising. They might depend on emerging technology that you don’t have expertise with, or take the product in a direction thatt will be hard to sell internally or expensive to integrate with existing systems. When that happens, you end up with a great idea that your team can’t afford to build. Or, if you get some people on board as a FIRE team or moonshot project, then a feeling that you’ve divided your organisation into the “haves”, who get to work on the latest shiny things, and the “have nots”.

User Experience

UX is the discipline that sits at the interface between the Software and Society. User experience practitioners use techniques from psychology, sociology and human-computer interaction to evaluate the usability, effectiveness, accessibility and benefit people derive from software systems.

Ideally, user experience would grow into a more holistic social experience field. It would answer questions about what other problems are introduced by people having access to this solution, and what problems they now worry about that they didn’t have before. It would asked whether the accessibility of this software causes problems for those to whom it is inaccessible. It would ask what biases and inequalities are introduced, particularly relevant when considering AI decision making at scale.

Failing to take the strengths, abilities and motivations of the team into account means knowing what a better product would look like without being able to incentivise the team to get there. If the team is focussed on velocity, they will prefer to work on low-risk incremental gains than on big-ticket enhancements that would realise secular changes to the business’s performance. Worse, when they find out that these improvements are out there but that they aren’t adopting them, they will become disillusioned, knowing that they are twiddling the bits on a product that is not as great as it could be. Ironically, when you give them permission to make the big changes, they will push back, because they don’t want to harm their hard-won velocity.

PETRI: grow all three.

To run a successful team, you need to take all three systems into account: the Team delivering the Software and the People using and impacted by it. You need to be able to see into the future, understanding how a change in any of the three systems will develop and affect your organisation. The PETRI Framework, created by the Labrary, gives you a headstart by helping you to define a path that supports:

To learn more and get an initial assessment, book into office hours.

Download the one-page PETRI brochure