Making sense of numbers

After a major feature release one of the engineers in the team rushed to tell me that the search conversion rate had increased by 300% according to the team’s data analysis. I challenged the number quite a few times but he and the team had triple-double checked the numbers and insisted that they are counting 3 times more clicks than before the feature release. I insisted back: if the conversion rate has increased by that much, where is all the additional revenue?

Our main revenue source at the time was clicks to merchants, a 300% increase would result in a similar revenue increase but the daily revenue hadn’t changed at all. Well, it turned out that the data were flawed, the actual conversion rate increase was marginal.

Humans have to deal with this type of number validation in their daily and professional lives. Being able to perform a basic validation of any number is crucial not only for making quick decisions but for understanding the world as well. Take fake news for example, almost 99% of the time they will contain some numbers. Those numbers will be most often exaggerated in order to draw attention and make a story believable but that exaggeration is also the reason the stories can be easily taken down by a quick number validation.

Numbers are connected. Not only in the math realm but in the physical world as well.

What if I told you that North American cicadas remain underground for 13 or 17 years before they emerge? The number is quite big to grasp, it is absurd to believe that a species would choose such a big life cycle and even more difficult to understand why not 9 or 21 but 13 or 17 years. You would have every reason to believe that I just made it up that number but before you go on to check Wikipedia let me assure you that it is a fact and those cicadas actually spend that much time underground.

There are many explanations as to why, the most accepted one being that 13 and 17 are prime numbers and ensure that when the cicadas emerge their natural predators will not be that “hungry”. If a bird for example has a 3 year cycle it will take 51 years before the bird and the cicada life cycle coincide making sure that as many as possible cicadas will survive.

Numbers are connected with little strings that you can push and pull anytime you need to validate a number. If a number is off there is a chance that you can’t validate it on a standalone basis but you can follow its dependencies and effects and validate those.

As another example, what if I asserted that a factory produces X millions items of product Y daily? One quick validation is to look at the materials required for that product: are there enough in the world? Same goes for those conspiracy theory government spaceships that require amounts of energy the planet doesn’t have (not even the solar system in some cases).

I have many examples where I, or a team I work with, made decisions based on a number that was obviously wrong but based on real observations. With huge amounts of data and complex attribution schemes there is always the possibility that a critical number is calculated in a way that is disconnected from reality yet everyone takes it for granted. Circulating it so that other people will validate it independently is a sure way to minimize errors. Do you have any examples to share?

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?

Embracing chaos

In my daily routine, and although Skroutz is not a startup anymore, I frequently have to deal with chaos. If you are a part of a high growth tech business chances are you are dealing with chaos as well, whether an individual contributor or a manager. Below I share my thoughts on why you need to embrace chaos and how.

Human beings evolved to avoid chaos. Throughout our evolution, the neocortex, the external part of our brain responsible for intelligence and consciousness, further increased our repulsion to chaos. In the final act, science and education set absolute boundaries on each and everyone’s definition of structure and chaos, boundaries that are so deeply engraved in our biology that even the description of a chaotic image can cause our hormones to react leading to stress.

Structure and knowledge has led to so many great things from well organized societies to medicine and space exploration. Our ability to function under complex conditions and continue pushing humanity forward can be attributed to our inner urge to replace chaos with structure. There are times though, where chaos is not only useful, but necessary.

When exploring the unknown or prototyping, there is no structure, only chaos. Yet every cell in our body is resisting half solutions, unfinished or duplicate work, unpolished outcomes: we want it perfect, well thought out, greatly engineered and perfectly executed, it is after all what we have been taught to do. But exploration implies unknown, uncharted territory. It implies having no idea what the right approach is or even if you are going in the right direction. Exploring requires accepting chaos.

We can all see the problem here: while we are wired to avoid chaos we also need to embrace it every now and then. Whatever our expertise, one day we need to strive for perfection, the other day we must accept messy, temporary solutions. There is a form of mental hackery that can help anyone navigate this cognitive dissonance: it is called changing the narrative.

I want to share a story where a simple narrative change helped me transform an experience I was struggling to cope with to a pleasant one.

