Understanding Brain Capture

This blog quickly looks at a phenomenon I noticed a while back, and referred to briefly in a recent blog. I call it “Brain Capture.”

My hope is that by being aware of Brain Capture, you can decide how you want or need to handle it. Be intentional about your consumption of tech details and how you spend your time. Or: technology documentation and knowledge is an ocean (or several), and you cannot possibly consume it all.

Which is good life advice anyway. It took me a while to learn to focus on what MY goal is first, BEFORE investing time. WIIFM, “What’s In It For Me” is a somewhat related theme. Knowing your objective also helps reduce unnecessary effort that fails to contribute to the end goal.

For example, the goal should not be “finish reading all these slides,” but more “learn what’s new with Cisco switches,” or studying for a certification or learning what you need for a current project (and is your goal deep knowledge of that topic, or just enough to get the project done, with some awareness of the things you didn’t deep dive on that weren’t relevant to the project?).

Maybe that’s obvious. I find it all too easy to get sucked into reading blogs, watching videos, etc. and have learned to skim for awareness. I also try to limit the time I spend on that. That conserves time for in-depth dives as needed. Also, for having a life!

(Admittedly, trying to focus and cap my time reading social media is still a Work In Progress.)

What Is Brain Capture?

Yes, I’m a blogger, trying for an attention-getting title. I admit it!

Blogs compete for eyeballs (eyeball capture). And for some of your time.

My claim is that vendors also compete for your eyeballs and brains. Well, really, your time. Probably unintentionally. In effect, they “capture your brain,” your “mind-share.”

I’ve probably mentioned this once or twice in prior blogs, but this is a whole blog dedicated to the topic!

Explanation by example: many years ago, I was coding, wrote something with GUI interface for early Windows, then ported it to the Mac. Along the way, it became clear that both platforms were evolving rapidly, including adding refinements to code interfaces, system calls, and new features. And the amount of reading to skim and stay current was massive. Let alone retaining all the new info one didn’t immediately need.

The conclusion I came up with at the time was that one could likely only be deeply expert on one computing platform, Mac or Windows (or Unix, but that wasn’t an immediate need at that moment in time). Or pick and choose and try to cope with the flood of information by filtering on a need-to-know basis. Since my interest was mainly GUI coding supporting a program, I didn’t need to know much about many other topics.

More recently (the last few years) I felt the same way, just trying to wrap my brain around what Amazon offers, for example. There’s an amazing number of service offerings there!

I recently tried to assemble a “cheat sheet” spreadsheet to help me sort out which of similar AWS services to use for what, significant caveats, strengths, or limitations with links to the detailed references.

The intent was to post it online as a resource, sort of a focused entry point to AWS for others. I’d hoped to do similarly for Azure and then put together a feature by features comparison. I ended up giving up, it was just taking too long. And that’s not even considering that in some cases, testing would be needed to firm up details.

One thing I learned from attempting that AWS cheat sheet is that each AWS offering has its own set of quirks and caveats (works with A but not B, etc., max of N per region, etc.). Trying to fit even the major caveats into the summary got ridiculously messy! You can’t necessarily ignore them either.

Part of the problem there was probably that my goal was too broad. Yet I found myself unable to trim it back, because part of the goal was interaction between features. I ended up trying to summarize a subset of the features, and even that proved unwieldy.

You do have to do things that affect your interests or the matter at hand. Having an overly narrow perspective in networking is a recipe for failure! But so is too broad a perspective!

Training as Competition

If you carry this line of thought further, documentation and training might act as a form of competition by consuming time and attention. That’s a bit cynical, perhaps. But if you’re working towards, e.g., a CCIE in something, do you have spare time for much of anything else technical? You do remember what your wife (husband) and kids look like?

A kinder perspective is that great documentation and training make one more likely to recommend and work with a company’s products. Less time wasted futzing around trying to get something working!

How Does This Affect Networking?

What brought this blog on was a recent Cisco Partner Virtual Team event. Five full days of talks covering new features, improvements, new products etc. at a tech sales level. Great stuff and a vast amount of information. Switches, APs, both Cisco and Meraki, along with related products like Spaces.

First reaction: who has time from selling or consulting to sit through all that?

Second reaction: and who has the time that not only for Cisco/Meraki but perhaps for one or two competitors?

I suspect the answer is few.

My answer is that some can prioritize and do that. Others, like myself, need to download PDF slides and/or recordings and digest them in their spare time. It’s more like skim for need-to-know items. Page after page of “micro-features” – I’m sure someone cares, but I’m not capable of remembering 20, 40, or 60 such per quarter per product line!

So, it’s great Cisco puts the info out there, and people can pick and choose topics of major interest / need for them.

On another front, I personally don’t do video if I can help it: it just consumes too much time. It’s much easier to fast-forward and skim in a slide deck!

My tentative conclusion overall is that one is wise to pick and choose, and probably best to specialize if possible. Pick some technical topics (one or two) and go deep! Add some more with medium or greater depth as time goes on. Which is what I’ve done over the years.

The market reality is that internal staff and some consultants can’t necessarily do that. Large organizations or consulting/tech services firms likely assign generalists to sites, and at suitable scale, may have a small number of switching or WiFi/AP specialists in house for example. Or the specialists may be deep in one or two areas and generalists on other topics.

Coping with Copious Info Flow

So the answer I’ve chosen in general is to skim updates and be aware of big things that affect design, deployment, doing things better, bugs, gotchas, etc.

It is fun reading about the latest new “micro-features” that make things better, but as far as impact, there may be TMI (Too Much Information) to sway a sale versus a competitor. Not to mention, if I don’t use a micro-feature, I’m unlikely to remember much more than its existence (if that much!) for very long.

What about Within a Company?

There’s an institutional side to this as well.

My analogy will be football teams. Since I’m not a huge sports fan, I’ll necessarily keep this brief so I don’t say something stupid! (Well, I can probably manage to do stupid anyway…)

Football teams have specialists. Linemen. Receivers. Etc.

And to whether you’re an organization trying to staff a network team, or a consulting firm, it helps to know the positions. And who is specializing in what? Data center design and switching, campus design and switching and WiFi, WAN/SD-WAN/SASE, etc. Firewalls, ID management, and other security tools. Network management tools. Etc.

In my experience, many of my consulting customers had ad hoc team assignments, i.e., who normally handles WiFi and who backs them up, etc. Within NetCraftsmen, we track skills (e.g., WiFi) and degree of expertise. Knowing who else has done similar work recently and picking their brain (“virtual experience”) is also helpful.

Documenting this can (1) help new hires or consultants and (2) establish responsibility, i.e., it is the responsibility of the lead and backup in a tech area to keep current on the subject, etc.

Conclusion

So like a lot of things in life, what’s your plan? How do you “divide and conquer” the knowledge your team needs? And how do you determine how deep is deep enough?

I don’t have ready answers for you.

I hope that being aware of the challenge of just TMI and limited time, and having a plan to deal with it, including what NOT to learn, can really be useful.

And apologies if this is something I’ve written (ranted?) about previously. I don’t have a great way to track that.

I just ran across the following on LinkedIn, and it seems appropriate: “Jack of all trades, master of none… but often times better than a master of one.”