Building Tech Organisations- The Secret Sauce

Building Tech Organisations is not that much different from “Selling Old Wine in New Bottle”; newer the label/organisation-name easier to sell to a wide variety of potential customers/engineers. This analogy not taking away any of leadership qualities away from the top brass of people experts in the industry, the fundamentals and example speak for itself. Having worked in the IT industry for nearly a decade, the beginning of every fiscal year is like waiting on a Roulette Table ; if the dice falls on your number/your teams don’t change you breathe a sigh of relief before the next throw of dice/beginning of the fiscal year. No-one wins all hands on a Roulette Table or even a Blackjack Table, so expecting from a team reorg is asking for too much.
The rules of Roulette are simple, so here with an attempt to simplify the complex annual perennial version of Tech Reorganisation. In principle, any team of engineers can be classified into two broad categories depending on the end customers of their tech solutions-
Platform Teams
Building Generic Solution/Toolsets for N number of scrums teams to use, Platform Teams are enablers for Offering Roles to multiply productivity without having the need to write thousand lines of code. Some examples — Identity, Security, Cloud Enablement etc. The key to build visionary platforms is to have a significant bandwidth allotted for Research in Emerging Technologies while serving the current needs of customers, maybe that’s what would have inspired Facebook to open-sourcing React to the world.
Offering Teams
Front-ending business needs, this team subset is focused on building solutions to serve an actual end user experience. The key mission behind fast-paced Offerings Roles is to improve Customer Experiences, improve Customer Retention and increase Product Engagement. Most often the technology behind these features is limited to solve a point of time problem with a backlog item to fix the Tech Debt in the future. Some examples of Offering Teams are Mobile App Teams, E-Commerce Cart Checkout Teams etc.

The Organisation Conundrum
With the above demarcation between building for future vs current needs, the constant conundrum for leadership is the aggregation of these roles within different boundaries- Same Scrum Team, Different Scrum Teams in the Same Org, Different Scrum in Different Orgs. Also, given the dynamic nature of evolving Platform and Offerings needs to be balanced, is there a secret sauce to getting this organisation and reorganisation meaningful? One way to throw light on this problem would be adaptability of a solution by Tenants spread across Single/Multiple Business Domains.
Single Tenants/Domain Dependent
Tech Solutions which only cater to functional requirements of a single tenant use-case within a Business Domain form the Base Unit of Offering Teams. Common pieces of these offerings such as authentication, security, deployment etc are either catered by an existing platform team or grow into the next step of Evolution Pyramid depending on the fulfilment of horizontal Non-Functional needs of Performance, Reliability, Scalability etc.
Intra Domain Tenants
Tech Solutions which address similar concerns across multiple tenants within a single Business Domain often act as building blocks for Orchestration into bigger platforms. Some examples of these are logging, auditing, deployment pipelines etc often built to improve Intra Domain Productivity by using reusable libraries across the teams within the same organisation. Often Engineer Organizations across have Dev-Ops/Automation Teams to build for their localised needs.
Inter Domain Tenants
As solutions from the above categories are generalised across Domain and Tenants to scalable Functional and Non-Functional needs, they blend to form centralised Platform Tools. Some examples are a Cloud Native Solution, Mobile and Web Containers to host UI widgets etc. These tools come up with pre-configured integration with libraries and other elements of the Toolkit. Most often self-boarding is done through a bunch of generic configuration files in the form of yaml, json etc.
With an understanding on the above classification of various evolutionary stages of a Tech Org beginning from the Original Unit of One to Solving for Platform Scale, it becomes inevitable for leadership at growing organisations to make changes to juggling between present and future needs. Given its inevitability, one thing large MNCs should often stay away from is lack of continuity from the previous leadership which eventually falls out on the orphaned employee through the fulcrum of the transition. Continuity along with an alignment towards the company’s vision often addressed through effective communication is the hallmark for long term team success in tech organisations.
For feedback, please drop a message to amit[dot]894[at]gmail[dot]com or reach out to any of the links at https://about.me/amit_raj.