The Most Important Role In Tech
They called him Average Al. Al Horford — beloved center/forward for the NBA’s Boston Celtics. Average Al. A cherished player. The guy who always does what’s best for the team. Average Al. Some people only care about accolades, but Al Horford cares about winning. Cares about his teammates. Doing the dirty work. The important stuff no one else wants to do. I worked with someone like Al Horford and his role is the most important role in tech.
Let me tell you about Dave.
Meeting Dave. And Getting Angry?
This story began in sunny Chandler, Arizona, where the forecast is always hot, hotter or face melting. As we always said, “It’s a dry heat.” Fortunately, we had good air conditioning at Intel’s Engineering Computing Help Desk. Too good, in fact. We often wore sweaters as we supported chip designers with Linux, Windows, Storage, CAD tools, and just about anything else that existed in technology. That’s when I met Dave, with his midwestern accent and quirky way of speaking uncannily reminiscent of my Uncle Normand.
You see, Dave came in as someone we were happy to hire. We weren’t excited. A bit more Linux experience would have been nice. Some scripting and programming might have increased our enthusiasm. He was a warm body with some experience and a great attitude. Little did we know that Dave would quickly become one of the most important people in our organization.
Like most help desks, we were responsible for managing accounts across a plethora of systems and services. It was easy work for new new hires and something Dave mastered quickly. Many would have left it at that, but Dave doesn’t just consider what is, he dreams of what could be. In his first week, he pulled me in front of a whiteboard and started drawing while asking questions. Why do we do it this way? Can’t this be automated? It was infuriating!
I hate people saying the way I do things can be improved. How dare this new guy suggest our processes might be anything less than perfect. It’s a character flaw, I know, but usually fades quickly. What Dave described made sense. So, obviously, I pretended that I’d been planning the same changes for a while now. Like I said. Character flaw. My obstinance aside, I realized that Dave soaks up information like a sponge and communicates new ideas well.
Dave had so many great stories about his time in the Navy. Relationships. Friendships. Working at a pharmacy as a kid — Or as I called it, drug mule for hospitals. I loved that each story he told had some hidden message. He’d never say it out load, but leave the listener to ponder. We became friends right away. My partner on the help desk. We spent countless hours in front of white boards solving todays and tomorrow’s problems.
Sidebar: How many of you immediately thought about this scene at the mention of a plethora?
KTBR Is Not a Four Letter Word
Dave came to Intel when IT was actively trying to be “worse, but cheaper.” This meant we would only provide resources to projects with high-dollar impact. Making people more efficient was not a priority. Security was an afterthought. Not a fun time to be in IT. While all the money was spent on high-visibility programs with dubious claims of increasing revenue, keeping the business running (KTBR) fell on individuals who cared enough to act.
If you’ve never heard the acronym KTBR, just know that it means the grunt work required for a business to stay afloat. It’s the accounts. The servers. Ensuring stable, secure environments. All things that would bring the company to a halt if not done, but are considered so typical that leaders don’t consider it important. Dave cares about KTBR and isn’t afraid of the dirty work.
The funny thing about KTBR, is no one wants to own any part of it. KTBR items end up aggregated into other services, but not called out explicitly. They run on and on with little thought or care and slowly degrade over time. A natural byproduct of corporate politics. Eventually, they degrade so much that leadership steps in with some new, innovative program that makes a certain KTBR item “Job #1.” Usually with some statement about, how this was always job #1, “Just like I’ve always said.”
Dave is a bit of a contrarian. You tell him KTBR is not worth his time, he’ll tell you it’s the most important thing. He believes that a house can be no better than the quality of its foundation. So while the rest of us looked for high-visibility projects to get the accolades, he pulled out his inner Al Horford and did the dirty work. He learned. Reached out across orgs. Automated. Improved security, efficiency and reliability for the engineers we supported. This work was under-appreciated for a long time. Until it wasn’t….
After all the whiteboard sessions and hours upon hours improving our account management, Dave was finally recognized. All of a sudden, account security was important to the company. Who would have guessed? By that time, Dave was already leading the effort. We didn’t need a new program, because he’d already unofficially created it. You see, Dave doesn’t wait for management, he acts as soon as he sees a need. Of course a new program was created, because attention seekers need to get credit for the work of others. But I digress again.
The Importance of Other
All this talk about KTBR and accounts. You’d think that’s the definition we are drawing towards. It’s not. The examples earlier in this story demonstrate behaviors and attributes needed for the role. Think of it as describing the type of person who could fill the role well. What is the role? What is is called? We’ll get to that soon. First, let’s talk about white boards and problems.
For most of my time working with Dave, I never saw his name on any ownership documents. All the glamorous work had owners. Everyone wanted to be listed as the owner of new technology. Open source? We were doing exciting stuff automating thousands of open source tools. That had an owner. Processes that reported to senior management? You bet. Everything with high visibility had an owner. Over time, Dave took accountability for everything that was not listed in our services. Everything that didn’t have an owner.
During one of our frequent talks, Dave brought up his role on the team. He couldn’t define it. He was someone who was continually improving our environment. Doing the grunt work. Fixing things management didn’t even know were broken. Critical stuff, but tough to describe in yearly reviews. He could not define his role. So, as usual, we grabbed a room with a white board.
First a we diagrammed our technical environment and listed owners of various services. Then we drew boxes for the work Dave did. Those boxes often fell in between services. Integration layers. Security processes. Random servers needed to make things work. These boxes were intermingled with everything else. Eureka! We’ve found it. I took my marker and drew an ugly, squiggly shape around all his boxes, then wrote, “Other — Dave.” Dave owned other.
Everything that was not specifically listed was Dave’s responsibility. No one told him to own this stuff. He just saw needs and filled them. You see, Dave looks for problems, then solves them. He doesn't need a project or a new program. He just needs a problem worth fixing. Like Al Horford, Dave was the glue guy. Or as I used to joke, “The glue that holds Intel together.”
What Is a Glue Guy/Gal?
We don’t generally think about glue until our cheap, box-store furniture starts falling apart. The glue holds everything together. Every successful team I’ve been on had someone filling this role behind the scenes. You know that person who monitors nightly processes? That’s the glue person. The one who makes sure all projects fit together seamlessly? Glue. That coworker who reviews PRs and recommends improvements? That’s gluing. You get the gist. The glue person keeps everything running smoothly.
The glue person is the most important role in tech. It’s not the CEO, the rockstar or the unicorn. It’s the person who ensures everything runs smoothly. While the glue person rarely receives the accolades they deserve, they keep at it. Improving. Optimizing. Securing. Doing all the work no one else wants to do. So take a minute to recognize who that person is on your team. Let them know how much you appreciate it. If your team doesn’t have one, be the glue. Be like Dave.
Five signs you might know a glue person. (Read in the voice of Jeff Foxworthy)
- Knows KTBR is not a four letter word
- Focuses on high importance instead of high visibility
- Doesn’t immediately increase profit… until they prevent decreased profit due to operational failures
- Doesn’t get recognized… Until years of work culminate in huge efficiency gains
- Doesn’t seek credit… And that’s a damn shame
