Why your engineering processes need to solve real problems [Product Management – Inside Intercom]
I came to Intercom from a company with a culture of heavyweight engineering processes. It was a well-oiled machine with battle-tested and often updated procedures.
From an engineering perspective, it successfully kept you focused on coding. Tasks were always well-described in Jira, with clearly defined expectations. Designs came in and were exported to HTML so you didn’t have to worry about using Sketch. You did your job, then moved the task to QA. If something came back, it was always with a good description of what wasn’t working.
Processes have to serve the development of the product.
When I started at Intercom, however, I was surprised at how lightweight the weekly engineering processes felt compared to my previous company. No estimations. No Jira. No separate QA team. Initially, I felt overwhelmed. I wondered why it looked this way, why everyone just aligned and no one tried to structure the processes as I was used to.
The main reason is that in both of these companies, there were different problems to solve, even though it looked similar on the surface. Intercom is very much a product-first company, and very heavyweight processes can be too much of a constraint in a product-first company. In this sort of environment, the processes have to serve the development of the product, rather than the product developing out of predetermined processes.
At Intercom, we have a very strong culture of solving the right problems. We are ruthless in defining what the true problem is, how we solve it using a small, well scoped project (or a cupcake, as we like to call them) and how it might eventually look like if the cupcake proves to be successful. In short, we ask what is the problem and how will you measure that it’s solved. And we don’t just use this approach when working on our products – we try to apply the same approach whenever we want to add new or adjust existing processes.
The subconscious benefit of processes
In any organization, processes are important and beneficial. They streamline the workflows, help people make fewer mistakes and bring some degree of comfort – having a good set of processes can create the sense that work has already begun to proceed.
In this way, processes are usually comfortable, in the sense that they are institutional habits. We are stretched in our jobs already, so work that is aligned to a process is similar to a habit. The process is already de-risked and is thoroughly thought through, and ideally has a proven track record of successes. It removes a lot from your plate to let you focus on what’s important. It’s compelling to have less on your plate, right?
Solving the problem you have
Whenever you are designing a new process, the most important and the hardest part will be to clearly define the problem you are attempting to solve. It’s crucial not to skip this step. If you don’t identify the problem clearly, then you need to ask yourself why you are even starting. Proceeding without a clearly defined problem can be a sign of a worrying tendency for bureaucracy – and this can often be the first step towards alienating your best people.
Work that is aligned to a process is similar to a habit.
Instead, processes must be agile. They are innovative. They let you move fast. They take a cognitive overhead off your plate to let you focus on the most important things. But only if you solve proper problems with them.
I am sure that you can easily find out at least couple of problems you would like to get rid of. It can be something huge as “we are making mistakes with people we hire” which means that we need a better recruitment process. In software consulting, the problems are predictability and accountability for your customers. At Intercom, it’s making the absolutely best product.
Define the success criteria
When you have a good understanding of the problem, define the success criteria for your process. Don’t start with the process, start with what success looks like. Starting from success gets rid of your biases around the design (what you are familiar with, what you are comfortable with, etc.) and focuses instead on the best outcome possible. This defines the true success of the process. Remember, the usage of the process in itself is not a measure of success – usage without value is a clear failure.
It’s easy to get into the trap of the “usage is a success” in situations of high discomfort. If you feel uncomfortable with the current level of structure around you, you start thinking about improving the structure and introducing new processes. But if processes don’t solve real problems and are not being constantly improved to meet the success criteria, they make people stop innovating and harm your culture.
Update your process periodically
It’s important to update or get rid of old processes once they have outlived their usefulness, rather than remaining reliant on them. The whole exercise of designing a process is based on solving the problem. However, this problem is present right now, at the time you design the solution – the problem won’t remain static, and therefore the process shouldn’t either.
If processes don’t solve real problems, they harm your culture.
To make sure that you are not solving the wrong problems, you must encourage everyone using the process to challenge the status quo. In order to achieve that, you have to make sure that your processes are easy to change.
Master your habits, and processes
Processes should be beneficial and helpful without becoming burdened by bureaucracy. They can help you innovate, move fast and keep focused. However, you need to remember that every company is trying to solve different problems and therefore different processes. The worst case scenario is when you try to apply processes that don’t solve problems or don’t serve the goal of the company.
Like habits, some processes are good, some are bad, and some outlive their usefulness. And like habits, processes can be hard to change. But remember that successful companies, like successful people, are defined by their ability to develop and change their habits, rather than becoming beholden to them.
The post Why your engineering processes need to solve real problems appeared first on Inside Intercom.
Source: Product Management – Inside Intercom https://blog.intercom.com/processes-need-solve-real-problems/
Post a Comment