🤔 20% Problems

Someone bent up about the time they are wasting

Some recent startup advice I got: work on 80% problems instead of 20% problems.

20% problems are "nice to haves" - things that move the needle, but not by much. This includes things like internal tooling, updating internal READMEs and docs, and to some extent, writing internal dashboards.

As I began working on healthcare interoperability tools, when things got tough, I began to gravitate towards these 20% problems. Soon recognizing this as procrastination in disguise, I realized that a good rule-of-thumb for working on startup problems is that if you're faced with working on two things, working on the one that's harder might be the better idea.

This is useful for a couple of reasons:

  • Something that's easy is not easy to defend
  • If it was easy and produced a ton of value, odds are it's either easy to copy, or has been done before
  • Working on hard things is hard to copy

I fell into this trap with code commits as well. Early in my career, I was obsessed with committing every day. I now tend to recognize this as a vanity metric.

Good management happens away from the "open a pull request" (good managers and operators act as editors, so slack + the comments section is where lots of valuable stuff tends to happen). And, good things take hard work and a while to ship. Tracking the "hard to measure" things then becomes really important. Celebrate wins away from the terminal.

So, try and work on hard things if you're able to. Being good at gauging how long those hard things will take, and communicating that to your team, is also really important.