Becoming a Developer Team Force Multiplier
Date Published: 02 January 2019
I have clients who describe me and my team as a "force multiplier" for their development organization. What does this mean, and how can it apply to you? How can you become a force multiplier for your team or company?
I talked about this topic briefly in a previous weekly dev tip email (subscribe):
A force multiplier is anything that increases the capabilities of existing resources. The 'force' described can be a literal, physical force like that applied to a nail with a hammer. Or it can be a fighting force, which is more commonly how the term is used in the military. A hammer is an example of a simple force multiplier, as with the same amount (or less!) effort, many more nails can be driven with a hammer than without one, or with a poor substitute like a rock. Combat engineers are a force multiplier in military operations, since their capabilities can increase the survivability of friendly forces and weaken and redirect enemy forces through the use of obstacles.
When I work with developer teams, my goal is to increase their effectiveness overall. With the same resources, the team will deliver more value, more rapidly, and more consistently, than the same team was able to do previously. That's what being a force multiplier means from the perspective of a trainer, mentor, coach, or even team member. In almost all cases, a single workshop or training session is not enough to overcome the inertia most teams have. Just like you can't turn a ship quickly, it's generally unrealistic to expect that a team of developers is going to change how they operate from one week to the next, no matter how compelling the content involved. What you can do with an initial workshop, though, is present to the team a vision of where they'd like to go, so that at least everybody is on board with team's new direction. Then what works well is to have an ongoing relationship with regular code reviews, Q&A sessions, and perhaps an additional virtual team member who already is well-versed in the skills the team is looking to implement. This has proven to be a formula for success with teams who've worked with me over the past several years.
Become a Force Multiplier on Your Team
Ok, so far this sounds like a commercial, so thanks for reading this far where we bring it back to you. Just like the reader who responded to my dev tip email, you're probably already a force multiplier for your organization. The software you write adds value that allows your users and customers to do more with their existing resources. But more than that, you too can be a force multiplier for your development team as well. Think about what you can do to enable your team members to be more effective. No, really, think about it. What kinds of things would that be? Here's a short list of ideas:
- Offer to review their code, even if your team doesn't have a formal code review process
- Ask about design and naming decisions you make to ensure there's some consensus and mutual understanding
- Write detailed commit messages that clearly indicate what changes were made, and why
- Write automated tests that clearly demonstrate your code does what's intended, and show how client code is expected to interact with your code
- Offer to do a lunch-and-learn on a topic you find interesting and think would benefit your team
- Offer to document your team's coding standards if this hasn't already been done; review them if it has
- Help to automate your team's build process
- Write one-click build-and-test scripts that can be run from the command line so any new developer can get latest, run the script, and immediately start working productively
- Consider ways to make your work area more productive (furniture, sound, etc) and share them with the team and/or management
- Continue learning more principles, patterns, and practices and be willing to (humbly) share them with your team members as you find uses for them in your software
- Add unit tests to code your teammates wrote
- Write unit tests that demonstrate the existence of bugs before you fix the bug
- Refactor your tests to make them less brittle and easier to work with, so more of your team members will be willing to write and maintain tests
I'm sure you can come up with more - please share them in the comments. Remember that automation is what we do as software developers, and automating testing (and building, deploying, monitoring, etc) of our systems should be second nature to us. Look for opportunities to reduce friction and eliminate manual chores wherever you can.
Why Should I Help My Competition?
In some ways, and in some (unhealthy, in my opinion) organizations, developers are made to feel like they are competing with their peers. Things like stack ranking can turn team members and their leaders against one another, as Microsoft discovered and eventually addressed. Hopefully you don't work for an organization like that, but even if you do, it's still worth looking at ways you can help your team and your peers to be more productive.
When you're considering the value you bring to your organization, there's a question of scale. There's only so much code you personally are going to write, test, review, etc. There are only so many hours in the day, you can only type so fast, etc. Scaling up your personal productivity will only take you so far. As a force multiplier for your team, and eventually for your organization, you're able to scale out instead of up. Instead of incrementally improving your personal capabilities, you're increasing the capabilities of your whole team. A 10% improvement for the team is worth far more than the same improvement of just your own ability. If you're able to consistently improve your team, that's far more valuable than if you're (only) improving your own skills, and you can leverage that increase in value to improve your career.
This depends on you and your current situation. If you're new to the industry, keep learning, and do what you can to share what you learn. If you're experienced but aren't progressing in your career as much as you'd like, think about some of the ideas above (and in the comments below, hopefully) as ways you can add more value. Be the team member everybody else appreciates because they make their own job easier and boost the productivity of the whole team. Find a team where everybody has this mindset and you'll never want to leave it.
Have questions? Subscribe to my tips emails and ask me. You can reply directly to any email and it goes straight to me. I'll answer as I find time. Want more dedicated career coaching? I've launched a small group coaching program that meets a few times a month and has a private Slack team and other resources. Learn more at devBetter.com.
Category - Browse all categories
Steve is an experienced software architect and trainer, focusing on code quality and Domain-Driven Design with .NET.