Precision questioning and answering

Of course architects don't have answers to all questions, but it's critical that they know how to ask precise questions. Sure, you know that, and you've heard it said many times before but I do want to focus on it for this post. I've worked on many projects over the years where people simply asked unclear questions and as a result, got unlear answers.

I certainly don't mean to imply that the person you're questioning doesn't also play a part in the process. If person A asks an unclear question, person B is equally obligated to ask clarifying follow-up questions, but oftentimes, users don't know which questions to ask so ultimately, asking the precise question falls back on the architect, program/project manager, etc. The impact of unclear questions and answers is unlimited however. Having spent many years as a consultant, I've seen multi-thousand person divisions of companies head down the wrong path for a year because their leader didn't ask clarifying questions of their leadership at the start of the year, likely for fear of looking incompetent. At the end of that year though those leaders incompetence became abundantly clear as they "decided" to leave the company and go "spend more time with their families." If you're not clear of what you're being asked for, ask clarifying questions, your success and everyone else's depends on it.

"Judge others by their questions rather than by their answers" --Voltaire

Of course there are many styles of questions (open-ended, close-ended, etc.) and effective architects must know which situations warrant the appropriate questionning style, but in any case...be precise in your questionning...and, equally important, in your answers. Avoid using vague terms in questions such as "When will you be finished?" if you and the person you're asking don't agree on what the word "finished" means. If you're asked a yes/no question...answer it with "yes" or "no"...not an explanation that requires the person asking the question to infer whether the explanation actually equates to "yes" or "no." This requires you to be very deliberate in what you ask and answer...and it's not a skill many are proficient at. You certainly can get better at it though, and must if you want to increase your effectiveness.

A wealth of resources to help you improve your questioning and answering skills are available at Vervago's PQ & PA Skill Sharpener site. Additionally, a good 3 part series on questioning principles can be found at the Creative Streak blog.

Be accountable for your actions & hold others accountable for theirs

The highest performing teams that I've worked with have the best mix of:

• Each individual on the team knowing their responsibilities (and the ability and ambition to execute them), as well as the responsibilities of their teammates.
• A commitment by everyone on the team to execute their responsibilities to the best of their ability...all the time, as well as a commitment to provide respectful, direct, and honest feedback to their teammates when they're not executing on their responsibilities.

Does this mean you don't help teammates when they're not at their best? Absolutely not...but there's a big difference between helping people and trying to do their jobs for them because you believe yourself to be better than them at it. Trust me, you're not.

Over the years I've worked with many people that either aren't completely clear of their own responsibilities and/or their teammates' responsibilities, their teammates aren't completely clear of their own and/or their teammates', or most often, some combination of all of these. There's a word for this...it's called anarchy.

Imagine a football team where nobody really knows what their responsibilities are exactly. Do you think they'd ever complete a play successfully? Do you think they'd ever win? Sure, maybe sometimes, but their ability to do so would largely be by chance. If you don't fully understand your responsibilities, get clarity from who you need to so that you do. If you don't fully understand your teammates' responsibilities, then get that clarity too. Once you have that clarity, be the first to admit it when you don't execute well on your's. Additionally, be the first to respectfully and directly speak to your teammate when they don't execute well on their's (though of course, the "pick your battles" rule always applies).

The book Crucial Confrontations is in the Recommended Reading list for this blog, and is a great tool to help you with these conversations. The worst thing you can do is go around people you believe aren't doing their jobs, at least not based on what you believe their job to be. This doesn't fix problems, and unfortunately, often creates more. The next worst thing you can do is to try to do people's jobs for them. This is just irritating, patronizing, and insulting...not to mention it takes you away from what you're being paid to do. Don't do it...you don't want people trying to do your job either. Instead of doing these things, provide respectful, actionable, and direct feedback to people. It will help them improve, and most people are thankful to those who help them improve.

Effective architects give effective feedback, are accountable for their actions, and hold others accountable for their actions because they know that's the only way problems really get solved. A resource that effectively illustrates this and other attributes of dysfunctional teams is the book titled The Five Dysfunctions of a Team: A Leadership Fable. It takes an interesting approach in that the "lesson" is told through a fable played out by characters. Though the "team" is an executive team in the fable, the underlying problems they face will resonate with you in different teams you've been on I'm sure.

