The short-term fallacy

It is quite often that we make important life decisions based on short-term rewards. Our brains are wired to hang onto short-term rewards since throughout the majority of human existence long-term thinking was hindered by life threatening situations. Can’t do much long-term thinking while being hunted by a lion or with an empty stomach.

I’m not talking about those situations though. I’m talking about career or partner choices that are based on state (that represents short-term) and not trajectory (that represents long-term). 

Take this image of an airplane for example: by the looks of it, its state is perfectly fine, flying in the sky towards some destination. Let’s assume that this airplane has reduced thrust in both engines and a flight computer malfunction is causing the airplane’s nose to pitch up. The airplane is flying alright but it is minutes away from an aerodynamic stall, a situation where the lift generated by the air flow over and under its wings is not enough to sustain normal flight. Unless the pilots do something, like pitch down for example, the airplane will fall from the sky in a free fall. 

It is quite common that we get carried away by a state that looks appealing and fail to see the trajectory. The examples are numerous, we choose a company because it reduces commute time, offers remote or uses a technology that we really like. We choose a business partner because it happens to be a friend or share a common lifestyle. 

These are states that don’t reveal anything about the future and while choices based on short-term evaluations are not irreversible it is worth taking some time to evaluate the long-term repercussions.

If, while evaluating a company, you favor the technologies they use, their office location, or any other perk, ask yourself: will these circumstances be equally important for me in the future? More importantly, how committed is the company to keep the above? What if they move in 6 months, change technologies or go under?

If you get a 10% salary increase by job hopping every year, ask yourself: what will a future employer think of me in my forties, will she be able to trust me for something important? 

If, while choosing a business partner, you evaluate his / her current commitment, ask yourself: how would I want things to evolve in 10 or 15 years when both of us have a family? Do we want the same things from our lives?

If, while evaluating a technology, you get excited about its current prospects, ask yourself: how dependent will I get from that technology, how easy will it be for me to change when a new one pops up? 

All these questions have no definite answers, in some cases a short-term reward is the only way out from a painful situation but in most cases we have the luxury to spend enough time to evaluate our decisions. 

Keep in mind that short-term gains (or even harder losses) are very much real and tend to understandably blur our vision. Break-ups are so hard because the immediate events are stressful and very easy to imagine than a vague description of better future times. Α bigger salary today is much easier to evaluate than stock options or a promotion that may materialize in the future. 

One trick I often employ to help myself from over-dramatizing short-term gains or losses and allow for a more calm evaluation is to write everything down, both long-term and short-term expectations. I also try to answer the question of what long-term effects my current decision will have and then put those in the evaluation mix. 

How do you make high stake decisions?

What is Kaizen and why you need to embrace it

One of the biggest drawbacks in a large organization is the increased network of communication that eventually slows down its operational and execution capabilities. Inversely, a startup’s greatest advantage is its friction-less environment and getting things done attitude.

The biggest challenge of a large and growing organization is to accept a small inevitable slow-down and strive to adopt methods to bring its speed as close to a startup’s speed as possible.

The slow-down mainly concerns the development process, not daily routines. The term development can refer to a new feature, an initiative, a sales or a marketing campaign, a process inspection, pretty much everything that enhances the organization’s product or operations.

A start-up that wants to build feature X has only a few things to consider, almost all of them related to the feature at hand. An established organization, on the other hand, needs to consider all sorts of things: how to market it, will it have any performance / legal / PR / repercussions, how to make sure that all teams are aware of new functionality, and so on and so forth.

There is also a common misconception that heavily researched projects are well designed and easier to execute. Even if that held true there is a problem on the receiving end: the user.

For as long as the project is being researched, debated, and internally communicated, the user still uses an inferior product. Ask anyone: would you like a car 10% better than the one you are driving today or wait for a 50% better car in 5 years? The answer would most definitely be the 10% increase today. Sure, some car manufacturer is working on a flying prototype that runs on solar power with an AI autopilot that will go into production in 10 years, but that doesn’t help me today. If you want to take the above example to the extremes, think of not having a car at all.

Now switch to any product or service. If a user doesn’t have useful feature A at all, she won’t mind having 30% of it tomorrow than 100% of it in 3 months. Instead of going from 0% to 100% in three months, you can go in steps of 33% each month.

The counter-argument here is that small changes usually take longer because of all the operations that have to be executed more than once. This subject is heavily debated, but for the sake of the argument let’s consider that there is a 10% slow down indeed and three months will get us to 90% instead of 100%. This progress is portrayed in the following drawing masterpiece:

It is evident that the total surface of the area where progressive release cycles are better is much bigger than the surface area where complete release cycles are better even when taking into account that progressive is a bit slower to get to 100%.

Consider an example from an eCommerce platform: we’ve identified that category X is outdated and we need to update its filters, or add more pictures and videos. If we bundle all those changes in a huge block that will require 20 days of work, the users will see an inferior category for those 20 days. In a worst-case scenario, a category that needs only minimal changes will be de-prioritized until it justifies a complete cycle. Until then, users will see an inferior category, getting worse by the day, until the grand revamp.

Meet Kaizen

Any successful product can be greatly improved with small incremental changes that eventually have an important impact. Even a 1% increase in an important KPI is of great value for the business but most importantly for tthe consumer.

Kaizen is the concept of applying continuous small improvements in all aspects of a business with the aim of achieving gradual but noticeable performance enhancements.

We are particularly interested in one variant of Kaizen, Point Kaizen:

