Shipping the org chart
How organizational structures shape the work of engineering teams
The other day, I was discussing our team strategy for next year. The company is making a big bet on a particular product, which falls under the responsibility of a different org within engineering. I pointed out that it’s challenging for my team to support this priority because we sit in a separate org, and there’s already a dedicated data team in that area. In the past, our attempts to collaborate with them were met with resistance, so I suggested revisiting the engagement model and setting clearer boundaries.
The response I got was that org structures and engagement models should not dictate our priorities, only business needs should.
I was puzzled by this, to say the least. This completely overlooked the reality of how organizational structures shape the way individuals and teams behave and operate. I have countless examples showing how organizational elements, such as org boundaries, objective functions, and incentives, often dictate technical outcomes.
Team alignment with the organization’s objective function
Every organizational unit has a key set of metrics or objectives that its leadership is held accountable for. If you’re a data team supporting internal stakeholders and your primary stakeholders belong to a different organizational unit, it can be hard for your leadership to fully appreciate the impact of your work. They may not see a direct benefit to the specific metrics they are responsible for. It doesn’t matter if your stakeholders are happy and value your work. They sit in a different org and wear a different team’s jersey.
The result? Your work is questioned ("Why are you doing this?") and lacks support, leading to lower internal visibility and interest. This is especially evident when it comes to funding (your team will likely be one of the last in the queue, especially in tough times when budget is tight).
In the past, I reported into an internal platform organization, but my main stakeholders were in the Revenue org. All my projects were focused on driving revenue metrics such as conversion rates and marketing leads, while my own organizational leadership was primarily measured on infrastructure reliability metrics. Because my team was serving external stakeholders, it was hard for my immediate leadership to fully appreciate the broader impact my team was making, because I wasn’t directly moving the right needle.
Org charts determining the product roadmap
A company is both a cooperative and competitive game. The ultimate goal is to drive overall business performance, but different orgs compete for credit to recognize their contributions.
One of the most common pitfalls in the industry, and a symptom of poor executive leadership, is when the product roadmap is determined not by customer needs, but by how the company is structured in different organizations.
A perfect example from my career was when Customer Success wanted to expand its charter beyond support tickets. They were responsible for the product surface where users could open support tickets. The classic IT support functionality, important for sure, but let’s be honest, not very exciting.
At some point, they started adding unrelated features targeted at the admin persona on the customer side, such as tracking the number of licenses and active users. This put them in direct competition with another product surface, the admin control center, creating confusion for customers. They noticed the duplication long before our Chief Product Officer did. This went unchecked for almost an entire year (not a great look). An egregious example of “shipping the org chart” where multiple orgs targeted customers in a siloed and incoherent way.
Internal processes and the stated organizational philosophy
Org leaders often publicly state a set of principles and values they want to promote. However, these values cannot be in conflict with internal operational processes. For example, if an org claims to prioritize empowerment and delegation, it cannot simultaneously have a micromanagement approach to project tracking and progress reporting.
One of my org leaders once published a post about the value of "doing less to do more." The idea was that by pooling more people onto fewer projects, we could achieve more: working faster, reducing silos, and fostering widespread knowledge. Doing less also requires more intentional and ruthless prioritization, bringing strategic clarity.
The message was solid and agreeable, but it was at odds with the existing promotion criteria, which still rewarded individual achievements in hero mode. Even without falling into extreme anti-patterns like promotion-driven development, promotions still depended on being a visible, single-handed problem solver rather than a collaborative contributor. Engineers were incentivized to take on “big solo” projects, delivering major features end-to-end.
I still remember presenting a promo packet where someone on the review committee went through all the issues and PRs and questioned the candidate’s true contribution because they saw multiple people involved. The promotion was ultimately approved, but that comment was indicative of the lens that was applied.
Conflicts between incentive structures and company priorities
When I was supporting the Revenue org, the company was going all-in on a product that was only the third-largest by revenue but represented the future direction for all other products. However, incentivizing the sales team to prioritize that product was complicated due to its different business model and subscription plan. The sales organization was still rewarded more for selling another product, a more established offering (the second-largest by revenue, and the most premium SKU).
Even though the company had set a new strategic priority, the sales department’s compensation structure wasn’t updated to reflect that shift. As a result, my team was tasked with driving revenue in alignment with the company’s strategic direction, but our sales counterparts only wanted data products that supported the product better aligned with their comp structure. Of course, the sales department won, at least in the short term, because that was the only way to ship something valuable and actually get it used.
I strongly believe that organizational elements have an outsized impact on technical outcomes. As an engineering leader, ensuring that all the organizational pieces are aligned before starting any technical work is crucial. This is not always easy, but it’s critical to making a meaningful impact and ensuring that your contributions are valued along the way.
Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews