When I was a junior engineer, I remember the bliss that was having no real expectations of me apart from learning technical skills. It didn’t matter that I would sit coding away all day without a care in the world. It didn’t matter that I would constantly forget to update Jira, or not be completely mentally present during planning sessions or product alignment meetings etc. It didn’t matter all that much if I didn’t speak to others all that often, and it didn’t matter if I forgot to do that one admin thing I’d been putting off.
Being a junior meant that the metric by which you were assessed was largely a technical one, and also that you’re not a terrible person to work with generally.
As you gain confidence and technical skills, perhaps you’ve been promoted to mid-level. It is at this point where your technical skills are less important to those to which your career progression depends. You have already proven you can write good enough code, you understand the tools and the best practices to a good enough degree. It’s a common mistake for junior to mid-level engineers to believe progression at this point is a continuation of your technical development.
Let’s face it, most programming roles simply don’t require the worlds greatest programmer or computer scientist to be productive. Problems within an organisation are only partially technical problems. They are in equal part the litany of problems none technical roles face. Prioritisation, communication, planning, presenting ideas, understanding the changing landscape of the business and what customers are asking for.
It wasn’t easy for me to grasp this initially, I almost noticed it by accident when I found myself doing more in some of these aspects. But I have noticed some behaviours that keep you in good stead.
This post will list several specific behaviours, and what they represent in terms of particular soft-skills. This post is by no means to say that I get these things right all of the time, but a recognition that when I do get them right, they are often greatly appreciated by those around me.
Be The First
Often, you will be asked to perform non-technical tasks, small pieces of admin that the business needs. It can be seemingly quite trivial, such as updating your name and address in the HR system, or filling out a form. You might see this as a waste of time, or begrudge having to do such a boring and uninteresting task. When I was a junior, I would put these tasks off as long as I possibly could, not realising the arrogance of my reluctance. By not doing something someone in another team has asked you to do, you are essentially saying that your time is worth more than theirs, and how dare they waste your valuable time with their nonsense.
If HR have asked everyone to fill out a form, it’s likely not for their own amusement, there’s probably a reason and in all probability a very good reason it needs to be done. They have to coordinate this with the entire company, which takes time, effort and frustration. Don’t be the person they have to chase up and waste more time on. Do it immediately and gladly. It will be appreciated more than you know.
It pays to be seen as someone who other teams can rely on to do what is needed. Try to be known as someone who is always the first to do what is asked of you. It builds trust and respect from your peers. It essentially signals that you value the work that they are doing, at the very least as much as your own.
Key takeaway: Be the first to do something that’s asked of everyone.
Communicate Publicly
In previous roles, I’ve been too hesitant to ask what I deemed to be stupid questions publicly. I’d do the Slack equivalent of whispering a question to people in DM’s, people who I thought might judge me the least, for example. But having the confidence to ask a potentially stupid question publicly benefits everyone else. It’s unlikely that you are the only person pondering this question. Chances are there’s at least one other person who will benefit from it being answered.
Making a habit of asking these questions publicly promotes the sharing of key information and discussions. It also highlights where documentation might be lacking, for example. Being able to search Slack for a question and immediately finding a lengthy thread on the topic and a solution is invaluable. Everyone wins.
But it’s not just stupid questions that benefit from this. If you are about to design how a new feature will work. List your thoughts publicly, in a document for example and allow others to review and comment on your initial ideas. Keep up this process throughout and you will have every decision, every piece of context documented. So when an engineer in five years time has to onboard to that feature, and wonders why it was built a certain way, you have it in writing in a series of design or decision documents.
Much of what is required of senior and above level engineers focusses around this type of communication, especially as more and more companies shift to remote work. Whereby discussions by nature have to happen asynchronously.
Key takeaway: Ask questions in public Slack channels, not DMs. Document your decisions and invite others to collaborate on them.
Do the boring stuff
Initially I started trying to do more of this because I was bad at it. My ADHD brain demands novelty, and throws a tantrum when asked to do repetitive or mundane tasks. So to try to learn some discipline around this, I started putting myself forward for all of those painfully boring tasks. Need a hundred Jira tickets creating? Need someone to change a date in fifty places in a code base? Please, allow me.
But what I noticed from doing this was just how much people appreciate you for it. Similar to the first point about doing things immediately, you get noticed as a team player, willing to shoulder any burden by picking up these types of tasks without hesitation or complaint. It really does go a long way.