When Things Break: Scaling Up Your BrainDB
Engineering management in hyper-scale environments is never easy. As companies, groups, and teams grow, managers have to adapt, evolve, and change their handling of managerial data.
This article is the second part of the BrainDB: An Abstraction of the Manager’s Brain Into Databases article series, where I draw the correlation between the manager’s brain and its database-like abstraction. In this part, we will learn how managers can use the concepts of BrainDB, and apply them to the hyper-scale team size growth scenario.
Part 1 Recap
In my previous article, I described some go-to tools for managing your data as your team grows, using an analogy to databases. I’ve shown how we use our brain as an in-memory DB in small teams, leveraging local cache and fast access capabilities for being quick and concise in fetching and updating managerial data.
I’ve also discussed that upon scaling up, complexity knocks. Tools, just like external DBs, provide us with a more efficient way to manage, locate, and fetch our managerial knowledge — thus assisting us in reaching a quicker and more efficient decision-making process.
However, team size and challenges are never constant. Your team will change over time — in size, developers’ count and seniority, and product demands. As changes occur, new challenges arise for your BrainDB. You may need to respond faster or store more data, and your optimization might no longer fit the demand for scale, or even your own expectations.
On the Verge of Explosion
Scaling up as a manager sometimes takes you to the extreme. Imagine, for example, that you have 10+ developers, 20+ projects to manage, infrastructure overhaul to navigate, and way too many meetings to attend. Your fine-tuned methods for fetching, storing, and processing data simply do not live up to your ever-growing scale anymore.
You now can’t keep track of projects, employees’ status, tasks, and deliveries as everything gets mixed up. You are overwhelmed with data that you don’t have time to store. You are constantly occupied with storing new data and removing old data, thus losing existing information in the everlasting battle for storage.
In the database world, scaling up also introduces pains and challenges. With high CPU rates and extensive memory consumption, failures begin to appear. Your 100% consistency record is degraded by duplications, fetch errors, damaged records, and timeouts. Your operations’ latency jumps and your application begins to falter.
A Cobweb of Databases
In the previous article, I demonstrated how the usage of a remote database optimizes your daily work. For example:
- Using a Kanban board, you can quickly access data (i.e., achieve low latency) when getting the tasks of one of your team members.
- Using a project management tool, like a JIRA Board, allows you to get a quick project status overview.
With databases, scaling up can be adding more remote DBs, like a cluster of multiple instances — sometimes even located in different geographical regions. Managerial data storage can utilize similar principles, by sharing your knowledge between several interconnected tools. In databases, you make a transactional query to fetch complex data from several databases. Following up on the comparison to managerial data, you can now make intelligent queries to several tools, thus reducing the number of queries and external tools in usage.
The fun part is selecting what suits your BrainDB best — just as is the case when choosing the right DB for a specific engineering task. Combining DBs to optimize our data flow is even more enjoyable. For each type of data, you can use an optimized storage type, with the combination of databases creating an ecosystem of knowledge. Instead of settling for one or several distinct remote databases, you can now develop interactions between these databases, optimize your storage techniques, enrich data, and simultaneously fetch data from multiple databases.
Let’s look at an example. In the previous article, I showcased Google Drive and JIRA as tools for storing your managerial data. Keeping consistency across both tools might be problematic, for example, if you have a change that you need to reflect on both. The transactional approach of databases can assist here, as you can integrate your tools using an Integration Platform as a Service (iPaaS) system. With systems like Integromat or Automate.io, you can create data integration rules that constantly update your external tools while saving you precious time. As your team grows, this helps you reduce clutter and complexity in your daily routines.
A word of caution here is required. When we add tools (or DBs), we also increase the risk of having consistency issues and duplications. It is never easy to scale up, and an explosion of DBs means more maintenance, higher costs, data consistency issues, and other such issues.
Beyond One’s BrainDB
Another approach for handling the hyper-scale scenario is a further abstraction. If we can abstract our managerial brains into BrainDB, why not follow this path and abstract your employees’ brains into their BrainDB as well?
The breakthrough realization: your peers, employees, and colleagues have their own BrainDBs. All come with the complexity, storage techniques, and external tools described earlier. Therefore, you as a manager no longer need to store this data in your BrainDB. It is stored elsewhere!
Let’s look at a few of the benefits:
- You are freeing up a considerable amount of space in your BrainDB.
- You are reducing clutter.
- Complexity is removed!
Let’s look at an example. You are interested in what Maya, your Senior Developer, is doing. Instead of remembering it, you can do an HTTP GET request, as if you are querying a database:
In her reply, Maya responds with the requested data. To highlight the similarities in the service-to-service API call, we can even abstract her response to a JSON format:
With this technique, you can now get the information you need. You can quickly learn that Maya is working with Carl. You understand that the estimation for her work completion is 10 days. And most importantly, there is no need to remember this data by storing it in an immediate-term “locally-cached” memory, or any remote DB.
Creating APIs for your employees’ BrainDBs relies on:
- Setting a contract. Like a service-to-service API scheme, you must agree on your APIs. When doing so, you can both define how data will be queried.
- Asking the right questions. Using the correct query will result in the information you need.
- Mentoring. Guide your employees. Help them set up and optimize their BrainDB, by utilizing the expertise that you’ve collected while maintaining yours.
- Independence. Your employees should be entirely independent when selecting their BrainDB type and structure. If one likes JIRA and the other likes Google Drive, that’s ok. All you as a manager care about, in this case, is getting the right API call response.
Most of all, this helps promote ownership and accountability among your team members. Managing and maintaining BrainDBs are ways to practice and express ownership. Essentially, your employees are building their managerial characteristics. At the end of the line, you’re promoting growth within your team, and laying the foundations for new organizational opportunities going forward.
Next Steps
When it comes to software, we always try to estimate when DBs break down or when our infrastructure can no longer tackle the growing scale. In your management universe, it’s always best to be ready in advance for these types of changes.
This means that you might want to map and assess the risks, tasks, projects, and data transfer around you. You can try new tools, see if you like them, and then optimize your work. You can even try combining them — and checking to see if they reduce workload and improve efficiency.
Whatever you do, always make sure you’re fully prepared for your next BrainDB upscale.
