Force Multipliers

 

What separates exceptional organizations from average ones isn’t that people work harder. It’s that one person, one decision, or one improvement changes everything else.

Activity and effectiveness aren’t the same thing. The better question is this: Where will one investment make the greatest difference?

Sometimes it’s technology. Sometimes it’s a process. More often, it’s a person others overlooked. Once you start looking for force multipliers, you begin seeing them everywhere.

The names in the following stories have been changed.

One of the first people who taught me what a force multiplier looked like was an engineer I’ll call Bob.

Before I interviewed him, I was advised not to hire him because English wasn’t his first language. I ignored the advice, and we interviewed anyway. After a panel interview, everyone reached the same conclusion. He was technically gifted, thoughtful under pressure, and unusually collaborative.

I was told a second time not to hire him. I respectfully disagreed. I remember saying, “If we don’t hire him, someone else will.”

The issue was never Bob’s ability. It was whether we were willing to slow down long enough to listen before judging him by an accent. Hiring him remains one of the best decisions I ever made.

Every conversation brought a fresh perspective, and every significant issue became a team effort until it was resolved.

Bob made everyone around him better.

Another engineer taught me an equally important lesson. I’ll call him John.

John spoke slowly. He greeted everyone with “Boss” because that was his way of showing respect. He rarely said more than necessary, and because of that, some people underestimated him almost immediately.

One morning I was instructed to terminate him because he “didn’t seem smart enough” and wasn’t in the office at eight a.m.

What no one realized was that John had worked until two o’clock that morning, preventing a significant network issue from becoming a major outage. He had called me during the night so we could work through the problem together. He wasn’t absent; he was recovering after protecting the organization while everyone else slept.

John wasn’t exceptional because he was technically gifted. He had remarkable judgment. He knew when to act, when to ask for help, and when something deserved immediate attention.

That experience reinforced something I’ve never forgotten. Leaders can’t confuse style with substance. Some of the greatest force multipliers don’t look like force multipliers until you give them the opportunity to demonstrate what they’re capable of.

Force multipliers aren’t always people. Sometimes they’re created by giving people a voice.

At one organization, we made what many considered a controversial governance change. Every major steering committee would include at least three engineers, and those engineers had veto authority.

Some worried it would slow decisions. It did exactly the opposite. The people closest to the work finally had a voice. Architects caught design flaws. Operations identified implementation issues. Engineers challenged assumptions before they became expensive mistakes. Meetings became shorter. Projects moved faster. Rework dropped dramatically—not because we held more meetings, but because the right people were helping shape decisions before they became expensive.

One of my teams spent nearly eight hours every week preparing slide decks. By introducing AI into the process, we reduced that effort to roughly three hours. The real benefit wasn’t the five hours we saved. Those five hours became time to solve problems, meet with stakeholders, improve solutions, and create value no AI could deliver.

I’ve learned that sometimes the multiplier isn’t innovation at all. Sometimes it’s discipline.

One individual consistently challenged every initiative. He questioned every proposal and often frustrated the rest of the team. Many viewed him as an obstacle. I saw someone who cared deeply about getting the right answer. Instead of minimizing his influence, I recommended he lead the steering committee.

Once responsible for balancing everyone’s priorities instead of defending only his own, his skepticism became one of the organization’s greatest strengths. He still asked difficult questions, but now those questions improved enterprise decisions instead of slowing them down.

Sometime later, another engineer on my team had become increasingly frustrated. His day-to-day responsibilities no longer challenged him, but through several conversations I learned he had independently earned three ITIL certifications because he was fascinated by process improvement and finding better ways for engineers to work.

Rather than asking him to continue work that had become routine, I challenged him to think bigger. I asked him to help us rethink our IT governance—how decisions were made, how technology aligned with business objectives, and where frameworks like ITIL could have the greatest impact. I wanted him to help shape how the organization operated—not simply implement processes.

What started as an engineer looking for a new opportunity became a broader transformation in how we governed technology. He found work that inspired him. The organization found a leader.

The greatest force multiplier I’ve ever experienced wasn’t a person, a process, or a technology. It was culture.

On one program, a junior engineer made a mistake that briefly disrupted network connectivity for an entire headquarters building.

Leadership immediately wanted a name.

I refused.
The team owned the mistake.
The team owned the solution.

Sometime later, another significant outage occurred. Once again, fingers immediately pointed toward the network team. Instead of assigning blame, we investigated. The root cause turned out to be a DevOps change.

