Given my academic background in philosophy, I am prone to asking myself the cosmic version of the question, “Why are we here?” and “What is the point of our existence?” As a senior leader in a technology team, and as a senior technology architect in a large enterprise, I am also prone to asking myself the more local, lower-case version of the question “Why are we here (at work today)?” and “What is the point to what we do (in this job)?”
This question feels especially pressing when I get to spend time with our DevOps teams delivering solutions for customers and colleagues. It was particularly acute recently when I visited several of our Commercial Banking teams in London where they showed me how we are working to improve our understanding of customers and to give them a better experience; how we are trying to transform not just the systems we use to support Trade Finance, but also the way Trade Finance is done; how we are automating and improving service management; how we are making powerful APIs available to a community of external developers, and how, through our Kinetic app, we are attempting to make it easier for small- and medium-sized businesses in the UK to manage their finances.
When I see people from a business background and people from a technology background solving problems together, working on code, infrastructure and security within the same team and having fun and succeeding together, it feels right; it’s as if this is the way things are supposed to work.
But it also prompts me to ask those difficult questions: What’s the point of technology leaders and what’s the point of senior technology architects? These teams are evidently delivering value every day. They are demonstrably successful. They clearly need expert architects, but they need them there in their teams alongside them, not in head office on the other side of the city. Shouldn’t we just follow the HSBC Technology Manifesto and, having found the best people for the job, get out of their way?
Fortunately, (for the sake of my own self-esteem - but also for others who are planning their careers), I think that there are reasons for technology leaders and senior technology architects to exist, and that the most important reasons are: To create an environment in which teams can succeed and to help them when things don’t work.
We are here to create the environment in which our teams can succeed.
No matter how autonomous and self-sufficient a team, it needs an environment within which to operate. This is as true for a start-up, in which the founders need at least to secure premises, provisions and essential technology, as it is in a large enterprise, in which leaders need to secure funding, accommodation and other resources for their teams. Teams that have to figure out where they should sit will not be productive teams.
This applies to the technology environment as much as it does to the physical and financial environment. In a start-up, it is possible for the founders and their first hires to make fundamental choices such as which Cloud to host on, who their network provider will be, and the basics of their software architecture. But if every team has to make these choices for themselves, then the slower they will go. A big part of technology architecture is settling these mundane choices upfront, and the more teams there are, the more they depend on these choices being settled.
We are here to help our teams when things don’t work
The range of problems which can be solved by a small, motivated and expert team, working with technology in a supportive environment is extraordinarily large - but it is not infinite. Every team will run into organisational problems which are beyond its ability to solve. DevOps teams containing people with business, software, security and infrastructure expertise are great things when they come together - but they do not always come together. Sometimes these people don’t get on, and have become used to working in isolation from each other. That’s when leaders are needed to bring teams together, align structures and incentives, and help people work through the hard graft of changing habits and beliefs.
Similarly, every team will run into technical problems which are beyond its ability to solve. The AI model needs data which is scattered across the organisation in forms which don’t reconcile or make sense. The mobile app is so successful that traffic exceeds the capacity of the network. This business process is dependent on functions embedded in multiple applications outside the control of the team, and many of these applications were built before APIs were a thing. That’s when architects are needed to figure out capabilities required across the enterprise, to address cross-cutting design questions, and to provide standards which, rather than imposing unwelcome constraints, help people, systems and data to work with each other.
I am not so modest as to believe that these are the only reasons for technology leaders and senior technology architects to exist: I believe that it is important to set a vision and purpose for the technology organisation, to orient structures and resources to enterprise goals, to find and develop the best people, and to nurture culture.
But I also believe that all these more exalted purposes are subordinate to the fundamental work of creating an organisational and technical environment where teams are free to do their best, and solving problems which those teams cannot solve on their own. This work is not always glamorous and sometimes feels like spadework and plumbing, but without spadework and plumbing we don’t have a civilisation.