Engineers and Career Growth: How To Capitalize On Your Success

The following is adapted from the book Replace Yourself: The Tech Geek’s Guide to Navigating Leadership by Rob La Gesse.

People don’t like my ideas. At least, not at first.

When I moved into the communications and PR division of Rackspace, I wanted to build a social media presence that differed from most, if not all, other public companies. Most of them were run by marketing agencies, organizations designed to push content on customers. Instead, I wanted to have a conversation with our customers, particularly when they engaged our social accounts to complain about a problem.

With a marketing team in charge, the response to a customer issue was always the same: “Please contact our support team at blah blah blah.”

As you can imagine, that response left customers even more upset than they were when they decided to comment on our social media pages. Chances were they’d already contacted customer support and gotten nowhere.

I needed a team that could be more proactive. More hands on. People who had the credentials to log in to the support systems and directly address the customers’ needs; who had the tools, the knowledge, and the internal contacts to get shit done.

I needed engineers.

Engineers Don’t Do Customer Support

Like I said, people don’t always like my ideas. The people who ran the customer support side of the company were no different. Some thought I was usurping their control, streamlining the process, or worse yet, they feared I was creating a new support channel, one that bypassed their ticketing system by sending customers straight to our social media account. My team and I were seen as butting in where we didn’t belong.

The problem with all of that was simple: it worked.

We didn’t undermine or cannibalize our support teams. We created an escalation path instead of a replacement path. If a customer utilized social media to lodge a complaint without a ticket number, we rerouted them to the proper support channel, where they would follow the normal process. Because my team of engineers had the skillset to address a large number of complaints directly, we could access the information from that ticket number and immediately address the next steps and solve the issue.

Our customer satisfaction rates increased considerably as a result. If a customer had an issue and an unresolved ticket number at eight o’clock at night with eight hours gone and no resolution, our team didn’t have to redirect them.

In doing so, we earned a reputation for using social media as a customer service vehicle. We were one of the first large companies ever to do so, and people took notice. I did a number of talks at both marketing and customer support conventions about our methodology. Large companies like USAA and AT&T called on our team to work with theirs on how to use social media for customer satisfaction and not just for marketing.

But… Engineers?

Yes, engineers. Look, I get it. If you’re in an industry where you work with engineers, developers, or anyone in the technical professions, I’d venture those individuals are the last people who come to your mind when it comes to customer support. In fact, I’d go so far as to say that you don’t imagine there’s much else they would do besides code and develop software — isolated in a cubicle, earbuds in, closed off from the rest of the world.

If you can’t see them in marketing or support, you certainly don’t guess they’d be a fit for leadership. In fact, they themselves might not guess it either.

You’d both guess wrong.

I know because I made that transition, and I’m going to tell you how.

First, understand that while I transcended my role as an engineer and software developer into the management realms of marketing and PR, I don’t claim to be an expert in either. In fact, for the purposes of this book, I don’t need to be. What is important is that I was extremely successful in both worlds and that I learned an immense amount from being immersed in those two very disparate settings. This allowed me to become something crucial for you.

An interpreter.

The Geek’s Dilemma

As a tech geek, one who is especially good at your job, chances are you don’t yet have the inner (or outer) voice that gives you the confidence to move above your current station. You don’t feel you have the ability or the tools to best communicate with other departments like sales and marketing.

You’re probably right.

It’s through no fault of your own. It’s due in large part to the way we think about engineers in this day and age: we think of the guy or gal in a dark room coding all day, solitary, headphones on all the time. Nobody wanting to interrupt them because everyone is saying that what they are doing is critically important.

Much of this perception of what you do and who you are stems from the ways you’ve been trained and the ways in which your skills are utilized. The problem with that is you condition yourself to believe these things about yourself that everyone else does. That’s fine until someone from management comes into your dark little room, turns on the lights, puts a name tag on your door, and tells you that you’ve been moved into management.

