6 ms·

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 unr

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.

brightball 5y ago
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.
- LAC-Tech 5y ago
  OK sure - I didn't do nothing. But let's be honest - what I did was nowhere near as difficult as actually developing software.
  - faangiq 5y ago
    On the contrary. Dealing with bullshitters is much more difficult than writing code.
  - adra 5y ago
    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.
  - winphone1974 5y ago
    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?
    - LAC-Tech 5y ago
      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.
      - mjhagen 5y ago
        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.
    - buu700 5y ago
      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.
    - deleted 5y ago
      [deleted]
cjbgkagh 5y ago
So you were a Bullshit Umbrella
- winphone1974 5y ago
  That's half of it, they were also the support network. Prop internally; shield externally
Trasmatta 5y ago
Can you be my tech lead, please
- LAC-Tech 5y ago
  Maybe, is your company hiring?
wmeredith 5y ago
> 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.
coding123 5y ago
> had nothing to do with me being an incredibly inspirational leader Are you sure about that?
- cema 5y ago
  Well, that may be hard to quantify.
kqr 5y ago
> - 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.)
doctor_eval 5y ago
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“
- ethbr0 5y ago
  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).
  - doctor_eval 5y ago
    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?”
- jseban 5y ago
  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.
  - doctor_eval 5y ago
    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.
jseban 5y ago
Sounds just like scrum, and the job of the scrum master, as it is (was) actually described.
- rb666 5y ago
  Exactly this, this is how a scum master is intended. First line of defense against distractions, nonsense and micromanagement.
  - hvidgaard 5y ago
    It's definitely not the scrum masters responsibility to decide on requirements.
deleted 5y ago
[deleted]
kavalg 5y ago
> 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 :)
- choeger 5y ago
  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.
kwhitefoot 5y ago
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.
rolandog 5y ago
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.
etripe 5y ago
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.
roeles 5y ago
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 https://www.youtube.com/watch?v=wdD80MkLEE4

brightball 5y ago

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.

LAC-Tech 5y ago
OK sure - I didn't do nothing. But let's be honest - what I did was nowhere near as difficult as actually developing software.
- faangiq 5y ago
  On the contrary. Dealing with bullshitters is much more difficult than writing code.
- adra 5y ago
  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.
- winphone1974 5y ago
  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?
  - LAC-Tech 5y ago
    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.
    - mjhagen 5y ago
      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.
  - buu700 5y ago
    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.
  - deleted 5y ago
    [deleted]

cjbgkagh 5y ago

So you were a Bullshit Umbrella

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

Trasmatta 5y ago

Can you be my tech lead, please

LAC-Tech 5y ago
Maybe, is your company hiring?

wmeredith 5y ago

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

coding123 5y ago

> had nothing to do with me being an incredibly inspirational leader Are you sure about that?

cema 5y ago
Well, that may be hard to quantify.

kqr 5y ago

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

doctor_eval 5y ago

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“

ethbr0 5y ago
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).
- doctor_eval 5y ago
  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?”
jseban 5y ago
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.
- doctor_eval 5y ago
  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.

jseban 5y ago

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

rb666 5y ago
Exactly this, this is how a scum master is intended. First line of defense against distractions, nonsense and micromanagement.
- hvidgaard 5y ago
  It's definitely not the scrum masters responsibility to decide on requirements.

deleted 5y ago

[deleted]

kavalg 5y ago

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

choeger 5y ago
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.

kwhitefoot 5y ago

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.

rolandog 5y ago

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.

etripe 5y ago

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.

roeles 5y ago

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 https://www.youtube.com/watch?v=wdD80MkLEE4