Leadership Principles

Leadership is founded on holding and executing certain principles—namely, the notions of trust, vision, safety, and clarity.

Establish Trust

Leadership is a learned skill. Some people have a natural tendency to lead, whereas for others it is a struggle. Leadership is all about trust.

Trust is in the examples we set for others and the integrity embodied in our actions (I do what I say, and I say what I do). Trust can be established in any number of ways: being an expert in a particular area; successfully delivering a project or part of a project; forming a social relationship; standing up for someone when that individual is in a defenseless position; enabling the other person to succeed; or truly listening to what someone is saying. Once you establish trust, your ability to influence and begin leading others goes up dramatically.

Conversely, if you destroy trust by invalidating the foundation upon which trust was established, your ability to lead others will be dramatically reduced. It will also be much harder to reestablish trust in the future.

If you have proven yourself trustworthy in the past, most people will give you a few breaks if you unintentionally do things that would normally erode trust. They realize that everyone is human and makes mistakes—but their forbearance is a very limited commodity, and you shouldn’t rely on it. Instead, learn to apologize and make it more than right.

Establish a Common Vision

Leadership is about establishing a vision that has the right context for each individual. In many ways, it is about sales—about helping people understand what the value of the vision is to them and allowing them to decide if this is where they want to go. The key is to get the right information to each person, because what works for one individual may not work for the next. Organizationally, the same is true. For this reason, you must get to know how each person involved in the project works and understand that individual’s point of view and concerns for the project.

Leadership is about establishing a common understanding of the vision. Even though you may have managed to get each person individually on board with the perceived vision, if the understanding of the vision is not cohesive across the team, the organization will not be aligned and relations across teams and other groups will likely be contentious. At best, such discord will cause an unintentional waste in organizational efficiency; at worst, it may cause the project to fail.

As an architect, you should consider using the 4+1 View Model of Architecture by Philippe Krutchen as a means of capturing essential details of the common vision. This approach uses logical, development, process, and physical views of a system, with use cases acting as the “glue” between them and illustrating the architecture for the “plus one.” Each view is a facet of a consistent whole. Variations on this model are also possible, but the essence of the approach is recognizing that different stakeholders have different needs, backgrounds, requirements, and even skills to bring to the solution and that, in turn, the architecture needs different views to accommodate each of them. Abstracting the key points of a solution for a particular model of a solution is the main skill underpinning architecture.

Establish Strategic Partnerships (Bring Safety Through Relationships)

Your success as an architect is often determined by your ability to establish strategic partnerships. The need for these partnerships will vary, as different facets of a product vision need to be taken into account.

The business vision for a product is usually established by marketing or new product development. Although you may be able to influence the product vision as an architect, you are usually not the product vision owner.

As an architect, you need to fully understand the business vision for a product, and you are ultimately responsible for turning it into a technical reality. To achieve this goal, you must be able to communicate the vision in such a way that the project team can understand it and lead toward it. By partnering closely with the business and with key members of a project, the architect can help maintain a common view of the vision throughout the product.

When establishing strategic relationships, it is important to focus on those parties who will influence your ability to progress from vision to final project delivery. The individuals or groups who meet this criterion will vary as a project evolves. To succeed at managing these relationships, you must understand the process that your organization follows for projects and product delivery. If you don’t, you will engage the wrong people at the wrong time.

For example, you may get to a certain point in the project when what seems technically possible may not be organizationally possible because of the opposition of a person or group that holds the keys to a particular door.

Perhaps your project needs specific hardware to be successful, but due to costs, competitive reasons, or operational standards, you may not be able to get it—and now your project is dead in the water. If you manage these types of dependencies closely and engage the right parts of the organization early on, you can avoid having these potential risks turn into real problems.

As an architect, you also need to establish strategic partnerships with those persons who can act as trusted advisors. These are people whom you can talk to and bounce different ideas off of—who act as a sounding board for your vision. Their input will help you formulate in your mind the organizational approach you may need to take to ensure the vitality of the vision. You need to know how to surf the organization so you can draw upon the knowledge and expertise of a wide range of individuals. An additional dimension arises when you are working with external regulatory bodies, white labeling partners, or third-party delivery partners. In such a case, the “organization” might be a virtual entity crossing company boundaries, but the same requirement for trusted advisors applies.

