Non-technical skills that have served me well as a software engineer
I have been thinking a lot about what traits and skills have served me well in my career. In this article, I'd like to highlight some of the non-technical skills that have served me well.
Finding the value in my work #
I generally need to feel invested in my work to do well. This means I need to find some sort of value in it. I was lucky to have spent a good amount of time in civic tech where the work itself does public good. During my time at the U.S. Digital Service, it was really easy to find value in my work: if I was successful at my job, people in the United States would get critical services and benefits owed to them by their government.
I haven't only found value in jobs where I'm "doing good." In my current role at a for-profit company, my software helps employees voice their opinions to management and improve their lives at work. Furthermore, I'm learning how to engineer systems in one of the largest tech companies on the planet. Finally, I'm mentoring junior engineers and helping guide them in their careers. Those are all extremely valuable things to me!
Note that the value I'm talking about in this section does not include financial compensation. I just kind of assume, for most of us, money is one of the most important considerations for employment and is in a league of its own when it comes to "value."
Over-communicating #
Over-communicating has served me well in every job I've had, and I had a few prior to being a full time software engineer.
One job I had was as a project manager. When getting my Project Management Professional (PMP) certification, something that stuck with me as absolutely critical was stakeholder management. I found the Power Interest Grid to be especially interesting.
Source: Stakeholder Analysis using the Power Interest Grid
I don't actually make one of these diagrams on each project I work, but I do use it as a mental model to inform how I communicate with various people on my teams.
Let's take a look at the quadrants:
- Low power, low interest (Monitor). These are colleagues that aren't on the same project as me. Generally I monitor what they're up to because of the possibility of external dependencies, but otherwise I don't need to do too much active communication. For example, updates during standup or mass email status updates are usually sufficient.
- Low power, high interest (Keep Informed). These are colleagues on my project or with dependencies on my project. I want to keep them informed of progress because delays in my work may impact their work or vice versa. If I don't maintain this communication channel and there are resultant delays, management will be unhappy.
- High power, low interest (Keep Satisfied). These are managers and technical leads on other projects. I try to keep them satisfied by fielding any requests from them and make sure they have an accurate picture of any potential for dependencies between projects.
- High power, high interest (Manage Closely). These are managers and technical leads on my project. It is very, very important to update these folks a lot. At the very least, I let them know about potential delays and how I'm mitigating them. I especially let them know as soon as possible if I need their help resolving an issue.
Again, I don't actually put this to writing for my projects, but I definitely think about all the people on and around me from this perspective. I have seen so many good developers fall victim to poor communication.
One thing I always assume about communication is as follows: if I don't communicate something to someone, then I'm letting that person make up stories in their head about why I'm not communicating. Often this story can be, "Nick isn't communicating because he don't care or he's not doing the work."
Filling gaps #
I take great inspiration from Tanya Reilly's talk, Being Glue. The basic idea is there'sa lot of "glue work" on a team for which no one is responsible. As a senior engineer, I'm expected to identify those things and take care of them. When I'm on a team, I try to identify these gaps and either fill them myself or delegate as part of planning (the delegation part may only be applicable if you're more senior).
Tanya's caution on glue work is important, though: there is often enough glue work to fill a full time job. I make sure not to find myself doing only glue work so I don't end up on a non-engineering career track.
Taking ownership #
Surely someone must own the end-to-end test suite right? I can't find the owner, and it's falling apart, but surely this thing can't be entirely unmaintained.
Wrong!
One of the worst assumptions I've seen on teams of any size is that everything neatly has an owner. The truth is, if I haven't been able to find an owner relatively quickly, then there probably is no owner. When this happens, I have had opportunity to become the owner (or at least try). Whether or not I have actually gone on to own the thing hs depended on whether I hve the time and desire to do so.
Improving developer experience and productivity #
One pattern I have developed at jobs is identifying the aspects of developer experience that don't seem quite right: long builds, flaky CI runs, poor docs, cruft, etc.
Rather than jumping right in and trying to "fix" these issues, I socialize them with leads and folks who have been around a bit longer. Sometimes, there's a decent reason for why things are how they are. But often, people just haven't had the time to figure out how to fix the issues.
Making my colleagues' lives easier has not only built good will with those colleagues, but also has been valuable to my organizations: employees who can work more efficiently will deliver features and bug fixes faster.
Mentoring #
Mentoring has obvious benefits to the mentee, but also has enormous benefits to the mentor. When I have mentored someone, it gave me a third-person view of their career. I objectively saw the things they did and why those things might have been good or bad. That's some great information to influence my own behavior and career decisions!
Beyond benefitting my own career, it simply feels good to help others. Watching something "click" for a mentee is a wonderful feeling, as is watching them get promoted or moving on to the next phase of their career.
Positivity #
I like applying a healthy dose of positivity to any job I start. I come in thinking that, "this is going to go well unless I get significant information to the contrary."
This shouldn't be confused with toxic positivity! If the building is burning, I don't say, "This is fine."
But I do notice that a lot of my colleagues default to a negative mindset without having enough information to end up there. This can be self-fulfilling: if someone comes in thinking a job will be bad, then there's a good chance they'll look for information to prove themselves right. Conversely, thinking that a job will be good means that I look for the positives. There usually are a lot!
Final thoughts #
These are traits that have seemed to work well for me. Of course, I'm only one person and I've only had a handful of jobs. Perhaps only some of these traits work for you. Perhaps none of them work for you! But I hope at the very least this has been some interesting information about one person's career as you develop in your own software engineering career.
If you enjoyed this article, consider subscribing on Feedly or your favorite RSS consumer. If you'd like to chat, I'm most active on Bluesky.
- Previous: Generating code was never the hard part