Clarifying Questions

• Has the engineering headcount growth been organic, through the acquisitions, or both?
• Are all four acquired companies still running on their own separate technology stacks, or has any integration work been completed?
• Is the concern purely about absolute cost levels, or also about output -- meaning is the engineering organization seen as slow or underproductive relative to peers?

Framework

Bucket 1: Cost Structure

‍Objective: Understand where engineering spend is actually going, since a cost that has grown disproportionately to revenue could reflect headcount growth, compensation inflation, tooling costs, or a combination.

• Headcount and Compensation: total engineering headcount growth vs. revenue growth, average fully loaded cost per engineer, and whether offshore or onshore mix has shifted
• Tooling and Infrastructure: cloud hosting costs, software licenses, and development tooling spend as revenue has scaled
• Capitalized vs. Expensed R&D: how the accounting treatment of development costs has shifted, which can make reported costs look higher without reflecting true cash spend changes

Bucket 2: Organizational Efficiency

‍Objective: Understand whether the engineering organization is structured and deployed in a way that maximizes output per dollar spent, since acquisitions frequently create duplication, misaligned incentives, and coordination overhead that inflate cost without adding value.

• Duplication: overlapping teams, redundant codebases, and parallel infrastructure across the four acquired entities
• Team Structure: ratio of productive engineering time vs. coordination, meetings, and context-switching across fragmented teams
• Prioritization: whether engineering capacity is being allocated to the highest-value work or spread thin across too many concurrent initiatives

Bucket 3: Product Portfolio Complexity

‍Objective: Understand whether the number of products being maintained and developed has grown beyond what the organization can efficiently support, since each acquisition likely added its own product roadmap, integration requirements, and technical debt.

• Technical Debt: accumulated shortcuts and legacy code across acquired codebases that require ongoing maintenance cost
• Product Sprawl: number of distinct products and features being actively maintained vs. revenue or customer value generated per product
• Integration Costs: engineering time and cost devoted to integrating acquired products vs. building new customer-facing functionality