The more success you have, the more organizational trust you will establish. This factor will, in turn, enable you to have more strategic relationships and the freedom to control more aspects of a project. In the end, you will have more discretion to move outside of what was previously the accepted norm and take the risks that may be necessary for a project to succeed.

Eat Your Own Dog Food (Bring Safety to What You Say)

On any given project, you expect the members of a team to follow certain principles. For example, if you expect the team to act in a transparent way toward you, you need to act in a transparent way toward them, as well as to both your superiors and their superiors. In this environment, team members will find that things you say are things that are safe to do. Follow these guidelines to bring safety to what you say:

• Be transparent.

• Be who you say you are.

• Be open and honest.

• Act with integrity.

Doing these things allows you to establish trust with individuals from various areas of the organization. It also enables to you obtain the information you need to help the project correct itself when it goes off course.

If your coworkers see that your walk and talk don’t match, they are likely going to have a lower level of trust in what you say. Later, when you need transparency to understand what is really happening, they may choose to be a little coy about what is taking place.

You need to eat your own dog food; you may discover that what you are asking others to do is not as easy as it first appeared. If you are not willing to do what you are asking other people to do, don’t ask.

The best architects have some skills in all of the areas that their architecture covers, so sometimes the “eating your own dog food” criterion can be technical in nature. By following this approach, you see the problem from the other side. This willingness to bend also engenders trust as you will be viewed as “one of us” by the team in question.

Perceive Risk, Assess Impact, and Act (Bring Clarity to Risk)

As an architect, you constantly face situations that demand your attention. Some come to your doorstep (direct requests for intervention), some are simply observations of different project areas that appear to be struggling (lack of movement), and some involve project areas that are moving fast but in the wrong direction.

The key to dealing with all of the commotion and determining where your time is best spent is to do one thing: Determine which risks apply if you don’t get involved (not just risks to this project, but also risks to the overall portfolio of projects for which you have responsibility).

After things have settled down and have begun to be resolved, you need to ask yourself the following questions:

• How could this situation have been avoided?

• Was some kind of training missing?

• Was bad information disseminated?

• Did some information fail to reach the parties that needed it?

Finding the root causes of these types of issues will help you better prepare for the next project (or maybe just the next week). Learn as much as you can from mistakes and failures. Don’t let negative history repeat itself.

When things go off track, take the time to find ways to point this part of the project back toward the vision of what you are trying to accomplish. Find nonthreatening ways to explain what happened and let everyone involved know what things could be done differently.

Be prepared to answer questions from others about what happened. Don’t assign blame to people. Deal with the facts in an appropriate manner. Deal with private issues privately.

Deal with Risk Appropriately: What Is a Firecracker Versus an Atomic Bomb? (Bring Clarity to Impact)

When you are assessing the risk of what is happening in a particular project, there is always a balance between stepping in and keeping your distance (allowing project teams to truly own areas of the project).

If the impact is small to moderate, the project team may be best off struggling for a bit and learning the problem-solving skills needed to recover on their own. This is more of the firecracker size impact: The situation will get your attention, but it is manageable.

If the impact of the risk is significant—for example, if the project will fail or be dramatically impacted—you need to step in and help out in whatever way will best resolve the issue. This kind of situation is more akin to an atomic bomb.

Assessing risk tends to be a fairly subtle endeavor. There are rarely red flashing lights to tell you that you have a major emergency on your hands. The effects on the project are usually multiple steps away from the initial root cause.

Part of good leadership is learning to listen to your gut. If someone tells you something and the information gives you an uneasy feeling, you probably want to listen carefully and look into matters in more detail. After you have had time to gather the necessary facts, you can determine the best course of action.

References:
12 Essential Skills for Software Architects
By: Dave Hendricksen