I've been in technical leadership roles for over a decade and I have to say, in large measure it is quite unglamorous. What I mean, of course, is that you don't get to re-design or architect large-scale systems every week.
Technical leadership typically involves a daily influence over small decisions -- those tiny course corrections that keep things moving in the right direction.
Perhaps you suggest a more flexible architectural model for a subsystem or you work to prevent data-coupling between services. Maybe you write a bit of glue code to stitch together parts of your software pipeline or you weigh in on how using a specific Java library can make code cleaner, easier to understand and maintain.
Of course, your hope is that these small, consistent adjustments, when aggregated over months and years, will promote software excellence on a broad scale. Occasionally though, you do run into situations that are a bit more daunting.
Here's one scenario to think about:
A team has gotten stuck -- they are consistently producing poor results.
When you take a more in-depth look, it's obvious these are due to the adoption of bad software practices. The problem is that these poor results have, over time, caused a lot of pain to all stakeholders involved (Dev, Ops, QA, Product etc and most importantly, your customers). This causes everyone to fear and therefore resist any sort of change.
So what does technical leadership offer to this situation?
I believe that courageous, persuasive technical leadership is the only way to get a team unstuck.
Courage is needed because where fear and suspicion dominate, speaking out could be dangerous to your career. And you will need all your persuasive skills to navigate these types of situations and to start, in a reasoned and methodical fashion, to guide the adoption of good software engineering practices.
The good news is that the adoption of good software practices has it's own positive feedback loop.
Adopting best practices should result in improved results, and you can start to track and measure these small wins. This in turn will produce gains for stakeholders (or at the very least, reduce pain points) which produces an openness to hearing and adopting more of your suggestions. And so a positive feedback loop starts to kick in.
So, when you face those daunting and seemingly intractable situations -- stay steady, speak up and get that positive momentum going!
Top comments (1)
I’ve found that even something as small as a simple naming convention can have a major (positive) impact on a code base, and help it on it’s way to technical (and thus business) sustainability.