So, let’s say you’re a technical admin, engineer, architect, whatever (most of you are). It’s probably safe to say that nearly all of you (I fit into this) have an occupation where our primary ongoing task is some combination of system or network administration, design, software and hardware engineering work, including build-out or troubleshooting, etc. Maybe it’s all of these. No matter what, it’s a safe assumption that a big, or maybe even number one reason we all get paid is because we’re really good at the technical work.

Take me for instance - I have worked in the VAR space for some time now, and although many things can change, one that doesn’t is that I’ll always be going into a customer site, gathering requirements, putting together a design, and probably implementing that design for them.

I’ve been on the customer side too - from that perspective, when you bring a consultant in, it’s usually either because you don’t have the time or ability to do a project. The main objective when signing that statement of work to bring in a VAR is to get a reasonable price, and some form of guarantee that the consultant is qualified to do the work.

Whether you’re doing technical work for your own company, or a company that’s paying to para-drop you in to help them out, our prime directive is and probably will always be to accomplish technical work. It only makes sense.

I was taught a lesson recently about how our role can be so much more than that. We’re always told that one of the biggest things that technical people can do to improve themselves is learn how to communicate well - the biggest cited use case, at least in my experience, is being able to communicate technical things to management. That’s pretty generic though - why exactly do we need to do that? More importantly, are there other, perhaps more important cases, where communication is needed?

Fred the Network Admin

Let’s go back to the technical engineer. We’ll assume for now that this is a network administrator at a medium-sized enterprise named Fred. Fred is quite good at his job, in fact he’s done a great job of keeping the network up and running, and staying under budget when it comes to procurement. However, Fred still isn’t getting the raises he wants, despite his years of service at the company and great track record of doing his job.

Fred nearly missed a great opportunity to open a constant dialogue between himself and his entire company regarding the infrastructure. Starting the next week, Fred started to hold weekly brain-share sessions with the entire technical staff, even those from other IT silos (let’s say the storage team). During these sessions, he clued everyone in on what he’s been doing, and what his plans are for the network. They may not get every detail, but they’ve heard enough to start asking some questions, and learning in the process. The following sessions, they take control and start telling Fred about what they’ve been doing in storage, and how the two teams might work together to get things done more quickly and efficiently. This is a cultural shift, started by one person’s willingness to share. Before long, Fred decides to hold a quarterly engineering meeting where he explains to management what his vision for the network is over the long-term. Before long, Fred starts seeing those raises come in.

It’s a common saying that “IT folks are doing their job when no one notices them”. I don’t like this saying very much, but I get it. While the objective of keeping everything running so that the business isn’t impacted is paramount, I don’t believe that means IT operates in stealth mode all the time. By taking charge, and forcing others to notice him for the positive, not just the negative, Fred is now seen as something far greater than just the maintainer of the network.

Bob the Consultant

Let’s talk about someone that works for a VAR, as many of you do. Bob has fifty CCIE certifications to his name, and really knows his stuff. His job is to go to customer sites, and perform work stated on a design or statement of work that was agreed upon by the customer prior to his involvement. Could Bob simply show up, say hello, and perform the work? Sure - that’s his job! I don’t even mean that he ignores the customer - Bob’s very polite and even talks with the customer about “those Red Sox” while he’s hacking away at the keyboard.

By doing the above, Bob will continue to collect paychecks. In fact, (and this is where VARs are a little different), Bob will even see regular increases in pay, as he acquires additional certifications, since that’s one of the biggest ways VARs place a value on their engineers.

What more is there to do? For one thing, Bob goes from customer to customer, sometimes as frequently as one per week, and does this work. Taking the time to say “Hey, by the way, here’s something cool I was looking at during my studies” or “Did you know that there’s a few other things you can do with this design?” are not specifically stated within the scope, so Bob doesn’t do it. Quite frankly, educating the customer on how that new piece of equipment works is generally NEVER within the scope of an implementation project - 9 times out of 10, the VAR will recommend that the customer attends formalized training prior to that engineer’s arrival. So why would Bob even begin to go down this rabbit hole?

In between projects, Bob decides that he can automate a large majority of the next few projects on his plate. He puts together a few scripts and realizes that he saved himself a day of extra work. When he shows up for the next project, he tells the customer about this, and offers to spend a day doing nothing but white-boarding concepts and answering questions. He even shows the customer this script and tells them that there’s a whole slew of things you can do with it. The customer continues to ask questions during the week, and Bob takes the time to make sure the customer really understands what they’re getting from him, so that the day he leaves, they can hit the ground running with it.

None of the above was in-scope, and Bob didn’t spend so much time doing it that he couldn’t get the actual project work done, the stuff he was actually on the hook for. The next week, he gets an email from his boss telling him that the customer just ordered a few million dollars worth  of gear for a project that Bob’s company wasn’t even aware of. That customer realized that if they were going to get any consulting services from anyone, it was going to be from the company who sent a guy that cared enough to spend the time with them, making sure they had everything they needed to make their project a success.

Conclusion

I realize that on paper, much of this is a “yeah, duh!” I’m not assuming that most don’t do what Fred and Bob learned to do in the end. I do know, however, that it takes a lot of effort to keep this behavior at the forefront. At the end of a long day upgrading routers, the last thing anyone wants to do is go talk to management about it. It’s also quite easy to get annoyed when customers have a lot of questions about a topic.

It’s difficult to see the value in being a teacher when your job is to do the work. You may even think that you’re not technical enough to be a teacher, assuming for some reason that only the experts in a topic should be teaching about it. Respectfully, I chuckle a little bit at this notion, because I blog for the exact opposite reason. Do you think I blog about topics because I feel that I’m an expert in them? On the contrary, most of the time when I’m writing about a technical topic, speaking as if I have any kind of authority on the matter, it’s because I knew nothing about that topic a week ago. Forcing myself to put words on a screen for the world to see is one of the most effective motivating tools for me to go learn about a topic, to the degree where I think I can probably convey enough about it to be mostly right. In the process, I’ve learned something new, and on top of that, I’ve hopefully taught someone else.

In my day job, this mindset helps me feel more confident, makes my customers feel like they’re getting their money’s worth, the sales folks see that they’re getting some additional love from the customer, and I get to do more of what I love to do. When done consistently, this mindset shows it’s value again, and again.

By the way, this topic is a tenet in my theory on the Unified Engineer. As a result of the hunger for knowledge, a Unified Engineer will also seek to spread the knowledge elsewhere, paying it forward so that the entire industry can benefit.