We hear about scalability all the time: Zillions of data, billions of hits on a website, millions of tweets, etc. With everything around us scaling to never seen before, the limiting element in all this is organization. Can we apply the knowledge of scaling software to scaling an organization? 1. Avoid Synchronization points One of the most common interaction points in the organization is the “meeting”. Meetings suggest people get together to meet each other at the same time. In software architecture, we call this a “synchronization” point. A synchronization point invariably means that some components wait for others which slows progress. Meetings also lead to resource contention: people’s time. Scheduling a meeting involves planning and blocking time which subsequently makes it even more difficult to find a slot. In software design, we call this poor resource usage. Does this mean we shun meetings? No. We need meetings for brainstorming, solution findings, planning, etc. You can avoid meeting when it is calling people to ask questions, reading slides that could be achieved by asynchronous communications like Email, chat. Use meeting judiciously when you need to maximize interaction. 2. Use Asynchronous Mode — Email, Chat In the corporate world, E-mail is hated just like meetings. It has one big advantage: it is asynchronous. You can process your e-mail when you have time. Getting a response may take slightly longer. One of the ways to overcome the limitations of e-mail is to integrate chat with mail. Chat turns the conversation into a semi-synchronous mode: it still allows the receiver to answer at convenience. The other effective way to conduct asynchronous communication without e-mail is to use chat products like , and . Slack Teams 3. Build Cache for Communication Much of team communication consists of answering the same set of questions again and again. E.g. When we receive repeated requests for simple information, such as an “on boarding” new member. We simply search for the information in the internal portal. We ask the portal, not another person. Search on portal succeeds because the answer is available. Loading on boarding information in the portal is like adding a cache in the system. Take time to explain commonly requested information in a short document, post in the forum. This lets 100s of people to search, read what you share. 100s of 1:1 meeting to explain the same would take a significant part of your work time. 4. Self-Service saves time Remember walking to Starbucks, McDonald’s, local food joints. They do not have waiter services. Why? Self-service scales. Food outlets have adopted self-service because delivery is fast. Similarly requesting service at work does not scale by making a phone call or e-mailing a person. To scale build a self-service portal that services commonly used functions (like ordering software, tools, policy queries) so that users can have faster response, save time. Conclusion Software engineers have implemented tons of things to scale systems, services that we use in our digital world. To make this work, engineers avoid synchronization points, partition data, switch to asynchronous communication, use caching strategies to fasten response. We can benefit from these learning, apply the knowledge to scale an organization. Does this mean we shun personal interaction, turn into a faceless self-service, e-mail, chat workflows? Not really. We need to maximize personal interactions for valuable things like brainstorming, negotiation, solution finding, personal bonding.
