Beyond Technical Skills - Getting to the Next Level

Moving ahead in your career depends on how well you can acquire certain non-technical skills

Somebody asked in a forum for experienced developers recently:

"What was the one thing that helped you get to the next level?"

It was in the context of career progression. How does one get promoted or move to the next level? What skills does one need to acquire? What habits do they need to build, and which ones should they drop?

It’s not possible to answer this comprehensively in a forum but I jotted down a few points based on my own experiences. People commented that they found my comments there helpful, so I have expanded on them in this article in the hope that it helps more folks. The original discussion was about software engineers in general. It was not specifically about Ops/SRE roles, and I’ve not changed my points to adapt them towards such roles, because I think the principles are universally applicable to all technical folks.

No One Thing

So what is the “one thing”? There is no single aspect, and it differs from organization to organization.

The bottom line is that technical skills alone don't drive career advancement. We hear this advice often but rarely follow it. It's almost as if we think it's a dictum to read and feel good about but not applicable to the real world. This tends to happen more in folks who have just joined the industry.

Functioning At a Higher Level

Start by doing what is required at the next level rather than waiting for a formal title change. Find out what you can do beyond your standard tasks by talking to your mentor, boss, lead, manager - whoever it is. This is of course assuming that you are meeting or exceeding expectations in your current role’s work and have time left over.

Doing this demonstrates that you are capable of handling higher responsibilities. It builds trust and often paves the way for moving to the next level. Don’t expect it to happen overnight, though.

A word of caution - it’s easy to overstep here. Implementing something without understanding needs and the bigger context can quickly backfire and lead to having other team members clean up after you.

Some organizations have a formal process for promotions in technical paths where you have to go through submitting a proposal, architecture, or design a system. These processes test for technical expertise as well as the ability to communicate. They don’t really prove that you are capable of functioning at the next level but are sometimes unavoidable depending on where you work.

Relationships

As we move higher in our careers, certain non-technical skills become important than others. Building relationships with your colleagues is one of them. Many juniors brush this off as "politics". I like to think of it as relationship building. It’s important to note here that I am not talking about dysfunctional organizations.

Building relationships can happen at many levels. Company gatherings and off-sites are a good opportunity to get to know colleagues from other teams or locations. So is presenting and giving tech talks, or helping out somebody with a problem they have.

Knowing how to build and maintain working relationships with people at different levels becomes more and more crucial for success as you move into bigger roles.

Communication

Over-communicate whenever you can. Over communication is usually harmless. On the other hand, assuming that the other person knows the context or relevant details of what you are talking about is all too common and can cause serious - unintentional - damage.

A common cognitive bias is The Curse of Knowledge. The Wikipedia definition states:

“A cognitive bias that occurs when a person who has specialized knowledge assumes that others share in that knowledge”

Whether you are talking about your plan for rolling out the new release, or why the new routing architecture has serious drawbacks - the same principles apply. Include all the information you can or think that is needed.

But hold on - do you need to talk about background information when you’re talking to your team? They all know it already, right?

It depends. They may not know about a specific but crucial piece. If you think that might be the case, state the assumptions you're making before you dive into the topic.

With remote work, we have more ways to communicate at our disposal than in-person. Video calls are the closest when it comes to matching in-person communication. In text chat tools, you have to make up for lost nuance. If you are not sure that you are getting your point across or vice-versa, and the person is remote, just pick up the phone and talk.

Presenting

An important but understated skill is to learn how to communicate with and present to different audiences.

A useful exercise here is to create a presentation about an important milestone you reached or a project you did recently and then create different versions of it based on the audience.

Modify your presentation assuming you have to present it to a certain audience, say, the CTO and the CEO. Next, assume you are presenting it to your team's engineers and modify it accordingly. After this, assume the audience is the entire organization at an all-hands meeting. As a final step, modify your presentation as if you have to present it to a non-technical department, say, finance. The last one is especially useful for bringing out points you might have never thought about.

This exercise is about which aspects you highlight and which you leave out. Each audience will have a different context and need a different level of abstraction, and will care about different things, and you will have to take that into account.

I recommend the book "Made to Stick" by Chip and Dan Heath for tips on how to present your ideas.

Breadth, Not Just Depth

Understanding the bigger picture means looking beyond our code, design, release strategy and cloud infrastructure. Why does your organization exist and what are its day-to-day challenges?

Depending on the level you are at, this will mean different things.

For example, for a developer moving to a senior developer role, it might mean understanding how other modules maintained by other teams interact with theirs. For somebody moving to an architect position, they have to understand the business and why their team is building what they are building. These are examples and not prescriptive.

The perspective shift that this leads to is often world-changing. Ensconced in our logical, bit-driven universe of code and configuration files, we tend to forget that the software we are building is a means to an end.

Who are your stakeholders? To use a less corporate phrase - who are the people who care that you do good work? Make sure you know what their expectations are.

Delegation and Other People

If you're moving to a team lead position, you may have a difficult time with delegating at first. We all go through it. A common worrier is whether the other person will do it the way you would have done it. Set expectations about the outcome, and any guidelines/processes/architecture they should follow, and leave them alone. Coach them when needed without micromanaging.

The more you delegate, the more trust you build, and help others grow.

I won’t attempt to explain people management in a one page post or even pretend to be an expert on it. Instead, I’ll share an anecdote from a time when I was moved to a team lead position from being a senior developer.

At this stage, many people have a resistance to what they perceive as "management stuff" - decisions that they don’t agree with, or feel that they impinge on their freedom, seemingly weird rules, and so on. An us-vs-them mentality. I did too, and after becoming a team lead I was more exposed to such things, and reacted in my usual way. After a few instances of such behavior my boss took me aside and said - "You're on the other side of the table now. Start seeing things from that perspective". It was his way of saying that I needed to look beyond my old assumptions. It was the jolt that I needed. Personally, I would not see this as a dichotomy - I prefer working with people rather than for them or having them work for me - but I still remember this incident because of the way it changed my thinking.

Conclusion

If I may suggest another book - "What got you here won't get you there" by Marshall Goldsmith is a good summary of non-technical aspects of your job that you need to adopt or modify to keep moving to the next level.

What has been your experience when it comes to moving ahead in your career? Share in the comments.

Note: All books mentioned link to their Goodreads pages. None of them are affiliate links.

Image credits : Photo by Samantha Sophia on Unsplash