Ask the Architects: How do architects learn to delegate?

‘How do you learn to delegate?’

One of my colleagues recently asked me this question. As they are at the stage of their career where they are thinking about managing people for the first time, this is an important and delicate question: how do you successfully move from a state in which your success is dependent on your own skill and efforts, to one in which it is dependent on the skills and efforts of others?

This is a difficult question for anybody, but it is particularly difficult for technology architects. For many people in many other technology roles, a step into management or leadership means that they do less of what they did before. Developers become team leaders or project managers. Sys admins become service managers. (Of course, this drift away from technology as you progress in management is not always a good thing - but that’s the topic of another blog post.)

But architects carry on being architects, even if they carry an exalted job title, such as ‘Chief Architect’. At least, that’s the way we try to do things in the HSBC Technology Architecture team: whatever level we are at, we all try to set direction, make decisions and solve problems, and we all aspire to embody the principles of Zang Jing Ge: technical excellence, communication mastery and leadership power. We just do it with different scopes, ranging from the whole enterprise to the individual solution.

But if we carry on being architects, how do we get comfortable with other people defining some of our architecture? How can we be sure that they are taking good decisions (where we usually define good decisions as the decisions that we would take)? How do we resist the temptation to interfere or take over (especially if it feels easier to rewrite than to explain)?

Although I have to delegate every day, I have to admit that I don’t have a perfect answer to this question: it is something I continue to struggle with. So I did what I do whenever I need sound advice and a variety of opinions: I asked the HSBC Architecture leadership team.

Here are some of their answers.

‘Be self aware: recognise that if you are an architect, you cannot get rid of the instinct to solution.’ Gareth Henman, Chief Enterprise Architect

One of the things that makes us architects is that, if someone puts a problem in front of us, we will try to come up with a solution, to the extent that we even make it into a verb: ‘to solution’. And, if someone puts a solution in front of us, we will often try to come up with a better solution. While this instinct is often useful, it may become a golden hammer, and can be actively destructive if we are trying to delegate: how would you feel if your boss always felt the need to redo your work?

Gareth’s advice is not that we suppress this instinct, but to make sure that we apply it at the right level. If we are leading architecture for a programme, then our time is probably best spent figuring out all the moving parts of the programme, and deciding how to break them down into components which can be designed, built and operated independently. If we are leading architecture for an enterprise, then our time is probably best spent figuring out the objectives, capabilities and strategies for that enterprise, and finding the technology that fulfils those objectives, capabilities and strategies.

‘Embrace difference: recognise that not everybody likes to be managed the way you like to be managed.’ Kate Platonova, Chief Architect for Technical Domains

When managing others, it is easy to make the mistake of thinking that they like what we like: that if we like to be left alone, they like to be left alone (and that they won’t feel lost or abandoned), or that if we like a frequent, regular check-in, they like a frequent, regular check-in (and that they won’t feel stifled and over-managed). Part of figuring out how to delegate is to understand the ways in which your team members like to work - and to realise that they will be different from you, and different from each other.

And how do we figure out how people like to work and be managed? Kate’s advice is simple: we can start by asking them.

‘Use your experience: you know what it’s like to be delegated to.’ Andy Wrigley, Head of Comms for Architecture

We may not have much experience of delegating when we first step into a management or leadership role. (And we may not have experience of delegating well, even if we have been in a management or leadership role for some time.) However, we have all had experience of being delegated to, and we have an idea of what works (so do more of that) and what doesn’t work (so don’t do that).

Andy’s advice is to avoid the mistake that many managers make: to forget that we have plenty of experience of good and bad management - just from the other end.

‘You must build trust - in both directions.’ Tracy Hawkins, Head of Architecture Practice

It may seem obvious that delegation is a matter of trust: you have to be able to trust your team to make good decisions and get the job done. However, it is sometimes less obvious that delegation requires trust in both directions: your team must be able to trust that you will create the conditions of their success.

Tracy’s advice is to remember that, just as your team can undermine your trust if they fail to deliver, you can undermine their trust if you show that they do not have your support and confidence.

‘Play to strengths - but also develop new strengths.’ Katie Agus-Smith, Head of Business Architecture.

When you delegate, your most natural priority is to get the job done, so it is easiest to pick the person who has the most relevant skills and the most suited strengths. This is often the most rational choice, but if it is the only choice you make, you risk missing opportunities to develop your team.

Katie’s advice is to remember that every piece of delegation (like every piece of work) is an opportunity to learn and develop. When delegating, a completed task is not the only outcome we should seek - we should also seek a stronger team.

‘It is hard to let go, and even harder to admit that you are not the best.’ Rosalinda Chavez, Chief Architect for Latin America.

When you are first getting started as an architect, it is easy to feel daunted by the experts you find around you. As you grow as an architect, you deepen your expertise, and establish your place amongst these experts. People seek you out because they respect that expertise.

When you first step into a leadership role, it is easy to imagine that your role is now to be the expert amongst experts: the person who knows more than anybody else. But if you believe that, you will find yourself second guessing, rewriting and redoing much of your team’s work: it will be a barrier to effective delegation.

Rosie’s advice is that, if you are serious about being an architecture leader, you need to learn to let go, and accept that your job is often to amplify, refine and transmit the voice of your team, not to replace that voice with your own.

It is difficult to learn how to delegate well, especially for technology architects. But this week I was reminded that, as with many difficult problems, if you ask the architects you will get a diverse set of solutions, and that they’re all worth listening to.