I contacted the leader privately—not to identify someone to blame, but to understand what happened and how we could prevent it from happening again. We focused on corrective actions and stronger guardrails instead of blame. 

Gradually, something changed. People stopped hiding mistakes. Instead of waiting for investigations, they stepped forward.

“This was our change.”
“Here’s what happened.”
“Here’s the fix.”
“And here’s what we’re changing so it doesn’t happen again.”

Accountability replaced blame. Problems surfaced earlier. Solutions arrived faster. Trust became a force multiplier.

When I walk into an organization today, I’m still asking the same question:
Where will one investment make the greatest difference?

Sometimes it’s a person.
Sometimes it’s giving the right people a voice.
Sometimes it’s technology used well.
Sometimes it’s a culture built on trust.

The answer rarely begins with asking people to work harder.
It begins by recognizing the force multipliers that make everyone better.

– Tim

Technology Isn’t a Cost Center. It’s an Enterprise Value Creator.

 

When organizations discuss technology investments, the conversation often begins with cost. Hardware, software, cloud services, licensing, and staffing are all scrutinized because they appear on a budget. It’s understandable. Leaders have a responsibility to manage investments wisely.

The conversation can also become distracted by the latest platform, the newest capability, or whatever technology happens to dominate the headlines. While innovation is important, adopting technology simply because it’s new is no more effective than rejecting it simply because it costs more.

Technology has never created value simply because it costs less or because it’s the latest trend. It creates value by enabling organizations to operate differently, make better decisions, remove constraints, and pursue opportunities that would otherwise remain out of reach.

One example came while leading the modernization of a large enterprise environment. We were preparing to expand into the cloud while continuing to support mission-critical applications running in our existing data centers. The architecture needed to support modern cloud-native applications while maintaining compatibility with existing enterprise systems. It also had to provide high availability across multiple organizations that depended on shared services.

At the time, the cloud provider’s native load-balancing capabilities had not yet matured enough to provide the flexibility we required. We turned to a trusted technology partner whose products had served us well in our on-premises environment and who had begun offering a cloud-based solution. Their initial assessment was straightforward: what we wanted to accomplish wasn’t supported.

For many organizations, that would have ended the discussion. The architecture would have been redesigned around the limitation, and the opportunity to build a more capable foundation would have been lost. Instead, we challenged the assumption—not because we believed the vendor was wrong, but because the business outcome mattered more than accepting the first answer. Our engineers worked alongside the vendor’s engineering team until we developed an approach that supported modern containerized workloads, traditional enterprise applications, and our existing infrastructure as a unified platform. The solution preserved existing investments while creating a scalable path to the cloud. It also improved interoperability across agencies and freed developers to focus on delivering business capabilities instead of engineering around infrastructure constraints.

The architecture quietly continued to pay dividends long after the project was complete. Developers spent less time engineering around infrastructure constraints and more time delivering capabilities to the business. Our CI/CD pipeline became more efficient, operations became simpler, and each successive technology decision became easier because the foundation had been built to evolve with the enterprise instead of holding it back. What began as an infrastructure challenge became a catalyst for enterprise value creation, compounding over time through faster delivery, greater operational efficiency, and the freedom to adapt as business needs changed.

Earlier in my career, I learned the same lesson through virtualization. Most organizations justified virtualization by counting the number of physical servers they could eliminate. The hardware savings were real, but they represented only a fraction of the return. Reducing power consumption, cooling requirements, provisioning time, and operational effort allowed engineering teams to spend less time maintaining infrastructure and more time delivering value. Once again, the greatest return came not from the technology itself, but from the stronger foundation it created for everything that followed.

That’s why I’ve come to believe the greatest return on a technology investment isn’t measured when the project is finished. It’s realized in every capability the organization delivers more quickly, every constraint it no longer has to engineer around, and every opportunity it can pursue because the right foundation was put in place.

Technology should never be viewed as a cost center. Its greatest value isn’t in the systems we deploy, but in what they allow the enterprise to become.

- Tim

Tim Gabaree is a technology executive who writes about enterprise value creation, governance, operational leadership, and the role of technology in helping organizations grow and perform.

When Paying More Costs Less: A Strategy-to-Execution Lesson in 2 Minutes

A client approached us after a cloud modernization and application rationalization program had fallen behind schedule. The initiative supported approximately 3,500 users and included more than 1,500 applications. One year into a planned three-year effort, progress lagged expectations, and budget concerns were growing.

