Let's start with some bold statements:

  • Team that did shitty waterfall work will most likely do a shitty agile work too (you can freely substitute the word 'agile' with Lean Six Sigma, CMMI3+, XP or whatever)
  • Nice tools can make a noticeable impact (by improving morale, increasing dev agility, etc.), but even the best tool won't solve the actual, root problem you have with software development quality / efficiency / etc.
  • No business product owner / manager / CxO (even the brightest of visionaries) will make your team successful, if it's your development team that is lacking something

Live with it. You're just floating around the actual problem.
Because it's all about ...


Ermmm, no, wait.


Oh yeah, that's better.

Even the smartest idea from the best book is useless if there are no proper executors.

What's the gain in having the best evangelist if people just don't give a f#$% about what (s)he says? Or they don't feel confident enough to implement the idea? Or they just don't understand it? Don't know how to start? Don't feel team's support to do it?

Don't get me wrong, I'm not saying that every team with not-that-impressive results is a bunch of idiots / sluggards / minimalists. Each team is different, you'll never have a team that consists of so-called rockstar programmers (and it's very good, I believe), BUT there's one category of people in software development teams that are absolutely CRITICAL regardless of what kind of method / platform / language / system you're dealing with:

"Inspiring Technical Leaders"

That's how I call them (in short - ITL). They are low-level influencers who:

  • have gains other respect by their practical programming skills
  • inspire, tutor & coach about 2-4 youngsters (not more, as it's about direct coop!) around them
  • set-up the atmosphere of continuous learning & improvement
  • pro-actively care about the quality of their work, feel responsible for it
  • are self-confident enough to push their ideas bottom->up

They are truly engaged programmers, who are not just good at solo codework, they are contributing to make WHOLE TEAM better. The lead in just micro-scale, yes, but they do it BY EXAMPLE, "in the field" & it's the best way to organically improve the software development processes.

If you're lacking ITLs (you should have at least 1 in each team), you're stuck in mediocrity: no method / tool / single leader can cover that gap (it's like having great generals & awesome weaponry, but missing the sergeants who are with the soldiers 100% of time in the actual battlefield).

And actually, that's what happens for the majority of companies:

  1. Some just reject non-management-related career advancement path, practically eliminating growth options for ITLs.
  2. In many cases managers are just afraid of ITLs influence -> that's why there are being tamed / silenced / moved aside. And their initiatives ceased ASAP, before anything good has a chance to materialize.
  3. I've also seen ITLs downsized to the role of one-man-crunchtime-army: assigned as responsible for the most important, delayed, hardest work, while all the others should not interfere & de-focus them... ;P
  4. In some companies unfulfilled ex-techleaders (who are now in more exposed positions) try to contribute in that area. But due to their limitations (lack of time, not being up-to-date, being stuck at their ivory tower) it just doesn't have any chance to work.

So, smart ITLs leave. Sooner or later. And no-one makes any move to keep them on-board.

Who cares - it was just a programmer, right? And besides, he was just a smartass, who absorbed others attention, so it's good he's gone.

Share this post