Avoiding Backseat-Leaders — Effective Leadership in Software Development
Many organizations believe that strong soft skills and an ability to lead people far overshadows technical expertise when managing technical teams.
But, let me tell you, you can’t effectively lead developers if you aren’t a developer yourself. It’s as simple as that.
One of the most absurd scenarios in corporate environments is witnessing “leaders” or bosses who lack the same technical background as the teams they oversee.
Having non-technical people leading developer teams often seems like a comical mismatch. Non-technical bosses think ‘We need this by Friday!’ is a motivational speech. Conversely, technical team members may struggle to respect leaders who don’t understand the ins and outs of their craft.
There’s almost nothing worse than having a boss who doesn’t comprehend what you do, how you do it, or why you do it.
As a software developer, I guess you know exactly what type of “leader” I’m referring to.
Tech-leaders need to be individual contributors (ICs) as well.
The agile movement has made it worse.
Modern “agile” frameworks has opened up positions within development teams that were previously shouldered software developer, and has now expanded into full-time roles.
A hilarious example of this is Scaled Agile Framework (SAFe). You’ll find a ton of “management” roles, such as:
- Product owner
- Solution manager
- Solution architect/Engineer
- Solution train engineer
- Epic owner
- Enterprise architect
- SAFe Programme consultant
And a bunch more roles that I don’t remember the names of.
The hilarious part? The individuals actually creating the product, ensuring everyone else has a job, are simply referred to as ‘team members” in SAFe.