Note: I’ve written before about The Process. My mind came into this again, and while there are some nuances in this post, there’s also some overlap.

The Process

One common theme around companies that have achieved some level of “success” is the attachment to the way of doing things, The Process.

It’s understandable, as it is probably this process that led them to where they are, that made them become “successful”. Trying out something different is risky and prone to failure and no one wants to fall from their ivory tower. If there’s room for improvements, those must be made on top of the existing process, the process itself cannot be suddenly replaced by something completely different.

So here we are, doing things the same way as always. If the project fails, the blame can’t be on the process, for that has always led to success. Were any improvements added? Then maybe that’s your culprit. If not, then the people are the ones responsible for not succeeding - maybe they are inexperienced with the process or maybe they missed some key detail.

And there is a funny invisible repercussion to a process-first company - hiring turns into a game of hiring for “fit”, where fitness isn’t really guided by general intelligence, being a good person, and ability to do the actual work, but mainly about fitting into the process. Culture, they like to call it these days.

I’m obviously being simplistic here, there are many good reasons for companies to default to a process. For one, finding a good process every time a new project starts takes time and effort, something that’s not really abundant. And a bad process has a big impact in the output, so one should play it safe. Totally valid reasons.

But following the same road will at most take you somewhere where you’ve been. That’s ok if that’s your goal, but if you’re into actual innovation or in exploration mode, then you probably want more or something different.

The Processes of Building Products

This post was motived by how companies go on to work on their new projects.

The obvious thinking is that the type of project (critical or experiment) and its goals should help guide how the project should be approached. There are also the usual considerations of how fast you want to launch, how much importance you are giving to technical debt and all of the liking. But the people that are picked to work on the project should have an important say. For example, applying the same process to different individuals most probably leaves a lot of value on the table, because the individuals might be suited to work in a different way.

Having a team of two engineers working “alone” for a month might produce better results than the usual team of five being overseen by a product manager.

As with many things, it’s about your definition of success, what axis are you optimizing for and the trade-offs that you’re willing to make.