Picking technologies for the teams we have (not the teams we want)

Peter Drucker once remarked that “dealmaking beats working.” It’s exciting, fun, romantic, and exciting, whereas working requires “grubby detail work.” Drucker then added “that is why you have deals that make no sense.”

He said this in the context of corporate M&A, not technology but I think some parallels apply there. Managing real IT work is hard. It requires intricate people moves and decisions in a field (information technology) that is immature relative to some professions. Dealing with that can be overwhelming so it’s a natural temptation to buy a product or buy a canned consulting offering. Sometimes that works. What can also happen is an organization spends the money on the product but is not able or willing to do a complete follow through on the “grubby detail work.” They then end up in a worse position than where they started because they’ve made some unattainable promises to go above and beyond the status quo they had.

Sometimes, the right answer, if it’s not the right time to really confront the “grubby detail work”, is to keep the technology you know or understand. It’s not pleasant or exciting to do that and there are certainly downsides to that approach but it might be more likely to avoid costly experiments that do not deliver. Perhaps the right thing to do is create some buy-in for at least a portion of the detail work/people changes and then pair that with the right product purchases?

Martin Fowler also addresses this topic on a more technical level when talking about NoSQL vs. relational databases in this video (see comments around 34:47 about most teams not being good). If we accept we do not have a “great team” as he calls it in the video, then it’s probably wise to pick tools that suit that team and focus my energy on either 1) using those tools to the max and/or 2) work on building the team to really change things.