Software is core to the operation of our business, and as architects, we are the key conduit between business and technology. Being technical leaders within this intertwined relationship means that we have a responsiblity to make sure that our business decisions and our technology decisions stay aligned. Being in this position demands leadership skills that are equal or better than our technical skills, so that we can effectively align business strategy with technical strategy, communicate that strategy to teams, motivate both teams and individuals, and influence outcomes.
Although it’s tempting to imagine a leader as someone who tells people what to do and how to do it, it is simply impossible to scale that style of leadership to an entire organization. Instead, we can teach leadership principles and coach individuals and teams in how to use principles to make decisions. This article provides principles that I believe are essential to developing as an architect and technical leader within the organization. Use them to guide your decisions and influence your work.
Architects have to provide a vision, and a path to realizing the vision
In order to be seen as credible by the business, you need to define a vision of where technology can take us. Think and talk in terms of outcomes rather than in terms of tasks, timelines and technologies. A good technical vision provides a clear understanding of outcomes. Think clearly about what outcome you want to achieve, and communicate with clarity a path to achieve that outcome. As a technical leader, you are responsible for helping other people understand the outcome, and working with teams to help them implement it.
Take ownership
There is a difference between expressing an opinion and really owning the results of a decision. Architects must own the results of a decision. Owning the result means setting clear expectations for delivery of an outcome, and following through with individuals and teams responsible for delivering an outcome. It means objectively measuring yourself and your results to make sure we are held accountable for decisions.
Sometimes taking ownership can be difficult. It may require difficult conversations, negotiating with managers or directors, and knowing when to ask for help.
Architecture is not authority
Using architecture as a club of authority you yield to make teams comply does not build a durable relationship — you will wear through relationships with people and teams, leaving you unable to own the results of your decisions. “Because I’m the architect” is not a good reason for your decisions. Making these statements loses you credibility.
How can we be responsible without authority? By acknowledging the expertise of the developers on teams and enlisting their help, and creating an environment of openness and trust. It’s okay not to be the expert. It’s okay not to know everything. The power and authority of leadership may be necessary on occasion, but the true role of an architect is take on the responsibility of helping other people succeed.
You may think you get into a leadership position by having all the answers. What’s more important than being right is giving teams ownership in problems they help you solve. Help the team get better by asking the right questions. Guide their thinking in ways that help them grow.
Defend your ability to succeed
An excellent way to fail is to never say no. By taking on everything that comes your way you will fail. Know how to focus, know how to prioritize, know what is meaningful, and defend your ability to succeed at these priorities by saying no.
It helps to clarify the vision for your role. What are you here to do? What are you here not to do? Don’t take on tasks that are too deep in the weeds and block your team, and don’t take on higher level issues that are beyond your current scope. It’s okay to raise a hand and say “this can’t get done”. It’s even better to raise your hand early and often and get help prioritizing what is important. Get clarity within the organization for yourself and your team on what really matters.
Make yourself obsolete
“Great leaders create more leaders, not followers.”
—Roy T. Bennett
One of the best ways to scale a software system is to avoid synchronization points. Just as in software systems, coordination in human systems is expensive and does not scale. If you feel the need to review everything, or to understand all the code, or to be intimately involved with sprint planning, you are becoming a bottleneck and a project risk. To make architecture durable we need to give ourselves enough room to look ahead by stepping away from the present. Provide principles and practices that enable a development team to make decisions in your absence. Mentor, coach, and teach teams and individuals so that they can solve the problem they have and allow you to move on to the next problem. Create the conditions that allow the team to succeed, and create more architectural leaders in the process.
Shape the problem before the solution
If we don’t have a problem the technology solves, then we shouldn’t use the technology. Get better at creating problem statements and pushing others to give you better problem statements. A good problem statement should describe a desired outcome that isn’t currently happening or an outcome that is happening that shouldn’t be.
Clearly understanding the problem is a critical success factor for yourself and for they organization. Spend a lot of time on the problem, before considering any solution.
“A problem well-stated is half-solved.”
— Charles Kettering