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.
This post is based on a talk I gave at our recent Building Intercom event. You can watch that talk in full here.
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.
Komentarai