Five ways to be a force multiplier in software engineering

Apr 24, 2022 career development

As you move along in your software engineering career, one of the biggest ways you can have a larger impact is to be a force multiplier.

What does it mean to be a force multiplier, you might ask? Having an outsized impact on others beyond your direct contributions. For example, helping level-up the skills of other members of your team so you can all deliver faster and with higher quality vs you alone just working the next development task.

While what you directly deliver as an individual is important, when you help level-up others your efforts have a wide-ranging impact that can multiply productivity across a team, organization, or the software industry at large.

Be a mentor

One of the easiest ways to be a force multiplier is to help mentor other folks in your engineering organization. There are always fellow engineers who are interested in learning from more experienced engineers, whether it's engineers with more career experience or more experience in their particular company. Getting started mentoring can be as simple as meeting every two weeks or every month and helping answer questions, suggesting tech or skills to learn next, and helping with any other topics are on your mentee's mind.

Depending on where you are in your career, you may start with mentoring junior engineers on your team. And as you progress further in your career you may begin to mentor senior engineers, newer managers, etc.

Present

Sharing your knowledge and/or experience through a presentation is a great way to have an impact on a wider audience.

There are many options for presentations - ranging from short 5-10 minute lightning talks on a specific subject or more in-depth hour-long presentations. And there are many choices for presentation venue as well, starting with informal presentations in your own team to engineering-wide presentations in your company or conference talks.

When folks are interested in starting presenting, sometimes they aren't sure what topic to present. In the past folks have mentioned to me they don't feel like they have enough expertise on any one subject. But presentations by experts aren't the only valuable ones.

Personally, I really appreciate talks where folks talk about their experiences using a given technique or technology. What problems they solved, what worked well vs what didn't, etc. If in an hour-long presentation I can learn from their hard-won knowledge over weeks or months of experience on a subject, that is absolutely a valuable use of my time.

Over the past few years I've given several dozen presentations, ranging from short lightning talks on my recent experience with a helpful technology to hour-long in-depth talks. Helping share my experience with others has been very satisfying (if a bit scary at times, depending on the audience size). Especially the times when attendees reached out later to tell me about how applying things from my presentation helped them in their own work.

Write

Writing and sharing through long-form docs can also be a great way to share your knowledge and experience. Longer-form written docs are easy for other folks to consume on their schedule and a great way to share knowledge that doesn't require your direct presence.

Writing can take many forms - from internal docs, blog posts, post-mortems, to work recaps and more. Examples of long-form docs I've written recently:

Investigation and solution for a thorny technical challenge. Writing down my investigation and results helped in several ways. First - it helped share the experience with my immediate team. Then a couple of months later, a peer team ran into a similar issue - and I sent them this doc and it gave them a jump-start on fixing their similar issue.
Post-mortem on a production incident, including both the specific follow-up actions my team is taking plus the specific learnings that are applicable to many other teams.
Getting-started docs for several testing technologies, including how to use them in the company's tech stack.
Analysis and details of the team's on-call load, including trends over time.
Blog posts like this!

You likely have opportunities today where others could benefit from learning through your experiences by reading docs you write.

Contribute to shared code

In addition to sharing knowledge, another way to be a force multiplier is to encode that knowledge in libraries and tools that folks can use across your company or the wider software industry. You can identify common pain points shared by others and create inner-source or open-source projects to solve them.

A sampling of some open-source and inner-source projects I've helped build recently, in case they spark ideas on your end:

Open-source project test results, code coverage, and static analysis reporting tool called Projektor
Automatic SSL certificate renewal application - eliminating the risk of expiring certs causing production outages
On-call alert visibility tool, including alert trend graphs, detailed information on alerts, and weekly alert recap emails
Gradle plugin to smooth publishing libraries to the company's internal artifact repository

In a prior job, I worked across about a dozen teams and noticed times those teams were solving similar issues as one another. Or a team was starting a work effort similar to what another team had solved recently. Or engineers were exploring new tech for their team that could help other teams as well.

I can share what I've personally learned - but I'm only one person. If I can also bring the combined experience of dozens of engineers together and they can share out - the impact is even larger. For two years I organized a bi-weekly lightning talk series, creating a platform for over 100 lightning talks.

And at a previous company we also had a weekly all-engineering lunch and learn series, and I helped on the team organizing and facilitating those lunch and learns. Then engineers could benefit from the collective knowledge and experience from folks across the entire engineering organization.

Conclusion

There are many ways to be a force multiplier in your software engineering career. You can personally seize these opportunities without needing to wait for specific projects in your role. And then you and your fellow engineers can reap the benefits of your larger impact.