Technology breadth and depth

While all architects were experts in certain technologies at some point in their careers, they now spend more time learning all they can about as many different technologies as they can rather than spending significant time learning all there is to know about a few technologies. Why? Because effective architects make the best (rather than right, see separate post for more on this topic) technology decisions to solve specific business problems. To make the best decisions, they need to know a lot about a lot of technology. There are simply too many technologies and too much too know about each one to stay deep in a given technology for long. So, what does it mean to know a lot about a lot of technology? Consider the following steps:

1. Start with a technology area, say customer relationship management (CRM) software, programming languages, operating systems (OS), etc.
2. Research to determine what offerings exist in the area selected in step 1. For example, if the area were personal computer operating systems, you'd identify Windows (multiple versions), Unix (multiple varieties), Mac OS (multiple versions), and Linux (multiple distributions) for starters. An excellent resource to start you down the road to identifying areas and offerings are the IT Roadmaps, developed by Jeff Tash.
3. Determine the pros/cons for each offering identified in step 2. You can often find product comparisons with simple Internet searches. Of course, comparisons can be biased based on who's doing the comparing, so be sure to read multiple comparisons from multiple sources. The pros/cons shouldn't just be based on feature/functionality, but also on pros/cons in meeting service level requirements for scale, availability, fit with existing software products, etc.
4. Select another area and complete the process again.

For each of these steps, you'll of course want to prioritize based on what's most important to the current position you hold or project you're working on. At this point though you'll have a fairly good breadth of knowledge in the areas you've researched. So what's depth then for an architect? Within the area you selected previously, complete the following steps (for starters) for each offering:

1. Understand the key components of each offering and how they relate to each other. For example, a CRM offering typically has an application server component and a database component. Each of these components may further have dependencies on specific database and OS technologies.
2. Understand the authentication options available for each offering and which options are relevant for your project.
3. Understand the offering's dependencies, and how those do/don't coincide with your existing environment.

Armed with this knowledge you can now begin to make the best technology decision for a given project, as well as in the future, though of course, you'll need to refresh your knowledge over time. Certainly, during implementation you'll learn even more about the chosen offering, but once its implementation is complete you may not ever touch it again. With all of the offerings available in different areas, it's almost impossible to stay current with it all, and it's certainly impossible to stay deep in a specific technology, unless you are a specialty architect. Effective architects' depth lies in multiple offerings across multiple areas, whereas technologists' depth within an offering is deeper, but less broad.

Operating within systems

On a daily basis, you participate in many systems. There are ecological systems, market systems, organizational systems, project systems, and an infinite number of others. Oftentimes, people participating in these systems don't understand the other participants' goals, the dynamics between them, or maybe not even that they're a participant in the system themselve. An approach to understanding this is called "systems thinking." Wikipedia defines systems thinking as "any process of estimating or inferring how local policies, actions, or changes influences the state of the neighboring universe. It also can be defined, as an approach to problem solving, as viewing "problems" as parts of an overall system, rather than reacting to present outcomes or events and potentially contributing to further development of the undesired issue or problem."

Effective architects must be systems thinkers, as if they're nothing else, they understand relationships between things...whatever the things are. Systems thinking requires you to understand the relationships between participants in systems and their causes and effects on each other. Most human beings by nature tend to focus first on their own needs, goals, desires, and objectives and often forget that everyone they work with does the same. This has unfortunate side effects given that many of the objectives you might have in life require help from others who have their own objectives that oftentimes, conflict with your own.

Strategies for finding win-wins is detailed further in the post titled Don't confuse influence with authority, but people who don't possess those skills or insight often simply assume that others are stupid, out to get them, or are up to something, because they don't understand this dynamic. Systems thinking helps you understand that just because others' might appear to be out to get you, oftentimes they're instead, just trying to achieve their objectives as best they can within the system, just like you are. In fact, if you better understood why they did what they did, you'd probably discover that if you were in their shoes, you'd do the same. Unfortunately though, many people don't take the time to better understand others in the system, because they're so consumed with their own objectives.

I've worked with many people over the years who believe that just about everyone who works outside their own team is stupid, inefficient, or out to get them. These are people who either don't understand systems thinking, or just don't care I suppose. Don't get me wrong, there are a lot of stupid, inefficient people in the world, and some are out to get you. The better you understand systems thinking however, the fewer of them you'll come across, because you'll start assuming the opposite instead...that your perception is probably incorrect because there's something going on that you do not understand.