The delivery model relied heavily on junior personnel. Labor rates were low, but the work required experienced practitioners. Rationalization, change management, architecture, and delivery all depended on sound judgment. Discovery and rationalization lacked discipline. Change management was weak. Application modernization decisions often lacked the experience required to execute effectively.

The project appeared inexpensive on paper. Delivery told a different story.

After assessing the program, we recommended a different approach. We introduced experienced business process specialists, change management professionals, application rationalization experts, and senior cloud engineers. Labor costs increased by 50 percent.

The team rationalized more than 1,500 applications to fewer than 500. Approximately 400 applications were modernized and rebuilt for cloud operation. Roughly 40 were migrated through lift-and-shift approaches. Remaining applications were retained on-premises due to business or technical constraints or designated for retirement.

The original plan projected three years to MVP. We joined after the first year and achieved MVP with approximately one year remaining on the original schedule. This means that delivery accelerated by 33 percent. And despite higher labor costs, program spend decreased by 20 percent.

Labor cost and delivery cost are not the same thing. Lower hourly rates often look attractive during procurement, but delays, rework, poor decisions, and deferred value rarely appear on the same spreadsheet.

Experienced personnel cost more per hour. The total cost of delivery often tells a different story. Organizations should evaluate the total cost of delivery rather than the hourly cost of labor because sometimes paying more costs less.

The Last Two Across the Finish Line

 

Many years ago, I attended the Ranger Indoctrination Program (RIP), which is now known as the Ranger Assessment and Selection Program (RASP).

One of the events was a five-mile run that had to be completed within a strict time limit. It was designed to create stress and accelerate attrition. 

About halfway through, I caught up to another candidate who was struggling and out of breath. He was in good physical condition, muscular and built more like a bodybuilder than a runner. He wasn’t a quitter, but this event just wasn’t his strength. I had a choice to keep my pace and finish comfortably, or slow down and help him. I slowed down and stayed with him. We spent the rest of the run pushing each other to finish. By the time we approached the finish line, everyone else had already crossed. Several candidates had already been dropped for not making it in time. The Black Hats (what our instructors were called) saw us coming from a distance. We were the last two across the finish line. And they informed us that we'd both passed. We’d moved on to the next round.

At the time, I didn’t think much about the decision, as during Infantry Basic Training, Advanced Individual Training, and RIP, one lesson was endlessly repeated: 

Never leave your buddy behind.

As you could probably guess at this point, this story isn’t really about running or about my experience as a Rippie. It’s about a lesson that has stayed with me for more than thirty years.

And I’ve seen the same principle apply in business: Some of the best teams I’ve been part of were built by people willing to invest time and energy in helping others succeed, even when there was no immediate benefit to themselves. Likewise, many of the best leaders I’ve worked with understood that their job wasn’t to win alone. It was to help the team cross the finish line together.

What Mom and Dad Really Gave Me

 

Back in the early 1980s, I wanted a computer more than anything. It was a Commodore VIC-20, for those who are curious. The problem was that my family simply couldn’t afford one. We were of modest means, and there was very little disposable income. My mom and dad were honest with me about it. They told me they wished they could help, but the money just wasn’t there.

At the time, I had a paper route and picked up odd jobs at stores near where we lived. So I started saving. Before long, I realized that at the pace I was earning money, it would take years to buy a computer. To a kid, that was FOREVER.

I asked my parents again if there was any way they could help me get one sooner. Once again, they explained that they simply couldn’t afford to buy me a computer. But instead of leaving it there, they encouraged me to think differently. They suggested I use my paper route money to buy a lawn mower, rake, and basic equipment to start mowing lawns in the neighborhood. They explained that it would take time and work to get there, but it could eventually earn enough money for the computer I wanted.

So that became the plan.

For about five months, I saved every dollar I could. I got about halfway to what I needed for the equipment. Then my mom and dad surprised me. Quietly, without telling me, they’d been saving what little they could to help cover the rest. Looking back as an adult, I have no idea what they sacrificed to do that for me, especially knowing how tight money already was. But they somehow found a way.

Their sacrifice and guidance changed the direction of my life.

Together with my savings and their help, I bought the mower and equipment and started a lawn-mowing business during the summers. In the winters, I shoveled snow. What started as a way to earn money for a computer turned into a foundation for learning responsibility, discipline, customer service, and the value of creating opportunities instead of waiting for them.

