How do I force multiply?

I'm often asked, "How do I force multiply?" I spend the majority of my time at work in force multiplying activities. It’s one of the most important ways I scale my impact and one of the mindsets I look for that differentiate junior versus senior engineers. I recommend first understanding what it is, and then maximizing your impact by improving effectiveness and increasing adoption.

In technology companies where I've worked, force multipliers are individuals who either possess attributes or deliver solutions that dramatically increase (hence, multiplies) the effectiveness of a group, giving them the ability to accomplish greater things. You’re more valuable than what you can accomplish directly by yourself because you’re contributing through others.

The term comes from military science where it’s defined as “a factor or a combination of factors that gives personnel or weapons (or other hardware) the ability to accomplish greater feats than without it”, e.g. morale, mobility, intelligence, etc.

Different seniority levels of engineers have increasing force multiplying ability and scope, from learning to proficient, and from a single team to across many teams in an organization. Examples include setting up remote debugging capabilities for a new development paradigm that significantly increases a team’s coding throughput, or setting up a design review mechanism that greatly improves the quality of an organizations’ technical designs.

The total impact that your force multiplying efforts have is equal to the increase in effectiveness per person times the number of people who adopt it, or impact = effectiveness x adoption. For example, if you can make five people or teams 20% more effective, then you’ve added the equivalent of one extra person or team of capacity.

If adoption is zero, it doesn’t matter how much you increase effectiveness. Anything times zero is still zero. But if I had to choose to focus on one over the other, I’d choose effectiveness. While there are cases of adoption driving effectiveness, like economies of scale, they seem rare. It’s more common, in my experience, for effectiveness to drive adoption.

If I work on something that dramatically increases someone’s effectiveness, it won’t be hard to convince others on the team to adopt it. And once a team adopts it, it’ll likely spread to other teams and emerge as a best practice. Soon, it’ll be foolish for anyone not to use it.

For example, I remember when integrated development environments (IDEs) weren’t a thing. Yes, I’m that old. Developers argued over whether vi (vim wasn’t even invented yet) or emacs was a better text editor for writing code. If you search for vi, a popular search engine will ask, “Did you mean: emacs” and vice-versa. Personally, I've used both throughout my career. vi is pretty ubiquitous and I find emacs more convenient even if it gives me emacs pinky. These days, I use Sublime a lot.

When IDEs started coming out, they were cumbersome memory and CPU hogs. NetBeans, Eclipse, and IntelliJ demanded the highest end desktops (laptops weren’t prevalent back in the early 2000’s). But those IDEs and others, like Microsoft’s Visual Studio and Apple’s Xcode, kept getting leaner, faster, and better. Today, it’s kind of foolish (impossible in the case of Xcode) to develop software without an IDE. Effectiveness of IDEs drove their adoption.

To find something that can improve someone’s effectiveness, think about how you can reduce their costs or increase their benefits. Reducing costs includes saving them time, e.g. we had a VPN script at work that saved me a little bit of time every morning during the pandemic while I worked from home. Whenever you unblock yourself, figure out the best way to help the next person who runs in to the same problem, e.g. answer a forum post question.

Increasing benefits includes helping someone move faster or build more scalable systems, e.g. log archiving and searching solutions. Instead of just answering a forum post question, figure out a way to make the system self-healing or preventative to obviate the need to post the question in the forum in the first place.

In a previous role, I noticed that teams were getting bogged down in endless debates about technical decisions. They sometimes seemed to make progress by closing on a decision only to have that decision later reopened for reconsideration if someone didn’t like the outcome.

I decided to put in place a decision making mechanism leveraging clear roles and responsibilities plus an escalation path. Teams could involve the right people to get closure on a clear decision and those decisions stayed closed. The result was that teams were able to move much faster with much less frustration.

Increasing benefits is usually better than reducing costs, because benefits unlock top line growth (gross income) which is practically limitless while costs squeeze out bottom line growth (net income after expenses) which is limited by the top line. Of course, it’s best to do both and grow your income faster than your expenses. But you’ll eventually run out of opportunities to cut expenses unless your income is growing too.

An even more powerful way to improve someone’s effectiveness than reducing costs or increasing benefits is helping them to think differently. Mental models and insights are often reusable in many new and seemingly unrelated situations and therefore pay large dividends over time.

I’m always looking for opportunities to teach what I’ve learned to anyone who will listen. In design reviews, I provide feedback, offer alternatives, and explain why I like or dislike something. I write and publish blogs and articles. I describe why I’m making a code change in code comments and commit messages. And I ask for clarification on the thought process behind a decision that I don’t understand.

While I recommend focusing on effectiveness, I don’t recommend completely ignoring adoption. Making something low effort, or better yet, zero effort to adopt generally helps. For example, it’s pretty well known that opt-out drives greater adoption than opt-in because the no-effort default is to adopt.

It’s also helpful to think about recursive adoption that can drive exponential growth. Word of mouth is an example of recursive adoption if initial adopters become promoters to subsequent adopters. The potential exponential growth makes it one of the most valuable forms of marketing. Training trainers or mentoring mentors are also examples of recursive adoption.

And finally, I recommend thinking about how adoption can recur over time. My published blogs and articles are an example of recurring adoption because it’s a source of content I and others can use to answer questions as they come up again over time.

So that’s how to become a force multiplier:

• understand what it is: ability and scope, impact = effectiveness x adoption, effectiveness drives adoption
• improve effectiveness: reduce cost, increase benefit, help people think differently
• increase adoption: reduce or eliminate adoption effort, leverage recursion, leverage recurrence

Hope that helps. What do you think? Do you have any other questions I can answer? Let me know in the comments!

#LuusAnswers #ForceMultiplier #TechLeadership