Working with Product, not Working for Product

John Cutler once again succinctly puts words on a general feeling that I’ve had on the state of the tech industry. In one of his latest weekly articles on The Beautiful Mess, he talks about three different team models for building tech products:

  • The first is focused on sprints, stories, or backlog. This model believes that designers should mostly design and engineers should mostly write code. Only well-defined, and for the most part, safe bets get put in front of engineers, whose job ends up being building the right thing right.
  • The second is a team and mission-centric model. In this model, the team collaborates on nebulous things and finds its way forward together. This includes the product manager, product designer, and engineers, all together.; This requires flexibility from engineers given that the team’s pace is a constant ebb and flow, requiring a well-rounded skillset that doesn’t just include working on implementation.
  • Lastly, there is the engineer-centric, often with rockstar product managers. I’m sure you’re aware of the usual last but certainly not least, well in this case it certainly is the least. This is typically how big tech likes to work. The biggest focus is to free up as much uninterrupted time as possible, engineers deliver the work and keeping them in meetings away from precious coding time is all but a waste of time. Both product managers and product designers form fully-specced out features that are being sold to engineering teams for implementation.

For most of my career, I have worked on teams with one of the first two models. From the model where engineers were mostly writing code, but now and then put their product hat on and provide feedback on areas they think need improvement or the future direction of the product. But my best work has always been directly teaming up with both the product managers and the product designers. Not just collaborating from ground zero of an idea through to measuring the outcomes, but also actively shaping our strategic direction. We were regularly managing up and out, discussing and influencing across the organisation.

This industry has an unhealthy obsession with imitating big tech on a much smaller scale, so for me, the telltale signs of a company moving towards the engineering-centric model are when product managers start to work across different teams. Sometimes it’s evident that the roadmap and its creation become more centred around specific solutions rather than problems, often shutting out engineering from these discussions completely. Working directly with a dedicated product manager whose sole focus is the one team also increases trust and the feeling of being in the same boat, shaping the same future. Without that, it’s much harder to contribute to the strategic direction.

The more experienced an engineer is, the more I expect them to move from the what, to the how, to the why, and ultimately to a combination of them all. Writing software is easy, making sure you build the right thing at the right time however, that is a completely different story. The power and with it the responsibility to make the strategic decision needs to lie explicitly with one person, however, it is vital for that person to listen to a varied set of inputs to make an informed decision. These inputs need to include viewpoints from across the business, including engineering.

Engineers can significantly contribute to the best software products being created, not by working for Product, but by working together with Product.