Driving Technical Change

Driving Technical Change: Why people on Your Team Don’t Act on Good Idea, and How to Convince Them They Should

Recently, in addition to pure tech books, I’ve also started reading some books focused more on soft skills. This one is the most resonant book I’ve read lately. General books on management and leadership rarely tell you what to do when your colleagues reject your proposals. Trying to reason with them often leads nowhere, easily spiraling into a vicious cycle.

During development, technologies can easily become outdated or ill-suited to the current context, sparking ideas to change the tech stack, frameworks, or deployment methods.

However, getting the entire team to accept your ideas often involves many trials. It’s common to spend a lot of passion, thought, and time “evangelizing,” only to have the team completely ignore you—or even wonder what on earth you’re busy with.

Even if the current technology is clunky and bugs keep popping up, people prefer not to change as long as it’s tolerable. Over time, you might also turn into an uninspired engineer, just churning out mediocre code day by day to get by.

This book categorizes several patterns of people who resist change. While you might not be able to apply everything immediately after reading, I find this book much more authentic than typical soft-skill books. In the real workplace, situations like this happen all the time—effective communication isn’t something everyone naturally does.

Persuading others to accept your ideas isn’t unique to software development; it happens in other fields as well, though it tends to occur more frequently in software engineering. When we want to convey our ideas to the team, we often act on natural preferences or opinions rather than thinking through a strategic plan first.

However, people come in all shapes and sizes. Not everyone welcomes the introduction of new tech or deprecating the old. You might be working hard on something genuinely great for the team, yet find no one else buys into it.

Therefore, how you promote your idea is the key. When your passion and proposed changes gradually spread throughout the team, it becomes much easier to gain their support. This book offers many effective practices and practical advice.

The Seven Types of Resistors

The book categorizes people who resist change into seven types:

• The Uninformed: They lack the relevant technical knowledge or context.

• The Herd: They just go with the flow and hold no strong stance of their own.

• The Cynic: The zealot. The book describes them with an exceptionally fitting analogy:

  They’re that kid in college who always asked your professors annoying questions to show how smart they are.

  Because they love skimming various technologies—aiming for breadth rather than depth—they try to intimidate you with bizarre anecdotes or edge cases.

• The Burned: The radical skeptics. Due to past bad experiences, they are vehemently opposed to certain technologies or frameworks and would rather stick with what’s currently in place.

• The Time Crunched: They simply don’t have the time to learn new knowledge or techniques.

• The Boss: Your manager. They often reject your proposals simply because they don’t understand the technology.

• The Irrational: The completely unreasonable. They will find every possible way to shoot down your proposal. As soon as one argument falls apart, they immediately pivot to another. They are essentially an amalgamation of all the types above. The best way to deal with the Irrational is simply to ignore them.

Preparation: Defining the Problem and the Solution

Before introducing any new technology, the most important step is defining the problem and its solution to ensure you are actually solving the right problem. For instance, you might want to introduce an automated deployment pipeline, but will automated deployment actually solve your current bottlenecks? Or, because the page state is complex, you might want to introduce a SPA architecture, but will that effectively resolve the state complexity?

Before pushing for a technology, think through the problem and the goals you want to achieve. This is not only helpful for deciding whether to introduce it, but also prepares you for questions from colleagues and managers who might share similar concerns.

You Might Be Wrong

Everyone makes mistakes. When faced with skepticism, don’t assume the other person is deliberately trying to block you (at least not initially)—they may just have their own valid considerations. When I first introduced automated deployments, I consulted a colleague about why they tagged Git commits with compiled hashes instead of semantic version numbers. It turned out to be a legacy method for tracking builds. Because of that conversation, I adjusted my approach so the automated deployment pipeline recorded the compiled hash automatically, successfully gaining my colleague’s support.

Some Techniques

The book proposes several techniques to address each type of resistor.

Gain Expertise

