The level of autonomy developers get influences their learning speed, job satisfaction and how fast teams can deliver software. As a person seeking as much freedom as possible this is a topic dear to my heart.
Disclaimer: I write as if all of what I'm saying is true. But this is just my writing style. It's still only my current thoughts on this topic.
I have seen a few different levels of planning out there.
1) People are told what task to work on
2) People can choose tasks from a predefined list
3) People get the vision, discuss how to best fulfill it, and then execute on that
4) People get the vision and work on whatever they want to fulfill it
5) People work on whatever they want
I personally experienced the first 3, heard first hand about the 4th one. The last one is just there for completeness sake, I have actually never heard or read from anyone having such a job, but I guess they exist somewhere.
In general autonomy is lowest in the first one and goes up the further you go down the list. There's another axis impacting freedom though, task size.
If people are told exactly which task to work on (1), but they are huge, say 2 weeks of work, they are more autonomous than in a system where it's discussed how to best fulfill the vision (3), but a sync and evaluation happens every day.
As soon as a task is estimated, team leads and managers want to keep close to that to not mess up their plans for the team and projects. Going on a tangent to future-proof code which doubles the task size is often not desired.
With the estimated time being at least somewhat fixed, doing their own estimates gives engineers the ability to calculate in important adjacent activities (like code improvements) that others might overlook. If team leads do the estimate all on their own, this freedom is lost.
The worst in terms of freedom is a team where the team lead estimates tasks, these tasks are tiny and people are told exactly what to work on at which time. And to top it all off, it's even defined exactly how to do them. Micromanagement in its purest form.
Jokes aside, I didn't hear of any organization yet where it's that bad.
Impact on Developers
Particularly young developers profit enormously from increased levels of autonomy. It provides a wider area for mistakes. And the mistakes made are their own. Which is crucial for learning.
If the someone else decided how to do it, it's too easy to reject all responsibility. In this case the learning effect is weak.
This is also why side-projects are so powerful. Developing one entirely on your own means you have total control, all decision are yours and all mistakes too. You see the impact of everything you do, of every line of code you write.
This is not to say that you can hire people directly out of university, let them alone for 2 years, and suddenly they are the best developers in the world. No. Inexperienced engineers need guidance and support. Sometimes there are issues they just can't figure out, or a quick explanation saves them days of research. It's equally important to show them what to learn, so they invest their time effectively, and to help them achieve their best.
For senior developers autonomy is equally important, just in a different way. They already know how to program and write software. To improve they need a wider area of impact, get exposed to more and different technologies, and learn the "softer" aspects of software engineering. Not only soft skills, also how their choices impact the consumer, how to create a good architecture, which technologies to use, how to fulfill requirements without overengineering, so on so forth.
I'd say that in general, people strive for autonomy and freedom in their lives. Developers maybe even more so than the average person. Regardless of how much experience an engineer has, autonomy will impact their job satisfaction. Exactly how much is different for each person, also because more autonomy usually also means more responsibility. This is for their team leads to figure out. Overall I'd say though the more the better for employee happiness.
Impact on Team Leads?
Team leads are responsible for the team's speed and set, or at least have a strong influence on, all of the 3 axis of autonomy I described above (task size, definition and estimation). The way this is done not only affects the developers, but also the team lead.
The more detail a task description has the better, as long as it describes what to do. Team leads often got their position because they are great developers and therefore usually have an idea on how to achieve the desired result. For the sake of team efficiency and velocity they add their knowledge to the description.
For issues where speed or correctness are highly important this makes sense, but that are by far not all. For the others detailed descriptions about what to do just has the potential to reduce the lead's productivity. If there is a pointer of how to implement something, questions for more details will come, which sporadically interrupt both parties. When enough of that happens it becomes difficult for the team lead to focus on bigger tasks.
The increased time needed to do closer managing of developers (not just answering questions) reduces the size the team can have. It's possible to micromanage 3 people, with more macro management it can go up to 10 or maybe even more. So higher levels of autonomy save time.
The goal is usually not to reduce the autonomy of developers. How much they have is usually a side-effect of everything else they do, often from measures to increase the team's development speed or make planning more accurate. For example splitting tasks up because small ones can be estimated more accurately or exactly knowing how to achieve the desired result to reduce estimation variance.
Over the long run increased autonomy engages the engineers and uses their full potential, knowledge and creativity for solving problems. As mentioned above, this maximizes skill improvement and therefore increases the team's velocity.
All of that is justified by developers learning faster with more autonomy. I'm quite certain that this is true, but of course cannot be 100%. It might also be different for each person. Full autonomy doesn't mean no guidance or mentoring though. This can and should still happen. It could even have more impact in high-autonomy environments.
Actively giving more freedom is not always an easy choice. It means not always knowing the status of tasks, where difficulties are and when they'll be done. It makes coordination and future planning difficult. Also reporting is affected by that.
So currently I'm thinking that high autonomy makes the team lead's job is more difficult with the long-term reward of a faster team.
Conclusion
The topic of autonomy is a hard one. Most of the time it's a side-effect of other measures and not explicitly thought about.
My current view is that autonomy is the key to being able to manage more and more people, utilizing their full potential and keeping developers engaged. The exact way to achieve all that depends on the company, the environment, the team lead and the people making up the team.
There is, as always, but unfortunately, not a one size fits all solution.
Oldest comments (0)