Dealing With Ambiguity

Introduction

“Architect” is a thought-leadership role, and being a thought-leader means dealing with ambiguous problems. You may need to be the solver of ambiguous problems, or guide your colleagues so they can do so.

Dealing with ambiguity is an important skill, otherwise it will slow you down or lead to poor decisions.

Beware of Over-Baking

A symptom of being paralyzed by ambiguity is to over-bake a piece of work – probably one that is comfortable.

Our brains love avoiding difficult or unpleasant tasks in flavor of easier and more enjoyable ones, so it’s important to recognize when you are faced with ambiguity before too much time is lost to avoidance. If you find yourself putting a lot of effort into something fun but relatively trivial – that might be a sign to move on.

For example, imagine some two part process: step one is to conduct some analysis, but you’re unsure what step two looks like. If you find yourself (or someone else) over-baking the analysis (“Oooh, I really need to add some more colour to these charts”) it might be due the next step is not well defined i.e. you don’t know how to start it or you don’t have a plan.

Mitigation Strategies

The following approaches can be useful for dealing with ambiguous problems. These approaches aren’t mutually exclusive – you can mix and match.

Go back to the Objective

One of the first things to do is make sure you haven’t forgotten the objective.

Often we immerse ourselves in a complex problem and get so caught-up in its intricacies that we forget what we’re actually there to achieve. Once we lose sight of our objective we tend to get lost. Therefore, remember to keep coming back to the objective: make sure you clearly understand it and don’t lose sight of it.

Also, you can use the objective as a point of reference – to work backwards from, and that can help penetrate the ambiguity.

Go Back to First Principles

Similar to the previous strategy, a good way to take control of a problems intricacies is to go back to first principles.

“First principle” is essentially a fundamental truth that stands alone. Aristotle defines it as “the first basis from which a thing is known.” In the context of this strategy, first principles refers to things which you know to be true – not things you assume.

Often our understanding of complex problems is a web of linked assumptions; if the overall hypothesis is flawed we can end up getting lost due to circular reasoning – essentially we get defeated by the complexity. Going back to first principles is essentially to throw all your assumptions out the window and start again.

Using first principles helps you work methodically and focus on specific things that matter; “divide & conquer” can be a good complimentary approach.

Give Yourself Time / Space to Think

Complex / multi-dimensional problems will require more mental processing than usual.

The number of variables & possibilities present, plus the variety of disparate information available, will be larger than usual.  Therefore, its important to give yourself time to think.

“Chipping away” is a great companion strategy – digest part of the problem and mull it over or sleep on it, then take another bite. As you build up a picture of the problem you’ll develop a mental model that you can fit new things into. Also be ready to change and restructure your mental model as needed – try not to be too rigid.

Just Attack the Problem

Brute force. Like starting a cold engine, you might need a surge of energy to make an initial break-through.

One way to break writers block is to just start writing – even if the initial output is total garbage, the act of forced writing can help kick-start the brain into the right kind of processing, and productive writing will follow.  The same can hold for problem solving – sometimes you just need to get stuck in and warm your brain up.

Divide & Conquer

Break a big problem into smaller ones. Concentrate on one.   Make progress or recognize when to give it time and come back to it.

Slightly related – rather than trying to solve the entire problem first, see if you can put some “stakes in the ground”, i.e. make concrete progress on some key points and use those as a basis for further work.

Find Themes / Consolidate

Group many moving parts into themes to reduce overall “noise”.
Look for patterns. 
See the big picture.

Chip Away

“Death by a thousand cuts” but in reverse.

Putting a small amount of effort into something huge usually seems futile,
but many small efforts added together
will make an impact.

1. Works well with “giving yourself time/space to think”. Take a small bite at the problem and mull it over.
2. Supports a sustainable pace. (Its a marathon, not a sprint).
3. Start early. Expect course corrections.

Defer

Putting-off something difficult by procrastinating is not a recipe for success. That said, problems sometimes have a timing dimension to them, and so picking the right time to tackle the problem is sensible.

The trick is to successfully identify the factors, and recognize that its real and not procrastination.

For example, the work of you and your team will often have dependencies on other projects, teams, decisions and future state strategies; sometimes the direction of these will be unclear. In such cases you may need to get clarity on where they are likely to land before it is worth investing significant effort in related problems.

