Nobody writes the article arguing for waiting. It is frequently the correct decision and it is never the exciting one.
Adopting a system to fix a process you cannot describe encodes the confusion. You end up with the same ambiguity, now in software, and harder to change.
Write the process first. Sometimes that is the whole fix.
Some problems are a capacity problem, a delegation problem, or a founder who has not let go of something. Software does not resolve any of those, and buying it delays diagnosing them.
Firms underestimate implementation load badly. Two concurrent projects in a small firm means two half-projects, and the second one usually stalls where it is most disruptive.
Finish one.
The cost of adopting something is not the licence. It is the attention, and you have one supply of that.
Specifically: what will your firm stop doing. If nothing stops, you have added a system rather than replaced work.
Every added system adds a seam. That is a real cost against an unspecified benefit.
Three days of demonstrations produces genuine enthusiasm and a bad decision-making environment. Anything that seems obviously necessary at a conference should be re-evaluated two weeks later, at your desk, against your actual list.
Much of it survives that test. Some of it does not, and that is the point.
Waiting has a cost too. A firm that never adopts anything accumulates a different kind of debt.
The argument is not for inertia. It is for the decision being yours rather than the calendar's.
Read next
What to automate first →