Skip to main content

On Solving The Right Problems

As a student of engineering you’re incentivized to write a lot and to read a lot. You’re expected to solve many well understood, discreet, simple problems, on paper, on sunny afternoons in late May and early June.

This kind of learning has its place – it encourages discipline of thought and allows you to develop certain important muscles that will be useful for later – but to be successful as a product engineer, you’ll also need to master a bunch of different skills.

In product engineering, you’re incentivised to deliver results and this means quickly shipping solutions to problems that are difficult to identify and hard to frame. You’ll need to trade off progress over perfection, speed over safety, and all of this introduces a lot of uncertainty.

There are things you don’t want to break.

I know what you’re thinking: “That sounds like ‘move fast and break things’, right?”

Nah! I’m not convinced Mark Zuckerberg has everyone’s best interests at heart, and you’d do well not to listen to people who don’t have your best interest at heart.

There are things you don’t want to break. You don’t want to break your customers’ trust. If your customers can’t trust you to deliver, then you’re done. But more than this, and from a personal perspective, you don’t want to break your spirit. Moving fast and breaking things as a modus operandi is a sure way to a broken spirit over the long term.

At Intercom we think slightly different and operate by a more robust core value: move fast and optimize for the long term. Like all great values, there’s a purposeful tension reminding us all that absolutely everything is a trade off. I’d like to propose five principles for helping you work with this value.

Pick the right problems

The most effective engineers don’t work on the “hardest things”. They work on the “right things”. So what do I mean when I say “right things?” We as engineers spend a lot of time on figuring out what is the right problem. In picking those problems it’s worth looking for those with asymmetric payoff. Practically, this means two things:

Like all great values, there’s a purposeful tension reminding us all that absolutely everything is a trade off.

First – pick problems where the reward for success is high. Don’t pick a problem to show off or to make yourself look smart; go solve a problem for your customers or your teammates. How many articles or tweets have you read recommending this functional programming language, that microservices pattern or rewriting in this super new framework? Framed in this way, things like rewriting your code base from scratch is not a problem where the reward for success is likely to be high. Instead pick the right problems, the ones whose solutions are likely to add and lock in definite value.

Next – make sure that the cost of failure is low and ideally fixed. Failure can look like a number of things: perhaps you didn’t frame the problem well, picked the wrong feature set or chose an approach that caused more problems than you anticipated. This happens, particularly when moving fast and often due to things completely beyond your control. It shouldn’t matter that this happens as long as the cost of failure is low. Keep the cost of failure low by moving in small increments that add concrete value and ensure that the act of moving backwards is not costly in itself.

Become an expert in not being an expert

To move quickly and hustle effectively you need to be capable of getting at the fundamental, core ideas of something and of mastering them just enough to create value. So get good at coming to grips with new concepts quickly and get really good at making your solutions as simple as possible. Compose your solutions of the absolute fundamentals and don’t get sucked into fancy for fancy sake. Get good at knowing a little more than you need to know to be dangerous and at having just enough fundamental knowledge to leverage for impact. You don’t have to be the “smartest cookie”, you just need a deep understanding of the fundamentals and the discipline and courage to bet big on the right hands.

Don’t pick a problem to show off or to make yourself look smart.

Make sure success or failure is obvious to everyone

Think of a time when you shipped or completed a project and all that you felt was an underwhelming sense of anti-climax. It’s not a good feeling. When you’re done with a project, it’s has to feel like a win; you’ve got to know that you’ve locked in value. Otherwise how do you know you’re doing something well? You need to define what winning looks like as objectively as possible and with just enough concrete metrics and customer feedback to know the score.

Short, tight feedback cycles help you to quickly understand whether you’re succeeding or failing or somewhere in between. This means getting on the same page to create a shared understanding of how we are doing, so that you can exploit success or react to failure. Being clear about how you’re doing in-flight will help with discerning your next move through a problem.

Predict broadly and position yourself to react

Be really careful when trying to predict the future, particularly when using approximations or models. The best model is production and the best test cases are your customers. Don’t try to figure everything out up front. Just get a good sense of your direction, move forward through the problem positioning yourself to react to the outcome. Reacting to the outcome might mean exploiting some piece of value you’ve locked in or reverting a bad move when you get more data. Don’t put too much faith in your predictions or models of your customers’ behaviour or get beholden or precious about your models – customers don’t always know what they want until you put it in front of them.

Get more data and remember it’s just data

Remember, there’s no such thing as bad data, it’s just data.

Don’t get hung up on being wrong. It is what it is. Paint your picture of what is true now and move through the problem with confidence as if that picture was completely accurate. That said, always be seeking new data, new perspectives and new feedback. When it matters, adjust your picture of truth and repaint it and then move again with the same confidence you had before. Keep gathering data, keep incorporating your metrics, customer feedback and your prior learnings into your future moves. Remember, there’s no such thing as bad data, it’s just data and how you choose to use it.

Keep it moving

In life and in product engineering you’ll never guess up front what’s actually going to work out or not work out. The more you learn, the more you know that you know absolutely nothing. You’ll need to take on a risk and manage it deliberately and effectively in order to learn a bunch of things the hard way. Ultimately, you’ve got to learn to keep it moving. You can’t spend your career looking at problems. You’ve got to look through problems. Then you’ve got to move through problems, and you have to move through them uncomfortably quick. These five principles will help you do that:

  • Pick the right problems
  • Become an expert in not being an expert
  • Make sure success or failure is obvious to everyone
  • Predict broadly and position yourself to react
  • Get more data and remember it’s just data

This is hard – it requires skill. You’ll need to develop courage and a disciplined sense of priority. You’ll need to develop a willingness to understand that everything is a trade-off and all options are on the table.


Popular posts from this blog

How the Python import system works

How the Python import system works From: If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like  ImportError: attempted relative import with no known parent package ; or tried to figure out how to structure a project so that all the imports work correctly; or hacked  sys.path  when you couldn't find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us  Importing files from different folder  (1822 votes),  Relative imports in Python 3  (1064 votes) and  Relative imports for the billionth time  (993 votes), are a good indicator of that. The Python import system doesn't just seem complicated – it is complicated. So even though the  documentation  is really good, it d

On working remote

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this. So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working s


मुद्दत हो गयी उन तन्हायियो को गुजरे , फिर भी इन आँखों में नमी क्यों है  ? तोड़ दिया मोहब्बत पर से यकीन मेरा, फिर भी मेरी दुनिया में तेरी कमी क्यों है ? हसरत है क्यों आज भी तेरी चाहत की मुझे, क्यों याद तेरी जेहेन से मिटती नहीं ? जलजला क्यों उमड़ता है ख्वाबो में मेरे, उस आशिकी की आगज़नी क्यों है  ? सन्नाटो में भी क्यों सुनता हू तुझे मेरी परछाई से क्यों तू जाती नहीं ? इन डबडबाती आँखों को तलाश तेरी, आज भी कहीं क्यों है   ?