Hacker News Reader

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.

OK sure - I didn't do nothing. But let's be honest - what I did was nowhere near as difficult as actually developing software.

On the contrary. Dealing with bullshitters is much more difficult than writing code.

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.

We love to say this, and it makes the techie inside feel good, but then why are there so many good devs and so few great leads?

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.

Dunno, I think I’d rather have one of you than one extra good dev.

The org also needs to be set up to do this though. I’d love to boot some people out of our meetings and prevent them from waffling on.

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..

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“

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).

Agree 100%. As a manager, I understand that my job is to make sure everyone else has what they need to do their job.

It’s not about asking “is it done yet?”. It’s about asking “how can I help you do this?”

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.

> the best project I ever lead, I barely 'lead'

Your post literally describes leading. All that stuff is exactly what good managers do. You manage "up" so your team can get work done.

Sounds just like scrum, and the job of the scrum master, as it is (was) actually described.

Exactly this, this is how a scum master is intended. First line of defense against distractions, nonsense and micromanagement.

It's definitely not the scrum masters responsibility to decide on requirements.

Can you be my tech lead, please

Maybe, is your company hiring?

So you were a Bullshit Umbrella

That's half of it, they were also the support network. Prop internally; shield externally

> - I ruthlessly pared down requirements.

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.

[1] https://www.youtube.com/watch?v=wdD80MkLEE4

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.

> had nothing to do with me being an incredibly inspirational leader

Are you sure about that?

Well, that may be hard to quantify.

> 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.