Similar to what was covered in the post Sooner or later, everyone will touch the stove‏, "getting" systems thinking is often best achieved by experiencing it in a learning scenario. To do so, I recommend that you play "the Beer Game" online. This is a supply chain simulation developed by the MIT Sloan School of Management in the 1960s and is an experiential way to "get" systems thinking. Supply chain management is just an example scenario of course, but I'm sure you can easily apply this dynamic to projects you work on as well.

I also encourage you to read the book The Fifth Discipline: The Art & Practice of The Learning Organization, by Peter Senge. Among other things, Peter mentions his use of the Beer Game in clients he's worked with over the years. Many of these clients or executive groups were from major Fortune 500 corporations. He discusses how some of the participants get so frustrated with the simulation they walk out of it without completing it. On a more technical front, a great reference is of course IEEE Standard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems

Effective architects don't get frustrated with systems, they know how to interact with the participants in them to achieve maximum results.

Sooner or later, everyone will touch the stove

If you're a parent, you remember when your child was a toddler and you told them not to touch the stove because it was hot. Like any good parent, you probably told your toddler time and time again but found that at some point, the toddler touched the stove anyway. Why? Because he didn't know what hot was until he touched it. Once he touched it, I bet he never touched it again, but he had to touch it to learn that lesson. Try as you may, as a parent you can't prevent this from happening as it will eventually. The best you can do is try to minimize the pain caused by doing so.

I mention this as a metaphor for architects. Effective architects know that eventually, people will touch the stove. It's frustrating to watch, as you know what the outcome will be, but oftentimes, you simply can't prevent people from touching it because like the toddler, they don't know what hot is until they do. This is an interesting phenomenon, and in learning theory, it's referred to as Constructivsm. "Constructivism is a psychological theory of knowledge which argues that humans generate knowledge and meaning from their experiences (Wikipedia)." So, given that you have experience some of the people on the project you work on won't, they simply won't learn until they gain the experience. This is obviously the way you learned the lesson as well, as you'll learn others in the future. Rather than being frustrated by this phenomen, effective architects realize that it exists, and have strategies for minimizing it's impact to projects such as:

1. They ensure that themselves, and optimally, each member of the project team thoroughly understand the Hersey-Blanchard situational theory (Wikipedia article) which details not only the development process individuals go through when executing tasks, but also what leadership style (directing, coaching, supporting, or delegating) leaders should use based on what development level an individual is at for a particular task. See the post Effective architects are leaders for further information on leadership as well. A key element of this theory is that the leader must apply different leadership styles based on the development level of the person being led on a task by task basis, not on an individual basis. Every individual has tasks they've done 100 times and tasks they've never done, thus leading them the same way on every task is a formula for failure. Most leaders have a natural style that they tend to overuse, and therefore they must be very conscious of not using their "default" style incorrectly. This is very prevalent in the technology industry as leaders often work with very smart people and therefore assume that individuals are proficient at every task. They're not, and neither are you. Effective architects accurately identify an individual's development level on a particular task and lead them with the most appropriate style. Conversely, effective architects also know how to identify their development level on a given task and appropriately ask questions of their leaders if they're being led with the wrong style.
2. Understand that nobody, including yourself, will possess all the experiences necessary to make a project successful, but if each and every team member understands the previous theory, they can more effectively serve as leader and follower. Having said that, staffing projects with individuals that have as many experiences as possible required for the project will obviously minimize the amount of project impact spent on stove touching.
3. Ensure additional time exists in projects to account for the phenomenon. It's not if it will occur, it's when.
4. Force earlier and more frequent deliverables. When people don't know what they don't know, everything sounds easy but unfortunately, nothing ever is. By forcing earlier and more frequent deliverables, you also force people to learn the lessons faster and earlier than they will if their deliverables are later in a release cycle. This is even more important for tasks which have dependencies on other tasks, particularly if those tasks are on the project's critical path.

I had a friend who years ago said "You can't cheat someone up the learning curve." That is a wise statement indeed. In addition to what's listed above, I enourage you to add a comment on other strategies you've found to be successful in minimizing the amount of "stove touching" that occurs on projects.