Being a geek dad, I used to buy all sorts of build kits: Lego, LittleBits, Kiwico, MEL Science, you name it. While these are built for children they do follow the same science principles I have been educated to. And they also have specific build plans and instructions you need to follow to complete the build. Fun times, right? Well, kids are not particularly fond of build plans nor do they have any specific urge to do things the proper way. You can already imagine what my engineering self felt like while watching my son connect pieces in every possible, but completely wrong, way or deciding to build a submarine out of a helicopter kit. I was completely frustrated when I had to build the same component over and over because junior wanted to see if it could fly. And how I had to react to ideas that defied gravity or other universally accepted laws of physics. It was obvious that I wasn’t having fun during an activity that was supposed to be lots of it. So I changed the narrative from “Building a kit with my children” to “Spending time with my children”. This simple narrative change made me go from “Why do I have to build this again” to “Spending time with them, this is awesome, let me see if I can get them to learn a thing or two”. I could now accept chaos because the narrative change made it irrelevant.

Going back to business and product, the same mental hack of changing the narrative, can do wonders when we have to follow a messy route. The narrative “Build feature X”, can be changed to “Learn if consumers are interested in feature X” or “Examine how merchants will react to feature Y”. This different narrative moves attention away from how we are building a feature to why we are building it in the first place. From how this is going to be perfect to how soon we can get feedback and adjust accordingly. From how chaotic and messy the prototype is to how much valuable feedback we got early on leading to less unnecessary debates and less work being throw away as being irrelevant.

We come across such cases all the time in our daily routines. We never wanted to build three versions of Skroutz Plus, our loyalty program, and have to go through messy update processes, sending upgrade emails, replying to customer complaints and so on. But there was no other way of understanding user behavior nor any scientific way to determine the proper structure for our unit economics to work. What seemed plausible during our early day analysis was changed by consumer reality.

This is not to say that we need to stick with chaos indefinitely, we just have to accept it long enough to draw our conclusions and build a large degree of certainty in our approach. As soon as the exploration phase ends we can always revisit and put as much effort as possible into getting it perfect.

What narrative can you change today? How can you better embrace chaos?

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.

The path to seniority

Disclaimer: In the vast majority of this post I’m targeting seniority in software engineering since my experiences are drawn from that profession. I would assume that most of the things mentioned below would apply to any creative profession or, simply put, to anyone who is building things.

As soon as someone starts being a certain type of professional, probably fresh out of university, he/she is given the title of a junior. A junior is someone that still has no relative working experience but he/she knows the science and accumulated knowledge taught in a university. In the following years, this professional will rise to be a senior, principal, architect, etc.

In my humble opinion, there are no levels in seniority, as soon as you start thinking like a senior you then go on to expand your experiences and knowledge but most importantly broaden your scope. Principals and architects are seniors with many years at that senior level. The industry needs those titles for a good reason but for the purpose of this post I will only cover the transition to “Senior”. After all, 95% of being a senior is about managing yourself and the things you know, as soon as someone reaches that level they are automatically capable of advancing indefinitely.

If I could give you only one piece of advice for becoming a senior that would be “Curiosity”. Genuine, humble curiosity. Becoming a senior is all about managing your curiosity and managing your own shortcomings.

Below I describe four simple steps to transition to a senior. These steps may take 5 years or 15 years but certainly not one.

Step 1 – Know your tools

Every builder has a set of tools that are required for the building process. Some builders will use a few tools, others will use a lot. Junior builders are introduced to their trade through the usage of tools.

For the better part of a junior’s career, the usage of tools will play a very significant role. I can still remember my early days where I would spend countless hours configuring my code editor, learning to quick-type, and setting up my environment. I even compiled my own kernel and packages because, well, it was nice knowing that I could do it.

In my recent endeavors in woodworking, I realized that every novice will start from this stage of tool fixation, it’s not a software engineering world thing. I’ve devoured every woodworking video out there and almost all of them describe tools or how to fix your own tools, how to enhance your workbench, or improve your dust collection.

As a junior, you need to master your tools so as to get them out of your way. You will eventually come back to some tools later as a senior but only again to get them out of your way, or simply have fun.

Step 2 – Start building

This may look like a captain obvious statement so it needs some unpacking. You need to start building like there is no tomorrow, all the time and without any hesitation. Your creations will look ugly and may go under heavy scrutiny from seniors colleagues or friends but you shouldn’t worry because you’re learning in the best possible way.

Every time you finish a project you will have a better understanding of the domain which will not only help you with your next project but also feed your curiosity that will be valuable for step 3.

Your purpose is to clear out the fog that surrounds the world of production and this can only be done by producing output yourself.

Put your head down, pay zero attention to your title, and just build like crazy.

Step 3: Know your craft

After spending some time on step 2 you’ll start understanding your domain as a collection of systems that interacts with other collections of systems. You already are comfortable with building something from the ground up but not everything makes sense all the time. This is where you need to escape from being an expert beginner and start being ridiculously curious about everything in your technical vicinity. How does a database index work, how do operating systems handle processes, how the browser paints content are a few examples taken from the software world.

