This case study demonstrates the following skills:

• I first understand the goals clearly. I also understand non-goals, which draws a boundary around the goals. We're often in a rush, so we start executing without clarity on goals, but that's like getting in your car and driving without knowing where you're going. In this case, there was one narrowly defined goal: to fix a bug where users upgrading to premium were not getting premium content.

• When I run into problems, I know when to take a step back from the given goal and evaluate the code holistically. Reframing the problem was necessary in this case to identifying the root cause, without which any efforts won't solve the problem. If you go to the doctor and say, "Hey, doc, I want a bypass surgery", the doctor doesn't say, "Great, lie down on this table over here, and I'll grab my scalpel and come back!" Instead, he'll investigate the problems and form his own independent assessment. That's what I did in this case when I stepped back from the given goal of the payments bug and holistically evaluated the tech.

• I'm able to tie my assessment back to the given goal: given the poor state of the code, fixing the payment bug in a way that stays fixed requires rewriting the whole code.

• Once I decide to rewrite the code, it's usually better to improve it in place: imagine you have a car where every component is broken: the engine, the transmission, the brakes, the seats, the windshield, and so on. It's usually better to replace the engine, at which point we have a better car than before. Then we replace the brakes. And so on, eventually ending up with a brand new car. Doing it this way is quicker, less risky and delivers value sooner than buying a whole new car. However, I also know when a general guideline is not applicable, such as in this case. I reached this decision by evaluating technical reasons (React being hard to upgrade) and non-technical (the founder's lack of confidence in the agency that built the app).

• I'm able to guide the founder on how to make the best use of a limited budget, such as by suggesting he prioritize UX over more features.

• When I find deficiencies in the client's thinking, I guide him on improving as an engineering leader, such as having granular milestones, or recognizing that a greater scope of work will result in greater time and cost. That way, the client is more effective in the future, and that the problem we started out with doesn't repeat. I try to leave clients better off at the end of the engagement than before, rather than making them dependent on me.

• When we started the engagement, we did not know that we'd end up evaluating agencies. I do what's best for the client. Having run a startup before, I'm not rattled by uncertainty. Instead, I bring order out of chaos.

• I was able to achieve all this in just 14 hours, resulting in a high ROI.

​

This flowchart tells you how I executed this project at a high level, followed by a detailed flowchart:

Step 1: Understand goals and non-goals

Step 2: Root-cause the problem

Step 3: Propose

Step 4: Execute, and Results