Why tactics ripped from someone else’s system rarely work and what to do instead
I want to start this one with a confession.
I am guilty of exactly what I’m about to describe. And I have also been on the receiving end of it more times than I’d like to admit, from people I genuinely respect.
Here’s the scenario. Someone in our leadership circle goes to a peer group. Or a conference. Or has a conversation with a founder they admire. They come back fired up with a tactic that’s working gangbusters for someone else. A new prospecting sequence. A specific sales framework.
A compensation structure. A technology platform that’s supposedly transforming the way another firm operates.
And they hand it to me and say: let’s do this.
So we try it. We run the sequence. We adopt the framework. We implement the platform. And more often than I care to put in writing, it lands with a thud.
Not because the idea was bad. Not because the person who shared it was wrong. But because we saw the play, and missed the playbook it came from.
My Daughter, BASIS, and a Lesson in Systems
I’ve got a front-row seat to a version of this that has nothing to do with business.
My daughter spent eight years at BASIS, one of Arizona’s top charter schools. If you’re not familiar: BASIS is not your typical school. Longer school days. Extended teacher-student contact hours. A culture of high expectations that is baked in from day one among students, teachers, and parents. Rigorous curriculum. Aligned community. It works because everything inside of it is designed to work together.
She moved to a public high school for a more social and athletic environment. And she ran into one of her former BASIS teachers, a teacher who was genuinely excellent now trying to apply the same techniques in a completely different environment.
Same lesson structure. Same high-expectations language. Same approach to student accountability.
Different results. Significantly different.
And it wasn’t the teachers’ fault. They’re great educators. But BASIS worked because of the full system around those techniques: the extended hours that allowed concepts to breathe, the culture that students had been immersed in for years, the parental alignment, the continuity. Pull one method out and drop it into a 50-minute period with a different student population and no shared foundation and it’s not the same thing. It’s a lighter, orphaned version of the real thing.
You can’t cherry-pick one piece of a well-designed system and expect it to perform the way it did inside the original. You’re not replicating what made it work. You’re just running a cheaper, incomplete version of it.
This Happens in Construction Firms Every Week
I’ve watched this play out with Arizona contractors in a few different ways.
The technology platform grab. A GC hears at an AGC meeting that another firm is getting incredible mileage out of a specific project management platform. So they buy it. They stand it up. Three months later, half the team is using it and half the team isn’t, the field data is unreliable, and the PM is still running the real schedule in a spreadsheet on his desktop.
What they didn’t see: the other firm spent six months on change management before rollout. They restructured their weekly meeting cadence around the platform. They tied field superintendent accountability to it. The technology was the last piece of a system, not the first.
The sales process copy. A sub watches a competitor close projects at a higher margin and assumes it’s their sales approach. So they replicate the preconstruction discovery questions, the proposal format, the follow-up cadence. Still can’t close at the same rate.
What they didn’t see: the competitor’s pipeline is 70% referral. Their prospects show up warm, already trusting the brand, already sold on the quality. The sales process isn’t creating the result, the reputation feeding the pipeline is. The sales process just doesn’t screw it up.
The IT security checklist. And here’s one that hits close to home for us. A firm sees that a competitor passed a cyber insurance audit or won a GC prequalification that required proof of IT security posture. So they go buy a security tool and a backup solution and check the boxes.
What they don’t see: that competitor has monitored endpoints, a tested incident response plan, email security, DNS filtering, and a managed services partner watching the environment around the clock. The tools aren’t the security. The system is the security. The tools are just components.
The System Concept Nobody Talks About
There’s a principle in systems thinking that doesn’t get nearly enough airtime in business conversations:
Individual components don’t create an output on their own. It’s how those components interact that produces the result.
A framing crew on a job without a foundation is just a pile of lumber. A pour without a proper form is a liability. A finishing crew on a project where rough-in hasn’t been inspected is chaos. Every contractor reading this understands this intuitively on the jobsite.
But we routinely violate this principle in the office. We pull tactics out of context. We adopt tools without the culture to support them. We implement processes without the pipeline conditions they were designed for.
And then we wonder why it didn’t work.
So What Do You Do Instead?
I’m not saying stop learning from other people. Peer groups, conferences, conversations with people who are ahead of you, that’s some of the best business development available. I’m still a believer.
But before you rip a tactic out of someone else’s context and plug it into yours, ask a few more questions:
- What else is running alongside this? What are the conditions that make this tactic work in their environment?
- What does their pipeline look like vs. ours? Are their prospects arriving warm or cold? What’s their reputation in the market doing for them that ours may not be doing yet?
- What’s the culture infrastructure underneath this? Is their team trained differently? Do they have accountability structures we don’t? Do they have longer runways for change adoption?
- What would we need to build first before this tactic could actually perform the way it does for them?
Sometimes the answer is: we’re actually close. Minor adaptations and this could work well here. Sometimes the answer is: this is a two-year build before we’d see similar results. Both are useful answers. Neither is the answer you get if you just try to copy the play.
A Note on the Technology Side Specifically
Because this is a TechTip and I’d be remiss not to land the plane here:
Technology is one of the most commonly misapplied tactics in construction firms, and it’s almost always a systems problem. A platform doesn’t work because the data foundation isn’t there. A security tool doesn’t protect you because it’s not connected to anything else monitoring the environment. An AI tool doesn’t deliver value because the processes it was supposed to enhance don’t exist yet in a consistent, documented form, and the IT foundation it runs on is not established.
The technology is usually fine. The system around it is what’s missing.
That’s what we spend most of our time building with clients. It’s not installing tools, but designing the system where those tools live. So when the tools perform, they perform as part of something. Not in isolation.
Before you copy someone else’s play, make sure you understand the playbook it came from.
Ready to see if your tech stack is built to win, or just built to survive?
Book a Free Consultation Review with Computer Dimensions.
For over 20 years, Computer Dimensions has been the trusted IT partner for Arizona's architecture, engineering, and construction industry. We help AEC firms communicate better, collaborate smarter, and actually use the technology they've invested in. Because in construction, the tools only work if your team does.
IT Built For Builders.
P.S. If someone in your peer group just shared a technology play that sounds too good not to try, run it by us first. We’ll tell you honestly whether your environment is set up for it to actually work.