It is one of the most commonly implemented types of kaizen. It happens very quickly and usually without much planning. As soon as something is found broken or incorrect, quick and immediate measures are taken to correct the issues.
These measures are generally small, isolated, and easy to implement, however, they can have a huge impact.
In some cases, it is also possible that the positive effects of point kaizen in one area can reduce or eliminate the benefits of point kaizen in some other area. An example of point kaizen could be a shop inspection by a supervisor and he finds broken materials or other small issues, and then asks the owner of the shop to perform quick kaizen to rectify those issues.

The first step to embrace Kaizen is to embrace methods to continuously monitor your product even when we are not actively monitoring it:

  • If you are lucky enough to be able to use your product as a user (e.g. an eCommerce site) you’ll certainly identify various problems.  If it is a small one and within your area of influence, fix it as soon as possible. If not within your influence or seems like requiring a lot of effort report it.
  • When testing the product for anything make sure to look around as a user, not an employee or a manager. Fix small problems right on the spot, don’t wait for them to be prioritized.
  • Make sure to spend a small amount of time every now and then to inspect the platform as the user. For every action that you make ask yourself the question: would I do that if I didn’t have all the internal knowledge that I have? Strive to make even the smallest improvement.
  • When researching a project with your team lean towards a design with small intermediate deliverables than a huge one after some time.

One positive aspect of Kaizen that we have not discussed is team spirit. Small incremental changes that have a visible impact will remove the frustration of missed deadlines and provide all the necessary dopamine kicks.

Finally, small changes allow us to validate our assumptions, gather feedback, and steer accordingly if required.

On process optimization

In every stage of a business, there will be some processes as part of everyday operations. Some examples include the onboarding of a new customer, replying to customer support tickets, or interviewing candidates for a new position.

All processes, whether well defined and documented or just common knowledge, start small and simple and almost certainly end up huge and complicated. Drawing a parallel with the world of physics, processes obey the rule of inverted entropy: every process wants to transition from small and simple (low energy) to big and complex (high energy).

This transition will not happen overnight but with small distinctive steps that will eventually slow down the team’s performance. In most of those cases, the slow down will not be attributed to the increasing complexity of one or more processes but to the high load of the team which will result in more hires and further performance degradation.

Apart from the obvious problems that a complex process has, taking more time to complete and requiring more resources, there is one more hidden in the background that poses an even bigger threat than a slow down: teams with complex processes don’t scale. Onboarding a new member takes a huge amount of time and the more people you add the more managers are required to control the complexity.

So how does someone optimize a process? As a rule of thumb, expect a significant efficiency boost in any process optimization effort. In “High output management”, Andy Grove says:

This is called work simplification. To get leverage this way, you first need to create a flow chart of the production process as it exists. Every single step must be shown on it; no step should be omitted in order to pretty things up on paper. Second, count the number of steps in the flow chart so that you know how many you started with. Third, set a rough target for reduction of the number of steps. In the first round of work simplification, our experience shows that you can reasonably expect a 30 to 50 percent reduction

Andy refers to production steps as in a factory but work simplification can be applied to any process. To keep your processes small and simple you need to do two things: don’t allow them to get complex and inspect them frequently to reduce the number of steps.

Both actions require asking the same questions either while introducing a new step or when inspecting a process to optimize it.


Process optimization is mostly about inspecting a process and eliminating all unnecessary steps or optimizing them if elimination is not possible. To identify those steps we need to take a look at the most common causes which are described below.

Better safe than sorry

Some processes have a number of steps to ensure that nothing ever goes wrong. Say, for example, your support team has a process for handling customer requests of a certain type that is working fairly well. At some point, an angry customer reports a not so common case where your process failed in a way that it created a lot of frustration or actual damage. One or a few members of the team took a lot of heat and the customer eventually churned.

To avoid this happening again the manager of the team will add an extra step with additional checks to make sure the process is fail-safe. With time, a few of those not so common cases will translate to a number of additional steps being added to the process.


This is a classic especially for processes that have been around for a long time. A step was introduced to gather some extra information required by law but that law no longer exists. Because of the distance between those handling the process and those designing it the step will sit there for quite some time even though it’s no longer required.

Scope creep

It’s not so uncommon to find processes with steps that apply to only a specific attribute of the business but have no scope. An e-commerce platform, for example, may require specific handling of a certain category that will be introduced as a new step. That step, however, isn’t that critical to all other categories and could be easily scoped affecting only a small share of the team’s resources.

Premature steps

Every process that has more than a few steps will probably have dependencies between them. Signing up a new customer, for example, will require an up-front setup fee and probably a few other steps. That setup-fee step should be placed at the top and all other steps should be blocked until the customer has made the initial payment. In many cases, processes pack all steps interdependently resulting in extra work that goes wasted if that critical step is never completed.

Requiring various levels of authority

Processes may have steps that can’t be executed by the same individual and requires a different, usually higher, level of authority. People with authority are usually far less than the people executing tasks which results in a bottleneck.

No automation

This is probably the easiest one to address. Some steps are gradually degraded to something that can be automated or in other cases the technology required for automation just wasn’t there when the process was designed (e.g. checking the creditworthiness of an individual). Note that optimizing parts of the step but not the whole step will still increase efficiency.

Designing a process is equally important as maintaining it after it has been deployed. The most common cause of process inefficiency is lack of maintenance, it’s not uncommon to find processes that haven’t been inspected for years. Heavy load processes should be inspected every 3-6 months, while less frequent can be inspected in bigger intervals.