Stephen Brand is an architecture leader and has led teams at Fortune 500 companies across the United States.
He has developed architectures for and overseen delivery of systems in a wide range of industries from insurance and finance; to government and import/export; from healthcare to consulting; and done a bit of everything in-between.
When not corralling systems and their teams, Stephen can be found hiking the trails all around his home in New Hampshire.
Good Morning Stephen, Can you provide some insight into the key achievements and challenges of leading the architecture team in line with business and technical strategies?
Architects have to be business leaders as well as technology leaders. They have access to information on both sides and can be the bridge.
Speed of trust is vitally important when leading a team. As Stephen Covey said “Nothing moves faster in business than trust!”.
When interviewing architects, I ask only one setup question.
Tell me about a time when you lost trust in a business partner and what you did to get it back?
I’m really interested in how they think about it and go about gaining trust and building relationships.
How did a cloud based, SecDevOps environment benefit the business?
I spent over 18 months as a senior architect in a group where we spent a full year upgrading software, waiting for the infrastructure team to deliver a database and assess performance needs.
We had a traditional monolith system which took a lot of time to setup and validate even small testing environment.
We eventually did and end-to-end walk through into how the environment was built – what it took to actually get it working and how many requests to the infrastructure team it took – so we fully understood all the moving parts and every handoff.
We wrote out the entire workflow – of ours – and another team’s actual experiences – and the results were an astounding minimum of 6 months to complete. After discussions with the senior leadership team, who couldn’t believe the timescales, the decision was to move to the cloud and automate everything we could – no more tickets if we could. It was further relayed that if the team didn’t start automation, it was going to take longer in the cloud. A goal of months to minutes for deployment was set and 9 months later, a group introduced in front of the CIOs showed that the entire process took just 15 minutes for deployment!
This not only saved the business money on human costs and also time to market was fast-tracked. Also the development staff were not spending their time constantly debugging infrastructure and were instead able to focus more on solving business problems.
What key architecture principles did you set to ensure teams operated more autonomously?
First off, generally speaking, there are never enough architects to work full time with every product team so they have spread their time based on skillset of the teams.
This means is super important to communicate and document the thought process and let them run with what you taught them. This is what it means to enable the teams and let them own their decisions while providing oversight.
Our first principal is always “Architecture is about balancing opposing forces” – and COST is always one of those forces. Both the financial cost and the opportunity costs. One of the key opportunity costs is time to market – or as folks today like to say we’re living in a world with “economies of speed”. Sometimes to win – you have be first to market.
There are plenty of other considerations surrounding the data, security, operations, etc – and there will always be tradeoffs. That’s the value of having an experienced architect.
When training and mentoring architects, what key areas do you develop most?
One of the things that most organizations do is to take the most talented technical people and promote them upwards. As we do, we expect, but don’t typically teach them what they need to do to oversee larger and large groups of engineers. As their need to scale increases, so does the need for them to rely more and more on their people skills. As they’re also making more and broader decisions, and can’t possibly always be right – resilience is the main the areas to focus on.
Architects need to be able to coach and delegate and bring others along on the journey and it’s important that they are accountable to their peers and setting good example with their behaviors.
What podcasts, articles, blogs do you follow for continued learning?
Corey Quinn (Chief Cloud Economist at Duckbill Group) – https://lastweekinaws.com/
Gregor hope (Architect AWS) – Wrote the seminal work “Enterprise Integration Patterns” with Bobby Woolf. His other books on architecture decision making include “Cloud Architecture” “Architect Elevator” and “37 Things One Architect Knows” “ His blog on “http://architectelevator.com/“ is great.
AWS Enterprise Cloud Strategy Blog – https://aws.amazon.com/blogs/enterprise-strategy/ is also a good read.
Mark Richards (Software Architect) – https://www.developertoarchitect.com/ – also has a new book out with Neal Ford “Fundamentals of Software Architecture”.
Martin Fowler (Chief Scientist – Thoughtworks) – https://martinfowler.com and https://www.thoughtworks.com
Allie Miller (AWS Artificial Intelligence Lead / Forbes AI Innovator of the Year) – https://www.linkedin.com/in/alliekmiller/
Lex Fridman (Human Centered AI Research – MIT) – AI Podcast – https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4
Thanks Stephen for a detailed look at how businesses transform by adopting new technology and best practices.