Every engineer is a product person
Previously Nilan explained how TransferWise teams are autonomous and trusted. This has some profound effects on what it means to be an engineer here. One of those is there is no real engineer / product manager difference, every engineer is a product person. It’s probably the main characteristic of our engineering organization.
Sure we do have product managers (i.e. product people who don’t code). Figuring out the right product is a time consuming task, requiring a lot of research, data analysis and sometimes specific skills. But when it comes to deciding how the product will shape, the engineer voice is not less important than the product manager’s one. Instead of having to fight to get his voice heard when it comes to product decisions, the engineer is expected to speak up and be involved in it.
Said that way, it sounds obviously amazing. Who wouldn’t want to have his opinion listened to? But with it comes responsibilities and expectations. Being a product person doesn’t mean just giving your opinion based on gut feeling. It means understanding the product, understanding why our customers are using us and even more important why they are not using us or are not happy. It means backing up decisions with data and research.
It also means building features without a product manager to rely on. You are both the developer and the product manager. This is not easy, and not for everybody.
How we hire is profoundly influenced by this philosophy. Most engineers have never been in such a situation and have no experience in it. This means we don’t expect a lot of product experience from our candidates (although having it doesn’t hurt). What matters is having a mindset that fits this world, a mindset which I would describe as caring for the product and being balanced in setting priorities.
This can also be translated in terms of motivation: We wake up every morning first and foremost to build an amazing impactful product for our customers. Of course, while we are at it, we try to write beautiful code or use the right technologies for the problem at hand, because that makes sense in order to build a sustainable business.
The trust we are given comes therefore with lots of responsibilities. We need to focus on the customer, but this doesn’t mean we can neglect investing in the long term. Refactoring code may not have direct impact on the customer right now, but is also required. Our deal with our customers is not only to offer them a great product now, but also build a company that is there for the long term. There is still tons to do to make money transfers right, we have only scratched the surface.
Not easy. But very fun to do!