Strive for “best” rather than “right”

There is no right solution to a problem; all you can really hope for is the best solution defined by members of your team. Thomas Edison once said:

"We don't know a millionth of one percent about anything."

Right:

• Tends to imply that you have all the data there is to have, that you completely understand the problem, and that there are no alternate solutions under any circumstances that can solve the problem. In other words, it implies alternative solutions are wrong.
• Will regularly stop you from remaining open-minded; a topic discussed further in the post titled Stay open-minded
• Oftentimes leads to analysis paralysis, in that action is halted until you’ve got it right

Best on the other-hand, while still implying finiteness, tends to be more open-ended. Best:

• Implies "not only" or "not perfect" solution, but rather, the best that the team can come up with
• Allows for some level of analysis, but leaves more room for drawing a line that says “we’ve analyzed enough, let’s move forward”
• Allows for the fact that you probably don’t completely understand the problem and that there very well might be alternative solutions to the problem, you just weren't aware of them when a decision needed to be made.

Consider the following process for defining the best solution to a problem:

1. Ensure that you’ve defined the problem, rather than just the symptom of a problem. This was discussed in a separate post titled Solve problems, not symptoms.
2. Define all unbounded solutions to the problem, which requires involving key stakeholders to help you define existing technologies, patterns, and frameworks which might be applicable. Use caution however...given all the variables involved, it’s rare that the solution to a given set of constraints on a project will be the best solution for the slightly different set of constraints on the next one. Clearly you want input from others involved in the project because even as a group, you won’t know all unbounded solutions to the problem, but you’ll certainly know more as a group than you will individually.
3. Determine the viability of each solution, to include its constraints, and the constraints of the environment (technical, people, and process). The constraints are often overlooked unfortunately. I’ve worked with many people over the years that assume (for example) that since a given product/technology has a feature they want to leverage, that they’ll be able to leverage it in their solution and then they make key decisions from that sometimes flawed assumption. Just because a product has a feature, and the organization has the product, does not necessarily mean that the organization's implementation of that product allows you to use the feature the way you expected to. Similarly, while implementing a certain bit of functionality on your PC might only take 10 minutes, it will take orders of magnitude longer in a production data center environment due to contraints, testing, etc.
4. Of your options, ensure that the person or group that has to live with the solution defines the best option. That person might be you, that person might be the developer, that person may be the operations team, or a host of other people or groups. The most effective architects know the most options, or know who to involve to get the most options into the discussion so the team can select the best one.

Once the best solution is determined, formalize the problem definition, key decision criteria, and solution and ensure all those that were involved in the process agree. Then formally document this somewhere, as later in projects, issues will crop up again, people will forget why particular decisions were made, and may question the reason that a given decision was made. That documented information will serve as a reminder as to how and why the solution was defined, which can prove to be tremendously valuable should the need arise to explain the rationale for the solution, and that need will arise, eventually.

Stay open-minded

The longer you’re an architect, the less you tend to use words such as always or never. Why? Because you’ve learned from experience that oftentimes statements containing these words are proven false. Effective architects have open minds, and being open-minded requires you to assume that what you believe to be true isn’t necessarily; no matter how much your previous experience might tell you that it is. It’s impossible for you to know everything and if you accept that, then you know that others often have information that you don’t, so it’s in your best interest to listen to them and potentially learn something new in the process.

"Fight for your opinions, but do not believe that they contain the whole truth, or the only truth." --Charles A. Dana

Being open-minded also requires you to understand context, as the same statement could be true or false, depending on the context in which it’s used in. Further,

"There are no facts, only interpretations." --Friedrich Nietzsche

When asked a question, consultants are famous for answering “it depends.” This isn’t to be evasive, but rather to seek further clarification. Since consultants often work on many projects for different companies, they’ve come to learn that a given problem is rarely exactly the same; no matter how much two instances of a similar problem might have in common.

Effective architects know this too and approach each problem as though it’s unique, as certainly, some attributes of it will be each time. This is not to say that some attributes of a given problem aren’t the same each time, which is when the architect applies a particular design pattern or identifies a set of best practices or framework that is applicable. Effective architects use design patterns and frameworks as relevant however, rather than using them always or never.

I encourage you to read the short article How to Exercise an Open Mind from the eHow web site.