Building a smart(er) nation: Simple models lead to better decisions

IT is complex. And while it keeps getting more exciting, it doesn’t get any simpler. At Singapore’s Government Technology Agency (GovTech) we are progressing well in our journey to the cloud, are building a technology platform for the whole of government, and are developing applications that improve our citizens’ lives. But we also face many of the same challenges that traditional enterprises do, such as having to manage an increasingly complex and interdependent set of applications and technologies. 

Making Good Decisions

Seeing order in this ever-evolving complexity isn’t easy. Many of our initiatives are ambitious multi-year endeavors that require significant investment in both funds and resources. Leadership approval and support is therefore critical. At the same time, these projects involve numerous technology decisions, most of which are difficult to discern or sound straight-out cryptic to high-level decision-makers. Many of these technical decisions will have far-reaching implications that affect the overall project scope and direction, so it’s important to keep all stakeholders aware of them.

A disconnect between technical details and decision-making bodies isn’t just frustrating, but also leads to poor decision discipline, which we’d surely want to steer clear of. One of my tasks is to help our engineering teams to clearly lay out their plans and decisions to management, for example in steering committees or approval boards. Not only will this increase transparency and quality of our decision-making, it’ll also help our teams gain clarity for their own planning and prioritization.

While there are useful constructs for technical decisions, such as Architecture Decision Records, we were looking for something that conveys higher-level aspects, such as project scope decisions and how the teams plan to bring their products to market. The last thing we wanted was to introduce management layers, so the expectation was that team leads and developers would present this information directly to upper management.

Models to the Rescue

One of the most useful tools to combat complexity are models - useful abstractions that help us gain clarity. Models’ most useful property is that they reduce the noise and bring out the essence of the problem or decision to be made. While they may be simple, models should not be simplistic. Instead, they should counter-steer the temptation to “dumb things down for management”, which is surely not going to lead to better decision making.

We devised three simple, but evocative models that we apply to new software project proposals. Our goal was to make the models as simple as possible but still meaningful - the simpler a model is, the better it is at shielding us from the complexity of reality. We also wanted them to be easy to remember and a little bit of fun. Based on many project architecture discussions three models emerged:

1. The Problem Yardstick
2. The Value Graph
3. The Strategy Cube

Let’s have a look at each:

The Problem Space Yardstick

When presenting a funding project proposal to upper management, there’s often a simple question in management’s mind: with all the platforms, libraries, and open source software available, why do I still have to build so much stuff? This reasoning particularly applies to reusable services and platforms, which often build on already existing platforms and services. 

When pitching a project, you first need to make sure to accurately represent the size of the problem space you’re addressing. For example, if you’re building an API gateway service, there are many facets to that problem such as micro-gateways, API directories, marketplaces, developer-service, quota management, and more. Because these concepts may not be familiar to management, you may need to create an overview, i.e. a map that shows the whole ecosystem and the part that you’re looking to bite off. 

Our yard stick breaks the problem into four categories:

1. What’s freely available, e.g. as open source (not counting operational and maintenance costs at this point), as code libraries, or as a free third party service?
2. What can I buy or use as a paid service? Most large IT shops follow a buy-over-build strategy, so you’d expect to not be the only people on the planet who had to solve this kind of problem. In most cases, buying existing solutions reduces complexity and speeds up delivery as long you’re OK with being tied to a specific third-party solution. 
3. If you can’t buy the solution, maybe another project or another division already built it? Especially in large organizations, the chances are actually pretty good.
4. Only what remains you have to build yourself.

Using this model, you can easily see what trap developers can fall into when presenting to management: developers love to talk about part #4 while executives keep wondering why that part is so big and the other parts are so small. The longer the developers present, the more worried management becomes. 

Decorating a project slide deck with technical acronyms usually stems from developers’ temptation to gain management’s appreciation for just how difficult their lives are and how hard they’re working. In reality, though, management will have much more appreciation if they are assured that the hard work doesn’t duplicate what’s already there. Our simple yardstick can bring this clarity. 

The Value Graph

