Chief Architect: Day One
What should you do in your first day as Chief Architect of a large organisation?
I got to ask myself that question four years ago, when I started as Chief Architect for HSBC: it took me a long while to find (some of) the answers. Now that I have left HSBC for a new role, my successor has also had the chance to ask that question.
Here are some of our combined thoughts, in the hope that they will be useful to other people stepping into such a role. As with all offers of architecture advice, they are offered with a combination of confidence (won through learning from many mistakes) and humility (recognising that anyone people taking up the role will already have found some better answers than mine).
State your vision, then simplify and repeat
It might seem that the first step is to define your vision before you can state it. But, if you have been successful in getting this job, then I bet that you already have a vision (otherwise why did you take the job?) and that this vision fits your company (otherwise why did they give you the job?). You should believe in the vision you brought with you.
It might also seem that the next step is to elaborate this vision rather than simplify it. Even if you have a strong and clear vision, it is probably still at a high level, and will need the expertise of you and your team to figure out the details.
Elaborating your vision is a valid piece of work that you should put in your plan. But, as Chief Architect, you will need to persuade many people to follow this vision, and to do that, you will need to put it in a form which is easy to understand, and you will need to repeat it relentlessly. My prediction is that you will never cease to be surprised by the necessity to keep repeating simple messages.
Day one is a good day to start figuring out the words and ideas that will carry your vision throughout your enterprise.
Know your team, then make it stronger
Every leader depends on their team, but a Chief Architect depends on them in a particular way. You are accountable for the technology architecture of the organisation, but it is impossible for any single person to understand all aspects of this architecture. You will rely on your team to be experts (and leaders of experts) who know when to take decisions on their own, and when to seek guidance from you. This requires trust, and trust requires knowledge.
Yet, even once you establish trust with each of your team members, you are still not done. Architecture leadership teams, particularly in large enterprises, are often distributed: each of your team members will likely be accountable for different business domain or a different technology domain, and will spend more time with those business teams or technology teams than with you.
It is easy for such teams to fall into a hub and spoke pattern, in which you are the only person who connects the team, and everybody comes to you for help. But the team (and you) will perform much better if they establish the same level of trust and knowledge between each other as they have with you: they will be more comfortable challenging each other, asking for help and relying on each other.
This takes effort, and it is worth starting that effort on day one.
Claim your decision rights, then strengthen decision making
As Chief Architect, you have clear decision making authority over the way technology is used in the organisation (and if you don’t, go amend your governance processes now). But most of the time you don’t want to exercise that authority: you want to empower teams to make autonomous decisions close to the action, within the architectural guidance that you and your team provide.
Unfortunately, it is easy to let this natural desire for autonomy become a habit of woolly consensus building: to shy away from difficult or controversial decisions, and to try to find a way to get people to agree. Part of your job is to decide when to decide: when to use your authority to cut through indecision.
In order to do this well, though, it is important to recognise that decision making is a skill, and, like all skills, it requires attention and practice. Day one is a good day to figure out what you need to know to make good decisions: what data is going to make the most difference?
Plan to communicate, and plan to educate
As Chief Architect, you and your team will define strategies, roadmaps, standards and many other ways of guiding your colleagues: it will be obvious to you that these will not work if you do not communicate them effectively. (Not all technology architects appreciate the value of communication, but it’s unlikely that you got to be Chief Architect without understanding its importance.)
However, it may not be so obvious that you need to educate as well as communicate. For the really new stuff, it’s not enough to tell people what the plan is: you need to provide them with the skills and concepts to understand that plan. The need for education increases as the speed of technology change accelerates - and it accelerates every day.
Investment in education will also help you in decision making and governance. No matter how confidently you assert your decision rights and how good you get at decision making, it is better for people to choose to do the right thing because it is the right thing to do.
Day one is a good day to take stock of the level of understanding in your organisation, and to plan what you need to do to help them learn. It is also a good day to recognise the gaps in your own understanding, and to figure out your personal learning plan.
Fix the present, but make time for the future
It might seem that, as Chief Architect, you will have plenty of time to think about the future: after all, isn’t it part of your job to define a vision, to set strategies and to create roadmaps? That is true, but you will quickly find that much of your attention is required in the present (where the present includes the recent past and the near future). What’s the flaw in our architecture which left us exposed to that recurring incident? How will we hit our project milestones if we don’t make that vendor decision today? Should we renew that upcoming contract, or do we have time to switch to a different service?
There is nothing wrong with being grounded in the present: the architecture team has to tackle problems which need solving today, to deploy the right experts in the right places, and to make quick decisions that make a difference. But if we let the present overwhelm us, then the future will take us by surprise.
Day one is a good day to figure out which part of your schedule you will protect for figuring out the future.
Serve to Lead
All leaders should realise that their teams are not there to make them successful: they are there to make their teams successful. But this realisation should be particularly profound for Chief Architects. As described above, it is simply impossible for you to do everything and make every decision: you must accept that your role is to find people who are smarter and more expert than you, and to create an environment in which they can excel.
Day one is a good day to figure out how you will help your team be the best team they can be - and to start thinking about which of your team members will eventually succeed you and have their own day one as Chief Architect.
