Product Engineer

Healthcare systems in a foreign country? Doctors, nurses, hospitals, gp practices, rota management… I worked in this company, but I had no interest in this domain.

I wanted to improve transferrable skills. I expected product managers and designers to hand me specs, so I could focus on architecting and building. That kinda worked out, but when our team met the cofounders for strategic discussions, I couldn’t contribute much. I could estimate the effort involved in building a mockup, but I couldn’t propose an alternative with 2x value at 0.5x cost. Others could smell my lack of enthusiasm for the business - especially the cofounders, who lived and breathed it.

Your colleagues want you to care about the team and company. People who care want to work with other people who care. When you prove your investment in the business, others will reciprocate, investing more in you. I could have accelerated my growth in responsibilities and position if I displayed more enthusiasm for the product and business.

Five years later, here I am working in that same business domain and a different technical one.

I once kicked off a project composed of just one engineer and the users of a narrowly-scoped service. We set the goal to be, “make the most impactful improvements possible within five weeks.”

The developer onboarded to the problem space as and when needed. The users and developer prioritized ruthlessly. They met ad-hoc every couple days to review the latest iteration and reprioritize. They shipped and shipped.

The entire problem space, solution space, priorities, and project plan lived in the brain of one person. There was little-to-no communication overhead, waiting, or blockers. It was an exceptionally productive and fulfilling project for everyone involved.

I once joined a team that needed its engineers to behave like product engineers. They didn’t.

The developers only met with their users when directed to, even though their users worked at desks a few meters away. The developer team waited for decisions to come from product managers and designers. The service they worked on was just a piece of a much larger product, about which they had little context. Decisions happened to them and they weren’t in control of their future. Their projects went off-track and got cancelled. They often built the wrong thing, and how could they know what the right thing was? They barely grasped the much larger puzzle they were a part of.

Of course, these circumstances came from mismanagement, blitz-scaling, and recent bad experiences - not the developers themselves, who were mostly new anyways.

The PM expressed that the developers were always invited to interact with users, but didn’t really participate. During onboarding, I did some user interviews to build context. Afterwards, I seeded FOMO by sharing how I interviewed our users, gaining key information and relationships necessary to make better technical decisions.

One month in, my first project on the team was set to begin bridging two products. Over and over, the team resisted a solution because we had a fear of imagined risks. We ended up going down the “low-risk” path that incurred tech debt - we spent six developer-months on a project and didn’t ship it. We scrapped the solution and we redid it properly later when everyone had sufficient context.