My favorite part of being an architect is the responsibility to think big: big problems, big solutions, big improvements for the organization. So it can be frustrating, even discouraging, when I prepare a big presentation about a big idea for a big audience… and get a tiny reaction. What's wrong with the idea? What's wrong with the audience? Most likely, nothing!
But if this happens to you, you might need to think more about your audience's headspace. Let me explain the concept of mental bandwidth, show you how it affects your big ideas, and suggest what to do about it.
[ Learn how to explain orchestration in plain English. ]
The concept of mental bandwidth
You've probably heard the phrase mental bandwidth, and this is how I think about it: Imagine a box that represents the finite amount of things you can think about or deal with at any given moment. Humans are notoriously bad at multitasking, so this box is pretty small in the grand scheme of things.
Everybody has limited mental bandwidth: You, your family, restaurant workers, taxi drivers, and yes, your co-workers. The amount of mental bandwidth a person has isn't correlated with how smart they are, when they started working, or what kind of job they're in—we're all human, and we all have the same limits.
Above, the box is empty. It's all whitespace, ready to be occupied. How do you use that mental bandwidth? You can (1) focus on tasks that require immediate attention, (2) use the leftover whitespace to daydream about the future, or (3) ignore everything else as noise.
How mental bandwidth affects big ideas
As architects, we're expected to be visionaries, and as such, our jobs are designed to allow for more daydreaming. With our sizable whitespace, we can afford to think up big ideas, understand how nebulous concepts are related to each other, appreciate nuances, and ultimately translate all of that into an expected outcome for "the business."
However, many of the stakeholders you work with—whether they are business leaders, engineering managers, or developers—are what I call practitioners. Practitioners predominantly focus on tasks that require immediate attention. That could be things like building new services, ensuring stability, responding to pager alerts, developing metrics, or myriad other things critical to keeping the lights on.
Here is the rub: When you put visionaries and practitioners in the same room, the varying levels of whitespace can create a disconnect. Specifically, your big idea doesn't fit into their available mental bandwidth, and it ultimately becomes noise. (As a reminder, this is not about intelligence; it's about which ideas folks prioritize based on what's expected of their role.)
What can you do if you need to convince the practitioner of your big idea to get it executed, but they don't have the whitespace right now to internalize it? One option would be to reduce the vision to the whitespace available, but that's pretty disappointing for us as architects (we love big ideas, remember?). Alternatively, you can address the root of the problem by freeing up more whitespace for your practitioners.
What to do about it
To free up whitespace, you'll probably need to take a break from your big idea. First, focus on the issues that require immediate attention, and work on solving those with the infrastructure you already have in place. Is it taking too much manual intervention to provision new servers? Maybe there are improvements you can make to the workflow using the tools you already have, like Satellite or Ansible. Are you responding reactively to outage complaints from your users? Take a look at what alerting options your monitoring suite has to become more proactive.
[ To make better decisions in complex situations, download 4 styles of decision-making: A leader’s guide. ]
This work may not feel groundbreaking to you, but it will free up some whitespace for the practitioners who care about these issues. That'll be important when you want to start conveying your big idea. In addition to that, it will earn you a lot of credibility because it shows that you can listen to the issues at hand and contribute to them directly, instead of just talking about your next big idea.
Next, now that you've got more whitespace and credibility, ensure your vision is incrementally relevant. That means determining how to achieve your vision in smaller chunks and articulating how those small chunks deliver value in the short and intermediate term. After all, practitioners mainly focus on the short and intermediate term because of the priorities of their jobs. You don't have to sell the entire vision, just the chunks that make sense right now.
For example, if you're excited about the role Kubernetes might play in your organization, start by introducing containers with Podman for a few targeted use cases that solve immediate pain points. Packaging up in-house and off-the-shelf applications in containers can yield many benefits for practitioners: dependency isolation, versioning, and consistent interfaces, to name a few. With this approach, you're still addressing issues requiring immediate attention while also introducing core skillsets (and mindsets!) needed to have a conversation about Kubernetes later.
Finally, repeat these steps to convey your full vision. Because you continue to open up whitespace and propose relevant increments, the big idea you came up with initially will no longer seem like a bridge too far. Instead, it's a natural progression of where the team is currently.
It worked for me; now it's your turn
The steps above—opening up whitespace, delivering relevant increments, and repeating—worked for me in some very change-averse organizations. If you find that your big ideas aren't landing with the stakeholders you work with, I encourage you to try this approach and see if starting small resonates better. Your big idea could be a game-changer for your team. Stick with it, but respect the mental bandwidth of those around you.
关于作者
Evan Stoner is a Senior Solution Architect at CrowdStrike focused on integrating its leading security platform with Red Hat’s enterprise open source solutions. Together, Red Hat and CrowdStrike provide a stable and secure foundation for the hybrid cloud: on-premises, in the cloud, or at the edge. Evan has previously held roles as a solution architect for aerospace and defense at Red Hat, platform engineering lead at a defense contractor, and cybersecurity researcher in academia. He has worked at the intersection of security and open source his entire career.
