What Tech Selection Skill Really Is — Not 'Choosing Well' but 'Turning Technology Into Organizational Power'

Recently I had a long conversation with Claude Code about technology selection.

It started with a fairly standard question — "how would you define tech selection skill?" — but as the dialogue continued, my thinking kept getting refined, and I landed in a completely different place from where I started.

I had assumed "tech selection skill = the ability to spot good technology." That turned out to be a pretty shallow understanding.

This article traces that dialogue process and organizes what I came to think about what tech selection skill really is. If you just want the conclusion, skip to the last section. But walking through the thought process together might give you more to work with.

The first definition — is tech selection about "setting evaluation criteria"?

The initial definition that came up looked like this:

All correct, technically. But reading it back, something felt off. "I understand what this says, but would this actually make a selection go well?" — that question lingered.

Things start to crack with "what causes failure"

I dug a little deeper: "What if the decision was rational at the time, but later turned out not to work — does that mean you lacked tech selection skill?"

The framing that came out was interesting:

"Decision quality" and "outcome quality" are separate things — like playing poker with correct probability and still losing.

But my gut pushed back: "If you're really thorough, does 'bad luck' actually happen that often?" I pressed on that.

"Bad luck" is mostly an excuse — skipping the process is the real cause

Looking back at my own experience making tech selections, I've had very few major failures. When I tried to articulate why:

I was following this kind of process.

And what I noticed: the "tech selection failures" people commonly describe almost always come from skipping these steps.

Failure from pure "bad luck" is, honestly, extremely rare.

Thinking about it this way, the earlier framing — "you can have a good process and still fail from bad luck" — doesn't quite fit technology selection. Tech selection has much less randomness than poker. Because these decisions are verifiable, process gives you near-complete control.

The "organizational resources" perspective

There are certainly areas where verification has limits: scale problems (issues at 100K users don't show up in small tests), time-horizon problems (maintainability degradation you can't see until year two or three).

My take on this: "Acknowledge the limits, step in anyway. When problems come up, wrestle the technology into a workable state. That's what organizational strength is."

If you only think about turning back, you can't move forward.

But there was a good counter-point: "the difference between technologies that are wrestle-able and those that aren't is often visible at the selection stage." Community depth, internal transparency, and so on. That rang true.

An even more important angle that emerged: how much resource slack exists within the organization. The same technology can be wrestled into shape with plenty of resources, but with none, retreat is the right call.

Evaluating the technology and evaluating your own organization — you need both before tech selection becomes meaningful.

Balance is what separates people

People who can't balance "what we want to do" and "what we can actually do" have higher failure rates, even with large-scale tech changes. People with that balance rarely fail, even on big changes.

This was something I'd felt intuitively, and it became a little clearer here.

Tech selection doesn't fail because you lack technical knowledge. It fails because the balance between "what you want" and "what you can handle" is off.

The accuracy of your estimates for organizational resources and response capacity improves with experience. "Tech selection skill grows with experience" is probably less about accumulating technical knowledge and more about improving this estimation accuracy.

As a side note, there are cases where stretching into slightly harder technology drives organizational growth — but that still comes down to "do you have the stamina to absorb the failure risk in advance?" The resource-dependent structure doesn't change.

The Resume Driven Development problem

"An engineer picked something purely out of personal interest, and it couldn't be operationalized or adopted" — this is a pattern I see regularly. The industry has recognized the problem and even named it.

Resume Driven Development

Choosing the technology you want on your resume. Motivated by increasing your market value.

Hype Driven Development

Heard at a conference, read on a blog, trending on social media — so we adopt it. "GAFA uses it" becomes justification.

There's a structural reason this happens:

In other words, the incentive to adopt and the responsibility to operate are separated. That's the root cause.

For my part, it's not that I lack interest in technology — I believe good things should be adopted. But I also feel that "choosing something the rest of the team can't follow will just not work."

Ultimately, my definition of "good" already includes whether the team can handle it. I'm not judging a technology in isolation — I'm judging it in our context.

What about existing frameworks?

Looking at frameworks that exist in the world:

Technology evaluation

Maturity assessment

Adoption and diffusion

Honestly, something bothers me about these. They're heavily biased toward "how to evaluate a technology" and have little to say about "how to make a technology stick as an organization."

Technology selection inherently spans software engineering, organizational theory, and business strategy — but academically, these are studied by different people in different contexts. That's a structural reason why integrated frameworks are hard to produce.

The purpose of tech selection is to produce business outcomes. Any systematization that doesn't integrate that dimension ends up with limited practical value.

The final definition

Putting it all together, the components of tech selection skill:

But listing these five still feels like "a list of items." There's one thing at the root:

Tech selection skill is not the ability to choose technology — it's the ability to turn technology into organizational power.

This is my current definition.

The goal isn't "choosing" but "making it yours." Not judging a technology in isolation, but meshing it with organizational reality and connecting it to business outcomes — that's the composite skill.

Closing thoughts

Compared to the first definition — "requirements fit, tradeoff judgment, risk estimation, communication" — the resolution has changed considerably.

The first definition treated tech selection as "a decision at a point in time" within the frame of "judgment to choose the optimal technology." But through this exercise, I came to see tech selection not as confined to the moment of choice, but as the organizational ability to drive the entire cycle: selection → validation → adoption → operation → correction.

On a slightly more personal note, I enjoy this kind of "re-questioning definitions" thinking. When you carefully re-examine something you thought was settled, you sometimes land somewhere entirely different. Introspection and engineering are surprisingly similar in that way.

Further reading

If you want to go deeper on architecture decision-making and the intersection of technology and organizational leadership, these books are good starting points.