🧭 Vertical vs Horizontal
Recently, I listened to Ilya's discussion with Stanford discussing OpenAI's corporate organisational structure, which, as per his statement, is unique to OpenAI and not replicated anywhere in the world (as far as I know).
Essentially, OpenAI is a "capped-profit company", transitioning to non-profit as soon as its obligations to investors and employees are satisfied. It's pretty interesting stuff. It is also evident that OpenAI has processes and models in place that prioritize AI-for-the-world over investor profits. Which is even more impressive.
Anyway, this discussion made me reflect on my experiences working for small businesses and large corporations (albeit the conversation is focused on fundraising and equity).
So, another thing I had been thinking about was the differences between horizontal and vertical organizational models, especially organizations that are heavily technology-oriented.
Anyway, I could talk about this forever, so let me break this out into some short bullet points below (non-exhaustive).
Vertical
Classic example is Google.
In general, a "big vertical" approach is very prescriptive, with large if not massive monorepos in place, underlying the larger core service offerings of the company.
The "big vertical" comes with a large surface area to explore and map the "big services" to a wide variety of business and operational usecases, pretty quickly. So, it comes with some "Agility".
What is more, the "big vertical", can be more consilodating, specially with regards to providing unique support to specific programming languages and technology stacks.
What is more, due to the tech consilodating benefits, such companies typically have more control, and are often the direct owners of pricing-usage models, and less dependent on external service-level engagements.
In Google's case, they have 100% Cloud share, being the owners and maintainers of their own tech stack. Whilst others, not so lucky, make do with service-level agreements but still obtain full control or a certain level of maintainability.
Due to the large surface area, managers, including engineering executives, do not always set strategy top-down.
The core engineers, who contribute to maintaining the monorepos, are also able to set the strategy. Naturally, this creates a strong sense of ownership and a strong sense of software reliability engineering (SRE).
Big Vertical benefits:
- Identify performance/security hog sooner rather than later (it's more noticeable)
- Fix the library and you will reap the benefits everywhere/anywhere
- Easy to conduct company-wide IT tech stack consolidation
- Strong sense of ownership + post-maintenance reliability engineering
- In theory, easier to setup statistically sound benchmarks
Big Vertical negatives:
- Can leave less room for experimentation
- One major vulnerability can produce a significant impact radius (high risk/reward)
- Services written in two or three tech stacks or programming languages only
- Requires highly-experienced talent for continuous maintenance/big rewrites
Horizontal
Classic example is Uber or even Facebook (now Meta).
More tailored towards the squads/pods approach, usually adopted by large (200,000++ employees) companies and organisations. Also becoming very popular across large consultancy firms as well.
Typically, hundreds of product teams maintain their own "micro-sandbox" or "product playgrounds" with IT infrastructure tiers matched to product types and or service-level/value-based pricing.
Follows a funnelled product lifecycle approach.
As you can imagine, it's great for scaling and expanding quickly, so ideal for some SaaS/PaaS, but actually, if not managed correctly, becomes really, really bad for accounting, as well as lots of legal as and security hurdles.
Decision making on tech stack is usually conducted by micro-service team which enables teams to feel more empowered, until some company wide service-level agreement with a big vendor, like Microsoft or AWS is announced.
Sometimes, you will often hear Horizontal approaches/operating models being discussed and explored within "platform engineering" circles/books as well. Many of the problems associated with the "Big Horizonal" approach are being abstracted and tinkered with throughout wider "platform engineering" discourse and discussion.
Big Horizontal benefits:
- Tech autonomy is available because the stack is often dictated by leads/teams/engineers
- More room for sandboxed/playground experimentation/innovation
- Tech consolidation can happen, but often requires some company-wide vendor partnership or cost-structures
- Emphasises DevOps culture for cross-team support/setup
Big Horizontal negatives:
- Work with 100+ teams to integrate change into 100 repos/places 😱
- Challenging to setup statistically sound benchmarks
- Challenging to hire/diversify teams due to the cross-tech stack nature
- Can lead towards intra-competition/gamification of squads/pods
- Maintenance or anything post-demo/MVP often gets zero attention
Bottom Line
Typically, there are +/- to each approach. Within organisations, different cultures permeate and cultivate overtime. Different pain-points will occur regardless of approach.
For example, it is likely that some software engineers will leave an organization if they aren't allowed to make technology decisions, while those who remain will be unlikely (due to the operational model's system) to point out known technical issues. The trick is to find some common middle ground between approaches, of course, this is easier said than done.