In the past whenever I’ve tried to solve a technical problem, the first thing I would do is find the right tool for the job. I would then test that tool against the known use cases, share it with others in the organization, and see if excitement warrants further consideration. If we’re spending a lot of money, the vendor will get involved and help push everyone toward a decision to go with the tool.

The phase is so exciting, so full of promise…

And often completely misguided.

Instead of starting with the tool, I’ve learned that I need to start with the business and the problems its leaders face. Once we all agree to the problems and have a clear, shared, measurable view of those problems, we can then determine the right tool for the job.

Recently I was in a meeting about Chef with a colleague who is not very interested in adopting Chef for his project. He doesn’t see how Chef fits with his operational goals for next year. He was talking about his main pain points being the greater need for operational visibility into his entire stack of hundreds of nodes. So I asked him, “what if we helped you solve that problem with a greater focus on monitoring?” He paused and said to me “I thought this meeting was about Chef.”

Once the meeting and discussion becomes about the tool, you’re no longer having the right conversation. Start with the problems, and find good solutions that fit those problems. Repeat.