BrainDB: an Abstraction of the Manager’s Brain Into Databases
Managing one developer is not the same as managing a handful of developers, and it is certainly very different than managing a dozen.
At each step of our evolution as managers, we are required to acquire new sets of tools, in order to process, store, fetch and optimize the way we handle and consume information around us. Similarly, when solving complex engineering problems, various sets of database combinations are needed in order to provide optimal solutions.
In the next two-part series, I’ll show the correlation between the manager’s brain and its database-like abstraction — promoting a crossover between these worlds that could well help you scale up your managerial skills.
- Part 1: Your Journey Begins With a Database
- Part 2: When Things Break — Scaling up Your Managerial Memory
Part 1: Your Journey Begins With a Database
Let’s start with a common scenario. It is almost 10 am, and your daily management meeting is about to take place. Your group lead, product lead & peer team leads will soon join the short informative zoom call — focusing on who does what, when and why. But how can you remember everything that your team does? The tasks, their status, the progress, the hardships?
What if we abstract the “managerial task” into an Engineering Project? And the “manager memory” into a Database? In that sense, a project needs a database (DB) to store and fetch pieces of data, to be used during execution and to make smart decisions in a changing environment. Kinda like you as a manager.
Imagine that the knowledge of your team’s tasks is stored in a database, much similar to any engineering project’s database that you and your team have probably used in the past. Can we make the equivalent, abstract your “brain database” (BrainDB) into the engineering database, and learn from it as we scale up as managers?
The Basics
In order to deep dive into that abstraction, let’s simplify our managerial meeting, as if there was only one question to discuss — What are your team’s tasks for this week? When answering this question, you might want to consider the following:
Do you have an answer? How fast will you respond?
In the DB world, the ability to fetch a required object can be referred to as Availability, and the fetching speed can be referred to as Latency. Both can be derived from how your data is stored (e.g. key\value or relational storage), where it is stored (in-memory or on remote disk) and for how long the data is accessible. By using our knowledge of improving DBs availability & latency, we can improve our managerial decision-making and memory-fetching speed.
What will your certainty level be? Will your answer be correct?
The capability of answering with certainty, and correctly, in the DB world, can be referred to as Consistency. This can be derived from all of the above, as well as for how long the data is accessible, is it still valid and is it actually the correct data (inconsistent data state). The engineering skills you have obtained for keeping physical storage consistency may well assist your managerial decisions’ correctness.
Managing a Small Group of People
As a manager, when you start small, life is much easier. You can easily organize your tasks, and quickly prepare for any meeting or question on your team’s backlog. The main reason is that you probably don’t have many tasks and items to remember. When being asked about your team’s weekly workload, you answer immediately with full certainty. Now imagine those brain neurons having to make just a small jump to an accessible storage where everything is there for your needs.
The equivalent, in the engineering world, is a project with a small dataset . You can easily model your project’s DB as an in-memory DB. As the data is quite limited, you do not need to worry about disk space. Furthermore, you can enjoy very fast access capabilities, while not worrying about fetch errors.
In management, your brain is the perfect in-memory DB. 99.9% of the time you are right, fast and concise. But still there are lessons from the DB world that can be utilized. In-memory DBs can break, e.g. when a machine is being restarted. In that event, your DB reboots clean, losing all of its data. For humans (most of the time, happily), there is no reboot\restart, but you do have blackouts sometimes. In both worlds, it is wise to have some backup storage, e.g. memos, notes, todo lists, and many more.
Eventually, Complexity Knocks
Sooner or later, the amount of stuff you need to remember, the amount of employees you manage and the number of projects you own — will get bigger. At that point, things get complex.
- At any given time, our brain can only store limited data in fast-access mode. Have you ever had that feeling of “holy cow, I knew that and I just couldn’t remember!”?
- You can’t always immediately answer everything. Have you ever had the notion of “mmm… Alice is working on… one sec… it was the new API of… the banners project”?
- And you can’t always be 100% sure of your answer (and at that point you add the two magical words at the end of the sentence — “…, I think”).
https://dilbert.com/strip/2008-04-10
When you scale up, you can no longer have everything stored in your memory and you have to store your data elsewhere.
With DBs, the strategy is quite simple — you can create a remote DB. Remote DBs can act as a repository, with much larger storage capabilities. The more storage you have — the more items you can create, fetch and access. As you scale up, more data needs to be stored — and you can store it in the remote DB, instead of your immediate in-memory one. However, remote DBs create a whole new set of problems:
- Your data access latency is gravely affected, as you now need to have an I/O operation for any memory-related task. To improve latency, you can select a fast DB. You can also create a cache on top of it, to get some in-memory boost for important items.
- As data is accumulated, it takes more time to fetch. Indexing is one way for you to optimize DB performance, by minimizing the number of disk accesses required when a query is processed. Indexing is supported by many DB types.
- A remote DB will also require costly maintenance, so you need to monitor your expenses, and potentially transition to a different DB over time.
In management, just like in DBs, the strategy is quite simple. It’s time to use a remote tool for storing projects, tasks, thoughts and items. And just like DBs, they come with a set of problems to be solved.
Task Management tools (like JIRA or Monday) are great to offload data from your immediate memory. When used wisely, you can quickly access your team’s tasks, allocations and projects. Your BrainDB no longer needs to remember in detail everything about every project. However, just like in DBs, we’ve added complexity: your ability to reply quickly is now dependent on how fast you access your tool. Let’s utilize DB concepts to optimize your tool’s usage: before meetings — go to your JIRA board (or equivalent) and “upload” current tasks to your memory. This will allow you to save storage, while staying quick and concise.
Storage services (like Google Drive or iCloud) can act as a great repository to store protocols and playbooks. You’ll no longer need to instantly remember how to onboard a new developer, or the list of resources you need for deploying a testing environment. You only need to remember how to fetch the stored data (and access it fast enough). Indexing concepts can help here — set clear and unique paths to your files, name them wisely and consistently.
What’s Next?
Even though you’ve found your go-to tools for managing your data, remember that managing teams is never constant. Your team will change over time — in size, in mix of developers, in product demands.
As change occurs, new challenges arise for your BrainDB. You may need to respond faster, or store more data. Your optimization may no longer fit the demand for scale, nor your own expectations.
And sometimes… sometimes your managerial journey may lead you to the unexpected territory of an enormous hyper growth process. A process where your BrainDB is pushed to the limits — where new tools & strategies are required. Part 2 of this article will address this (not so rare anymore) edge case.