By the age of 11, I finally bought that VIC-20.

More importantly, though, the experience taught me lessons far beyond that. Mom and Dad showed me what love looks like through sacrifice. They taught me the value of work, perseverance, gratitude, and ownership. They could’ve simply said no and left it there. Instead, they helped me find a path forward and quietly supported me however they could along the way.

I’ve never forgotten that and am forever grateful.

Thanks for reading.

Tim

Capital Discipline is Operational Discipline

 

If you have not read my earlier post, “Stability is Underrated,” I would probably start there first. This is really the financial side of the same conversation.

Healthy organizations usually think about money the same way good operators think about infrastructure.

Idle systems create waste. So does idle capital.

A lot of companies become so focused on controlling spending that they stop thinking carefully about whether their money is actually working once it reaches the balance sheet. Cash starts accumulating with no clear deployment strategy. Then six months later, leadership is simultaneously talking about cost pressure while large amounts of capital sit untouched, earning almost nothing because nobody wanted to make decisions around reserves, treasury management, reinvestment timing, or debt reduction priorities.

Conversely, sometimes organizations treat debt emotionally instead of operationally. Some leadership teams become so focused on eliminating debt entirely that they unintentionally restrict their own flexibility and delay investments that would have improved scalability or long-term operating health. Other environments go too far the opposite direction and operate as if cheap debt automatically excuses weak operational discipline underneath.

Usually, the healthiest organizations sit somewhere in the middle.

The strongest operators I have seen usually stay focused on flexibility:

• Enough liquidity to absorb problems without panic

• Enough discipline to avoid unnecessary exposure

• Enough operational consistency to keep investing during uncertain markets

• Enough structure that capital keeps moving intentionally instead of sitting untouched for years

That does not mean taking reckless risks.

Usually it means the opposite.

Some organizations quietly build strong long-term positions simply by staying disciplined while everybody else swings between overexpansion and overcorrection. Excess cash gets parked intelligently in low-risk instruments instead of sitting dormant. Capital projects get prioritized based on operational impact instead of internal politics or whoever speaks the loudest during budget season. Leadership stays realistic about what actually improves scalability versus what simply sounds impressive in a board presentation.

The environments that scale best usually understand a few things:

• Stability creates flexibility

• Predictability lowers operational stress

• Consistent cash management creates room for investment later

• Simple playbooks scale better than emotional decision-making

• Healthy debt and healthy liquidity can coexist

Most of this is not glamorous work. Nobody announces a major press release because reserve strategies became more disciplined or because treasury management quietly improved in the background.

But those things compound over time.

The same way operational debt compounds when organizations ignore process problems too long, financial inefficiency compounds when capital stops moving with purpose.

Good operators usually understand that stability and growth are not opposites.

Consistency creates room for growth.

- Tim

Stability is Underrated

 

A lot of leadership discussion today revolves around disruption, rapid transformation, aggressive scaling, and moving faster than everyone else. Some of that absolutely matters. Markets and technology change and organizations have to adapt.

But most environments do not actually fail because they lack another transformation initiative.

Usually, they struggle because basic operational consistency starts breaking down underneath them.

Sometimes processes and expectations change depending on who is leading the meeting that week. Different teams have different ways to solve the same problems. This leads to inconsistent reporting. Escalations can become emotional instead of procedural. Onboarding playbooks don’t stay up to date, and institutional knowledge lives inside individuals instead of an operational structure. This makes steady growth hard.

The organizations that tend to scale well are often the ones that become a little boring operationally. Good onboarding. Predictable governance. Defined and consistent ownership. Repeatable processes. Stable escalation paths. Consistent communication. People know what success looks like and how decisions get made without needing constant interpretation from leadership every single time something changes.

That kind of stability creates room for organizations to actually grow.

Without it, scaling usually means multiplying confusion.

I think this is part of the reason some organizations keep hiring smart people and still struggle operationally. Intelligence alone does not create consistency. A strong operating model does. So do simple playbooks that people can actually follow under pressure instead of beautifully designed processes nobody uses after the consultants leave.

The funny part is that this kind of operational discipline rarely gets celebrated publicly because it’s not exciting. Nobody announces a major press release because the escalation process got cleaned up or reporting structures finally stabilized across departments.

But those things matter.

Especially in environments trying to scale without burning people out or creating constant operational chaos underneath the surface.

Most organizations do not need more drama.

They need more consistency.

-Tim