Five Ways Software Engineers Can Manage Perception
Software engineers who improve their presentation skills and self-advocacy are more likely to gain respect and acknowledgement, and advance their careers. But people may regard this as inauthentic and uncomfortable. They may believe that hard technical work ought to speak for itself, and it’s a failure of others — especially management — to not understand the importance of what they do.
You’re shooting yourself and your team in the foot if you don’t actively manage how your work is perceived and create awareness of what you do. Your manager simply cannot know every detail of your job, nor should they. There’s no reason to expect non-technical stakeholders to accept your word that projects are more complicated than they seem unless you show them why. It’s your job to communicate what’s going on, to explain the decisions you’re making, and to be explicit about how you want other people to understand you. And you need to create awareness of all the great work you’ve been doing. This is particularly important for work that isn’t as obvious and visible, like backend infrastructure. When it’s time for your annual performance review you want everyone to already know your reputation as an engineer who gets stuff done.
In this post, I’ll share five ways software engineers can actively manage their perception to set themselves up for success.
- Find victories
- Learn how to tell a story
- Show up as the role you want to play
- Make friends outside of engineering
- Be known for “a thing”
1. Find victories
At the end of the day, visible success is what matters. While it’s unfair, people only remember great results and quickly forget about good intentions, smartly placed bets that didn’t pan out, or laborious slogs to do necessary-but-not-visible work. If you want to gain influence and recognition, you need to chalk up victories.
This doesn’t mean glomming onto all the flashy projects. It would be toxic if teams squabbled over the “best” assignments. Instead, think about it this way:
In one year, what impressive stories I can tell?
When you start a project, make sure you’ll be able to later point back to it as a success. One way is to shepherd interesting work all the way through the end; some developers just focus on the development phase, but if you want to shine then you can follow-up to ensure testing, deployment, metrics, and post-release support all go smoothly.
If you feel like you’re only being assigned small fix-it tasks, it’s totally OK to tell your manager you’d like to work together to find a project with bigger impact. It always reflects well on employees when they ask for growth and new challenges.
When there’s a major new project, do a quick assessment to see if success is defined and possible. Is there a scenario where external stakeholders will congratulate the team on a job well done? Sometimes there isn’t such a path. For example, suppose there’s a big initiative to rewrite a backend chunk of code on a tight and fixed deadline. If you think about it, there are two outcomes: either the team works really hard and completes the work, in which case the result will be met with indifference because the system works the same way; or something goes wrong and there will be negativity that engineering wasted a ton of time and money. Victory isn’t possible. But you can work with leadership upfront to shape the project plan: perhaps there are interim milestones everyone agrees to celebrate, or important metrics this project will unlock. And if there are risks, raise awareness upfront and get everyone to sign-off on those so any stumbles will be treated as a shared burden rather than someone’s fault.
This isn’t about scheming individualism to nab all the “good stuff” at the expense of the team. Rather, if everyone is explicitly trying to ensure they and their teams find a steady stream of wins — making a tangible impact on the company — while avoiding unimportant work or failures, then everyone and the company are much better off.
We’ve talked about identifying successes and making sure they will be acknowledged; but this requires that everyone has a shared goal. If you’re operating in an environment where the direction constantly changes or factions disagree about what matters, then winning isn’t possible because there isn’t a goal line. It is leadership’s job to ensure everyone has a common strategy and objectives. If you’re struggling because the top-level goals don’t make sense or there are politics above you, this isn’t something you can fix yourself but it’s certainly worth escalating.
2. Learn how to tell a story
Many engineers cannot effectively present ideas and explain their work. Conversations often jump directly into “how” things are built without explicitly laying out assumptions, providing context, or understanding what level of information people need. The result can be glazed-eye boredom or people wasting time debating details because they aren’t aligned on priorities. Engineers striving for correctness and some ideal of being objective forget that it’s pointless to be right if nobody will listen to you. You need to understand your audience and deliberately choose how to best communicate and convince them.
Use storytelling as a way to explain your thought process in a way that engages the listener. Effective leaders are storytellers, and they develop a sensitive understanding of audiences to hone their message and delivery.
Effective leaders are storytellers
Human evolution has hardwired us to socialize through stories, and people are adept at following a narrative structure of “it started as X, but Y happened, so we did Z.” A software engineer could start by turning their regular status updates into a narrative. There are often opportunities to present at group meetings or to revamp bland slide decks into a dramatic sequence of events. Always be telling stories.
A technical story serves to make a point, which is usually to justify a decision or to explain about why things are a certain way. Start by choosing the essential takeaways. As you tell your story, make sure you know what your audience is looking for and be alert to boredom or confusion.
- Provide context. Even when it seems obvious or repetitive, always start by stating the current situation, the problem, and the goals.
- Reduce the solutions to options. Don’t belabor the details; instead, provide a digestible menu of options and provide a recommendation.
- Pause frequently and make eye contact. Most people say too much, too quickly, and without inflection. A good pause is invaluable because it breaks the flow and builds tension, gathering audience attention. You can use this moment to read the room and acknowledge the people who are there. (And a meaningful pause makes you look smart!)
- Use names. Remind people who you are. Give kudos and shout-outs. People love to hear their names, and it ties the story back to the team.
- Ask for feedback. People won’t tell you if you’re a terrible presenter. Ask a trusted friend how you could have better framed an idea — was it too long, too detailed, confusing? Was your delivery monotone and hard to follow? Would visuals have helped?
The best way to learn technical storytelling is to study effective presenters. Find highly regarded conference talks and analyze the speaker’s presentation choices — what’s the sequence, how much information is shared at a time, what visual aids are most effective, what is the pacing, do they vary the tone?
3. Show up as the role you want to play
As the saying goes, half the job is just showing up. Mimicking how you believe someone in a role would act — their professionalism, knowing where to be, the kinds of tasks they would handle or delegate — can quickly lead to actually assuming that function.
The best way to get promoted is to demonstrate you’re already operating at that level. It’s tempting to focus on the technical skills development, but the behaviors and organizational practices are at least as important. You need to act like someone in that role.
The idea of slipping on a mask to play-act some idealized role may seem to be the very definition of inauthenticity and being an imposter. But don’t forget, a great stage actor doesn’t pretend to be Julius Caesar, they become Caesar. And likewise, professionalism is a mask we wear every day so that shared conventions and standards facilitate smooth social functions. Work isn’t about expressing your most authentic inner self, but choosing the aspirational public image that you strive to become.
4. Make friends outside of engineering
Engineers often hang out only with other engineers. How will they learn how the company works, or get other points of view?
Leave your comfort zone and forge connections outside your department. You’ll learn about how things work from another perspective and can share the engineering team’s experiences with people who may see your department as a black box. At the very least, you’ll be setting yourself up for serendipity: someone may drop your name to a VP, or perhaps you’ll hear about a challenging problem that’s coming up.
The easiest way to get started is to just fire off a 30 minute meeting invite to someone you may barely know at work suggesting you get coffee and learn more about each other’s roles. Almost everyone will say “yes.” Or there are apps like Donut which arrange random meet-ups.
5. Be known for “a thing”
You don’t want to be an anonymous engineer known only for your capacity to do work. You need to stand out so people know your name, bring opportunities to you, and advocate for you during promotion or compensation adjustment cycles.
Consider the handful of things you want people to associate with you and take an active role in establishing that reputation. For example, suppose you’re really excited by Javascript and open source so you manage an NPM package. You can’t expect your boss or coworkers to spread the word that you’re the go-to person about Javascript packages. You should find opportunities to share this out yourself. Perhaps you could give a brownbag presentation, or write thoughtful comments on pull requests. Ask your manager for ideas, too.
Conclusion
Perception matters. Set yourself up for success by taking control of how your work is interpreted. This may be daunting for introverts and people who just want to be left alone to write code. Paying attention to public image may seem disingenuous and political. But it’s important to actively own your career and insist on respect and recognition. This isn’t something you should expect your manager to do for you; some managers may help a great deal, but it’s ultimately up to you.
