Skip to main content
Nick Scialli

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.

power-interest grid
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:

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.


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."

this is fine meme

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.