Architects on a Train

Maybe we shouldn’t have made the theme of our UK Architecture Symposium ‘disruption’.

To start with, when those of us in London tried to reach the venue in Sheffield, our journey was disrupted: the train was turned back just past Leicester, and the line shut for the rest of the day. And, when we tried to join the event remotely, we had to battle flaky wifi, a non-existent mobile signal and audio that only worked one way. Fortunately, if you put a bunch of architects in a room and give them a technical problem, they’ll find a way to solve it: through a combination of video conferencing, a projector, WhatsApp, an online survey site and a lot of hand signals, we managed to have a productive conversation, despite our physical distance.

But I was also reminded that inconvenience can bring opportunity.

In this case, it was the opportunity for the five of us stranded at Leicester (Aru Chakrabarti, Bunmi Alade, Joe Lester and Abhay Bhosale) to have an in depth conversation about our Technology Manifesto and what it means to be an architect at HSBC. As ever in such conversations, I learnt a lot:

We should emulate Spider-Man

One of the main principles in our Manifesto is that discipline equals freedom: that if we are in control of our business and the way we work, we can have as much autonomy as we want.

Everybody agreed with this, but had an additional thought about what this means for architects. As architects, we are lucky enough to be free from a lot of the operational work which our peers do: we don’t manage large teams and we don’t manage large budgets. Yet, if we are doing our jobs correctly, we have an enormous impact on the experience of millions of customers and hundreds of thousands of colleagues. We get to shape the services which we provide to customers and the technology which makes those services possible. We make decisions which affect the risks our organisations run, and the costs they manage. We have an enormous amount of power, even if that power is not always obvious through the formal company structures of hierarchy, budgets and reporting lines.

We need to be careful and thoughtful about how we wield that power. We have to impose on ourselves the discipline that goes with freedom.

And, we should remember that nobody has expressed this idea better than Spider-Man: ‘with great power comes great responsibility.’

Technologists like detail . . . and tools

One feedback we have had on the Manifesto is that it is quite long: it is 15 pages of text, rather than a set of headlines, bullets and slogans.

Interestingly, this was not the feedback from the team on the train. Just like many other technical teams who have given their feedback so far, they are not afraid of detail, and are prepared to read a slightly longer document to make sure that they understand (and can engage with and criticise) the ideas it contains.

In fact, we have found that most of our Technology teams want more detail: the most frequent question they ask is what measures we are going to put in place to hold ourselves to account for putting the Manifesto into action. Our teams seem to have appetite for a supplementary volume to the Manifesto which describes the practical steps we are going to take to implementation (this is why I love working as part of a Technology team).

The answer, of course, is that we don’t know yet exactly how we are going to put the Manifesto into practice and measure success. We have developed some tools: for example, for the section on leadership, we have developed a 360 degree feedback mechanism to help leaders understand their own behaviours. But, while a feedback survey is useful for this dimension of the Manifesto, it’s not right for everything. Through the conversation we are having across our Technology team, we are hoping to figure out which tools will best help us with the rest of the Manifesto.

Measure problems as well as successes

One of the most profound insights in our conversation came from Aru. Aru works with our Core Banking systems, and observed one of the most important measures for such systems is the number of failed processes. Our natural instinct is that the number should be zero, but Aru’s advice was that, in a large, complex set of systems such as Core Banking, we should aways expect failed processes: handling these exceptions without causing incidents is an essential part of the architecture. In fact, any time when there are zero failed processes is a sign that the whole system has probably stopped running.

This thinking applies to the adoption of the values in the Manifesto. In order to live up to the Manifesto, we will have to change, and we should expect to see some friction and problems in that change. If we don’t see any problems, we are probably not trying hard enough. And, even if we manage to achieve everything in our Manifesto, we will still have problems. We are not setting out to create a smoothly functioning machine in which everybody thinks alike. We are setting out to create a team in which talented, opinionated, motivated people can bring the best of themselves to bear in their work, and we should expect that to be messy. If we don’t have the human equivalent of failed processes (as well as the human equivalent of exception handling), we are not doing it right.

Sometimes silence is okay

The last insight really made me think. Joe, Bunmi, Abhay, Aru and I were all discussing the challenges of creating team cohesion in a globally distributed organisation, where everybody is fully consumed by the work directly in front of them. There is no magic to this, but the team all credited the Chief Architect they work for, Gareth Henman, with putting extra effort into the basics: creating the time and space for the team to connect several times a week, and to talk about themselves as people as well as about their work.

The key insight was that, when a team connects regularly like this, when it forms a genuine bond, sometimes silence is okay. We tend to forget this. When we are forming teams, we are taught to worry about whether everyone is engaged, and the easiest measure of engagement is how much they have spoken. So, we encourage people to speak up and make sure that nobody is left out.

This is often good practice when the team is forming. But when the team have been through their initial arguments, when they have failed and succeeded together, when they have genuinely got to know each other, they don’t all need to be loud all the time to know whether they are engaged. The mark of a great team is that they know each other well enough to know when silence signals a problem, and when it’s just a quiet person being quiet, or a thoughtful person being thoughtful.

Sometimes silence is okay. And that’s a good place for me to stop.