Being a (Tech) Product Company
After many years of working in Silicon Valley, Boston, London and Oslo, I’ve realized that I’ve never been in a company that was one or the other- it’s always both.
Most companies talk a lot about being a “Tech Company” and then engineers often get frustrated when it seems like Product (and other non-engineers) are calling the shots.
Nothing can happen without decent engineering of course, so in the end it’s there’s not really a choice between being a Tech or a Product Company and the goal should be finding the right thing to focus on at the time and matching the types of engineers in the company to the teams where they’ll do best.
At Vipps, we recently re-structured to organize Product and Engineering as a joint venture with platform/enabling teams and re-aligned product teams. If you’re working on a platform team, you’re working on the engineering focused part of the company, and the product teams are (obviously) focused more on user-facing products.
Good engineering needs to happen in both types of team. I think the difference lies in perspective and prioritization. We’re all working towards the same goal, though different teams add the most value in different ways.
Product-Focused Teams: Two Distinct Phases
A common startup mistake is to focus on building something amazing and scalable before figuring out what to build. So whether it’s for a new startup or a new project within a larger company…
First: Figure out what to build
The initial focus of a product team is on trying out ideas and validating next steps. This is the least strict phase for engineers. Shortcuts and hacks done quickly to validate what to do next is more valuable than well-engineered code. If hacky code gives you answers in a month, that’s more valuable then amazing code that gives you answers in 3 or 4 months.
Then: Build a solid product
Eventually your team knows what they need to build and then quality engineering leaps to the forefront. In this phase, work should take more time and the engineering should be thorough. You’ll need this to work well in production for thousands/millions/billions! of users.
Repeat?
During this phase we should keep in mind that what we learn while building might send us back to the previous stage where we need to figure things out again.
Engineering-Focused Teams
These teams also need to first figure out what to build and then build it, but there’s not really any room for hacky code here. The focus is on getting it right as much as possible, engineering is done in a stricter way and quality almost always trumps velocity. These teams enable other teams, so there needs to be some balance between “getting it right” and not blocking too much other work from happening.
When to Switch Phases
This is something that really needs to be a joint decision between Product and Engineering. Engineering needs to be ok with Product taking its time in phase 1 and doing quick hacks/prototypes to validate ideas. Product needs to give Engineering time to replace the quick hack and prototypes with solid code.
Getting the right amount of time for each phase can be a struggle. Product-Focused Teams can find themselves spending most of their time in Phase 1 and then rushing to get to production and to the Next Thing. Engineering-Focused teams can spend too much time “perfecting” their code and thereby slowing down the teams they are enabling.
What is “Good Code”?
It’s contextual. What is the expected lifetime of the code? What questions does it answer or problems does it solve? Short term questions just need code to answer that question. Maybe that’s proof-of-concept code that we plan on throwing away after the proof is proven (or disproven). Long term problems need code that can live a long time. There might be more emphasis on stability and performance with long-term code, as well as readability (over the long-term it’s more likely somebody that is not the author will have to update the code).
Good code is code that provides value. It’s up to you and your team to decide what is valuable and what you want to get out of the code you write.
Closing Thoughts
On a high level, the key thing here is to not try to make a binary decision about what kind of company we are. We need to try to find the right balance for each of us to contribute in the way gives the most value for the company and for us as individuals- some people like doing very detailed engineering, some people like prototyping, some people like building products- we have opportunities for all of that here.
