I Want to Bring a New Tool to My Team.

The dev world moves fast. A tool or approach that’s been the “trend” for a decade can turn into legacy overnight. Developers are drawn to new things almost by instinct, and everyone’s probably wanted to run a project differently from how the team usually does it at least once. But bringing something new in means getting your teammates on board, and that can go smoothly or turn into a long argument.

None of this is meant to take sides, and it’s not an argument for chasing the latest trend either. It’s just some thoughts on the friction a developer runs into when trying to bring something new onto a team project, and what that friction actually means.

First, Examine Your Own Argument

Before you push for a new tool on your team, ask yourself honestly: is this really about solving your team’s pain, or are you just curious about the tool? If it’s curiosity, that’s fine — just keep it at “hey, check this out” instead of turning it into a full adoption pitch. Pushing for adoption before you’ve separated curiosity from an actual need feels risky.

We’re a Team Because We Think Differently

Say you’re confident it’s a real problem and not idle curiosity, so you pitch it: “Adopting A solves problems 1, 2, and 3 we’re dealing with right now, makes writing tests easier, and brings a bunch of other benefits.”

The bigger the team, the less likely everyone is to nod along right away.

Obviously, because people think differently. Some will focus on the upside of A, same as you did. Others will think the payoff isn’t worth the learning cost, or push back with “sure, A helps, but it also creates problems 1 and 2.”

You might have had your eye on this structure or library for a long time, weighing whether to bring it into the product — but that’s a conversation you had alone, with yourself. You still have to weigh the payoff against the learning curve, and take the downsides just as seriously.

All of this is completely normal, and a good team is one that talks it through and finds common ground.

No tool is 100% perfect. Before you argue for one, you need to be sure that, downsides and learning curve included, it can actually solve your team’s problems and pay off down the road.

What Approach Do We Need?

Anything new takes time to land. That might mean pair programming, or a well-written doc, or a presentation. If you want people to actually buy into your opinion, you also need to spend time figuring out the most effective way to make your case.

Nobody opposes something for no reason. They might just not know the tool, or not be convinced it’s worth the effort to learn, or it might simply be hard. If someone already believes the current approach solves things well, then whatever you’re proposing just reads as “new, and a hassle to learn.” Whatever the reason is, you need to understand it, and persuade them while treating them as a colleague.

Going through that process of persuasion is also a good way to test whether the knowledge you assumed was solid actually has gaps.

So what do you do if you’ve empathized, made your case, and it still isn’t landing? Take another look at whether your argument actually holds up, and if nothing changes even then, that’s the point where you need an ally.

모든 걸 한 번에 바꾸려 했다가는 반란이 일어날 것이다.
반란이 일어나면 어렵게 얻은 신뢰를 잃고 모든 노력이 수포가 된다.
감당할 수 있는 변화의 속도는 팀에 따라 다르다.
모두에게 '완벽한 변화'를 강요하지 마라. '아군'을 모집해서 주장의 타당성을 인정받는 게 중요하다."

- 심플 소프트웨어 Chapter 18~19 내용 中-

Agreeing with you doesn’t make someone an “ally,” and disagreeing doesn’t make them an “enemy.” If you insist on getting everyone’s buy-in, you can easily lose sight of the actual point — the improvement you were after in the first place. Ideally, you win allies who back your argument, and through that, they help cover the ground you can’t cover alone. And sure, sometimes that whole process ends with you realizing your opinion wasn’t actually right.

What matters most is letting go of the need to be right, and staying focused on the “essence” of the matter.

Reflecting on the Outcome

Once you’ve actually gone through the process of pitching and adopting something new on the team, it’s worth reviewing both the technology and the process.

Technical Retrospective

Every decision looks a little regrettable in hindsight. It might have been the right call at the time, but that doesn’t mean it still looks right later. For example, I used to think managing state separately just meant “keeping View and Data apart and designing business logic safely,” but looking back, that doesn’t really line up with the “single source of truth” idea.

New experiences and environments widen your thinking and shift your perspective. Watching how your future self judges your past decisions is its own kind of growth. And if a tool or approach you fought hard to introduce turns out, in hindsight, to have been the wrong call, sharing that with the team is how you grow together.

Process Retrospective

Look back at how you handled the negotiation with a teammate who disagreed. Was that strategy really the best one, or was it just stubbornness dressed up as a pursuit of “something better”? The team growing and solving problems in better ways matters, sure. But something matters even more: not losing trust between teammates.

Wrap-up

Bringing something new onto a team is never easy. Everyone values different things, and that “difference” isn’t “wrongness.” I think it’s through discussing the team’s direction and reaching agreement on something new that everyone gets to “grow together.”