Driving Technical Change

Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should

Recently, besides purely technical books, I’ve started exploring some soft skills literature. This particular book has resonated with me the most among my recent reads. Typically, books on management and leadership rarely provide guidance on what to do when colleagues reject your proposals. It can feel frustrating when logical reasoning fails, leading to a vicious cycle.

In development, it’s common to encounter outdated or inappropriate technologies, prompting thoughts about changing tech stacks, frameworks, or deployment methods.

However, getting the entire team to accept your ideas often requires significant effort. You may invest a lot of passion, thought, and time into "evangelizing" your approach, only to find that the team completely ignores you or wonders what you’re busy with.

Even if the technology is cumbersome and bugs are rampant, as long as everyone can manage, there’s little motivation for change. Over time, you may find yourself becoming a dispassionate engineer, just going through the motions and writing mediocre code.

This book summarizes several patterns for those who resist change. While it’s not a manual that you can apply immediately after reading, I believe it’s more authentic than many soft skills books, as you’re more likely to encounter such situations in the workplace rather than everyone communicating effectively.

Persuading others to accept your ideas is a challenge not only in software development but in other fields as well, albeit more frequently in tech. Often, conveying your thoughts to the team is not about planning first and then acting, but rather about naturally expressing preferences or opinions.

However, people come in many types, and not everyone will welcome your technological innovations. You might work hard to do something great for the team, but others may not agree.

Thus, how to promote your ideas becomes crucial. When your passion for change spreads throughout the team, it’s easier to gain support from other members. This book offers numerous effective practices and suggestions.

Seven Types of Resistors

The book categorizes those who resist change into seven types:

• The Uninformed: They lack knowledge of relevant technologies or topics.

• The Herd: They are conformists, going along with the flow without a specific stance.

• The Cynic: Described in a particularly relatable way in the book,

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

  They tend to explore technologies superficially, using odd stories or experiences to intimidate you.

• The Burned: These are the radicals who hold strong opposition to a technology or framework due to previous failures, preferring to stick with existing solutions.

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

• The Boss: Your supervisor may reject your proposal simply because they don’t understand the technology.

• The Irrational: They go to great lengths to reject your proposals; if one argument doesn’t hold, they quickly switch to another. They embody a combination of the above types. The best way to deal with the irrational is to simply ignore them.

Preparation: Define the Problem and Solution

Before introducing new technology, it’s crucial to define the problem and the solution to ensure you’re addressing the right issues. For example, if you want to implement an automated deployment solution, will it actually resolve the current problems? Or if you wish to introduce a Single Page Application (SPA) architecture due to complex page states, will it effectively tackle the issue of complexity?

Before adopting new technology, clarify the problems and the goals you aim to achieve. This not only helps in deciding whether to introduce new technology but also prepares you for potential questions from colleagues and supervisors, who may have similar concerns.

You Might Be Wrong

Everyone makes mistakes. Therefore, when faced with skepticism, don’t assume that the other person is obstructing you (at least initially). They might have their own considerations. When I first introduced automated deployment, I asked a colleague why we should use the compiled hash as a git tag instead of a corresponding version number. Upon inquiry, I learned that this was a method for tracking the hash, which led me to slightly modify the process to automatically record the compiled hash, ultimately gaining my colleague’s support.

Some Techniques

The book provides techniques for dealing with each type of person.

Become an Expert (Gain Enterprise)

Before introducing a technology or tool, ensure you have a solid understanding of it to address others' questions. Merely skimming the documentation and FAQs isn’t enough; you need to grasp the technology thoroughly. To achieve this, you can:

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

Action Steps

1. Read the entire documentation.
2. Explore how people discuss this technology in relevant forums and see if you can answer their questions.
3. Start writing a blog about this technology.

Promote Your Message (Deliver Your Message)

Present your proposal to others without viewing them as adversaries; instead, invite them to participate. To successfully gain their support, several key factors are important:

• Be a Person, Not a Computer: People have emotions. Simply pointing out that another's solution is wrong won’t facilitate effective communication; it can be counterproductive. Rather than directly telling someone they’re wrong, demonstrate that this tool or method is more efficient and productive.
• Enthusiasm: You want to introduce new technology because it simplifies and speeds up work processes, not just because it’s more comfortable for you.
• Use suggestions instead of commands, like: “Have you considered xxx?”
• Listen First: Some team members may have used different solutions; ask about their experiences before taking action. For example, when introducing CI, I discovered that everyone had previously used CircleCI but had abandoned it due to needing permission to use the company’s CircleCI server.

Action Steps

• Practice your pitch.
• Try to listen to what you’re saying. If you were in someone else’s position, would you be persuaded?

Additionally, I want to emphasize that currently working in Japan, speaking the other person's language can make your proposal more convincing. Presenting the same solution in Japanese can be more persuasive than in English, as it’s easier for them to comprehend.

Demonstrate Your Technique

Demonstrating results is often more effective than mere words or text. You can create presentations, perform live coding, or develop a proof of concept (POC) as excellent approaches.

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

So, how do you find the right moment? You can find a time to gather everyone or showcase your solution during a Code Review.

Propose Compromise

Sometimes, seeking a compromise is necessary. You may not be able to implement your ideal solution 100%, but you can at least find a balanced approach.

Create Trust

Building trust is one of the more challenging aspects of the techniques mentioned above, as it’s not easily achieved. Simply completing A, B, and C doesn’t guarantee trust. However, once established, trust greatly facilitates driving technological change. Though there’s no specific method to build trust, here are some principles to consider:

• Don’t lie.
• Be willing to admit mistakes.

Face-to-Face Discussions

Online discussions (asynchronous) often suffer from time and environmental factors, making it difficult to express thoughts clearly. This can lead to a breakdown in communication, causing both parties to lose patience and trust over time. In such cases, consider face-to-face communication to resolve issues.

Some Strategies

• Ignore the Irrational, as debating with them is usually futile; they merely want to obstruct your introduction of new technology.
• Focus on those willing to help you.
• Seek assistance when appropriate.
• Help your boss solve problems: As mentioned earlier, supervisors often reject proposals due to a lack of understanding. Therefore, present how your solution increases productivity and reduces bugs.

Conclusion

I’ve encountered similar situations in the workplace, sharing my enthusiastic ideas with the team, only to find them disinterested or questioning why I spent weeks on such matters. I felt quite frustrated. I’ve also dealt with colleagues who are irrational, firmly believing in their own technologies and methods, making it challenging to integrate within the team.

A former colleague recommended this book, and I finished it in about a week during my commutes, as it’s just over 100 pages. The content and methods discussed are very practical, and I highly recommend it.

Change doesn’t happen overnight. Engineers who have been in the workforce for a long time might already know how to handle such situations.

However, engineers sometimes avoid learning how to communicate with others due to inconvenience or laziness, not realizing that collaboration heavily involves interpersonal dynamics. If you want a smoother career in the future, you must learn how to handle people effectively.

This isn’t a manual that you can apply immediately after reading; building credibility and practicing the above suggestions takes time. But with the right approach, gradually showcasing your passion and sense of responsibility will eventually influence your team positively.