There’s a desire, in software engineering, to capture and harness the mythical 10x Engineer. These 10x Engineers are highly unusual, often unique to context, and almost impossible to generate on demand. As Jessitron writes: It’s circumstances that make this happen.
A 10x Engineer can cause as many long-term problems, as they solve in the short-term. There’s the risk of a fragile or impenetrable codebase, built to a singular point of view. A team powered by one person, with no resilience and a very high Bus Factor. And what of the other engineers on the team? How do they feel? How do they grow?
We can get many of the advantages with few of the dangers by taking a different approach.
Intentionally multiply team effectiveness and reach by building a 10x Team.
Build 10x Teams instead
Great teams can quickly and effectively understand user-need, effect change, and add value. They collaborate and build towards sustained value and operational learning, adapting on the way. The power to learn, adapt, and deliver is essential. Ultra short learning and adaption cycles have become essential assets.
We are not talking about a perfect team, but a fast learning, well coordinated one. One that wants to get changes and ideas to customers and see if it solves a problem.
A focus on the team as the unit of delivery is not a new one, but one it’s well worth examining. Building, sustaining, and sometimes rescuing teams like these is what this site is about. If you want to find new ways to multiply the effect of your team or teams, read on.
10x Team key multipliers
1. Effectiveness: Flow and Safety
‘Flow’ is often viewed as a focused state of mind – focus-time for an individual to solve a complex task.
Whilst that is valuable, here we are focused more on team flow. The ability for a team to swiftly take changes from concept (or hypothesis) to the customer, produce feedback and react with learning.
Having a team-state where that can happen with focus and intention, makes a team super effective at value delivery.
Flow is underpinned by safety: the awareness of being safe to take risks and share openly. This is critical. Google’s Project Aristotle found Psychological safety was the most important factor for a team’s success. Without safety, the ability for the team to learn or adapt is low, and so, any flow state cannot be sustained.
Journey to safety and then to flow
Teams optimised for flow produce valuable results. But before that can be done, build safety in.
By focusing first on safety, you build a team that can take on ownership and risk, one that can handle conflict and errors, then turn them towards self-improvement and learning. This naturally leads to space for to build flow.
Once in the high safety and flow zone, these forces can support each other. Managing flow and safety together helps build teams that can go far.
2. Ownership: Autonomy and Alignment
Teams need high Autonomy and high Alignment for success, especially at scale. This wonderful diagram by Henrik Kniberg explains that without a balance of both either innovation or predictability are lost. Without both, value is wasted.
Teams should be empowered decision makers on their product focus, problem solving and when and what to ship. But alignment is needed for clarity and efficiency, as well as long term operability.
3. Continuous Delivery : Feedback and inspection
The DORA State of Devops reports and the Accelerate book have made clear that highly-effective teams are those that know what’s going on, and are able to act swiftly on that information.
Continuing the thread that began in the Continuous Delivery book, their research has highlighted that highly-effective businesses are those that can reflect on quality and act quickly. This then drives the business forwards. The Dora report in 2021 summed this up as ”excellence in software delivery and operational performance drives organisational performance”
How does this work at a team level?
The ability to gather and act on feedback before releasing a change (pushing quality left with CI/CD) and the ability for a team to own and repair customer facing systems, (Pushing quality right with Observability and Testing-in-Prod) have become critical tools in software ownership for teams. Contrary to the metaphor. Pushing both left and right are key to success and leads to greater Resilience and Robustness.
4. Value Orientation: Focus and Learning
Teams can be swamped with information and still not have what they need to make good decisions. A massive backlog of work may look like clear direction, but it starves the team of adaptation and the ability to seek value for the business and their customers.
Highly-effective teams have a big mission, but work in short cycles, with the most useful data. Data which is both specific and accurate. SLOs and OKRs, for example, can provide some of this, as external steers, but teams need time to focus and time to innovate, as well as the tools and ability to measure and to adapt.
Simply put. Effective teams have cognitive space to think about the challenges they own, put their theories to the test often, and adjust the plan as a result. Think Big and Work Small, as Jason Yip says.
What’s next?
If you have been persuaded to generate 10x teams rather than capture a 10x engineer… welcome!
You may well thinking: can I get some practical advice on how I could do this?
Good news. This site is here to focus on these areas, and others, that help build and operate 10x teams. And maybe some war stories to entertain and educate.
We’ll provide examples of what you can do in your teams to raise effectiveness. It will tell some stories from the trenches on how teams have been unblocked. It will gather some some useful thoughts around team effectiveness and flow that you might find useful on your journey.
10x team 