You should also start paying attention to all the other systems that interact with yours. As you would expect a cockpit designer to know a thing or two about human performance and limitations, you should know a thing or two about human interaction if you’re a frontend engineer for example.

Don’t accept to not know how something works, ask questions, and be curious.

Step 4: Finding purpose

The time has come to deal with yourself. By now you should be pretty confident with your skills and you’ve learned how to learn. You should also no longer feel the need to prove anything to anyone which will help with the final stage of the transition to a senior: finding purpose.

Building is about providing a function to someone who needs it and this never concerns the materials used for the build. No-one constructs a chair because some blocks of wood were unhappy but for a human to sit in.

In my experience in the software world, I’ve seen many people unable to escape from the connection they have with their tools and themselves. They keep fixating on new technologies and developments but always related to how good experts they are or can be, not what they can build with those. They will bend the world to satisfy their endeavors, not the other way around.

How can you go past that stage?

Start talking in a simple language avoiding jargon. It shows that you care about the outcome more than showing everyone how much knowledge you possess.

Start talking results instead of technology. You can still use the cool stuff if you have to.

Be iterative, the world doesn’t want you to rebuild it from scratch every time something doesn’t work.

Worry about the quality of the service of the system you build provides more than how the system was built.

Constantly expand your scope of knowledge. You can design and build better if you understand what purpose your project will fulfill.

Avoid complexity. A simple design is a sign of seniority.

Work with yourself. You don’t have to be a manager to have soft skills, good communication, self-management, and empathy are powerful tools.

Be a listener more than a talker. It shows that you’re trying to understand the problem.

Stop worrying about your title and start worrying about how much value you add to your team, colleagues, and the world.

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.
― Why The Lucky Stiff

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.

Optimizing

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.

Legacy

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.

How to be great at anything

I have come to believe over the years, through my personal experience and by observing others, that there is a small piece of advice – only 4 words – that if taken seriously will make you great at anything. It’s battle tested and it works 100% of the time. I’m not asking any money for it but if I did I would offer a lifetime money back warranty.

If, like in games, had one jar of hyperbole and I could only use it once in my life time then that would be the case. It’s the single most important advice you’ll ever hear, apply it and you’ll get instant small life improvements and guaranteed lifelong greatness in whatever you want to be great at. So here it is, 4 words:

Lean Into The Pain

First things first, I’m not talking about physical pain or any other unbearable pain. Cutting your finger off will not make you great at anything, maybe only on finger cutting and that isn’t that respected nowadays. When I say pain I’m mostly referring to discomfort but that wouldn’t make much of a title and I’m still left with half a jar so I need to use somewhere.

Leaning intο the pain means identifying all the issues that keep you from having a great relationship , a great job, a happy life, good health or any other thing that troubles you and working against them. You might think that this is what we all actually do, and yes we work against issues all the time, but only within our comfort zone carefully trying to avoid any pain. I know because I do it all the time:

For the better part of my life I was obese, weighing 30kg more than I should. I knew that I had to loose some weight but breaking up my relationship with food was painful. I did lean into the pain, started eating less calories than I needed, begun regular exercise and lost 26kg. I was also afraid of flying so I started flying lessons that eventually led to a pilot license. This very post is painful, I don’t have good writing skills and I struggle to find the words, let alone the fear of criticism.

I’m not trying to portrait me as a winner, I got some of my weight back, extreme weather conditions still terrify me when airborne and you’re already in pain from my writing skills. I’m only saying that what kept me going was repeating in my head “the pain you’re feeling right now means you’re doing the right thing, keep up”.

I also don’t want to patronize or question anyone’s happiness. If you have figured out everything perfectly in your life and go to bed with no troubled thoughts then bravo! It would be great if you could share how you got there.

Start leaning today.

If you have a friend that angered you don’t wait for it to sooth out, it never does, go on and tell him / her, have a heated argument, sort it out.

If you love someone don’t let it drift away, reach out, speak up about what’s troubling you, do the tough, painful, discussions.

If you want to stand up in a meeting and say something do so. If you fear you’ll get mocked then lean into it, say something stupid, learn from it and say something smart the next time.

If someone criticized you for your behavior look into it. Go see a therapist, talk to friends, frame it and improve it.

If you feel small in your current job role then develop yourself. Read books, seek coaches, mentors and take responsibilities.

It doesn’t have to be all at once, you can select a few or just one. Make sure your life is filled with some kind of growing pain that you’ve selected to lean into it.

Related material: