Assuming you’re working in an environment where you have to communicate and collaborate with others, avoiding micro management starts out with the architecture of whatever you want to build. I was once asked how I would go ahead of leading a software development department, and my answer was; “Well, first of all, I consider everybody to be a lead developer one way or another.”
The above is a crucial mindset to facilitate for autonomy. Simply because as developers, our primary objective is often to become better, and as a manager I perceive my primary task to facilitate for that, within an environment where arguably the company’s primary objectives, are solved almost as a “side effect” of the individual team members’ personal objectives are being solved. By aligning the company’s incentives with the individuals’ incentives, your team members will be able to deliver 100 times more than if these are in opposition with each other. After a while, it becomes like “gravity”. Self sustained software development departments, with such momentum, that for the uninitiated it seems to be like a force of nature, you couldn’t stop even if you tried!
When you love your job, you don’t need to work a day in your life
I have worked below micro managers many times myself, and what always happens is that it destroys the spirit. This again results in that nobody does anything as long as the manager is not looking. Since the manager can only look at one person at the time, it ends up becoming an environment where you work extremely hard for 1-3 days every month, and then do your best at not being noticed for the rest of the month. Effectively, you end up becoming the hands of your manager, implying unless he explicitly thinks about what “his hands should do”, his hands doesn’t do anything. Due to that such managers always tends to take credit for everything that’s right, and always blame others for everything that’s wrong – The individual team member is never acknowledged, has zero room for growth, and everything goes south, stalling productivity, to the point where the individual team member becomes afraid of contributing, due to the fear of failing. My advice to you is as follows.
Allow your team members to fail
And do not blame them when they do. If you’re looking for brilliance, you’ll need an environment where learning new things is OK. If you want to allow for people to learn new things, they will inevitable have to fail before they get things right. If you don’t allow people to fail, you will never see brilliance, and words such as “innovation” is nothing but a false dream, you can never truly apply in the real world.
The fix for the above is what I refer to as “micro teams”. What I imply with that, are small teams of maximum 1 to 3 developers, working with as much autonomy as possible, given clear directions of what they’re expected to deliver up front, while the leader above them interferes as little as possible once the task has been given.
This of course is only possible with a micro service environment, where each part of the system is some sort of encapsulated component, solving one problem, and one problem only – With extreme amounts of cohesion, SOLID architectural principles, sound documentation, and segregated pipelines and teams. Hence, it starts out with the main project proposal, moves down into the system’s architecture, through the DevOps pipelines, into the classes, methods, and functions the developer in the end produces, every single day.
The result becomes increased personal responsibility and increased accountability on a personal level. Basically, you start out with a micro service specification, from a use case type of perspective, you hand it to the relevant team/person, they give you an estimation, and you leave them alone from that point on until they are expected to deliver. At which point your job as a leader becomes more like a conductor than a manager, realising each individual team member can probably play his or her individual instrument better than you can, and hence all you need to do is to get “out of his or her way”, to allow the person do what he or she is good at. Steve Jobs said this beautifully in his famous quote.
We don’t hire brilliant people to tell them what to do, we hire brilliant people such that they can tell us what to do
Another brilliant quote in regards to this is the following one of my CEOs once told me.
If you’re the smartest guy in the room, you’re in the wrong room
That was an amazing CEO. I simply adored the guy, and I felt personally responsible for his success, making me yearn to deliver even more, regardless of how much I a had already given him. A great leader brings more out of his employees than they thought they had within themselves, resulting in that every individual are proud about their individual contribution, and hence stays simply due to not wanting to let his leader down. You will often see that companies capable of applying the above principles have less people quitting, and their employees stays longer, feeling personally responsible for the success of the company as a whole. However, as a leader of software developers …
It starts out with SOLID code
And you thought this article wasn’t about code …? 😉