I’m trying out a new point based blog format, instead of the usual prose style thing that I and most everyone does. I compose a lot of my articles like this and then change them to the prose style later. I want to see if this makes for easier reading and conveys the ideas better, in the same form that I thought of them. Let me know what you think in the comments.

Let’s talk about autonomous teams, evolution of developer self-identities, and a manager’s role in all this.

1. Simon Wardley says that all teams and business problems need three kinds of solvers. He calls them pioneers, settlers, and town planners. Quoting from his book:
   1. Pioneers are brilliant people. They are able to explore the never before discovered concepts, the uncharted land
   2. Settlers are brilliant people. They can turn the half-baked thing into something useful for a larger audience. They build trust.
   3. Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale.
2. All engineering teams start from not having a system, to building the first version of the system, to gradually maturing and standardizing the system. Each of these phases is suitable to a unique temperament,
3. Good software is a potent force multiplier. By building good products, developers are often left with only tweaking knobs to achieve tremendous output. 
4. If the mandate of a team is defined by the work they do rather than the problem they solve (a “data download team” is unlikely to do anything other than download data), then as the team builds better technology to handle their job, it is also setting itself up for increased work-dissatisfaction. Good software developers and teams are always making themselves redundant in their current form.
5. If the team is defined by a system, some developers (pioneers) will start getting restless at this point.
6. The only way to satisfy them is more greenfield system building in the current or different team. This is fine if we have the bench strength of people who want to take over an existing system and make it better as well as a transition plan. If not, managers will be stuck with the current developers, who will, eventually, quit out of boredom. With them goes their domain expertise and tribal knowledge. 
7. Because the entire team’s identity is based around the ownership of a system or set of components, there is a limit in terms of system maturity beyond which first the pioneers and then the settlers stop being interested in being parts of the team’s mission. Conversely, there is a limit to the chaos of experimentation that town planners and settlers are willing to tolerate.
8. We see the breaching of these limits very often in organizations – the most tell tale sign is components whose owners have all moved on to other teams (or companies). This is partly an operational problem (no single owner of the component), but most fundamentally it is the problem of tasking someone to “build a system” for some purpose. The task is finite in scope and engagement, and the builders obviously move on once their job is done. They don’t have any incentive to hang around once the current system objective is met.
9. What can we do to keep all three types of developers engaged in a team? This problem gets worse the better the team’s software is – poorly written software will keep its owners working on it for a long time plugging leaks, rearchitecting etc etc. Good, powerful software gets boring really quickly.
10. One solution is to define the purpose of a team and its members in terms of a business problem rather than in terms of systems. They are in charge of solving a business problem, and the systems they work with or build are incidental to the problem solving process. Such a team is often called an “autonomous team”.
11. An autonomous team is a team which is responsible for solving a specific business problem. The members of this team cut across system boundaries to solve business problems
12. Autonomous teams are a great way to engage all three types of developers since they can be different stages of evolution all at the same time.
    1. There may be components which are highly evolved and are being treated as the organization’s standard or platform for something.
    2. There may be other components which are becoming tried and tested and need to be stabilized now.
    3. There are ways/tools of solving the problem that the team has never before explored and need to start playing around with.
13. All three types of developers can cycle through these types of components in the autonomous team. Pioneers can tinker around with experimental stuff, settlers can stabilize prototypes and town planners can drive standardization/platformization of stable products.
14. Unless a business problem ceases to be a problem for some reason, an autonomous team’s work is never done. It is forever building on top of what they built in the past to climb the value chain and attack the problem at a higher and higher level. Sure the gains become smaller and harder over time (law of diminishing returns), but the team is always on the lookout for newer tools, while it still runs the business with the systems it has already built.
15. It is critical that developers understand this distinction in how roles are defined. Unfortunately, developers in many companies are insulated enough from the business goals that business achievements or metrics fail to inspire them sufficiently.
16. They think only in terms of tech stack or scale, and get far more fired up by technical numbers and achievements. This ties a developer’s self identity deeply with the systems they build, the tech they use, or the technical challenges they surmount rather than with the actual problem they are trying to solve.
17. A lot of attrition in companies happens when developers feel “there’s not much left to build”. When I joined Myntra, a colleague of mine said that our team’s job was nearly done. 5 years after that conversation, we were still building that problem.
18. But in an autonomous team, a developers profile cannot be locked in and MUST climb up the value chain. We are what we do, and so our self-identity also cannot remain fixed if we are not to be “bored”.
19. Therefore, it is important for managers to coach their teams in this process of growth. This means that they themselves need to be looking to climb the value chain in the mission of the team. “More of the same” is easy for both managers and developers because both can operate from a place of familiarity instead of having to find new common ground of expectations in an environment with changing goals.
20. “more of the same” is far easier than honest self reflection and scanning the horizon for the next challenge. Growth is not easy and invariably some members of the team will not be comfortable with it.
21. Managers need to drive home the idea that developers are not bound by what they are doing but what they can bring to the table in terms of solving the business problem at hand. It is far better for the entire team if the developers can become champions of “what next” in this quest rather than having tasks being handed over to them. This is the essence of autonomy and purpose.
22. All that said, autonomy is not for everyone. In my experience a lot of developers (and people in general – as Erich Fromm eloquently describes in his book “Fear of Freedom”) don’t take well to autonomy. If they are not invested in the mission and engaged in the process, they will inevitably end up following what others(teammates, manager, product manager etc) want to do and will feel unmotivated and uninspired because “nothing much is left to be done”.
23. This applies in general to tech and scientific progress. It is easy to see over large time horizons but difficult to keep track in the day to day work, but it applies nonetheless. Every advancement in technology removes more and more of the automatable things from our lives or makes them very fast/trivial. This leaves us with more and more time on our hands. It is up to us to decide what to do with this time we can browse social media or pick up a new hobby. This is the personal equivalent of picking up bigger problems to solve or doing the same things over and over again and getting frustrated in the process.
24. So if you want to manage an autonomous team, you have to look out for signs of this behaviour. Get them engaged in your mission and problem statement. If this doesn’t work, don’t be surprised that they soon walk out.
25. The challenge of the manager is to get his team to engage with the problem statement, and then to constantly move them up the value chain of the problem space. 
26. The ability to do this, in my opinion, the hallmark of a great manager/leader, because being able to reinvent ourselves by not getting tied to static self-identity is how we truly grow in life. Self-disruption is the key in personal growth, and someone who can induce us to it is worth working with/for.

Read Next : Layering microservices and domains for manageable microservice architectures