---
# Stop Polishing the Cathedral

**URL:** https://crunchtools.com/stop-polishing-the-cathedral/
Date: 2026-02-24
Author: fatherlinux
Post Type: post
Summary: In large enterprise software companies like Red Hat, two organizations build the product: the Business Unit (BU) and the Engineering org. The BU owns business strategy, market positioning, pricing, and customer relationships. Engineering writes the code and ships the bits. These aren’t adversaries. They’re two halves of the same machine. Steven Sinofsky, who ran MicrosoftContinue Reading "Stop Polishing the Cathedral" →
Categories: Articles
Tags: Best Practices, Product Management, Red Hat
Featured Image: https://crunchtools.com/wp-content/uploads/2026/02/stop-polishing-the-cathedral-thumbnail.png
---

In large enterprise software companies like Red Hat, two organizations build the product: the Business Unit (BU) and the Engineering org. The BU owns business strategy, market positioning, pricing, and customer relationships. Engineering writes the code and ships the bits. These aren’t adversaries. They’re two halves of the same machine.

[Steven Sinofsky](https://learn.microsoft.com/en-us/archive/blogs/techtalk/the-path-to-gm-some-thoughts-on-becoming-a-general-manager), who ran Microsoft Office and Windows, described six core functions in any software organization: Engineering, Program Management, Product Marketing, Sales, Support, and Quality Engineering. His point was that these functions need each other. When they operate in silos, you get bad decisions. When one group makes commitments without the others, everyone loses. The only way forward is cross-functional collaboration.

The same dynamic plays out between BUs and Engineering orgs. And the failure mode is almost always the same: someone waits too long to share their work.

Humans have a deep urge to wait until something is perfect before they show it to anyone. Ideas, code, business problems, feature proposals. We want to polish the cathedral before we open the doors. It feels responsible. It’s a trap.

At Red Hat, Product Managers live in the BU and tackle customer problems. Product Owners live in Engineering and prioritize the backlog. These roles depend on each other, but they sit in different organizations with different reporting chains. That’s where friction creeps in.

This week, a Product Owner told me he was frustrated. Things felt like they were “coming down from on high.” Requirements arriving fully formed, decisions already made, no room to shape the outcome. Then he said something that stuck with me. He mentioned the way my colleague Ben Breard and I operate. We bring people along. We collaborate. We share early.

That’s the whole secret. Bring a half-baked market problem to Engineering and let them help shape the solution. Share the rough draft of the business case before it’s “ready.” The instinct to wait robs people of agency. Nobody wants to implement someone else’s fully-formed plan. Everyone wants to help build something.

Insecurity drives the urge to wait. We worry that sharing something unfinished makes us look like we don’t know what we’re doing. But the opposite is true. Sharing early signals confidence. It says: I trust you enough to show you the scaffolding. I want your fingerprints on this.

Red Hat lives its values and collaborates well. But every company has seams between organizations, and those seams are where the “coming down from on high” feeling grows. The fix is simple. Release early. Release often. Not just code. Ideas. Problems. Plans. Give people a reason to fight alongside you instead of wondering what just landed on their desk.

---

## Categories

- Articles

---

## Navigation

- [Home](https://crunchtools.com/)
- [Articles](https://crunchtools.com/category/articles/)
- [Events](https://crunchtools.com/category/events/)
- [News](https://crunchtools.com/category/news/)
- [Presentations](https://crunchtools.com/category/presentations/)
- [Software](https://crunchtools.com/software/)
- [Beaver Backup](https://crunchtools.com/software/beaver-backup/)
- [Check BGP Neighbors](https://crunchtools.com/software/check-bgp-neighbors-nagios/)
- [Chev](https://crunchtools.com/software/chev-check-vulnerabilities-script/)
- [Graph BGP Neighbors](https://crunchtools.com/software/grpah-bgp-neighbors/)
- [Graph MySQL Stats](https://crunchtools.com/software/graph-mysql-stats/)
- [Graph Sockets Pipes Files](https://crunchtools.com/software/graph-sockets-pipes-files/)
- [MCP Servers](https://crunchtools.com/software/mcp-servers/)
- [Petit](https://crunchtools.com/software/petit/)
- [Racecar](https://crunchtools.com/software/racecar/)
- [Shiva](https://crunchtools.com/software/shiva/)
- [About](https://crunchtools.com/about/)
- [Home](https://crunchtools.com)

## Tags

- Best Practices
- Product Management
- Red Hat