Career advice for engineers: Step away from the keyboard

7 tips for how to be a successful engineer.
168 readers like this.

Over the course of my career, I've had two to three major mindset shifts in how I approach my work. At first, I just focused on engineering—trying to know the most about whatever language or libraries I was using, being very "trivia" focused, and ultimately ignoring the concerns of others in an effort to just write good code. This wasn't to say I didn't try to get along with my coworkers or help them out, but my efforts to improve were all about me; after all, the team and the company do better as I become better. And to be fair, this approach isn't totally unfounded in its merits. As engineers, we must constantly evolve, learn more, and improve because the industry is getting harder with bigger problems that need more technical solutions every day. This approach worked well enough for me for the first half of my career, where I was junior enough to have such selfish (albeit well-meaning) motivations.

Then I took a job where I worked with more engineers in one office than I had worked with in my entire career to date. This job nearly broke me. I went from being one of the better people in my role to barely scraping by… for nearly two years. I struggled to succeed, I constantly felt outclassed by the people around me, and many days I couldn't figure out why they even hired me (a feeling, it turns out, that some of my co-workers shared). But there was no big epiphany, no single defining moment that turned it around. Just a series of hard, abject failures from which I had two choices—give up or learn and grow. I did my best to do the latter. As I moved back to a smaller startup, I saw firsthand just how important it is to cement a culture, from the ground up, based around these lessons.

My final mindset shift happened when I transitioned into management after the startup was acquired by a larger company. I didn't choose to be a manager; management chose me, in that I was offered the position. I was also told that, while everyone really believed in me, the ultimate reason they chose me was that they felt it would be less tumultuous to promote someone from within than hiring someone from outside. We had a very aggressive timeframe after the acquisition, and my new company didn't want to risk things by bringing in an outside leader who didn't have the team's trust. I found that this phase reinforced everything I had learned before about being effective in an engineering role—and turned up the dial on how hard I need to apply these lessons every minute of every day.

Taking it to Twitter

In May 2018, I tweeted about career development after a particularly meaningful and valuable conversation with a junior member of our extended team. This Twitter thread got more attention than I expected, and Matt Broberg asked me to write about it for Opensource.com. (Matt told me I'm not allowed to swear in this post, so please understand that his jurisdiction does not extend to my tweets.)

If you're just looking for the short version, here it is:

  • Focus on improving how you communicate with others, specifically the content, tone, and timeliness of how you communicate.

  • Make efforts to be a stronger collaborator—"engineer in the corner" is not a title you want

  • Understand what it means to be responsible for something and strive to hit your commitments. Leveling up in your career means broader responsibility and less direction with what to do with it.

  • Learn to fail, and learn from failure. You'll be doing a lot of it, mostly little failures… but a few big ones too. Don't let it derail you; use it as a stepping stone to your next success.

  • "Problem-solving" is the single most important engineering skill you can have.

  • Never stop learning. If you stop learning, you stop growing. If you stop growing, you can't move onto bigger and better things.

  • Learn SQL; you'll thank me later

How to be a successful engineer

I posted this Tweet (and the thread that follows) after a support engineer asked me for advice about growing as a software engineer. I think he expected me to rattle off a list of technologies, tools, and programming languages that would help him get a job on an engineering team. Instead, I gave him a list of behaviors to focus on. My mentality is whatever job you take (especially at a junior level) will likely train you in the technologies you'll need to succeed. (This is true, at least, at any place that has a healthy relationship with how and who to hire.) But the things I mentioned were things no engineer was likely to explicitly work with him on because they're traditionally aligned with what we unfortunately call "soft skills."

I'll pause here for a moment and state that the phrase "soft skills" downplays the impact they play in being a well-rounded person, not to mention a successful member of a team. Try to avoid calling them that (I use it here because sadly, it's the term we all know). "Holistic skills" is probably a better term, but it's less catchy, and honestly I'm not here to sell you on flashy new terminology.

It's important to call out that these are not skills that you ever "achieve" or stop growing in (which I'd argue is true of most skills but especially in this context). Team dynamics are incredibly complex. As people, we're fickle. We have our good days and bad days, and we struggle and we break. Compounding that, we do so in ways that cannot be covered in a FAQ or automated in a script, unlike many of the systems we run. Our failure cases err on the infinite, and so our capacity to learn, to be resilient, and to recover needs to match. I've failed countless times and accept that I will fail again countless more. But so long as I'm always learning, I'm always growing. And I can confidently say that the people I've enjoyed working with the most over my career all rate highly on the following skills, primarily because they keep working at them.

