Which part of the script are you in?
I am going to tell you a story that is entirely hypothetical.
I know you know that no real persons were harmed in the making of this story because it didn’t happen. It’s fictional.
I also know that you probably have about 30 real stories very similar to this one. So feel free to fill in the gaps of this made up story with your own version of this.
You work in financial services. It may be in a start-up. It may be in a bank. It may be in a tech provider. In what I am about to describe, they are literally all the same.
In your organisation, things will get built every day.
There will be a process for sign-offs, approvals and reviews, and although everyone talks about meritocratic approaches and engineering-first cultures and all that good stuff, the reality is there is a hierarchy of power… and a hierarchy of decision making… and a sequence of things… and there are important decisions made in rooms with important people and then there are people in other rooms who do the work and some people who run between the two rooms, providing status updates to the important people. If big issues need resolving, there is an escalation process whereby the important people get the salient facts summarised for them (read: over-simplified) and the available options explained so they can make a decision at the right level of accountability.
Sure.
Yeah.
Only, it really doesn’t work that way.
What constitutes an important decision?
This is a serious and unanswerable question.
In our hypothetical story, the CTO of a bank or a start-up or a tech provider deemed critical or important is called in front of their regulator because of an outage that impacted consumers.
That happens every day, by the way.
And, let me state the obvious here, even though it happens literally all the time, it is not a thing anyone wants to experience. It’s even worse if you go to the first couple of meetings unable to pinpoint exactly why the outage occurred, even after you have resumed normal service.
After what feels like years (but overworked teams assure you is only three days), you identify that the outage occurred because of a design choice in one particular service that required re-authentication if you took longer than a couple of minutes to complete a transaction. If that didn’t succeed, it sent itself into a spiral of doom by bombarding the server with pings until it satisfied its security requirement.
Is that an important decision? Designing the service like this?
Arguably it is one of the many ways in which you could do it and it’s no better or worse than many others. OK, maybe it’s a little worse, but honestly I have seen some horrors in my time and this isn’t it.
Is this a decision the engineering team was allowed to have made on their own or was it an important decision that needed to be made by important people and communicated to the whole team?
Because if you look at its potential impact after the fact then, well, yes. It is a very important decision. But if you asked your ExCo to opine on the design choices for authentication handshakes or take a view on server management and capacity requirements, they would probably glaze over before you even finished the sentence.
And arguably that is dangerous, and across the industry we really need to have more technical know-how at the top table but, the reality is, even if you had an ExCo made up entirely of ex-engineers, you would still not be asked to opine on these decisions. Because thousands of such decisions are made by your engineers daily.
That is literally their job.
That is what you hire and pay them for.
Which decision is important is a moot question. They are all important. They are all unimportant. They are all as important as each other.
And none would have been made better by bringing it to the room of important people for a view.
OK, great, I hear you mumble. Helpful as ever. What do we do instead?
So glad you asked.
Three things:
- The people in the very important rooms with the very important hats need to realise that the vast majority of decisions in their organisation are made by engineers. Not them. Not anyone else in the room they are in. And not the people running between that room and where the engineers sit.
But by the engineers themselves.
What they need is context to understand and manage dependencies.
Not directives.
Context.
Not imperatives but guard rails that allow them to colour within the lines of business drivers, regulatory requirements across geographies, budget and pricing considerations and also the lines imposed by inter-dependencies. I did this so you need to be mindful of that, type territory.
- The engineers need to understand where in the machine they are and what upstream and downstream consequences their choices have and actively manage those dependencies as part of their job each and every day.
It’s a distraction, I know. But it is the job.
- Everyone inside the organisation… and I mean absolutely everyone… needs to be actively aware of which part of the plot they are in, so to speak. As if building a business was the script of an action movie.
Where is action taking place right now and are they involved? How far down the story are we with decisions already made? What cumulative impacts do we have? What quests and side quests and challenges do our heroes need to battle in the shape of regulatory expectations and budget constraints?
What do we need to do next to flex the story in the right way? It may be a small thing or a big thing. It may be a decision that won’t feel important unless you know which part of the script you are in.
#LedaWrites
Leda Glyptis is FinTech Futures’ resident thought provocateur – she leads, writes on, lives and breathes transformation and digital disruption.
She is a recovering banker, lapsed academic and long-term resident of the banking ecosystem.
Leda is also a published author – her first book, Bankers Like Us: Dispatches from an Industry in Transition, is available to order here.
All opinions are her own. You can’t have them – but you are welcome to debate and comment!
Follow Leda on X @LedaGlyptis and LinkedIn.