For the last four years, I have had a rough pencil sketch sitting on my desk. Stick figures, infrastructure diagrams and Cupids. In this time, I’ve moved jobs, companies and continents. Yet, this sketch is still to hand, resplendent in bad art, coffee stains and all kinds of creases and rub marks from frequent moves and frequent handling.
It started life as a jovial attempt at explaining to HR what type of person I was trying to hire. It turned my star engineer into a stick figure character building bridges, busting legacy and getting a hug from the Corporate as the latter realises that said star engineer is the key to not just working out the future, but making the future work. Him. Star engineer extraordinaire. Not what he does, not what he knows: who he is.
Taking a step back to take a leap forward
Our banks are complicated beasts fed by unexpected growth and strategic acquisition, not design. Infrastructure came to serve the business, which in turn grew around the point of sale, itself reflecting the client need or at least the market opportunity. As things changed, tweaks were made and complexity was added. We didn’t scrap and start from scratch at any point. We optimised and streamlined, and above all else we specialised. There is hardwired separation between functions in banks. The silos may emerge separating units out by virtue of what they do or who they do it for; slicing functions by business or creating groupings by ‘step’ in a value creation process. Whatever the heuristic tool deployed, separation exists partly for regulatory proposes and partly to get a handle on the complexity of the business. After creating complexity, we added complexity to manage said complexity. Anon. The result is a degree of specialisation so extreme it becomes de-skilling to staff, who often become unable to change what they can only see a fraction of, and process has to trump logic in the absence of adequate information.
This situation is even more extreme in corporate and institutional banking, where such labyrinthine complexity is matched on the client side. That correspondence isn’t accidental – the organisations grew together and the constraints of available technology were common, as were the drivers of profitability. It worked, but there was no science behind it. It was good because it worked, and now it doesn’t really work any more, which means that no matter how good you may be within this setup, the setup is no longer any good.
What’s technically available combined with regulatory trends and increasing market demands means that it’s not your delivery that needs to be revamped: it’s your entire organisation, since it was a vehicle suited to a particular product, a specific delivery discipline, a moment in time. We know that. We are dealing with that. But old habits die hard and we’re still trying to fit change in the same organisational shape, still hiring and managing with the old hat on: looking for ‘fit’, looking for people who can do the job, even as it’s changing, because they’ve done it before. We’re looking for people who can prove they have the technical or product knowledge we needed yesterday, so we can tackle tomorrow. We’re still all about knowing, not learning. I hate to break it to you, but that doesn’t work any more.
Do what no one has done before. Every day
The stick figure at the heart of all this, my then star engineer, wasn’t a star because of what he knew. He was a star because of what he was willing to learn, and what he was able to do with what he learned. He was hired as a Java developer, and started playing with REST APIs in his own time, before it turned out we needed that skill for the day job. He was learning Scala and Kafka in his down time, had a PhD in theoretical physics and was a bit of a film buff. And if you’re like my HR guys, glazing over at this point, then wake up! Because it matters. His innate curiosity and tinkering nature matter. The fact that he’s interested in seemingly unconnected things absolutely matters. The fact that he has a horizon absolutely matters, because in a changing world of emerging capabilities, it’s who he is, not what he knows, that will make him useful to the corporate; his willingness to learn, understand, tinker and observe. Not what he did before, but what he’s willing and able to do next.
Assuming you could find him. Assuming you could recognise the super power. Assuming you manage to hire him. Do you understand what about him makes him valuable? Do you know how to manage him to get to that value?
The star engineer in question once ran regression testing on the colour distribution of candy in M&M packets. True story. The batch number apparently has no impact on how many brown ones you get. It was an ongoing experiment: every time someone in the lab had M&Ms, the data was logged and crunched (pun intended). Once a week, he would run the analysis and observe. It took no more than five minutes a day, but it worked wonders for the atmosphere in the lab. The shape of the questions the young’uns felt permitted to ask. Not just about candy. And that wasn’t even his intention. He genuinely wanted to know how the colour distribution worked, and without asking. He wanted to work it out. That’s the whole point. But every time a client visited the lab, the business wanted the M&M board covered up, and that’s when my stick figures went from joke to talisman.
In a world that’s coming to rely on learning more than knowledge as a survival skill, a business needs at the very least the ability to learn to recognise what it needs to learn in order to survive. M&Ms may not hold the answer to everything, but looking for patterns, answers and paths does. And if you find someone who thinks that way and can cut code, hire them and then give them a hug. Mould your organisation around them, because they will find a way to deal with your legacy and take you into the future. And since they like to learn new things, they will learn how you make money today. And since they like figuring things out, they will play around with how you can make money tomorrow (till they work it out).
As I said: stick figures, infrastructure diagrams and Cupid. Let’s face it. The infrastructure diagrams were for you, to reassure you. They don’t need them. They see the matrix. It’s time to stop seeing the people that hold the key to your digital future as stick figure abstractions with unknowable skill sets, and it’s time to get to know them and let them get acquainted with the guts of the business. The separation of old has outlived its usefulness. It’s in the way of your future profitability. Away with it. Love your engineers. For they shall build the Earth for you to inherit.
READ NEXT: Balancing experience and vision
Image by Ollyy, Shutterstock.com