It's also a good time to note that no one should expect you to be perfect at all, or any, of these skills all the time. Everyone has bad days. The point is to make it so the bad days are the outliers, so that when things do get a little too tough and you react in a way you know (upon reflection) was subpar, people don't assume that's your norm. These skills will help you build credit with your team that you can cash in during those moments in time when you don't bring your A game to the situation, for any number of reasons.

Communication is one of the most important parts of your life as an effective engineer. The idea that you can be the lone wolf in the corner, cranking out masterful code with no one else interfering with your craft, is not a realistic one for 99% of people who work in our industry—probably even more than that. While the romantic notion of being this effective on your own is quite the lure, the hook hidden within is that these individuals are often seen as a liability.

I thought I was a good communicator early in my career, but I learned that I was an over-communicator when it didn't matter and an under-communicator when it did. I struggled to find the right balance —when to get too technical (which I almost always went for) and when to just give the 50,000-foot overview—depending on the type of person I was talking to. I also hid when things weren't going well or weren't "ready to be seen"—I wouldn't ask for help until too late, I would iterate alone on designs until I felt they were ready, and I confused critique of the approach as critique of myself. It took me years to internalize the need to be open with my coworkers about my ideas, the state of my work, and the raw nature of my designs as early as possible.

I remember when I noticed I had improved here. I was working on a small but important project at work and instead of waiting for problems to build to the point of exploding, every day I told my manager about where the project was, what blockers I feared were on the horizon, and what that meant for the bottom line. You might think "Isn't that what standup is for?", but most of us just use standup to rattle off a list of things we did and what we might do. It's not for having conversations. But that's what I found had helped me more effective: conversation. We had casual-but-detailed conversations on the state of things, and took no longer than 10 minutes a morning as I was settling in for the day. There was never any confusion about where the project was, what the risks were, and whether I needed any external help. It taught me to communicate early and often, and that (in a healthy environment) I wasn't to be punished for not being perfect. On the contrary, I was rewarded with further autonomy because I demonstrated that I knew how to communicate effectively.

Try having conversations with your manager about the work you're doing. They'll thank you for it (in between running to their next meeting).

Communication is the cornerstone of collaboration, but buildings are not made from cornerstones alone. Effective collaboration is communication applied within a framework of getting things done as a group—sometimes that's a group of two, other times it's a group of 20. Sometimes collaborating is knowing when not to involve too many people, so you can focus on getting something to the point where it's tangible enough for feedback, and sometimes it's not starting on anything until you have enough feedback to know exactly what you should be building. In other words, it's a balancing act. But focusing on being an effective engineer means collaborating with others—sharing work, sharing ideas, giving good feedback, accepting feedback well, and above all else, mentoring (and eventually sponsoring) the people around you. You cannot collaborate well without communicating well, and vice-versa. They're inextricably tied together.

This requires you to learn to compromise, however, so that you can defend without being defensive. It's ok to back up your work or your proposals with your reasoning, but accept that others might have a different view or need from what you're doing, and that those opinions matter as well. Collaborating means having good, healthy, and sometimes difficult discussions about the state of your work. Learning to participate in them without being an attacker, and to walk away without feeling attacked, is one major aspect of collaborating effectively. This is where it takes the whole team working together to settle on a set of norms that make working together possible. Remember that everyone is here to do their best work, but not everyone has the same idea of what the best work is. Build trust from that starting point.

On the topic of mentors: many folks might make the mistake of thinking mentorship is always some kind of formal partnership between two people, but this isn't always the case. Whenever you work with others, you're passively (or, better yet, actively) teaching them things about yourself and what you can do, just as much as they're teaching you. Effective collaboration could be summed up with the famous adage "a rising tide lifts all ships." It's acknowledging that you're here to support others, just as you expect them to support you. Eventually, the time will come that you find yourself in a position to advocate and provide cover for those you've mentored (known as sponsorship) - but you'll never get there just trying to be the lone wolf who doesn't play well with others.

Another big lesson to learn is that collaboration does not occur solely at the engineering level; engineers often (and especially for important projects) need to collaborate across business concerns to get things done. Things you work on could impact the reporting pipeline that finance folks use to present numbers to business stakeholders, for example. High-priority task often have a lot of eyes on them due to their impact. Communicating and collaborating both upward and outward is increasingly important - especially as all of them will have a slightly different skew on the information they need from you. You might say, "well, that's what the manager is for, so the engineer can keep working," but this is ultimately incorrect.

