The cupboard under the stairs

Written by Leda Glyptis
2nd January 2025

I remember when we were in the basement.

If you are in business, the business matters. That needs to be something we all actively agree on.

It was not so long ago.

This isn’t a Harry Potter-esque ‘cupboard under the stairs’ story. In big banks, the IT folks (everyone from tech support, the people who will get you a spare mouse and reset your password after you’ve been logged out for the 17th time, to the people building systems for the people who made the big bucks for the bank) all used to sit in the basement.

Usually literally. Often figuratively.

Sometimes, the basement wasn’t big enough for all of us, and we were allowed to spill over onto other floors, but they were basement-esque in their aura and set-up. They looked emphatically like non-executive floors. They also looked nothing like the floors where the business folks sat. There was a difference: subtle, visible, palpable, real. And we all knew it.

The IT folks were never taken to meetings other than with other IT folks, or maybe with HR and like, their boss. We never got to see the clients and any and all business considerations were digested into requirements before we laid eyes on them. We were not given user stories, back then. We didn’t know what the users were trying to do… even less what the business was trying to achieve. No ‘business tailwind’ narratives for the likes of us.

Context and nuance was for the business. We were told what to do and we did it.

We weren’t even allowed to speak to our users.

We communicated via proxy.

The users spoke to BAs who wrote BRDs (and oh the fun we had with those), then we communicated back and forth via a sustained period of change requests and defect hunting (think of it as marriage counselling going terribly wrong but with a lot of green blinking cursors).

When that phase concluded, we communicated back to the user community via the medium of the Superuser: someone from the business who was going to represent All Users to us and learn All the Things they needed to learn about the system so that when it was rolled out, the other users would go to this user with All the Questions.

Not to us. To the Superuser.

And then at some unspecified time a few months (and occasionally years) after a system was rolled out, a team provided by a third-party contractor would turn up to do KT.

That’s short for knowledge transfer, and their job is to ensure that the esoteric knowledge engineers have of how the system works doesn’t leave the organisation in the shape of an engineer leaving the firm or in the form of the knowledge leaving their heads in the shape of garden-variety forgetfulness.

Of course, by the time KT happened, both of those eventualities had usually come to pass.

My most abiding memory of that time isn’t even the frustration of the engineering teams. It was the nonchalance that whatever happens over there doesn’t need to be understood anywhere else in the business. There are translators for that. The business will do whatever it does and the engineers will be told what to do and they will do what they are told so the business can continue doing whatever it does.

Obviously, those days are over. And not a moment too soon.

The digital era made sure of that. BRDs are (largely) a thing of the past. And engineers talk to the business. Heck, they even talk to clients.

Because we have learned that what we do and how we do it are more closely linked than we ever appreciated before. Because we know that the separation between the business and the way the business is delivered is artificial and future competitiveness relies in so many ways on that fusion.

The days where the business operated without the techies are over.

So, all is well, I hear you say.

But no, not quite.

I wrote a couple of weeks ago about how the vast majority of decisions inside your organisation are made by an engineer. I stand by that. But I also stand by the implication in my earlier piece: most organisations either don’t realise that or don’t realise what it means.

So even though engineers are respected a lot more and treated a lot better, the attitude of ‘voodoo happens here’ hasn’t entirely disappeared and there are many a senior decision-maker who are divorced both from the implications of the decisions made by their engineers and how they need to provide managerial context for the engineers to be able to make their thousands of daily decisions in alignment with each other and the purpose of the business.

This is where a bunch of you will pipe up and go, “That’s not us: we are engineering-led.”

By the way, if you are sitting there going, “Oh, whatever she says next isn’t about us, we are product-led,” I am afraid what I am about to say applies to you entirely also.

Because being product-led or engineering-led feels different for the folks inside the team but doesn’t change much else in the world.

You can have an engineering-centric culture and that’s great. You may be engineering-led in product development, and that’s fine. It’s not better or worse than product-led organisations. Just different. And the only people who have die-hard opinions on this are product folks and engineers themselves because the posture of the organisation changes who’s king of the jungle. But it doesn’t change the jungle for everyone else.

Besides, when it comes to entire organisations describing themselves as engineering-led, they are not referring to the discipline of not having unnecessary meetings. Of allowing work to determine the flow of your day. Of having a dynamic way of surfacing issues rather than trying to guess at everything upfront.

They are not even referring to the fact that we can agree to disagree on whether saying ‘good morning’ and ‘signing off’ on an email are ‘non-optional social conventions’ or can be dispensed with.

If they meant any of the above, I would be game.

But they don’t.

In my opinion, a lot of the times I have heard an organisation describing itself as engineering-led, they were trying to put a positive spin on their inability or unwillingness to operate in a way that commits to timeframes and deadlines. Clients wanting to know when they can expect to start testing, customers wanting to know when they will get a feature, investors wanting to see traction by a certain time.

Or the most existential metric of all: delivery moving at a pace that outruns cash burn as no cashflow = no business.

‘We are engineering-led’ doesn’t mean we are afraid of commitment.

‘We are product-led’ (which is invariably though less frequently used the same way) doesn’t mean we do not commit to timeframes.

It may mean we arrive at commitments and timeframes differently and negotiate accordingly, but it does not (in its purest form) and cannot (in its most practical form) mean ‘we do what we like and it will be ready when it’s ready’, because you are not five years old.

How you are organised internally, how you speak about different dependencies and articulate goals and enable the decisions to be made in a responsible way, can be product-led or engineering-led. Or business-led. How you organise internally is up to you. If you are a tech company, then by all means be engineering-led. Organise the cadence of your days and the way you measure your success around the ways of working of your workforce.

Show respect to their craft and their output. By all means. We are out of the basement and intend to stay out, and with that change comes a lot of other changes: around ways of working and development cycles. An understanding that requirements gathering, development and testing are much tighter cycles of dialogue than we ever thought before. We are still not 100% there, but we are absolutely getting there.

So when you tell me you are engineering-led, you’d better mean that your product lifecycle is led by the engineers who do the work. That your commitments are informed by the people who understand what it takes to deliver. And you’re realistic about dependencies and touch points and the need to come back and clarify whether the way you solved an unforeseen complication is still in line with the purpose you are trying to fulfil.

You’d better mean it is a way of putting your most valuable workers at the heart of your organisational way of being.

You’d better not mean that you feel you are above client commitments, deadlines and a diminishing runway.

Engineering can no longer be an afterthought.

We have learned that, finally.

But neither can business. Business can’t be an afterthought. And if you are in business, things like client commitments and deadlines and cashflow matter as much as your cultural purity. Arguably more.

Because a business can survive without cultural purity, but it cannot survive without money.

Whether you are engineering-led, product-led, investor-led or led by an army of magical lions with purple manes, if you are in business, adulting is expected.

Things like deadlines, cashflow and commitments matter.

They are all non-optional, you see.

Necessary and sufficient conditions for your survival.

And that should be something business folks, product folks, engineers and magical lions with purple manes should all understand and agree on. The basic fact that if we are in business, the business matters.

That needs to be something we all actively agree on.

Everyone else, can return to the basement.

#LedaWrites

Leda Glyptis is FinTech Futures’ resident thought provocateur – she leads, writes on, lives and breathes transformation and digital disruption.