Monorepos and Product Engineering

The term Product Engineer seems to have emerged recently as the latest in-vogue term in the tech industry.

From what I can tell, it refers to a Software Engineer who understands business value and prioritizes work based on that value. Many people have been doing this for decades, but perhaps it’s a good sign that popular culture is now recognizing this as a valuable trait for Software Engineers.

Thinking in terms of business value is a good thing. It helps you make decisions that better align with the goals of the business. This, in turn, means achieving outcomes valuable to the business, which can lead to job security, lower stress, promotions, better compensation, and recognition.

Some people have an inherent ability to think in terms of business value, but that doesn’t mean you can’t learn it. It’s a skill that can be developed. I took courses in Business and Economics at school, and the skills I learned have been invaluable in my life so far. I would recommend everyone learn the basics of these topics.

In my career, I’ve seen many Software Engineers fall into the trap of spending significant time on solutions that are fun, interesting, or complex but provide little value to the business.

Providing value usually means enabling features in application code to reach production, where they can serve customers as quickly as possible. Of course, there are other requirements, like maintainability, scalability, and security, but the primary goal (in most cases) is to get features into production.

Spending excessive time (and therefore money) on solutions that are far removed from application code and don’t enable features to reach production is usually a bad idea. SaaS, IaaS, and PaaS solutions — provided they meet requirements — are extremely useful in freeing up time to work on higher-value tasks.

Unless there’s a strong business requirement, don’t run your own Jenkins server; use GitHub Actions.

If you just need a simple container in the cloud, use ECS/Fargate or App Runner; don’t run your own Kubernetes cluster.

If you need a simple event bus, use EventBridge; don’t run your own Kafka cluster.

As your business grows, requirements will change, code will need to be refactored, and applications will need to scale. Eventually, there may be a case for running your own Kubernetes or Kafka cluster, but only when the business needs justify it.

This brings me to the topic of monorepos.

Monorepos are somewhat trendy at the moment because companies like Google and Facebook use them. A monorepo is when you have all your code in a single repository.

Conversely, a polyrepo is when you have multiple repositories.

In theory, both have their pros and cons. However, I urge small to medium-sized companies to avoid monorepos. They can be complex, require additional tooling to be effective, and demand a significant amount of effort that is far removed from value-centric work. Platforms like GitHub are poorly suited to monorepos by default.

Of course, in less business-centric roles, delivering features to production quickly may not be the primary goal, and there may be different requirements. If you’re NASA, you likely care more about correctness than speed of delivery. Nevertheless, you can still apply the same principle of thinking in terms of value to the wider organization.