One goal of effectively managing engineers is to make them accountable to the right stakeholders and watch them grow under that light. Hide them from it, and you stunt their growth. The balancing act for managers is knowing when engineers are in too many meetings and no longer getting enough time at the keyboard, but that's another talk for another time. Put the expectation on engineers to collaborate with stakeholders directly, and you help them grow their set of holistic skills. Try to block them from these conversations, and ultimately you're only reinforcing the idea that their only value is in the lines of code they write, and not in the solutions they build to solve customer problems.

Managers, encourage your engineers to collaborate and build relationships with folks across the business.

Managing responsibility is difficult because the more experience you get, the larger the scope of things you need to be responsible for with less direction on how to do it. In practice, this means acting responsibly is a context-sensitive endeavor, and often to handle more responsibility, you need to learn how to manage yourself so that you can handle more tasks, and perform them with more autonomy.

Let me provide two examples to clarify what I mean. At one point I found myself responsible for managing the queueing and background job infrastructure for our entire platform. This required me to be responsible to the other engineers who were relying on this infrastructure so that they didn't have to have actively worry about its health, provide clear and unambiguous advice on how to add new features or jobs to the system, and aiding in diagnosing issues with their integrations. I had to be responsible to engineers and teams over the entire company not only for existing state of the system, but to help them figure out how to grow their reliance upon it. Luckily for me at the time, I largely only needed to interface with other engineers and so the situation was manageable within the skills I had at that point.

Later, I was responsible for a large-scale migration of the platform's financial backbone. Because the gears that move money through the platform ultimately impact a lot of business concerns, suddenly I needed to interface with folks from the billing department, various product managers, and bosses of bosses, not to mention all the engineers whose code I might be touching. This required a level of coordination and collaboration that I had never been exposed to. It also meant I had to get better at talking with folks who weren't engineers, who largely didn't care about engineering concerns, who needed to know what was going to change in their job, and who just needed to know it was going to work. To them, the problem wasn't a technical one, it was a business one: We need this data, we need it accurately, and we need it on time. No amount of engineering-centric commiserating on the aging nature of the codebase was going to placate them. It took months of planning, testing, executing, meeting with folks I'd never heard of who suddenly had to place their trust in me, etc. I wrote more emails, participated in more meetings, and ultimately spent more time outside of my editor-of-choice than ever before in my career. Without question, it made a better engineer out of me. For the first time I actually had exposure to the real customers I was providing a solution for, got their input, made them aware of issues, and found compromises to problems or edge cases with them. It was amazing.

As engineers, when we take on bigger and more widely scoped projects, we need to embrace the full weight of this responsibility and not just hide in our code. By reaching out to other teams, both engineering and otherwise, I had a better understanding of who I was building and maintaining for, which helped me understand what priorities were genuine and which were just distractions to the greater goal. Managers cannot hide these opportunities from engineers, and engineers need to know when they're ready to embrace these opportunities.

This might be uncomfortable for many people to talk about because failure doesn't naturally occur equitably. Folks from certain demographics disproportionately face criticism and ultimately judgment over their performances, much more so than others. It's important for everyone to understand that fixing this issue begins with you. Don't punish your peers for trying and failing, just as you wouldn't want to be punished or judged. Celebrate failure as a way to learn. It's far too easy to fall into the trap of tearing people down, especially those who aren't "like us". Avoid this mentality at all costs. The success of others does not threaten your own success (in many ways, it helps it), and focusing your energy on building up those around you pays far greater returns.

Plan as if failure is a guarantee. I am not saying to set out to fail, but the lesson is to expect and embrace it as it happens.

And if you find yourself in a negative, "punishment" culture today: Change it. Change it right now. Leave more meaningful and collaborative feedback on pull requests (PRs). Ask yourself, "Am I judging this person directly, or am I providing actionable feedback about the code?" Learn the difference between, "This is something that definitely should change" and "This isn't how I would do it, but that doesn't mean it's wrong." To that end, you might work on a phrase you can use that codifies this feeling without directly saying it. For example, when someone asks me for feedback on something and it's not how I would do it, I make sure I understand their goals, explain how I'd approach it, and say, "but you should follow your heart." That way I'm not telling them how to do it, just providing context on the way someone else might approach it. And I never ding someone on my "follow your heart" feedback if they choose not to take my advice. When you do need to give critical feedback, choose better words. "Telling it like it is" can easily become "You don't matter to me as a person, and so I'm free to use whatever language I want to criticize your work". You can be honest and direct without being blunt or abrasive.

All that said, as an engineer, you need to learn how to see the value in failure—because you'll be doing a lot of it. Things you work on will break, systems will suddenly collapse, projects will fizzle out, and folks will be reassigned to other work, and sometimes you will just flat out be wrong about things. This is just part of the job, and learning to not get discouraged by it, but embrace it as a learning opportunity, will make you a more effective engineer over the course of your career.

The number one technical skill I recommend people focus on is problem-solving. It's also one that not everyone naturally excels at, but it is something I think everyone can learn, given enough time. You need to focus on strategies for solving problems because ultimately that is what you're paid for.

The biggest misconception a lot of engineers have is that they're paid to write code. This is false.

You're paid to solve problems—but the most common problem-solving medium you use is your code editor of choice. So, initially in your career, the act of solving problems is largely related to your ability to write code—fixing bugs, following a spec or set of outlines to add a new feature, etc. But as your career progresses and the scope of what you work on increases, you'll increasingly find harder and harder problems, eventually breaching into problems you can't solve with code alone. But the drive to those solutions—to know how to quickly assess a situation, use your experience to determine a likely cause, and work to prove or disprove those assumptions—will always be the most important skill you have in your toolbox.

But this doesn't mean you sit in isolation until you can solve the problem yourself—good problem-solving often requires involving others to help you think. Getting an outside perspective on a problem can provide a unique set of information about things that you might lack and may have never come to on your own. This is one of many reasons why it's important to hire folks from diverse backgrounds - if everyone around you has only ever known what a nail is, you'll build nothing but better hammers while the screwdriver company next door eats your lunch. Too often we try to solve problems in a way where the solution only fits who we think we are. It leads to poor products, it leads to inflexible code, and it leads to lost opportunity. Challenge this.

When it's time to actually do the work, knowing when to go heads down and when to go wide with your problem-solving efforts is another aspect of this skill you'll need to hone over time. Sometimes, you have to solve a problem using just your own hands; sometimes you need the help of others. Learning when to do each (and you should always err more on the side of the latter) is the mark of experience.

This might be embarrassing to admit, but during one project I was working on I straight up needed a refresher on some basic math - the rules of exponentiation. At first, I was hesitant to ask for help. After all, engineers are supposed to be good at math. I'm terrible at it, though. I did so-so in all my math classes growing up, and my college (thankfully for me at the time) did not have a strong math requirement for CS. After spinning my wheels on how to properly apply a number of exponent-based rules to some financial data, I realized I was being a coward. I went to my nearest coworker and asked him to help me whiteboard out some math so I could get my head around the rules again. He spent almost two hours with me late in the day as we both re-taught ourselves how this worked. I now had someone I knew could help me review the code better, looking for more errors or to provide more direct feedback on the implementation. I had to solve this problem, but I didn't have to solve it alone, and wound up with an easier review process because of it. I still think about that as one of the most enjoyable things I've done in my career.

If problem-solving comes naturally to you, you might assume learning would too. After all, what is problem-solving if not the act of collecting and executing on new information?

But it's fairly common for a lot of folks to feel like they're "done" learning. They've been doing the job for X years, they feel established, they feel like an "authority" on things - and they very well may be. But technology and the tools we use to maintain it are changing every day. You simply cannot declare yourself "done" learning, in any capacity.

Specifically, you've always got something new to learn about how to work more effectively with others, you've always got a new area of technology to get your hands dirty with, and you've always got the next failure hiding behind the corner just waiting for you to take away a lesson from it. I really don't have much sage wisdom here, other than to say that you should never be afraid to encounter something you don't know, and to admit you don't know it. Additionally, you don't have to know everything, as tempting as that feels. It's not possible, and if you can trust those around you, you don't need to know everything. Sit in on the post-mortems of other teams. Find something in the product you don't understand, and go ask someone about it. Ask your boss to help find a new area of the codebase for you to learn. Be hungry for knowledge, and it will find it's way to you.

In the Twitter thread, I was rightly called out for the loaded term "younger," so I want to start by clarifying that I meant "younger in their careers," not age. It's easier than ever for folks to change careers, so we need to be mindful that we don't apply bias to people solely based on age.