Share Your Problem

If you’ve been struggling on your own, share your problem with a colleague or a friend. Often an outside perspective is all we need to get us started.

Time-boxing

Not so much a strategy of it’s own but something which applies to many of the strategies above.

Think about how much time to invest in a given approach. If you still haven’t made progress after an appropriate amount of time, ask yourself:

1. Is this a signal you need to switch to a different approach?
2. Should we put the problem to the side for the moment and come back to it later?
3. Is the problem insoluble, and we may need a change in overall strategy?

More Info

This expands on part of the “Consulting Architect – How To Get Sh#t Done” talk I gave at the Geekle Worldwide Software Architecture Summit, May 2023:

1. Deck, extended response to some audience questions, etc: https://morphological.wordpress.com/2023/05/16/consulting-architect/
2. recording of the event stream: Worldwide Software Architecture Summit’23 – Career Track – YouTube
3. Event Schedule & speakers: Agenda- Worldwide Software Architecture Summit 23 (geekle.us)

Advertisement

Consulting Architect

As (intended to be) presented at the Geekle Worldwide Software Architecture Summit 2023
May 16, 2023 at 9:00 am UTC – May 17, 2023 at 7:00 pm UTC

consulting-architect-geekle-wsas23-may-2023-v0.1Download

In this talk is based on my lived experience, working as a consulting solution architect.

There’s a skills overlap between consultancy and architecture; and I think architects have an opportunity to be more effective by applying some of the consultants mindset and techniques. In short – “consider being a “the consulting architect”.

The deck includes extensive notes on selected slides, and I’ll be publishing blog posts on selected topics in due course.

One of my motivations behind this talk is that there’s lots of ideas, skills and techniques which (as far as I am aware) aren’t usually discussed in architecture circles, so this is a chance to explore some of those and see how they can help us be more effective architects.

Update – Q&A Session Responses

As much as I like the challenge of answering questions on the fly (in Q&A sessions), because I’m (almost certainly) dyslexic I often don’t have enough processing time to give really good answers. Last night I got three questions, and I’ve done some more processing 🙂

To those who asked the questions – I hope you see this and that its helpful.

How to select / weigh which is hardest easiest problem to start with?

Usually the size of a problem is obvious. Whilst I think it is wise to be mindful about which problems we start with, it’s also something which is easy to over-think.

In my talk a mentioned how the brain has two modes of reasoning: heuristic (intuitive) and analytical; the former is usually pretty good at sizing up the relative size / difficulty of a problem, and that’s often sufficient. Is the relative difficultly immediately obvious?  If you have to stop and think about it for too long that probably indicates it’s not easy.

If you do want to be more analytical, below are some of the things I think about when doing problem triage, in roughly the order you may want to consider them.  Remember:

1. You don’t need to apply all of them!  Just use whatever works for you to sort the problems.
2. Triage is just an initial assessment – it’s okay to change your mind later (as to if it’s an easy or hard problem) because all you’re doing is sorting out which problems you want to tackle first.
3. Because its an initial assessment, use simple coarse-grained measures; for example easy or hard; or easy, medium, hard, unknown.  The point is to balance effort and accuracy – whilst we’d like an accurate measure, but it’s probably not worth investing a lot of effort.
4. A lot of these techniques can be used with different levels of effort: a 30 second thought exercise in your head; a 5 minute doodle on the back of an envelop; a 10 minute whiteboard chat with a colleague.

Things to think about:

