Technology and product go hand in hand for the most part. Most organisations map these two teams together to some extent, even if they are not entirely under the same proverbial roof. 

From the outside, product teams decide what to build and technology teams build it. But that is overly simplistic. Technology teams are responsible for architecting a stable yet agile organisation.

Product teams “build, measure, learn,” and product managers may work without the context of a larger tech stack. These differing points of view can lead to contention: Product wants to move quickly, technology wants to architect properly — so the end result is a slower build of external products or stacking up internal tech debt. 

Some organisations balance this by having a decision-maker who is able to make the trade-offs at a senior level. One executive once told me that it was essential otherwise any disagreements would need to be decided by the CEO — and that is not their role. 

Examples of a wide remit include the INMA Product and Tech Advisory Council’s John Kundert, chief product and technology officer (CPTO) at the Financial Times, and Julian Delany, chief technology officer/data and digital at News Corp Australia. While Julian’s title doesn’t specifically say product, it includes product in the remit.

One media company had a hybrid for a period, where the software development team sat with product, and architecture and PaaS remained separate. But when checking in for this blog post, they told me that they have moved everything under product. Not because it didn’t work per se, more because of a senior departure made an umbrella organisation make more sense. 

Other people I have spoken to have said that the roles need to be separate as they have different objectives and it is good to have a colleague to counterbalance. Also don’t forget that “tech” may also include internal systems (IT help desk) and areas such as cyber security. Keeping a company safe, up, and running will take priority over product development. 

Ultimately, some of the decision comes down to size. A larger organisation can support/justify more hierarchy. Smaller organisations have to be more nimble with the resources they have. 

It’s also worth noting here that the question of team organisation gets harder when discussing groups with multiple titles. Centralisation of resources, particularly around product and technology, makes a lot of sense. Why would you have multiple teams building similar things? 

Ultimately, this leads to slower overall development and a bloated tech stack that needs upkeep. However, centralising everything means losing some of the nuances of local brands. This is an area that I will dig into in more detail soon. 

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .