Old Is New Again

It’s interesting how a lot of old are new again. And I guess I’ve been around the block enough times to see the similarity in things that have longer cycle times. Strategy doesn’t always repeat itself, but it sure does rhyme.

Looking at things through the eyes of a relatively well seasoned technology executive it’s hard not to see the same patterns emerge just with a slightly different flavor to them. The advances in AI are, without a doubt, going to change the way a lot of things work. But we’re seeing the same knee jerk reaction of creating executive titles with “AI” in the name, similar to what we saw with executive titles with “Data” in them, not too long ago. Sometimes it’s the right call at the time and can really be useful in helping an organization get its feet under it in a new area or a new way of working by making a new seat at the leadership table to advocate for it and educate about it.

But far too often those people don’t really get a seat at the leadership table. Before too long the role starts to feel like they’re a living breathing unfunded mandate. What seemed like it was the right thing to do, before too long starts to age like milk, and I’m not talking about a hearty chunk of Parmesan.

In my experience, while some of these roles do end up being successful, they’re more often a symptom of an organization that is unwilling to adapt to new circumstances. Specifically those circumstances where technology features prominently, but I’ve seen it in plenty of other arenas as well as a response to “crisis”.

The future calls for adaptability and impact. It always has. Being able to understand the desires of the business, key stakeholders in it, and deliver outcomes aligned to those needs and wants. Go a little bit deeper and that starts to sound a whole lot like the ‘ole agile manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Sure, some of the language may be just a little bit dated at this point, but it is 25 years old at this point and it’s earned the privilege to be. I think the key points of it remain quite true. And reading it while assuming the best of intentions, it sounds quite a bit like what we’d expect a Forward Deployed engineer / product manager, or a Builder would and should be doing. Or maybe a lot like what our best, brightest, and highest functioning teams have been doing since before there was a laptop on everyone’s desk.

I guess my take away is this, sometimes we had it right all along and new tools and techniques let us accelerate that rightness. Even if there is a little bit of rebranding along the way for those who have been doing things this way for a while.