I wrote some time back about how we all write throw-away code, how applications have life spans and you don’t want to work on the same code for two decades. Recently I was discussing this topic from a slightly different angle, in terms of how a product team’s technical culture has momentum and how important it is to be able to shift that momentum over time. I speak here of the collection of tribal wisdom and best practices that influence the technical decisions of a team over time, the technical values that the primary decision makers rely on when steering the ship.
If you’re fortunate enough to work on a product that stays in the market more than five years, you’re probably going to be deploying it under somewhat (perhaps vastly) different circumstances than existed when you first architected it. You may have had “simplicity” in mind as a core value when you first architected the application, but what does simplicity mean today, in a world where most applications don’t even have installations any more? What does “security” mean when you may have to worry about a ransomware attack that takes your whole drive hostage? What does “efficient” mean in the world of ubiquitous virtualization?
Staffing your team with adaptable leaders who see those disruptions coming and adapt to them, perhaps quicker than your stakeholders do, can be critical for success. By the time your customers realize the winds have shifted, wouldn’t it be nice to be able to tell them a story of how you’ll accompany them in the new direction?
But you run a risk doing this; you can’t shift product direction with every changing breeze. Where do you draw the line? How do you define your values in a way that survives the test of time?
Hopefully you’re able to employ or provide mature leadership that can see the difference between a disrupting innovation and a distracting fad.
