My most eye opening leadership experience was last year. I was made tech lead of a small team, and asked to to accomplish something with a hard and somewhat unrealistic deadline.
It was a success, but it had nothing to do with me being an incredibly inspirational leader. Or being a brilliant developer - I don't think I actually contributed any code. It honestly wasn't much to do with me at all. I basically just set the stage for them to work effectively:
- I booted out all the non-coding people from our standup. The CIO in particular would waffle on, and it was draining everyones will to work (and possibly live).
- I ruthlessly pared down requirements. We had some written specs, and whenever there was a question about which way we should go I chose the one that either didn't involve us doing anything, or was easiest.
- I handled dealing with the stakeholders myself, and reported back to them the relevant info.
The end result was that they were the first dev team to deliver something on time in the history of that company. No one had to work any over time (demo was Friday mid-day, so I got clearance for them to leave early).
So yeah, the best project I ever lead, I barely 'lead'. I was a supporting player. I played interference. I made sure everyone left them the hell alone, that they had the information they needed, and told them that if it fucked up it was all my fault so relax (always blame the contractor).
And and they pretty much did it all by themselves. Turns out developers can develop if you trust them and get out of their way.
All true, but you did plenty. You got things out of their way. You made the call on trimming requirements when that normally would have resulted in scheduling a meeting to get approval.
Bravo for that. Getting decisions made is one of the biggest hindrances to moving forward.
That depends on the political environment, you still had to get the CIO to accept being booted out of the stand-up, the stakeholders to accept you deciding on the requirements and so on. Sometimes it's relatively easy, sometimes it's impossible.
Yep, he had the balls to stand up for the team, and to get away with that the organisation has to be very pragmatic and reasonable, which is not always the case..
Hmm. Maybe I'm just a mediocre maintenance dev but a decent tech lead. I went back to being a dev afterwards, and I was shocked by how much harder I found it.
I'll say one mistake is to have a tech lead that spends most of their time coding. I don't know how you can do everything else effectively if the company still relies on you to deliver code.
I'm facing this right now, but I enjoy coding so much more. It's a hard choice, but I'm leaning towards going back to coding full time. Worse career choice, but better for my sanity, I think.
A possible explanation is that leading a team effectively isn't necessarily more difficult, but rather that it might be less pleasant and/or less financially advantageous than being either an individual contributor or an ineffective team leader.
In my experience, it's way harder to find good managers than it is finding good developers. Maybe I've just seen a bunch of talented devs and outright terrible managers, but that's my data point.
What you're describing is leadership, just not the popular style. To put terms to it, you weren't doing Taylorist command and control, you were doing servant leadership.
In my opinion, yours is the only sane way to lead. With command and control, all you would be doing is creating the illusion of control, providing no actual added value. If your leadership style is adversarial, you're stimulating your employees to see you as a liability.
Totally concur with the other comments here - you were a great leader. The problem with “leadership” as a concept is that many people think it’s an active thing - pushing people to work harder and forcing your opinions into them. But that doesn’t work. Get out of their way and they’ll work out the most efficient way to get there.
Antoine de Saint-Exupéry said, “If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea“
I agree, in principle, but I think not only was he a good leader, he also was lucky to have good team members (which probably also became better team members from the trust and respect that his leadership got them). But a large percentage of people simply don't function when they are trusted and left alone, so it's up to someone to make a leap of faith, and not take the "safer" path of command and control. And when your livelihood is on the line, most people don't want to take any risk.
I don’t really agree with “a large percentage”, but yeah it happens, and identifying these people is part of being a manager, right? Everyone on the team needs to pull together, and we need to ask non performers to leave.
I don’t think there’s any real evidence that “command and control” is actually safer - the world is full of failed software projects - but I agree that it’s perceived to be safer, and the rest follows on from there I guess.
IMHO, the core epiphany in "servant-leader" is not about inverting authority, but about understanding that needs for high performing teams come from the ground up.
On the one hand, it's about solving problems so your team isn't even aware of them (typically, politics and spec stuff).
But on the other hand, it's about listening to your team and working on problems they tell you are problems (e.g. non-coders in stand-ups).
This, I'm starting to think, is one of the most important parts of the job. When people have their heads down in technicalities, every requirement becomes a challenge they gladly accept.
But in practise, you have to match the workload to the workers. That's the only way to ever do things on time.
(Though I am useful when I reject requirements, I do try to teach my team to stop every now and then and consider the actual value of requirements for themselves. I don't want them to depend on me for workload adjustments.)
That has been my experience as well; playing supportive interference, managing stakeholder expectations, and good communication and solidarity with your team makes for a much more productive environment than being a human version of a corporate whip.
As many are saying, what you did is great leadership.
A somewhat "out there" book on servant leadership that I really like is John Heier's "Tao of Leadership". It's an adaptation on the Tao Te Ching towards modern leadership. Here[1] is a part of it as audio.
Reminds me of the advice I read many years ago that said that the single best thing a manager of software developers could do was to take away their telephones to make sure that no one could interrupt them or pester them for extra features.
> I chose the one that either didn't involve us doing anything, or was easiest
In my leadership experience, in the long run this is a recipe for disaster. If every team does this, in the end you get silos and a toxic culture, where it is really hard to steer architecture and product changes. At meetings with team leads all will seem fine, but then there will be some silent, elegant and even somewhat unintentional boycotting and delays, eventually grinding the organization to a halt. After years this leads to major changes in the management chain and then rinse and repeat :)
It's really a fine line, I think. You cannot do everything and you cannot discuss everything. Unfortunately, you also often cannot undo such a decision cheaply later. (One of the big fallacies of agile software development is that making changes has essentially constant cost of effort, whereas in reality changes get more costly over time.) So the only way out is some kind of agency/ownership. Every team should have a basic understanding of the goals of the stakeholders so they can make such decisions in good faith.
It was a success, but it had nothing to do with me being an incredibly inspirational leader. Or being a brilliant developer - I don't think I actually contributed any code. It honestly wasn't much to do with me at all. I basically just set the stage for them to work effectively:
- I booted out all the non-coding people from our standup. The CIO in particular would waffle on, and it was draining everyones will to work (and possibly live).
- I ruthlessly pared down requirements. We had some written specs, and whenever there was a question about which way we should go I chose the one that either didn't involve us doing anything, or was easiest.
- I handled dealing with the stakeholders myself, and reported back to them the relevant info.
The end result was that they were the first dev team to deliver something on time in the history of that company. No one had to work any over time (demo was Friday mid-day, so I got clearance for them to leave early).
So yeah, the best project I ever lead, I barely 'lead'. I was a supporting player. I played interference. I made sure everyone left them the hell alone, that they had the information they needed, and told them that if it fucked up it was all my fault so relax (always blame the contractor).
And and they pretty much did it all by themselves. Turns out developers can develop if you trust them and get out of their way.