Whenever someone proposes a process change, or forces me to switch to a new tool, I send a variation of this email to them. In this post I use the example of Dropbox Paper, but you can pick any other shiny tool.


I think we need to write a detailed doc every time we propose a process change. Like if we are pushing for adoption of a new tool we should write a pitch doc with a strong WHY (the need), WHAT exactly is part of the switch, and HOW we will measure success. For most of us, google doc was working fine and I am yet to understand what the move to Dropbox Paper helped us achieve.

If the document makes sense, and a lot of end users [the unfortunate few who will have to use this new tool] agree with the upside and downside, then only it should be adopted. Note: There is a huge switching cost associated everytime we move to a new tool or process.

And regarding success metrics, I sincerely believe that tool improvements/upgrades are more about downside protection than upside maximization. 

Example. Moving to Jira from Google sheets might help a good team track bugs better, but it won’t help a dysfunctional team improve its shipping velocity from 2 months to 2 weeks. 

Also, I am yet to see someone’s communication become 10X better because they started writing on Dropbox Paper vs Google docs.

As a team, we should focus more on better processes and less on tools.


P.S If you have worked for as many companies as me, you might have seen your own share of process/tool changes just because someone in management has shiny tool syndrome.