Todd Biske: Outside the Box

This is a first in what I hope will be a few blogs around the subject of architecture by influence. There are no shortage of people who are writing that enterprise architects can’t be successful unless they have some teeth, i.e. the ability to stop activities in their tracks that aren’t compliant with the architectural direction. There’s also no shortage of people who have written that architecture by mandate doesn’t bode well, either. You’ll either never have that mandate (i.e. no teeth), you’ll leave so many dead bodies in your wake that morale will take a precipitous decline, or the first failure will be blamed on the mandated architecture and the team will be disbanded, or worse, fired. Well, my goal with these posts is to get away from these “what’s wrong with EA” posts and to start the conversation on ways we can make it work.

In order to do this, we first need to talk about the decision making process, which is the focus of this talk. If you don’t understand how decisions get made, you can’t hope to have systemic success with your architecture program, let alone your solution delivery efforts. How many times have you been on a project where meeting after meeting is happening and you just want to stand up and scream, “someone make a decision” It’s usually not for the lack of ideas, it’s usually because it’s unknown who has the authority to make the decision. In the early days of my career, I saw this all the time when a project had a project manager, but had no stated technical leadership. The team would look to the only hierarchy they had- the project manager- but the project manager lacked the knowledge to make good decisions. It’s the project manager’s job to make sure decisions get made, but the scope of decisions they’re normally trained to handle is schedule and resource management.

So, step one is to first understand who has the authority to make the decisions. If it’s unclear, clarify it first, don’t just bring everyone into a room and try to make decisions. There’s nothing worse than having a bunch of people in a room who think they have the power to make a decision, when they really don’t. That’s when things can get very ugly. Often times, the winner is not the person with the right idea, but rather the person who has the most domineering personality. Another common trend is that it is the person who holds the checkbook. For decisions that involve spending money, this is frequently the case. If funding is not in question, then this person may not be involved. Even worse, they may get escalated to this person (because they’re seen as the top of the food chain), at which point credibility erodes because they are likely to say, “What am I paying you people for? It’s your job to make those decisions.”

So, the next question is, how do we avoid personality-based or bias-based decisions? It’s human nature to fall into this trap, as we’re bombarded by it in virtually every facet of our life. The way I’ve found that works, and simply stated by a former boss of mine, is to get the decision criteria out on the table and get everyone to agree on it. If you’re worried about internal expertise, make it part of the decision criteria. If you’re worried that integration challenges will exist down the road, make it part of the decision criteria. Not only does this allow people to check their biases at the door, but it also gives the necessary context for people to actually present their options. If you don’t know what you’re being evaluated against, how can you hope to be successful?

This is one of my personal pet peeves when it comes to architecture reviews. Too often, the guidance for a team undergoing an architecture review is nothing more than, “you have to have one or more of these people that we believe are smart look at your architecture.” How can a team have any idea on what things are important to that reviewer or review board? They make their best guess, and then the whole thing dissolves into the reviewers trying to show that they know more than the team by finding something that was overlooked (and there’s always something) or opening up debate on other options, regardless of whether or not those options actually make any difference in what is going to be delivered. Again, it’s setting people on a path toward frustration, rather than setting them up for success. To be successful, make the team aware of what things they will be evaluated against up front, give them a framework for which options can be presented rather than an all or none checkpoint approach, and keep the focus on delivering the right thing, rather than on wielding power.

So, to summarize, here are the guiding points for analyzing your decision making process:

• Figure out who has authority to make decisions. Different people can handle different decisions, but you really want one person with the final call.
• Define the criteria for which options for each decision will be judged. Check your biases at the door. Make sure to prioritize those criteria, as well.
• Present options for the decision involved, and evaluate each option against the criteria. Avoid “I don’t know” for any criteria. If the criteria are known up front, there’s no excuse for not doing the analysis of your option against those criteria.

For some, this post may fall into the “stating the obvious” category, but at least based on my own personal experience, far more important decisions are made by personal bias or opinion than by this approach. You can make a career by having good decision-making ability, but all it takes is one bad decision to have it all come tumbling down. With a more fact-based decision making approach, it’s easier to see where the failure was due to poor, incorrect, or incomplete information supporting the decision rather than a poor decision maker.

2 Responses to “Making Good Decisions”