Should you Hack or Pick?

(image courtesy: Jason Yip)

One of the most important things leaders have to do in their jobs is to “decide”. This deciding comes in many forms and there's a lot written about it: on the one side, there are best practices on being detail-oriented and on driving alignment between teams and individuals. On the other side, there are best practices that state how speed and decisiveness matter and the fact that moving fast is a strategic advantage. And I often wonder: what is the right approach?

The approach I have found works best for me: I like to divide any problem into "Hack" and "Pick" decisions. Hack decisions should be quick, decisive and ideally, you empower other people in the organization to take these decisions. Spending too much time on them is going to slow you down. Ideally, the person who owns the decision and the consequences is the person who makes the decision and moves forward quickly. It’s not that Hack decisions don’t need alignment - stakeholders are consulted and quickly aligned, but usually, the chips fall into place fast. If a team is spending too much time on Hack decisions, it probably indicates that there are some deeper problems in the team.

Pick decisions are the ones where there's a lot of effort put into making sure the decision is the right one for the long term. Stakeholder alignment is key, but not always “contentious” and in a lot of cases, in fact, the stakeholders would consult external advisors, get a better understanding of the state of the art or best practices in the area. The alternatives may also not be clear and figuring out alternatives and their pros and cons is something that the team has to do together. Getting this right is key to the survival or continued success of the organization.

The hard part often is when presented with a question or a problem — should we take out the mousetrap or the cannon. How to use them is well known. Note that oftentimes, it’s not obvious at the time of decision making and people in retrospect realize they picked the wrong path oftentimes with detrimental outcomes — social media's struggles with trust and safety are well known but I’m sure the decision-makers thought of it as a Hack decision at the time. I would be surprised if people did raise this question, it probably got lost in the sea of A/B testing.

If you use "Hack" for a "Pick" decision, it oftentimes creates alignment issues down the line, or sometimes you might end up choosing the wrong path altogether - e.g., setting up a mission for your company that may lead to a suboptimal outcome due to lower multiples. At the same time, there are many companies that lost their mojo because they spent months and years on "Pick" decisions. They ultimately end up getting disrupted by emerging Silicon Valley companies because they decide to bring out the big guns on stuff that they maybe should have just tested quickly and cheaply. At Square, they call it the Kombucha scale of decision making - when the cost of decision making far exceeded the ROI from the decision.

Given all this, what should be the considerations in deciding what framework to use? This is by no means exhaustive but some thumb rules to think through:

  • Strategic Nature: Does this impact the future of the organization in significant ways, or perhaps the productivity of several teams? Will it probably change our relationship with customers or partners? Is this something that has a short-term impact or a step function change? E.g., a decision to use a different technology platform or entering a new market segment. While this seems obvious that people can make out whether a decision is strategic or tactical, it’s not always the case: very often seen in decisions are hidden in a small paragraph in a design document or requirement doc when that should have really been discussed more broadly. No wonder picking well is so important in investing - one well-made Pick decision can mean the difference between dreamers and high-achievers.

  • Reversible or Iterable: Is it easy to revert this decision or change to another alternative down the line? For instance, if we have two features to prioritize of small effort, will the sequence of execution matter significantly, and should it be deliberated a lot or within a few weeks we will be in the same end state in either scenario — maybe it's a local optimization best left out to the people executing it. Sometimes it’s important to Hack a solution quickly and iterate fast, rather than obsess over finer points. At the same time, if there’s a lot of rework needed in case of mistakes, you probably want to pick well — e.g., engineering framework selection or company branding.

  • Risk: What is the impact if it goes wrong? Will it cause financial loss to your customers if you get this wrong? Will we get into legal trouble or impact customer's trust significantly? How much harm can this person do if we make a wrong hire? Choosing the wrong investor or board member very often falls in this category but also think through your security infrastructure.

  • Level: Interesting to note that whether a decision is a Hack or a Pick can vary a lot based on the level or size of the organization too. A Hack decision for the CTO may be a Pick for a division head, or for an IC engineer. At the same time, bubbling up "Hack" decisions to your CEO is probably going to make her mad for wasting her time. Sometimes, you may want a decision to get more airtime than usual just because you want to position an emerging leader in the best possible manner.

  • Alignment: Is this something that’s used to bring a lot of people together and you want to make the decision inclusive. Company and Team Mission Statements are both strategic in nature as well as bring all the people together.

  • People Impact: In most places, any decisions about people are thought through and hotly debated very carefully at various levels. For instance, in most high-performing companies, hiring or promotion practices are designed to be "Pick" decisions.

    I’m pretty sure we hack a lot more than picking, but each successful pick can dramatically change the trajectory.

    Subscribe now


  • Loved this essay from Farnam Street. In most places there are only a few geniuses, the social butterflies are probably even more critical in carrying ideas around. Similarly, for most innovations, the person who markets it is probably as important as the person who invents it (I still remember watching “The Founder”)

  • Hiring great talent is one, but making sure they onboard quickly and successfully is as important for any leader. Designing your onboarding process to be inclusive, effective and making people successful quickly helps a lot in increasing organizational bandwidth

  • A lot of teams make mistakes. Some of them are due to our fault. As managers, one of the best things we can do is minimize those mistakes - which happens mainly through ruthless prioritization. There's the counter-argument to this as well: removing the fear of failure. This probably applies to Hack vs Pick decisions in some ways. We may make a strategic bet and it may not turn out okay, but spending time on unnecessary things should be avoided at all costs.

  • Of course, all of this advice gets thrown out of the window if you are working for somebody like Steve Jobs and live in the reality distortion field :)



  • One of the hallmarks of a high performing engineering organization is the ability to conduct objective impersonal post-mortems and keep improving continuously. Here’s a great list of existing post-mortems from some of the largest companies on the planet.

  • We all talk about Chaos Engineering, but what is it and why is it important? A great intro to Chaos engineering

  • When we start building a system, it’s always useful to start with a walking skeleton. The value of getting an end to end working system and the confidence it inspires in the delivery can not be understated.

  • Computer Science FTW. See the impact good algorithms can make.

  • If you have worked in enterprise software, you can probably identify with this. A lot of software touted as off-the-shelf is not really as easy to implement and there’s a lot of devil (and evil lock-in) lurking inside.


  • Opendoor is going to be public soon - and this S-4 breakdown was definitely very interesting to read. Lots of interesting potential but enough challenges and competition along the way

  • Raising VC funding is sexy, but I wish more people wrote about bootstrapping and building things on their own. Sometimes, it can be fairly rewarding. Loved this Twitter thread.

  • I have heard about the FOGG Story before, but it was great to see this written down in detail (India CPG, but definitely fascinating for anybody)

  • Staying on the theme of CPG, Ryan Caldbeck's blog post about transitioning out as the CEO of CircleUp is doing the rounds: his candor and being willing to be vulnerable in public is commendable. Also, intriguing is the "feedback" email to his board member.


Share Day Zero: Always Learning

Thank you for reading right till the end :)