In my opinion, these skills are more important than any piece of technology. While it's easy to point to a few perennial mainstays, this isn't usually what people want to hear. What they want to hear is "Learn Kubernetes because it's literally what everyone does, so it'll never go out of fashion EVER." Or "This new (Apache/Cloud Native Foundation/some other consortium project you've never heard of) is going to be THE THING in five years, so become the expert on it now." The sad fact is those answers are actually poison to someone's growth. Chances are, anywhere you get a job will have its own stack that you could never have predicted (but you can bet your ass it'll have some SQL somewhere in it), and you'll spend a not-insignificant amount of time at that job learning and growing to manage that stack.

Instead, when someone asks you what technology they should learn, ask them what they want to learn. What interests them? Maybe it's graphs, maybe it's statistics, maybe it's art or photography or music. These can all point to interesting and niche technologies that the right person would fall in love with due to the outcomes they enable, not the flashy blog posts written about how they're poised to take over. Engage with people on a personal level to find out what excites them and what problems they'd love to solve with technology, and encourage them to learn those technologies.

But if someone asks how to be a better engineer, think about what will make a team want to hire them. In my experience, it's the skills and attitudes covered in this blog post. I'll hire for these things over any one piece of technology or programming language any day of the week.

The number one thing you'll spend time doing as a career engineer is talking. Talking to other engineers, talking with product managers, talking with support and sales, talking with your boss, and maybe even talking with their boss from time to time. Being able to manage these relationships effectively—by being a good communicator in many directions, working well with others even when you disagree, handling increasingly difficult and complex responsibilities, learning from the inevitable failures that will come your way and not getting hung up on them, focusing on applying these skills to the area of solving problems (technical or otherwise), and above all else always growing and learning—these are the skills that will carry you into a successful career in engineering, more than any one, individual technical skill.

Except maybe SQL. You know what, do yourself a favor and learn SQL. Anyone who tells you that some flavor of the week newfangled database removes the need to learn SQL is lying to you, whether they realize it or not. Learn SQL; it's genuinely valuable, and it's not going anywhere.

Sean Kelly
User profile image.
Engineer, Speaker, Writer, Hair-grower. I used to be nasty at NBA Jam. Not so much anymore, though. Available to give Terrible Advice, fee negotiable.
More about me

10 Comments

Avatar
Greg Pittman | March 19, 2019
No readers like this yet.

To me this statement isn't quite right:
"Learn to fail, and learn from failure."
I think it's more like not fearing failure, since failure always represents a learning opportunity. If you don't have an unreasoning fear, you are willing to push some system to its limits and beyond, so you end up with real information about why something fails. Strategically avoiding failure leads to mistaken ideas about why and how failure occurs, and it also prohibits seeing some unexpected positive outcomes in the midst of failure.

Avatar
Sean Kelly | March 19, 2019
No readers like this yet.

Actually, I have an entire talk on that subject, literally called "Don't fear failure" lol. I wanted to provide a slightly different take (and with it, a different wording) on it in this article since it's only one aspect of what I think engineers should be focusing on. I actually was hesitant to put a "quick summary" at the top because I feared folks would simply read those bullet points and not the content deeper into the post, but hopefully the actual content in the article allays your fears about the advice I'm trying to impart.

Thanks for giving it a read!

Avatar
TF3 | March 19, 2019
No readers like this yet.

Great article with well rounded view. Used the quote "defend without being defensive" in a meeting this morning!

Avatar
TheGNUdist | March 22, 2019
No readers like this yet.

Amazing article! I am a former IT professional who left to pursue a PhD in accounting. I always feared that I could never go back to IT despite having taught accounting information technology (including SQL!) for five years, but you have taught me that the same skills that make a great researcher or instructor or accountant also make a great engineer. Thanks for giving me perspective and hope.

Avatar
Sean Kelly | March 25, 2019
No readers like this yet.

Thanks! I'm glad you found it valuable! Best of luck!

Avatar
Paul K. Courtney | April 2, 2019
No readers like this yet.

Hey Sean, this article is such a welcome read during my morning coffee! I loved the honesty about your own experiences, especially when you said, "I went from being one of the better people in my role to barely scraping by..." I'm going to share this with a group we have recently set up in our start-up on mentoring.

Avatar
Sean Kelly | April 2, 2019
No readers like this yet.

Thanks! I'm glad you liked it, and hopefully it can help others as well!

Avatar
Tiago | April 2, 2019
No readers like this yet.

This post just widened my perspective. I felt hugely related to almost all your adventures and I can reminisce the same mistakes you made due to the lack of usage of these attitudes. Thanks a lot for posting this article and best of luck in your carrer.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.