Hero Hero

Stop feeling like an imposter, get better at tech products & projects.


key digital product knowledge


digital product management


crappy products nobody needs

What's Apptitude?

What's the problem?

Recoding America

There are problems with tech outcomes in Govt.

I was recommended a book recently. "Recoding America". I read it. It's a great book, exactly as every reviewer praised. The person who made the recommendation was spot on. Most of the stuff written there are things that I'd heard here and there working in the public sector. You could change the names, agencies, systems to Singaporean ones, and it would still make sense.

It's true that across government tech, we have policy people writing tech policies without knowing it, decision makers who don't know what they're approving/rejecting, segments claiming to be "agile" (WaterScrumFall lul), project manager and business owners stacking requirements, people thinking they know everything based on non-tech experience, staffers feeling like imposters.

To demonstrate my point, here are extracts from the book. They are very familiar.

Structures, Culture

Blaming software that fails gets us little in the way of fixing the problems that government faces. More helpful is to understand the structures and culture that created the software, because they determine not just how the software works but how the whole system operates.
Formally, the tech implementers are not charged with building services that meet users’ needs or achieve policy goals. Their job is simply to meet a predetermined list of requirements. These are often exceedingly specific, but nowhere in government documents will you find a requirement that the service actually works for the people who are supposed to use it. The systems are designed instead to meet the needs of the bureaucracies that create them—they are risk-mitigation strategies for dozens of internal stakeholders. And they often fail even at that task; trying to be all things to all people, they’re unable to make any reasonable tradeoffs for the sake of usability.

Policy Is King

That public servants get held accountable to process over outcomes is well known; I do not presume to know how to change this, though I desperately wish I did. What I do know is that the perverse effects of glorifying process are far greater in technology, for the simple reason that there are so few people in government who understand tech. Rigid, overly specific interpretations of law and policy are hard to avoid when those doing the interpretation can’t evaluate the work for themselves.
Policy people tend to see those who implement the policy decisions they make as being far below them in the pecking order, perhaps even at the bottom of it. OMB was the pinnacle of that pecking order. In other words, No, thank you, that’s lowbrow stuff. That’s not the kind of thing we do in powerful places in government.

Policy Complexity

None of the modernized states were able to avoid accruing backlogs, and few of them seemed to do much better than average in terms of scaling to meet demand. The problem is that the modernization projects all sought to “add functionality” — more layers of paint — or just to move to more modern infrastructure, particularly to the cloud. None of them targeted serving clients better or scaling to meet demand. If the people running the systems had set scale as a goal and truly analyzed their bottlenecks, they would have recognized the need to rationalize and simplify the accumulated layers of policy and process along with bringing in new technology.

Legacy Infra

... and because tech investments must always be pitched as adding some new capability to the system (rarely just renovating what already exists), each piece of the system gets built in different technology paradigms from different eras... The system is not so much updated as it is tacked on to. Over time, new functionality is added, but the system never sheds the core limitations of the foundational technologies. At the same time, it becomes enormously complex and fragile... It becomes harder and harder to support the technologies in the lower, older layers, while the more recent layers require constant updates and patches. The paint cracks.

Decision Making

Arguments about what is or isn’t required happen all the time, but they are much less likely to lead to a suffocatingly risk-averse answer when the people involved in the argument understand the domain... it is highly unlikely that anyone else in the debate — likely to be dozens of people in dozens of different roles — had any basis on which to judge whether an ESB was a good thing or a bad thing in this context. Thus, to nix the ESB, dozens of people in dozens of different roles would all have had to agree to jeopardize their jobs over a recommendation they didn’t understand. These discussions tend to function as a vetocracy, in which it takes all thumbs up in order to accept the risk, and only one thumbs-down to stick with the less-risky option. The ESB stays.

Scope of Requirements

Government’s obsession with requirements — voluminous, detailed requirements that can take so long to compile the software is obsolete before it’s even bid out—stems from a delusion that it’s possible to make a work plan so specific that it requires no further decision-making. You hand it off and the developers just do exactly what they’re told. Why not let those developers choose the best tool or platform for the job?
But the goal in government seems to be to drain the job of software development of any opportunity to exercise judgment... it’s particularly destructive when hardly any of the people writing the work plan have much basis for their decisions either.

Build vs Buy

Government procurement teams have a terrible habit of contracting for bespoke software when they could buy commercial products — partly because we tell these teams to collect every possible requirement they can think of, which encourages and even calcifies arcane practices within the departments they serve.

Owning and Building Products

It can’t just be a project that was contracted for, developed, tested, and declared “done.” You need to own the code, and you need to be able to change it to meet your needs... you must have the core competencies to support a living, ever-adapting system. Government knows how to acquire technology. What we need to acquire are capabilities.

Chip Away At This By Improving Tech Knowledge

This is far too big a problem to solve by any one thing. You can create GovTech (and indeed this was partly why GovTech was created), reform other engineering agencies (doesn't seem like it), but cultures and people are far more entrenched.

But I can point you to stuff I think you need to manage tech products & projects better - online resources and great points I've picked up from smart Govt people.

How Apptitude Tries to Helps You


Go on a learning journey to upskill and git gud!

Swole Doge

Step 1a: Learn Foundations

With my curated resources across a wide range of tech topics, you'll learn at your own pace. Whether that's cloud computing, product management, AI.

The resources are spread across websites, YouTube videos, and free online courses, giving you flexibility and convenience.

Panda reading

Step 1b: Apply Knowledge

Do personal projects, try stuff beyond tutorial copy-pasting or Coursera Labs.

VS Code

Step 2: Use My Cheatsheets To Revise

You won't be able to learn everything by yourself in a short time. Or maybe never.

Get a boost by referring to my "Cache Up!" cheatsheets, which give you the essentials I've curated from looking at mine and other people's projects.

The good and the bad.

Panda Superhero

Step 3: Better Manage Products & Teams

Lead your products & teams better with all your new knowledge! No one fools you anymore.

Never again will you need to say "I don't know and can only trust you on this".


Step 4: Say "No!" to Shitty Products & Rules

Use your upgraded judgement and trust that you're 10x better than you were. Gain confidence in your judgement to terminate useless products. Stop underperforming projects in their tracks.

Now that's truly Tech for Public Good

Feels good
Annoyed panda

What are you waiting for?