This article is brought by Acumen, helping dev leaders release software faster with engineering intelligence. Transform data from Jira and devop tools into insights. Learn More
I can’t even count the number of times I’ve heard this old record play.
At first, when the dev team is small and intimate, everyone knows each other well and there’s a feeling of harmony. Centralized processes, workflows, tools and methodologies ensure that things just work smoothly: communication flows, everyone is aligned and collaboration is harmonious.
If there’s a problem, it’s usually pretty clear what the source is and the path to resolution is usually sitting just a few feet behind you. All you have to do is grab them for a quick cup of coffee to work things out.
What I’m trying to say is that when the dev team is small, a centralized approach is the obvious choice because it’s easy to implement and the benefits are clear to everyone.
But at a certain point, as the team grows, this centralized approach needs rethinking.
There comes a time in the process of scaling a dev team when the leadership simply cannot keep tabs on everything that’s going on. This is when a 100% centralized approach is no longer suitable, and engineering leaders should start thinking about giving both their teams and individual team members more autonomy.
There’s all sorts of reasons why dev leaders can’t keep up with their fast-growing teams. It can be because teams are working remotely or in different time zones, or maybe the responsibility for certain flows are broken up between different individuals, or a myriad of other reasons. Whatever the reason may be, the fact is that whenever teams grow, chaos ensues and keeping motivation up and productivity high becomes a challenge.
The chart below clearly demonstrates how productivity can diminish as the team grows, which in theory is completely counterintuitive:
Every single time I’ve had the pleasure of being around when the team scales, different versions of the same debate can be heard in meeting rooms: can we afford to give the teams more autonomy? How and what do we delegate and what do we keep centralized? Should everyone have the same degree of autonomy?
I’ve also heard similar debates and questions come up when new leaders are onboarded. There’s a lot to consider when you’re a new leader: you need to build trust, set up communication processes and balance ownership with autonomy. There are different strategies for doing this well.
This article sums it up quite nicely: “As a manager, it’s your job to achieve a balance that results in the best overall outcome.”
Whether you’re scaling your dev team or just got that coveted promotion to manage the team, you will soon be asking yourself how much autonomy you should allow and what the best approach for your specific team might be.
Both centralized and autonomous approaches to dev team management are relevant choices. Each one allows you to balance alignment, quality and process control with different levels of autonomy; it’s all a question of finding that sweet spot that’s right for your team at this particular stage of their growth.
So is it possible to have alignment and control while also giving your teams the autonomy to work the way they want?
Usually what happens is that the debate becomes more complex as projects scale. On the one hand, a centralized approach provides a common framework for decision-making, collaboration, processes and problem-solving. But, software projects are notorious for their fast-changing dynamic, and a more autonomous approach provides teams with boots on the ground with the flexibility to adapt and call the shots in real-time.
Pros and cons of each:
An autonomous approach to team management dictates that teams have the freedom to work in the manner they feel is most effective. Many organizations that want to work agile see autonomy as the best way to achieve more creativity, innovation and productivity. Teams and individuals use the tools they want, and communicate how they want to. They usually have the freedom to make their own decisions when problems arise, with managers often assuming that the teams in the trenches have a better ability to make the right decision.
A centralized, top-down approach to software development provides leaders with greater visibility into the project..
In my experience, the answer is a resounding yes! Although it’s no walk in the park, there’s definitely a way to balance freedom and autonomy with control without making your team members feel like you’re constantly looking over their shoulders.
Here are some guidelines to help you:
Numerous studies and research have proven that there’s a strong connection between autonomy and higher motivation and job satisfaction. When team members feel that they have more autonomy and are trusted by the organization to make the right calls, retention, productivity and job satisfaction go up. That’s why everyone on the team, from the most junior to the most senior member, must understand what the organization’s goals and strategy are and how they can contribute to its success.
One of the best ways to enable autonomy in your engineering organization while maintaining control and minimizing chaos is monitoring real-time data coming from the different platforms used by the team in its day to day work (e.g, Jira, GitHub).
Engineering intelligence software like Acumen provides visibility into key metrics such as team cycle time, maker time, and mean time to resolution. These can help identify trends, bottlenecks and upcoming issues, and enable much more efficient management of the team.
In his New York Times bestseller, Drive, Dan Pink lays out the four aspects of people’s work where autonomy can drive intrinsic motivation. One of them is autonomy in how people do whatever it is they do over the technique they use to complete their tasks.
As a leader, you should find ways to collaborate with your team, but make sure that they have ownership over how they do their work. This principle is actually a central pillar of agile methodologies and is explicitly mentioned in the 2017 Scrum Guide. Enforcing techniques on your teams is a big no-no that almost always leads to lower motivation and productivity. While you should feel free to implement new engineering practices such as Test-Driven Development or Pair Programming, give your teams the autonomy to choose which technique to adopt and don’t ask them to do something just because you’ve seen it work for other teams.
At this point you may be asking, wait a minute, how are autonomous team members supposed to know how to act when they do eventually run into problems that they need to solve? Using finely tuned software development strategies such as chaos strategy that empower autonomy while providing guidelines for handling the inevitable unexpected issues can help with this.
Chaos strategy is a loose set of rules for solving technical problems in a way that aligns with the business strategy. Basically it boils down to always resolving the most important issue first, with importance being defined as a combination of big, urgent and robust. Big issues are those that provide value to users, urgent means that these issues hold up other work, and robust signifies that the issue is tested and trusted when resolved.
Let’s continue with two additional guidelines to enabling more freedom and autonomy for your teams without losing control:
Creating a shared sense of trust and openness is critical to empowering autonomy and freedom in your teams. I mean, if you can’t trust your teams to be open with you, how can you ever let go and give them the autonomy to run at their own speed? Now, trust is all about ensuring that you have clear lines of communication open so that any issue can be quickly discussed and solved. Here’s a shortlist of different types of events that I’ve run in the past that have opened the doors to real, effective communication:
Ask-me-anything sessions. Sometimes you’ve got to jump in front of the bullet to get people to believe in you. Ask-me-anything sessions are just as the name suggests: fully transparent discussions where anything goes. In these events, leaders allow their teams to ask hard questions, even if they don’t have the answers.
360° feedback sessions. Don’t dish it out if you can’t handle it. These all-hands group meetings are all about fostering a shared sense of accountability. Individual team members sit together with their managers to give and receive feedback to each other, so that any underlying tension can be quickly hammered out.
Skip-level 1-on-1s. When there’s too much hierarchy, lines can get crossed. Skip-level one-on-ones put individual team members in a direct discussion with their managers’ managers. The point is for higher level executives to communicate context and get their organization's messages across in a direct manner. Feedback is given on the direct manager of the individual, so that there’s more of a sense of bilateral controls and measures.
Autonomy and centralized approaches live in harmony on a sliding scale. In reality there never is total autonomy nor complete centralization, but rather a mix of the two. A truly optimized team embraces both in a balanced dose and uses external aids to support the disadvantages of the other.
Data can be used to give managers of highly autonomous teams more control so that leaders can track progress and derive meaningful insights without micromanaging the team. Data is everywhere and is constantly being collected by multiple tools. Its analysis can provide better understanding into what the team is doing, where the risks lie and what can be done to improve performance.
There are several tools, Acumen.io being one of them, that leverage technology to aggregate data from multiple sources, identify patterns that shed light on team performance, and are fully automated and don’t come with too much overhead. Hey, if everyone else in the organization (HR, marketing, etc.) is already leveraging data, why shouldn’t R&D, the most technical team, do it too?
The VP R&D of Axonius put it well: “…historically, there haven’t been many tools available to promote visibility and data-driven decision-making as R&D teams grow. Git analytics or JQL are a jumping-off point, but they tend to offer a flat, one-dimensional view of data from a single system. You can read the considerations that guided Axonius' VP R&D in starting to work closely with data here.
Get instant visibility and the actionable insights you need to maximize your dev team’s potential!Get Started