It’s terrifying for so many reasons. You feel a ton of pressure when you’re offered a promotion. You think, Shit, they want to promote me and if I don’t take it, I’m not going to be seen as a team player. What if I don’t take it, and one of my coworkers becomes my boss? If I reject the offer, does this mean I’ll never get another raise? You’re also faced with the idea of no longer being a daily contributor to the technical aspects of your job, the thing you were trained to do best.

Those ideas, though? They’re in your head. Internally placed. None of those worries are actually true unless you make them so.

Understand that if you’re a good developer or engineer, your company knows this, and they still think that a better place for you is in leadership, managing other developers. They are taking a known quantity out of a productive position because they are hoping to invest in you to expand and spread your knowledge, grow your contribution, and increase the overall productivity of the company by promoting you.

I’ve personally witnessed the need for engineers to become leaders quickly and watched their high rate of failure. I’ve watched companies lose a strong developer and gain a weak leader. I wanted to write a book that leverages my experience, mistakes, and successes in a language that technical professionals will understand.

I did. You’re reading it now.

You Can Do This

There are not many engineers writing new code these days. More often than not, when you’re writing code and you don’t know how to do something, you’ll do a Google search to find a snip of the code, adjust it for your needs, and use it. You learn to create and write code from those examples.

In this book, I’ll give you examples from my own personal experience with this journey to tell you how you’ll learn to go from the person who makes the widget to the person who decides to order more widgets. You won’t use them all. You’ll take snips from this one experience, pieces from another one, and come out better prepared for a move into management on the other side faster than you thought possible.

Most developers work on projects they have to deliver this week, next week, or in a month. Management means looking at the long game and knowing how to “see around corners” to anticipate problems before they occur. Based on real-life encounters and experiences, you’ll learn what it takes to go from a development mindset to a management one.

Perhaps most important of all, you’ll learn how to prevent the washout cycle. Too many times in my career, I’ve seen good developers who had the potential to be great managers fail once promoted and return to their original position, or worse, leave the company or get fired. It happened because they had no one who spoke their language to prepare them for what was to come.

I speak your language. I understand how the engineering mind works. Trust me to guide you along the path so you only have to do this once. There will be no restarts. This book will explain the journey in a manner that resonates with your technical mindset and will prepare you for a career of continued success.

This Is No Diet Book

Know that there are no recipes contained within. Nowhere will I tell you to prepare your food in exactly this manner, eat exactly on this schedule every month, and you’ll end up with washboard abs.

There is no formula for success for you to follow, no playbook that tells you how to get it all right because, quite simply, everyone is different. Each person reading this book will take something different from the experiences I share. Some chapters might not even apply to you, and that’s okay. Just like taking those snips of code to create a new set of code, use the stories and lessons provided here to assist you where you feel you need it the most.

This is also not a guide about how to get promoted. The truth is, if you’re reading this, you should already be on that path.

This is a book about how to deal with getting promoted and how to be successful once it occurs. It is a source of reference — a series of situational examples on which you can look back when you encounter similar challenges to mine. It’s about how to reframe your thinking such that you retain the ability to maintain contact with your community of developers and engineers but also become cognizant of the larger realities of the company that you’re now being paid to address.

You’re not just being paid to deliver a widget anymore. You’re getting paid to figure out what new widget is coming out next year or how many the company will need to supply the demand. That’s a different type and level of thinking, one you’re not used to and one of which you think you’re not capable.

You’re wrong, and I’ll show you how.

You Will Fuck Up

If I had to read a book by some guy telling me about all the wonderful things he’d done over a storied career where he’d made absolutely no mistakes — well, I wouldn’t put myself in a situation where I had to read that book because I would not read that book.

The truth is that people, especially high achievers, are afraid to share their failures — that is, if they’ll admit they’ve had them at all.

You are going to fail in your journey. It’s how you frame those failures — seeing them as opportunities for improvement — that will determine how you let those failures affect your trajectory. It’s not enough, however, for me to just tell you that it’s okay for you to fail and to embrace it.

Instead of beginning this path with some epic success, let’s take a look at how I fucked up royally, and how it was one of the best things I could have done.

***

To keep reading, pick up your copy of Replace Yourself: The Tech Geek’s Guide to Navigating Leadership by Amazon.