5 Principles for Forming Autonomous Software Engineering Teams
Over the past 6 months I’ve been spending a large percentage of my time hiring and forming 3 software development teams at Navico as we step up our attempts to drive innovation in the Smart Boat era.
As a leader, I have to make fundamental decisions about how the teams will operate. Will I be an authoritative figure who dictates process, priorities, and solutions or will these responsibilities be shared? I cannot avoid this decision. Either directly or indirectly I have to make a choice.
It’s actually quite a simple choice. A decade of experience has shown me that the top teams who are pushing the barriers of innovation, speed, and quality are highly autonomous.
I believe, in general, giving the teams as much autonomy as possible leads to greater motivation, innovation and productivity. In fact, I have one primary heuristic that guides everything I do every day “How can I distribute my responsibility and make myself redundant?”.
Building a culture of autonomy is not easy. It’s not a case of just saying “go ahead and make all the decisions yourself” to the team. I believe the first step is to create a set of shared values or principles which align with the behaviours you want to achieve. Once you agree on the principles, you can then use them to guide behaviour.
Here are 5 principles which I believe are essential for autonomous software development teams, and how you can use them to guide the behaviour of teams to increase autonomy. These aren’t the only principles, but they are 5 that are crucially important in my experience.
The structure of the remainder of this document is how I typically present the principles document internally to the team except for the ‘discussion’ sub-heading, which is used in this article to explain each principle in more detail.
1. Lead by Intent
Don’t always ask for permission from your colleagues or your boss. Instead, tell them what you are going to do and allow them to give feedback if they disagree.
Example
Bad: “What should I do next, boss?”.
Good: “I believe the new Marketplace API is our top priority, so we will pair up on the API design today”.
Benefits
- enables everyone to make decisions
- prepares everyone to become future leaders
- moves away from a hierarchical model where the boss makes all of the decisions
- team can still function well when the boss or anyone else is away
Exceptions
If you need to raise a concern or are not sure of the best solution it is always OK to raise an issue or ask a question without having a solution.
Learn More
Read one of the best books on management, the book where this concept originated: Turn the Ship Around.
Discussion
Intent-based leadership was transformative for L. David Marquet in the US Navy as he built one of the highest performing crews on the lowest performing ship.
Intent-based leadership inverts the typical model. Instead of reports asking for permission from their boss, they express their intentions and the boss will correct them if necessary.
This principle is especially relevant to software teams who are used to taking orders. Their natural response is to continually ask “what should we do?” because they have been drilled to think this way.
As a leader, you can refer to this team principle and ask your direct reports what they intend to do until it becomes their modus operandi.
Eventually your teams will grow into leaders who rely on you very little. If you relish on feeling important and making key decisions and you cherish job security, this principle might not be for you.
2. Stop Starting, Start Finishing
We should focus on completing existing work before starting new work. The more work we have in a started-but-not-finished state (aka WIP — Work in Process) the more time we spend context switching and the less time delivering value. We get bombarded with notifications, pull requests and so on about all the WIP and it starts to burn us out.
To focus on finishing we must understand what the most important work is and be comfortable saying no or not yet to lower priorities.
Example
When we are blocked on a piece of work, instead of starting a new piece of work escalate the blockage and try to solve the underlying cause — how can we unblock the work, and what can we do to prevent this type of blocker in future?
Benefits
- we deliver more value
- we are not burnt out
- by focusing on underlying causes, we improve the system of work by removing the source of blockers
- delivery is more predictable (because work isn’t blocked we are more likely to deliver within expected time frames)
Exceptions
When highly-important work is required urgently, it may be sensible to immediately begin work without finishing the current work. However, this should not be a frequent occurrence.
Learn More
Learn about Theory of Constraints. Read The Goal.
Discussion
The typical organisation has so much work in progress that a high volume of engineering effort is wasted context switching. Autonomous teams need the ability to focus on what they think is important and say no to what isn’t.
By limiting the amount of work in progress it also forces teams to fix the cause of work being blocked which results in more predictable and more efficient delivery of work.
You have to read The Goal by Eli Goldratt to truly appreciate how important this principle is, and then you’ll see the world in a completely different way.
3. Make Work Visible
Ensure all of the work we are doing is visible to everybody in the team and people outside of the team who need to know.
Example
Bad: Receiving an email from another team to add new features and doing the work immediately without telling anybody.
Good: Receiving an email from another team to add new features and telling your team you are going to work on it next, and then putting a card on the work board.
Benefits
- everybody in the team can see all of the work in progress
- no important work gets missed because everyone thinks somebody else is working on it
- ensures low value work does not jump to the top of the priority
Learn More
Making Work Visible by Dominica DeGrandis
Discussion
For teams to be autonomous there needs to be a safety net that the most important work is being done and nothing important falls through the gaps. Instead of relying on a project manager or similar role to coordinate the team, which reduces autonomy, the answer is to simply make work visible.
By making the team’s work visible, it’s clear to everyone what is being worked on and what is not. It’s then clear to everybody if something high value is not prioritised accordingly and they can self-organise to resolve the issue.
It may seem dogmatic, but make sure every piece of work goes on the board. When teams get sloppy and don’t keep their board up to date, people quickly lose alignment with priorities and important work slips through the gaps.
4. Share Architectural Responsibility
No one person in the team dictates the architecture. Architect is a shared role and responsibility where everybody can and should contribute ideas and artefacts.
Example
Bad: “We need to wait for the boss to return to architect the solution”
Good: “Let’s whiteboard new architectural solutions and share them with the rest of the team, including the boss, for feedback”.
Benefits
- combining everybody’s expertise results in the best architecture
- no single-point-of-failure in the team
- everybody learns and improves their architecture skills
Exceptions
The team lead will be an arbiter of the architecture and may need to decide the solution when the team cannot reach collective agreement.
Learn More
Simon Brown’s Software Architecture for Developers and his C4 Model of Architecture.
Discussion
Software architecture is an essential activity. Having a single person who creates and owns the software architecture is a bottleneck, a single point of failure, and a missed opportunity to create a better architecture by leveraging the whole team’s knowledge and insights.
In autonomous teams, good architectural decisions will still be made and communicated if any member of the team is away. By frequently referring to this core team principle day-to-day, in retrospectives, and in 1:1s, you can ensure everybody has a chance to grow their architecture skills and contribute to the architecture.
5. Maintain Sustainable Pace
We should work in a way where people’s mental health is not compromised due to the nature or quantity of their work.
Example
Bad: “I have so much work to do, I’m going to work over the weekend to catchup.”
Good: “I have so much work to do. I’ll let the team know I’m overloaded but then I’m going home to my family because I go home on time every day.”
Benefits
- we all have the energy and enthusiasm to produce our best work
- we don’t create hard to maintain code because we are tired
- people are likely to be happier and improve the morale and quality of work of everyone around them
- people are likely to enjoy working here and not want to leave
Exceptions
Staying late or doing work over the weekend a few times a year is not unreasonable. However, any extra time spent working should be reclaimed.
Learn More
Are Your Programmers Working Hard, Or Are They Lazy? is an epic post by Mike Hadlow. Please try to find some time to read it.
Discussion
It’s not uncommon to treat software developers as resources and to squeeze every last line of code out of them. There are two problems with this model:
- Lines of code do not correlate with business value. In fact, bad code can result in negative value.
- If people don’t have sufficient time away from work to recover, the quality of their work decreases.
By having this as an explicit principle, and providing a clear example of going home on time every day, you set the tone for sustainable pace in your team, and it communicates clearly to everyone that you don’t expect them to work long hours to show they are working hard.
You have to regularly review this principle and encourage people to leave work on time. And you yourself have to leave work on time and not respond to emails in the evening or when on holiday.
Communicating and Honouring Your Principles
I hope you find these principles useful. I’m sure you’ve encountered them before if not by different names, anyway. Whether you agree or disagree, I think the way you convey your principles is important.
I believe it’s key to not just have a bullet list of principles, but to expand on them and provide clear examples of what the principles look like on a day-to-day basis so people can use them to guide behaviour and not just view them as platitudes.
In my opinion, it’s also essential for the team to add and iterate on their own principles. As a lead, you can set the initial principles for the type of culture you would like in the team, but if teams are going to be autonomous they eventually need to define their own way of working and their own additional principles.
Finally, you have to truly believe in your principles and honour them. You have to think about every action you take each day and ensure it aligns with the principles. If it doesn’t, nobody else in the team will value them either.
I recommend reflecting on your team’s values in 1:1s, at-least once a quarter. I also think they are good retrospective format, by asking your team to rate themselves how well they think they are doing on each of the values.