One of the worst questions you might get during a management review is “what could you deliver for half the money?” or “what could you do with one developer less?” Team leads will be inclined to answer “not much - resourcing is super tight as it is.” 

Unfortunately, this answer isn’t nearly as clever as it may initially sound. A good project plan delivers value incrementally, focusing on highest value items first. After an initial ramp-up phase, any non-trivial project should therefore deliver more than half the value at the halfpoint of time or effort. 

You can show this by way of a simple value graph, which plots value delivered over time. If in fact cutting 10% off a project leads to no value delivered, this curve would look like the proverbial “hockey stick” - you have nothing to show after 90% of time and money is spent, and then magically in the last 10% everything comes together. Right… Management has seen enough of these kind of projections to not fall for it one more time. 

The graph admittedly is only a rough approximation and is meant to be used qualitatively. However, asking yourself the related questions and plotting your progress not only in money spent but also value delivered, helps you be prepared when management eventually does ask (burn down charts have a similar goal once the project is running). In many cases, if your answer is clear and well articulated, there’s little reason to reduce budget or headcount - management mostly wants to see that you’ve done your homework.

The Strategy Cube 

Lastly, when you build and roll out a platform or service there are many directions you can go. For example, you can add more features, enhance existing features, or increase adoption. Along these dimensions you can take many routes: you could aim to drive adoption based on a simple use case first. Or you may want to first build a solid feature set before testing with a limited set of pilot users so that you can deepen the features before rolling out widely. 

Representing these paths as three dimensions of a cube, you can now plot your strategy as a path inside this cube. Many paths are possible, but paths that meander along the bottom plane for a long time are going to worry management because they imply that they’re investing into features that aren’t rolled out to many users until later - this’ll also cause your Value Graph to resemble the dangerous hockey stick.

More than Three Dimensions

In unison, these three simple models help technical teams articulate their value proposition and their go-to-market strategy. After coming up with these models, admittedly empirically, we realized that the Problem Yard Stick has one dimension, the Value Graph has two, and the Strategy Cube naturally has three. This somewhat serendipitous setup makes the models easy to remember (We didn't dare come up with a four-dimensional model just yet).

However, the models accomplish more than communicate decisions. They also help us positively influence the dynamic of review or approval meetings. 

Reviews are Valuable

Traditionally, teams may consider management reviews and steering committees as a burden and aim to just get “the stamp of approval”. Those folks may actually be somewhat happy that management can’t understand the technical details because it makes it more difficult to interfere. 

Instead, teams must realize that having leadership attention gives you access to some of the most experienced folks in the organization, who have access to a broad perspective that helps you detect blind spots or duplication. Translating your work into a language that's familiar to them will assure that you get the most value from the meeting.

Transparency Enables Autonomy

Other teams might feel that giving too much transparency weakens their position or reduces their autonomy. You can recognize these folks by their super-high-level presentations with lots of promised benefits but little substance to back them up. 

This strategy is short-sighted at best, though. Lack of detail is likely to leave management with question marks, which in turn will lead to closer supervision. Transparency, in contrast, builds trust, which will give management the comfort level to grant teams greater autonomy.

Discipline isn’t Boring

Lastly, there’s a widespread belief among technical teams that decision discipline is where fun goes to die. Our experience is that mapping technical decisions into evocative models does quite the opposite. Our architecture reviews draw a wide circle across end-user demand, technical trade-offs, and economic models. We routinely end up with several square meters of whiteboard graffiti plus memorable metaphors like comparing platforms to fruit baskets and fruit salads. But that’s probably material for another post..

======

Thanks to Jason Bay and Ming Sien Choong for being a constant source of inspiration during our Government Digital Services architecture sessions. 

======

This is part 2 of a loosely structured series on my work as Smart Nation Fellow at GovTech Singapore. See also Part 1: Speeding up is more than going faster

======

Join us at GovTech’s STACK Developers Conference on 30 Mar - 1 Apr 2020 with an exclusive discount rate! Use the promo code GREGOR120 at www.govtechstack.sg