False dilemmas for architects

I was introduced to the idea of the false dilemma (aka false polarity, false dichotomy, or fool's choice) as a leadership concept by Alisa Hata some years ago. In political debate, a false dilemma is a common rhetorical device (e.g., "you're either with us or against us"). But false dilemmas also show up regularly when leaders (including architects), are asked to participate in decisions.

Once someone points this out to you, you may start seeing them everywhere. Here's a little collection of false dilemmas from my work as an architect. How would you respond to these?

Breadth or depth

• Q: "We don't have unlimited time to do analysis. Should we go for the most breadth or go deep in one area?"
• A: "Neither. All problem-solving moves naturally between breadth and depth. We'll need breadth for context, and we'll need to validate it with enough detail, and as we go we'll see we need depth in some but not all areas."

High level or detailed

• Q: "Senior leadership doesn't have time for details. We should keep the presentation very high level and not go into any detail."
• A: "It can be helpful to do both. Make the high level points quickly, but also pick one issue for more detailed explanation to help people understand what is behind each issue."

Top-down or bottom-up

• Q: "Should our management make this decision top-down, or should it be left to each team to choose bottom-up?"
• A: "Neither. We should help management gather input from employees and consider it in setting goals. Within those goals, teams should have latitude to meet local needs in the most sensible way."

Central or decentralized

• Q: "If groups start doing this themselves, it will become a decentralized activity! Wouldn't it be more efficient to do this centrally?"
• A: "Over time and across many activities, some of both. New activities are often best explored by a few groups with the biggest stake. There may turn out to be long-term benefit from centralization, and if there is, some groups will still have specialized enough needs that are most cost-effective to meet locally."

Standard or exceptional

• Q: "We have a standard process for this. If we start making exceptions to it, won't we lose the value of our standard?"
• A: "Probably not. Leaving aside very precise manufacturing processes, most business processes involve variation and judgment based on circumstances. Design and management of the process should account for this, within reason."

Waterfall or Agile

• Q: "For this project, should we iterate in an Agile way, or do traditional sequential planning, requirements gathering, design, and implementation?"
• A: "Some of both. Some up front planning and early discovery work will validate the scope, provide necessary context, identify priorities, and ensure a more successful project. But once enough good information is in place, the team should start designing and implementing iteratively."

Planned or unplanned

• Q: "It would take too long to plan this in enough detail to guide our work, and anyway the plan will change. Can we just identify one or two good next steps?"
• A: "Some of both. In order for the organization to stay on track over time, it should have a long-term vision, choose a high-level strategy, and maintain an evolving roadmap. But it is equally important to start working on short-term wins and learning from them. And certainly not everyone has to be involved in planning to the same degree."

Buy or build

• Q: "We'll have to decide whether to buy or build the solution. That will result in a totally different project and team."
• A: "To some degree. Unless the problem/solution is trivial, both approaches will require very similar planning, analysis, design, testing, integrations, change management, and even operations activities. Some of the detailed work and essential technical skills will certainly be different."

Secure or unsecured

• Q: "Should we design the solution to this security standard, or leave it unsecured?"
• A: "Neither. Just designing to a standard isn't enough to consider something secure. There is always a risk, so security is always a risk calculation. Work with the stakeholders to define the appropriate amount of effort to mitigate different kinds of risks."

Compliant or non-compliant

• Q: "We have to do it this way, even though it's costly, or the enterprise won't be legally compliant."
• A: "Maybe -- let's find out more. Like security, compliance is risk management; we'll never avoid all compliance risk, so we should prioritize. And do the users really need to rely on this particular solution for compliance? Also, the regulator may not have expected this outcome. What was really intended and what other approaches would be acceptable?"

Completed or failed

• Q: "It doesn't look like we can complete this work as scoped -- it turns out it won't be worth the effort. So the project should be considered failed."
• A: "Well, not exactly. Learning is also a return on investment in a project, if we apply what we learned. Based on what we've learned, we can better define successful future work. Continuing to do something with no further value would have been a failure."

In each case the catch is that taking into account more possibilities will probably take more effort and time. It may change the intended outcome of the meeting you're in or even the scope of a project. The stakeholders may not respond well initially. Deciding when to push back on a false dilemma is one of the judgments involved in being an architect or leader.