1. Is the relative difficultly immediately obvious?  If you have to stop and think about it for too long that probably indicates it’s not easy.
2. How many unknowns?  Easy problems tend to be well understood because there’s not much to them.
3. Can we change our minds?  Architect is about making sound decisions, where we know that once we make those decisions it will be very challenging to change them, so we need to be careful.  Easy problems can sometimes also be relatively straightforward to change later.
4. Blast radius.  If you misjudge the problem and it explodes – what’s the likely blast radius?  Would it affect just you, the project or the whole enterprise?  The bigger the perceived blast radius the harder the problem might be.  Also see “risk profiling” (below) which expands on this idea but is more complex.
5. Is the problem rooted in people or technology?  Technology problems tend to sit there waiting for you to research the answer online (easy).  Problems that involve other people can be harder because people tend to have their own ideas about things (how dare they!), so you may need to engage with them: take time to understand their perspectives, motivations and priorities, factor any new ideas and information they provide into your mental model; sell them your ideas, influence and negotiate.
6. “Firsts”.  In solution architecture you’ll often be faced with “new” problems, coming up with new patterns, using new technology and so on.  This relates to “unknowns” but the nuance here is about doing new things for the first time – you might have a good idea of what needs to happen but because it’s the first time in this context there’s a degree of unpredictability.
7. Risk profiling: think about the risks that might relate to the problem – hard problems tend to have more risks.  For the risks, think about them in terms of likelihood and impact – the more likely they are, and/or the bigger impact they have the more serious you need to take the risk.  Harder problems tend to attract more serious risks i.e. more likely and bigger impact.  For an initial problem triage you don’t need to think of all the risks associated with it – you only need to identify if it has any that cross a red-line in your head.  As soon as it crosses that line put it in the hard basket and move on.

Must read book for developer wanting to migrate to solution architecture?

The developer to architect journey is one I took myself, so it is important to me.  I’ve been focused on this topic for a while now and have these resources which may help.  They are listed in a suggested reading order.

1. https://morphological.wordpress.com/2017/01/26/the-laymans-guide-to-it-architecture-roles/
2. https://morphological.wordpress.com/2017/01/31/career-progression-into-architecture/
3. https://morphological.wordpress.com/2021/01/27/your-first-project-where-to-start/
4. https://morphological.wordpress.com/2021/08/03/roles-responsibilities-of-the-solution-architect/
5. https://morphological.wordpress.com/2021/02/26/geekle-meet-up-feb-2021-apis-and-microservices-architecture-cheat-sheets/
6. https://morphological.wordpress.com/2021/01/27/four-traps-experienced-solution-architects-fall-into-and-how-to-mitigate-them/

How do you manage continuous delivery?

This is a very open-end question, but here’s some thoughts:

Is it even your problem?  If you are new to architecture, and in your last job you were responsible for delivery (maybe you were a tech lead), then it’s possible the answer is “no”.  In such cases you’re mentally still trying to do your old job; you need to try and move past it.

In those cases you can still be supportive but don’t make the mistake of doing someone else’s job for them at the expense of your own.  In general I think solution architects need to be ready to support delivery, but with as light a touch as possible.  This assumes you’re on a fixed term project as opposed to a product team in which case it might be different.

If we look through a RASCI lens, typically architects are not responsible for delivery (outside of the architecture), they are only consulted or supporting.

How to be supportive in managing delivery?  At first glance continuous delivery is a classic “people, processes and tools” scenario, so considering it through those lenses might be a good place to start.

Here’s some thoughts: things you might observe, and responses.

Observations that might prompt these questions:

1. Are there problems, is the delivery on fire?  Investigate – what’s the root cause?
2. Are there issues working with teams / stakeholders outside of your control?
3. Are things sustainable?  Are people working at a sustainable pace?
4. Is there too much work, are the deadlines unrealistic?
5. Do people have the right skills, and skill levels?
6. Do you have the right processes?  Are the processes being followed correctly?
7. Do you have the right tools?  Are they being used correctly?
8. Is there a bottleneck or some kind of resource contention?
9. How do you know the above is true or not – do you have the right visibility?

Potential responses:

1. Is it something the team can self-resolve through discussion – e.g. at a retrospective and by adopting some goals?  (Don’t forget SMART).
2. Faced with a risk or issue?  Can you: avoid it, reduce or control it, transfer it somewhere else, or do you have to accept it?  The latter might mean making changes at your end even if the issue originates from outside.
3. Do you understand all the stakeholders involved – their motivations and priorities?  Sometimes smooth management just means keeping the right people in the loop.  Consider stakeholder mapping.
4. Bring in expertise from outside, probably on a temporary basis.  Could be a formal engagement or informal.  Sometimes someone from the outside will immediately see the issue which the team couldn’t see because they were too close to it.  Sometimes advice from an outside (neutral) perspective helps get doubters on-board.
5. Do you need to escalate?  Perhaps you need more staff, better technology or something else which you need to ask for.