Senior people need to understand technology
It's a truism that the hardest job in engineering is that of 'Tech Lead'. You're the person who's not only writing code, but simultaneously leading a small group of other engineers and spending large amounts of time talking to stakeholders and the Product Manager (or, ten years ago, *Project* Manager).
This is taken from our Unfiltered newsletter. Subscribe now for a no BS, uncensored analysis of fintech news and hot topics delivered to your inbox each fortnight.
People who enjoy writing code don't, typically, enjoy spending time in meetings. In a small tech-focused company, you likely stand a better chance of keeping your hands on the keyboard. However, if you're in a large organisation, you'll eventually find yourself in a quandary. Your team is only a small part of the machine, and taking promotion means you're going to be spending most of your time talking to other parts of the organisation. Your main job becomes enabling your team and creating space for them to be productive. In practice, this mainly translates to ensuring everyone knows how valuable your team is, whilst managing a deluge of requirements coming in from multiple stakeholders. There won't be much time for coding.
Congratulations: you're an engineering manager in a big bank.
You're still an engineer, of course. You think you can still write code. Then again, officially I never retired from rugby, but I haven't played for a long time. In enterprise-land, your primary job is making things happen in a large (and usually byzantine) organisation. It takes considerable time, effort, and not a little luck to enact change in this environment. And the environment, the org chart, and the architecture is so complex that it's rare indeed that the efforts of one small team are directly connected to the customer, and thus to the company's 'bottom line'. If you're a Quantitative Developer on a Trading desk, maybe you can connect your pricing models and algorithms straight to profit. Otherwise, well, it's complicated.
So if you can't directly connect what you do to your company's profit, how do you really know what you should be doing, and how do you make decisions? You have objectives, set by your manager. And your manager's boss will set their objectives in turn, and so on, presumably all the way to the top. It could be KPIs, KRAs, or OKRs (which are all the rage these days). Either way, you're a long way from the top, and increasingly a long way from the coalface (or, if you will, the code base). Across your organisation, you'll have hundreds of peers, all with their own teams to protect, and their own interpretations of their objectives.
If you're making any technical decisions, particularly about integrations for systems you own, please, please involve the people who are going to be doing the work.
My unfiltered opinion
So, if you find yourself in a management role in technology in a bank, can I ask a favour of you? If you're making any technical decisions, particularly about integrations for systems you own, please, please involve the people who are going to be doing the work.
I've spent the majority of my career building software in banks, and I have lost count of the number of times technology choices have been foisted upon us 'from above'. Often, we're told that we need to use internal systems, internal platforms and services run by teams in other parts of the bank, and it makes sense, on the surface. If you need Capability A, and there's a team in the bank that provides Capability A, you'd use it, wouldn't you? The problem is that the Manager of Capability A doesn't write much code these days either, but is highly motivated to make sure that their system is used. So they'll genuinely believe that their system does everything you need it to (and more), and you'll be highly-motivated to take them at their word. Plus, of course, you'll have a tonne of political and management pressure on you.
To possess technical knowledge at a managerial level is so unusual as to be noteworthy.
So a roomful - sorry, zoom-full, of managers and stakeholders makes the decision to use the internal team’s version of Capability A, and some time later it's presented to the engineering team. The problems start sometime down the line when your engineers start trying to do the work: when they point out that it doesn't have a RESTful API (not even HTTP), or that it's down for 'routine maintenance' every night, and that it can only accept five requests per second. They will probably ask you who made the decision to use this system, and you'll likely tell them you had no choice (or, rather, that 'there was no choice', distancing yourself further). Too late now, though, and so commences a testy relationship where the other team argues your requirements are wrong whilst begrudgingly trying to make it work, while your engineers constantly argue for simply writing it themselves from scratch ("I could do it in a week, boss!").
All of this could be avoided if you either a) know the detail or b) bring someone from your team along to the discussion who does. To possess technical knowledge at a managerial level is so unusual as to be noteworthy. I once heard of a senior manager who was known to 'scare' Managing Directors, simply by virtue of the fact that she knew what she was talking about. Because, you see, you simply have to speak with credibility at a management level, because the people you're talking to don't know the details either.
We’re here to help build up your tech teams and offerings. Get in touch with one of our experts.