Made with Humane Club
Spark seamless collaboration between product and engineering
When complexity is unintentionally introduced to the company’s organizational structure, it leads to a confusing hierarchy and a reward system that will cause talented individuals to leave the organization, as it hinders their work effectiveness and thus their ability to learn and grow.
What makes for a good structure
It also falls under the mandate of The Product Organization to work closely with HR to declutter the structure.
Below are some thoughts on what makes for a good structure:
Organizations should be structured for clarity so that each team understands the activities of other teams, and any overlap is minimized. This will lead to increased collaboration and decreased competition among leaders.
Discouraging general management
We live in a disruptive and ever-changing age. To stay ahead and innovate, organizations need deep functional leaders with the judgement to identify which bets or trends are likely to succeed.
Such leaders understand, debug, and fix work done by three levels down in the hierarchy. Experts report to other senior experts, which builds teams that consolidate expertise and gives the organization a competitive edge.
In contrast, an organization structure that promotes General Management struggles in the long-term. Smart value-creators (functional experts) are led by General Managers, who are either not interested or not skilled in the nuances of the trade. GMs may guide the value-creators incorrectly or withdraw from execution after giving high-level directives. This leads to smart value-creators not receiving enough recognition, growth, and respect for becoming better at their respective trades. Eventually, the organization fills up with generalists who lack the information asymmetry to make bets.
The truth is, it is easier to train management to a smart value-creator than to teach expertise to a general manager.
Guard against principle-agent problem
General managers are more susceptible to the principal-agent problem because they often view the number of people who report to them as an indicator of status, power, and job security. As a result, they become possessive and protective of the people who report to them, creating work for them to justify and maintain their proprietary over resources. In contrast, the principal would have reallocated resources to projects that would have the highest outcomes.
To address this, product managers should specialize in a specific project or product. Engineers, on the other hand, should be maintained in a common pool that gets deployed to whatever project or product that will generate the highest outcome at any given time.
Don’t mitigate accidental complexity by throwing bodies at it
The bottom three categories are a result of general management and accidental complexity, leading to an inflated head count in the organization. It is better to address the root causes than to simply add more personnel.
Bucketing the product organization
With these principles in place, let’s look at what could be a good organization structure for a news product. We’ll split it into three units:
This team of Product Managers and Product Analytics is responsible for staying on top of the business health, growth hacking with the operations team to reach this year’s AOP targets using existing capability, and defining new capabilities required with the platform team.
Individual Product Managers are assigned ownership of products, similar to how products are organized in the Com Score dashboard. This links each product manager’s outcomes to how clients (advertisers) perceive the value of products.
The business team does not have technology or design talent allocated to it, but instead accesses the pool allocated to Engineering and Operations.
Product Serving Product
A big media company will have many different media properties that vary based on type of content covered and/or audience targeted. However, most of these media products are built up of the same building blocks.
Hence, it makes sense to consolidate design, product, and engineering these into specializations.
The supply-side team focuses on content creation, storage, and delivery:
- Content Management System (CMS): This team builds the CMS for editors to file content. Their focus is on making content filing, image/video archiving, and tagging simpler. They work closely with the templates team to ensure editorial templates and products are properly integrated.
- Content stories via the CMS is made available to the front-end via API Services.
- Templates: This team works in close collaboration with the CMS team to design and create optimized, reusable, SEO-optimized templates – Articles, LiveBlogs, Photo Galleries, Web Stories, events, microsites, webinars, etc. – with programmatic ads for editorial and branded/sponsored use on both browsers and apps. Additionally, they handle integration with distribution platforms such as Google AMP and Facebook Instant Articles.
- Editorial Products: This team works closely with the Editorial team to handle content and template diversity use-cases. They need to build expertise to scrape, clean, analyze data, and create reusable, SEO-optimized content with programmatic ads for use cases such as cricket scorecards, automated charts, elections, weather, and cryptocurrency. They also use data science and GenerativeAI to generate pre-content for editorial.
The demand-side team focuses on distributing effectively:
- Audience engagement: Homepage, emails, newsletters, push notifications, personalization
- Experience services: Single Sign On, Loyalty, Comments, Gamification, Subscription.
- Data: Data pipelines, data warehousing, analytics, insight discovery
Engineering
Different ways of defining functions within an engineering organization exist. At its simplest, engineers can be grouped by the same software language, regardless of the product they work in. This consolidates expertise, such as best practices, components, tools, libraries, and know-how, into one division, even if it is used across multiple products.
Each team has an Engineering Lead and at least one Product Owner to manage the backlog, helping to create a weekly, bi-weekly, or six-week cadence for execution. Finally, around 10% of the bandwidth can be spent on planning for future sprints and prototyping.
It is important to be aware that the engineering organization consists of different types of engineers: 5% Computer Scientists, 15-20% Framework Builders or Architects, and the rest Application Engineers.
< to be continued >