7 Lessons Learned Leading an Architecture Team
Over the last year, I've had the opportunity to head up the Architecture capability for a flagship program of a large FSI. Leading a team of Engineers to deliver complex technical solutions is not new territory. The challenges are well-defined, the results, achieved with lines of code, are far more tangible. From my experience, architecting with one or two like-minded individuals is also relatively easy. You first identify how to solve a requirement, then create a design for the solution. Leading an Architecture team has been quite an experience.
If you're looking for an article about rainbows and ponies and how things always went well, this might not be the one for you.
The lessons outlined below have been hard fought and are evolving. There have been moments of joy, such as successfully conveying a technical message to a non-technical audience. Equally, there have moments of pain when I've run over by a high-speed corporate train which I valiantly attempted to steer in the right direction. The opportunity to scale my delivery to have a wider impact is well worth the effort.
To be completely transparent, there are a lot more than 7 lessons. The following are my favourites.
Lesson #1: Have a vision
A key requirement for any leader, technical or not, is to have a destination in mind. If you don’t know where you’re going, you’re going nowhere.
In much the same way that wizards like Harry Potter are issued with a wand, Architects get a crystal ball. It may take time to arrive, but you will definitely receive it. What makes our job much more exciting is what happens in the present changes the future. Important to note that all crystal balls are issued with an optimistic outlook. The future you see should always be a better place than the present. Some insights are super vivid, but sometimes it will be vague. A mistake many Architects make is that they often wait for a crystal clear image before setting off.
From experience, the best way to sharpen the focus on the image, is to simply start with what you can see. Your goal - is to make that vision a reality.
Lesson #2: Tell a story
Once you have the vision, you need to share it with those around you. This is where you need to evangelise. You have to convince those around you that this is worth the time/cost/effort - to get to that better place in the future.
As your audience could range from senior executives to fellow Architects to super technical developers, you’re going to have to tailor your message accordingly. This is one of the reasons why Architects need to code. You also need to define a path from the “As-Is” (current) to the “To-Be” (future). Those cloudy crystal ball insights could add to the complexity, as you might still be figuring out the final destination.
A principle that has worked incredibly well is - interim to target. You might not precisely know what the target solution is, but your interim approach should be robust enough to support the target or pivot elegantly - without catastrophic changes.
Lesson #3: C-Level sponsorship
I have been extremely fortunate to have the support and guidance of a seasoned, no-nonsense, take-no-prisoners CIO. She has provided us with miles of latitude because she understands and believes in the vision. Equally, that support has to yield results.
It is always important to keep in mind that the decisions you make or suggest could impact the reputation, possibly the career, of your stakeholder. This makes it a two-way relationship. Be open and transparent. Highlight potential gaps, risks and consequences. Provide options or solutions when identifying issues. Meet regularly to share updates or status. Have a clear understanding of who does what. You have to complement each other. Importantly, trust and respect is an essential ingredient for a long-lasting relationship.
When under fire, it is reassuring and motivating when you hear the words “we win together, we fail together”.
Lesson #4: When in doubt, ask!
When joining a new organisation or team, there is always that initial period when you’re trying to figure out what systems are being referred to in meetings, or nod knowingly when you hear another TLA (Three-Letter-Acronym) while you furiously scan your notes to recall what it means.
This condition can be even more precarious stepping into a Lead role as the team looks to you to provide direction. Instead of adopting a “fake it till you make it” approach, I rely on the subject matter experts, who have years of experience and context, for their opinion and guidance regarding how best to approach a problem. The combination of their years of organisational experience and my fresh, and sometimes overly optimistic, perspective has resulted in some really innovative, enterprise-grade solutions to old problems. Asking for help is not a sign of weakness. It is a clear indication that you want to come up with a collaborative, inclusive solution.
This is also a two-way relationship, like the one with your executive stakeholder. You have to give as much as you take. There is also a “statute of limitations” after which you should know what is going on.
Lesson #5: Think differently
A key memory from studying World War II in school was that some countries took a policy of “appeasement” when Germany started invading its neighbours. This is precisely the same mistake I made when I stepped into the role.
To fit in, I intentionally steered away from making any major changes. I also opted for taking people on a journey. The approach was to build small and incrementally in a non-critical area to show results. I had allowed myself to get caught into the whirlwind of the current project delivery and instead of executing toward the vision I had seen and was evangelising, I was running the business as usual.
You can’t be preaching a new way to do things while practising the old!
An approach I’ve since adopted is to regularly chart progress toward the vision. If you’re in the same spot, you’re going nowhere. Be careful of getting caught into the trap of thinking you’re moving, but you’re actually going in circles!
Lesson #6: Prescriptive guidance
Many years ago, during an intense but entertaining debate over email with a Customer Architect, the debate came to an abrupt end with the phrase - It’s a democracy for as long as I say it is!
One of the blessings of working in IT is that there are a myriad of ways to solve a problem. It is also a curse! And oftentimes, we allow ourselves to get sucked into the existential debate of Java vs BPEL or Lambda vs Container - all the while missing the forest for the trees. The consequence of the policy of appeasement I was following (above) is that reviews of architecture designs took months. The benefit of rapid delivery as I had evangelised was rapidly evaporating!
If you want to make friends, get a puppy. It is impossible to please everyone all the time. Although the development team might feel they’re living in a democratic world, they do not have a view, or feel the pressure of a departmental/organisational objective for adoption of new technology.
You will often have to make a unilateral, but hopefully data-driven, decision. It is key to have a set of well-defined and well-shared architecture principles which not only guides the design process, but also supports the decision.
Lesson #7: Create a succession plan
A valuable lesson I learnt early in my career was that I could only move off a project if there was someone who could replace me.
This is one of the reasons why I do my absolute best to share what I know with the team around me. It is also important that you share with everyone, not only those in your immediate team or organisation. If more people understand a concept, there are different perspectives and ultimately more robust solutions. The only thing more rewarding than observing a session where everyone is talking about solving a problem using your vision, is when you see someone elevating or optimising the vision. This is confirmation that they see what you saw in your crystal ball, possibly even more vividly!
Your next question is most likely - if they don’t need you, what do you do? This is a perfect opportunity to return to Lesson #1 - go have your next vision!
Leading an Architecture team can sometimes be a lonely journey. Peering into crystal balls and trying to determine if what you see is an epiphany or hallucination can be stressful. Equally, the roadshows and campaigns to sell and evangelise require significant amounts of interaction, calm and patience.
However, it is extremely fulfilling when you see your vision come to life to support and drive your organisation's objectives.
Note: I work at Amazon, but this is my own opinion.