Before introducing a technology or tool, make sure you have a deep enough understanding of it to answer others’ questions. Skimming documentation and FAQs isn’t enough; you need a solid grasp of it. To achieve this, you can:

• Seek out other experts
• Teach it
• Use it (in your personal projects)

Actionable Steps

1. Read through the entire documentation.
2. Visit relevant technical forums to see how people discuss the technology, and see if you can answer their questions.
3. Start blogging about it.

Deliver Your Message

Promote your solution to others without treating them as enemies; instead, invite them to participate. To successfully win their support, a few things are essential:

• Be a Person, Not a computer: People have emotions. Simply pointing out that their current approach is wrong does not facilitate effective communication; in fact, it does more harm than good. Instead of telling them they are wrong, frame it around how this tool or method brings greater efficiency and productivity.
• Passion: You should want to introduce new tech because it makes workflows simpler and faster for everyone, not just because you find it more comfortable to use.
• Suggest rather than command, e.g., “Have you considered using…?”
• Listen first: Some team members might have already tried different solutions in the past. Ask about their experiences before taking action. For example, when introducing CI, I found out the team had tried CircleCI before abandoning it. Upon asking, I learned that using the company’s internal CircleCI server required a tedious permission request process.

Actionable Steps

• Practice your pitch.
• Try listening to what you say—if you were on the receiving end, would you be convinced?

On a side note, working in Japan has taught me that speaking the other person’s language makes your proposal far more convincing. Pitching the exact same solution in Japanese is much more persuasive than doing it in English because it’s easier for them to digest.

Demonstrate Your Technique

Directly showing results is far more effective than just talking or presenting plain text. Giving a presentation, doing live coding, or building a POC are all great ways to do this.

People believe what they are shown more than what they are told

How do you find the right timing? You can schedule a casual session to gather everyone together, or demonstrate your solution during a Code Review.

Propose Compromise

Sometimes compromise is necessary. You might not be able to get 100% of what you originally wanted, but you can at least reach a viable middle ground.

Create Trust

This is perhaps the hardest technique among those mentioned, because trust isn’t something you automatically earn just by checking off items A, B, and C. However, it offers tremendous leverage: once people trust you, driving technical change becomes significantly easier. While there is no single recipe for building trust, here are a few principles to keep in mind:

• Never lie.
• Have the courage to admit your mistakes.

Face-to-Face Discussions

Asynchronous online discussions can easily suffer from misunderstandings due to timing and context, making conversations drag out or stall. Over time, poor communication erodes patience and mutual trust. When this happens, consider switching to face-to-face communication to resolve the issue.

Some Strategies

• Ignore the Irrational: Debating them is a waste of breath because their sole intention is to derail your efforts to introduce new technology.
• Focus on those who are willing to help you.
• Ask for help when appropriate.
• Help your manager solve problems: As mentioned earlier, managers often push back because they don’t fully understand the tech. Therefore, frame your proposal around how much productivity it boosts and how many bugs it reduces.

Afterword

I’ve encountered similar situations at work before: sharing things I was passionate about with the team, only to be met with lukewarm indifference or even questioned why I spent weeks on such things. It felt thoroughly disheartening. I’ve also dealt with irrational colleagues who stubbornly believed only in their own tech and ways of doing things, making it hard to feel integrated into the team.

A former colleague happened to recommend this book. At just over 100 pages, I finished it in about a week during my commutes. Yet the insights and approaches it offers are exceptionally practical. I highly recommend giving it a read.

Change won’t happen overnight, and seasoned engineers might already know how to handle these situations.

Still, engineers sometimes shy away from learning how to communicate with people simply because it feels tedious or bothersome. But human factors play a massive role in collaboration. If you want a smoother career ahead, learning how to handle interpersonal dynamics is unavoidable.

This isn’t a quick-fix tutorial you can apply immediately after reading—building credibility and practicing these suggestions takes time. But if you use the right approaches and gradually let your passion and accountability shine through, the team will eventually be influenced by you.