Lately, in addition to purely technical books, I have started reading some books on soft skills. This book is one of the most impactful ones I have read recently. Typically, books on management and leadership rarely discuss what to do when your colleagues reject your proposals. It can be difficult to reason with them, and it often leads to a vicious cycle.
In software development, it is common to encounter situations where technologies become outdated or no longer suitable, and there arises a desire to change the technical stack, frameworks, or deployment methods.
However, convincing the entire team to accept your ideas often requires many challenges. You may find yourself investing a lot of passion, thought, and time into "evangelizing," only to be ignored by the team or even seen as wasting your time.
Even though the technology may not be ideal and bugs may be abundant, as long as things are somewhat manageable, people may resist change, and over time, you may become a dispassionate engineer who settles for mediocrity.
This book identifies several patterns for dealing with people who resist change. Although it is not something that can be immediately applied after reading it once, I find it more "real" compared to other soft skills books because such situations are more common in the workplace, where effective communication is not always guaranteed.
The act of persuading others to accept your ideas is not limited to the field of software development; it happens in other domains as well, but it is more frequent in software development. Sharing your ideas with the team is often not about planning first and then taking action, but rather expressing your preferences or opinions naturally.
However, people come in different types, and not everyone is enthusiastic about your ideas for introducing new technologies or replacing outdated ones. You may be doing something great for the entire team, but not everyone will recognize it.
Therefore, the key is how to promote your ideas. When your passion and desire for change spread throughout the team, it becomes easier to gain support from other team members. This book provides many effective strategies and suggestions.
Seven Types
This book categorizes people who resist change into seven types:
-
The Uninformed: They lack knowledge about relevant technical topics.
-
The Herd: They go with the flow and have no specific stance.
-
The Cynic: They are religiously fanatical, and the book describes them aptly:
They're that kid in college who always asked your professors annoying questions to show how smart they are.
They like to explore various technologies superficially and use strange stories or experiences to intimidate you.
-
The Burned: They are radicals. Due to past failed experiences, they strongly oppose certain technologies or frameworks and prefer to stick with existing solutions.
-
The Time Crunched: They lack time to learn new knowledge or technologies.
-
The Boss: Your superiors. They reject your proposals often because they lack technical understanding.
-
The Irrational: They will find ways to reject your suggestions. As soon as one argument fails, they move on to the next. They are a combination of the aforementioned types. The best way to deal with irrational people is to ignore them directly.
Preparatory Work: Defining Problems and Solutions
Before introducing new technologies, it is crucial to define the problems and solutions to ensure that you are addressing the right issues. For example, if you want to introduce an automated deployment solution, can it actually solve the current problems? Or if you want to adopt a Single-Page Application (SPA) architecture due to complex page states, can it effectively address the complexity?
Before introducing a technology, it is essential to clearly define the problem and the desired goals. This not only helps determine whether introducing a new technology is beneficial but also prepares you for potential doubts and similar thoughts from colleagues and superiors.
You Might Be Wrong
Everyone makes mistakes, so when facing skepticism, don't assume that the other person is hindering you (at least not initially). They may have their own considerations. When I introduced automated deployment, I once asked my colleagues why we should use the compiled hash as a git tag instead of a corresponding version number. Couldn't we use version numbers instead? It turned out that tracking the hash was the method used in the past. As a result, I slightly modified the approach, enabling the automated deployment system to record the compiled hash automatically. This change successfully gained support from my colleagues.
Some Techniques
For each type of person, the book provides techniques to deal with them.
Gain Expertise
Before introducing a technology or tool, make sure you have sufficient understanding of it so that you can address others' questions. Merely skimming through documentation and Q&A is not enough; you need to have a solid grasp of the technology. To achieve this, you can:
- Seek out other experts.
- Teach others.
- Use it in your own projects.
Practical Actions
- Read the complete documentation.
- Explore how people discuss the technology in relevant technical forums and see if you can answer their questions.
- Start writing a blog about the technology.
Deliver Your Message
Recommend your solution to others, but don't perceive them as enemies. Instead, invite them to participate. To successfully gain support, the following things are important:
- Be a Person, Not a Computer: People have emotions. Pointing out that someone's current solution is wrong is not an effective way to communicate; it can be counterproductive. Instead of directly telling them they are wrong, emphasize how a particular tool or method can be more efficient and productive.
- Enthusiasm: Your desire to introduce new technology should stem from its ability to simplify and accelerate the work process, rather than just personal preference.
- Replace commands with suggestions, such as: "Have you considered xxx?"
- Listen first: There may be team members who have tried different approaches. Before taking action, ask about their experiences. For example, when introducing Continuous Integration (CI), it was discovered that many had previously used CircleCI but later abandoned it. By inquiring, it was revealed that obtaining permission was required to use the company's internal CircleCI server.
Practical Actions
- Practice how to pitch your ideas.
- Try to listen to what you say. If someone else said it, would you be convinced?
Additionally, I would like to add that I am currently working in Japan. To make your proposals more convincing, it helps to speak the language of your audience. For example, presenting the same proposal in Japanese can be more persuasive than in English because it is easier for the other person to understand.
Demonstrate Your Technique
Demonstrating the results directly, rather than just speaking or relying on written text, is the most straightforward method. You can create presentations, perform live coding, or create a proof of concept (POC), among other approaches.
People believe what they are shown more than what they are told.
But how do you find the right opportunity? You can schedule a time for everyone to gather or demonstrate your solution during a code review.
Propose Compromise
Sometimes, finding a compromise is necessary. You may not be able to proceed exactly as you envisioned, but you can still find a balanced solution.
Create Trust
This is one of the more challenging aspects among the mentioned techniques because building trust is not easily achieved. It is not something that can be accomplished simply by following steps A, B, and C. However, it has significant benefits. Once someone trusts you, it becomes easier to drive technical changes. While there is no specific method to build trust, there are a few principles to consider:
- Don't lie.
- Be willing to admit mistakes.
Face-to-Face Discussions
Online discussions (asynchronous) often hinder clear expression of ideas due to time and environmental constraints. This can make discussions difficult, and over time, both sides may lose patience or trust in each other. In such cases, face-to-face communication can be considered to resolve the issues.
Some Strategies
- Ignore the irrational ones (The Irrational) because debating with them is often futile; they simply want to hinder the introduction of new technology.
- Focus on those who are willing to help you.
- Seek assistance when needed.
- Help your superiors solve problems: As mentioned earlier, superiors often reject proposals because they lack technical understanding. Therefore, discussing the productivity improvements and bug reduction achieved through your proposed solution can be effective.
Afterword
I have encountered similar situations in the workplace before. I enthusiastically shared my ideas with the team, but they showed little interest and even questioned why I spent weeks working on such matters. I felt quite discouraged at that time. I have also encountered colleagues who resemble the aforementioned irrational type, firmly believing in their own technologies and ways of doing things, making it difficult for me to fit into the team.
Coincidentally, a former colleague recommended this book. With just over 100 pages, I finished reading it during my commuting time in about a week. The content and methods presented are practical, and I highly recommend everyone to read it.
Change does not happen overnight, and engineers who have been in the workplace for a long time may already know how to deal with such situations. However, sometimes engineers avoid learning how to communicate with people due to the trouble and laziness it entails, without realizing that collaboration is a significant factor. If you want a more relaxed career in the future, you have to learn how to handle interpersonal matters.
This book cannot be immediately applied after reading it; accumulating credibility and practicing the suggestions takes time. However, with the right approach, gradually showcasing your passion and sense of responsibility, the team will eventually be influenced.
