Outside-in Thinking

Or 'How to Actually Finish Projects'

The machine gun was invented in the latter part of the 19th century and after the First World War, had cemented a reputation for being the most fearsome weapon on the battlefield. However, early versions of the machine gun were notoriously inaccurate. Since they had massive range, accuracy was further hampered by wind and other environmental factors. Weapons developers across the world spent countless person-days trying to better the barrel, better the rifling, better the gun-sights, all to no avail. The machine gun remained a spray-and-pray device. Until, that is, someone had the bright idea to coat every 10th bullet with phosphorus. These ‘tracer bullets’ would glow as they flew through the air and using this feedback, the machine gunner could adjust where the bullets were actually landing.

This is an example of outside-in thinking. Working backwards from the desired goal and building feedback loops that guide you to your goal. All of the work on barrels and gun-sights was inside-out thinking. Inside-out thinking can get you out the door, but to truly get to where you want to be going it’s useful to deploy outside-in thinking.

Recognising the Pattern

Inside-out thinking is characterised by a pattern that is imbibed by programmers early on - the pattern of thinking of the desired goal in terms of the steps required to get there. Programmers starting out to write a ‘hello world’ or a fibonacci algorithm spend 99% of their time thinking about what is required by the computer and thus starts their long journey down the road of Inside-out thinking. Don’t get me wrong - inside out thinking is important, but it’s meant to be used tactically, not strategically. It is a necessary, but by itself insufficient part of driving projects to finish.

Real World Example

A team I work with, wanted to replace an API endpoint with a proxy endpoint and move much of the computation that the browser was doing to the server. However, every time they deployed the proxy, business metrics fell. When business metrics fell they would go back to their code and read it, do QA and so on looking for where the drop might be coming from. They kept approaching the problem inside-out. focusing on the  optimisation of their actions to achieve the desired outcome

The outside-in approach is completely different and starts by asking the question - how do we know it’s working?  followed by asking ‘can we see the manner in which this is not working’? In essence, outside-in thinking boils down to the following simple algorithm 

Can you see the problem in a way that suggests the fix? If not, you have one more layer to peel off.

So we peeled off the layers, and it soon became apparent where the problem was. First we cut the business metrics by various segments and ascertained that the proxy was underperforming across all cuts. Then we started dashboarding the actual performance of the proxy. We dashboarded the API response times, time-to-first-byte and time-to-decorated-response for the proxy and the non-proxy. These dashboards led us to a misconfiguration in the proxy that was adding 1200ms latency to the response.

We fixed the config and numbers fell in line. Number of hypotheses tested - 0. Number of failed attempts to fix it - 0. Number of QA cycles involved - 0.

An example of one of the dashboards we used to drive our hypotheses

Outside-In thinking is an OODA loop - it helps you observe, orient, decide and act in ways that Inside Out thinking cannot match. The InsideOut or Deductive logic seeks to go from Theory to Confirmation, and the OutsideIn way or Inductive logic seeks to go from Observation to Theory.

This might sound overly simplistic but most things are. Try this out the next time you’re faced with an issue that won’t go away.

Applications

Outside In thinking can be applied in many places. Take meeting requests for example, - most are driven by the urge to get the answer to a question. Very little thought is spared for what the outcomes from the meeting will be for the participants and the org as a whole. This results in meeting requests taking the shape of thoughtless bids for x person-hours, contextless and narrated by pithy one liners. The result - mostly everyone shows up,  on time and unprepared, only tospends their time reacting to requests for information instead of responding thoughtfully.

How would an outside-in thinker approach this meeting? They will start by asking the simple question -- what do I want from this meeting? (ie how will I know it worked?) They would then proceed to peel off additional layers and ask further questions. What will enable the participants to provide me with the best answer? What do they need to know before the meeting to respond correctly? A meeting request thus composed will probably require much preparation, but will have context and be thoughtful. It will  inspire the participants to reciprocate with similar preparation. The meeting then becomes a complete and comprehensive proposal aimed at driving the desired outcomes.

OutsideIn thinking forces you to think about what it is that you want to see in the real world, it first asks - is our mental model of the system correct?  This leads to completely different solutions than the InsideOut approach which asks - what should we do next given our mental model of the system. The problem with InsideOut thinking is clear - it can only be as good as the mental model you have and it prioritises inputs and outputs over outcomes.

Fixing the Anti-pattern

For programmers and product engineers there are two essential tools to adopting more OutsideIn thinking.

TDD

TDD begins with a question about API design. This thing you’re building - what is it? How is it instantiated? How is it used? What are the results from using it? This is Outside-in thinking. And this might be why you find TDD so un-intuitive. It goes against the grain of what programmers learn from the very start. But it’s a very important and meaningful level up in your engineering journey because this will probably be your first taste of Outside-in thinking.

Dashboards

The biggest gains in velocity come from not solving problems you don’t have.

OutsideIn thinking starts with the attempt to clearly describe, recognise and visualise the problem you’re having. A good dashboard will automatically answer the question - Is this broken? In what way?

At ShaadiTech, we fight the temptation to succumb to InsideOut thinking by having a dashboard for each release. Every time a deploy doesn’t perform as expected we save a tonne of time root-causing the issue because we already have an idea of what success looks like and we have a dashboard that answers the question - broken where?

There’ll be more about the above in a subsequent post on Fast Feedback Loops.

Conclusion

Are you stuck in a project where each iteration takes forever and doesn’t seem to get you closer to a conclusion? Then you’ll probably benefit from deploying some Outside-in thinking. Before shipping your next iteration ask yourself - how will I know this is working? Then go and build those tracer bullets.