If you ask most software engineers what they want, they often will answer with “To build the best software, with the latest tools, without being bothered.” In other words, they want to build what they want and how they want, without lots of distractions or input. Couple that with the trends in Agile and the ever promoted self-organizing team’s concept and you can end up with anarchy, instead of autonomy.
Many of the software engineering teams I have worked with over the years promote the self-organizing, antonymous team concepts. They champion that it drives engagement and ultimately better (and even faster outcomes). I am all for autonomy but in at least established companies, that structure and discipline create better results. That doesn’t mean hierarchical command and control, instead, it means teamwork, collective thought, respectful debate, compromise, and results. Corporations are there to create value for their customers. In turn, that value provides jobs and profits to the corporation and its employees. That cycle of value creation, with the customer at the center, is important to keep front and center. I cringe when I hear engineers push to cut scope for the sake of delivering software on a predefined date, without the guardrails of value.
The challenge I have seen with self-organizing teams is that they struggle to come together on their own, let alone within a collection of teams in a larger enterprise. Say, one team picks a pattern for a contract between systems without collaboration with the other teams. When those other teams go to pick up that contract, they realize the pattern doesn’t match theirs. A debate ensues with tempers rising, feelings hurt and teams moving further apart vs. closer together. Autonomy can be interpreted as absolute. The concept of the people taking care of themselves and organizing turns into tribalism. Tribalism can turn into anarchy.
So instead of the customer at the center of how value is driven, the team can become the center of the value chain.
Going back to the premise that self-organizing teams and autonomy is a good thing in software engineering, then how do you go about it without resulting in anarchy. Systems can create proper boundaries for autonomy to thrive. Without systems and inherently principles of the system, individuals and teams have no context on how to operate. Without context, then each team creates their own, which often results in anarchy… again. The irony here is software engineering is all about creating systems, so we need a system for our teams to operate within. In effect, every organization needs its own ‘Operating System’ for how it will accomplish its work. This should be a combination of the companies culture and workflow processes.
CULTURE + WORKFLOW PROCESS = OPERATING SYSTEM
There are many systems (or in old school terms — software development life cycles). From formal Project Management Institute waterfall to scrum, KANBAN, Scaled Agile Framework and WAGILE (water-fall agile). They are all right and all wrong at the same time. There are several mistakes I see technology departments or traditional companies make when implementing a new system:
- Take an academic approach, implementing each component to the letter of the framework, even if the organization structure isn’t there to support it.
- Cherry-pick the best or misinterpret the intent of the system
“We’re Agile, we don’t need to plan or think about requirements…” - Fail to take into account the company’s or departments culture
The impact of a company’s culture is the most missed and frankly most critical ingredient when determining how to create your companies operating system. If a company is very hierarchical, rigid and driven by annual planning cycles and tightly controlled budgets, introducing Agile will be challenging at best. On the other hand, if a company is free-spirited, shuns bureaucracy and is process is adverse, introducing Agile or any process framework will also be challenging.
As you create your operating system, you have to factor in the culture. The best way to do this is to start with a single cross-functional team with the first step being to outline your cultural norms. Understanding that starting point will enable you to debate how a process framework will be received and what potential pitfalls you may need to watch out for. With that team, start small. Take the simplest concepts and start to introduce them. For example, start with a daily stand-up. After a few weeks, pause and do a retrospective on what worked and didn’t work. Adjust accordingly. Next, layer in visualizing the teams work on a whiteboard. Enabling the whole team to see the work at hand will start to drive insights into potential roadblocks. This step will start to surface process gaps that need to be addressed. Keep doing those retrospectives every few weeks to learn and adjust. Make sure to take the time to document what is working and not. After a few months, you may want to formalize roles, like product owner, scrum master, tech lead, etc.
As you introduce your operating system, lean heavily on the “retrospective” process to learn. The retrospective is the barometer in how your culture is accepting or rejecting your operating system.
Once you feel you have a solid operating system that factors in your culture, start bringing in more teams. Each team will need to be trained and given the space to learn on their own. As they perform retrospectives, keep adjusting your operating system as necessary factoring in their learnings. Your next inflection point will be when you start to coordinate work across teams. You should expect to have to adjust your operating system to factor in scaling out.
If you introduce the concepts of an operating system, regardless of which framework you choose, and then allow teams to self-organize and create a team level operating system, you will fall short of your objectives as an organization. Think about a manufacturing plant with dozens of stations that have to hand parts of work off to each other to build a finished product. If they each worked at their own cadence, with their own definitions of quality, your ability to produce high-quality finished products will be low.
However, if you channel that autonomy into choice on what a team works on and in what order, but the flow within the team and across teams is consistent, autonomy can thrive without leading to anarchy. Start with setting a clear goal, with context on the value of that goal. They allow the teams to define the work that they need to accomplish to meet that goal and in what order. Management can pressure test decisions and challenge the team back to ensure they are factoring in schedule, budget and resource constraints. From there, the teams can move on their own, leveraging the ceremonies of their operating system to report progress.
Goal + Value = Context
Autonomy can be a very powerful tool within your organization. To maximize autonomy, you have to build an operating system around your culture, fed by consistent communication of your goals and their value.
