單靠技能不足以提升競爭力

Learn another programming language. Master a new framework. Get better at using AI agents. Automate more tasks. Build faster. Ship more.

That's pretty much what we keep hearing about becoming a better developer.

And to be fair, it works. We have tools today that allow a single developer to accomplish what once required an entire team. Projects that used to take months can sometimes be built in weeks or even days.

But there's something interesting about this race toward productivity.

We see more projects, more applications, and more people delivering impressive amounts of work. Yet many of these supposedly massive achievements end up looking remarkably similar. The tools are getting more powerful, but the difference between having powerful tools and producing something genuinely valuable isn't always obvious.

Being able to produce more doesn't automatically mean being able to accomplish more. And sometimes, the problem isn't your skills or your tools at all. You can be skilled and still get nowhere

Imagine you're working on a feature.

You understand the requirements. You know the architecture. You have the right tools and enough experience to implement it. Except you need access to a database.

That requires approval from another team. Once you get access, you discover the documentation is outdated. Then you realize the service you need doesn't expose the expected API. You ask someone for clarification, but they're busy.

Suddenly, something that should have taken an afternoon takes three days. Did you become a worse developer? Of course not.

You spent most of your time fighting with an environment that wasn't ready to support the work.

We often associate performance with individual abilities: how much someone knows, how quickly they code, or how many problems they can solve independently. But your ability to do something and your ability to actually get it done are two different things. The second depends on much more than you.

Where Work Enablement comes in

Work Enablement starts with a different question. Instead of constantly asking how we can make someone more productive, we ask whether the environment actually allows them to be productive.

• Are the tools connected?
• Is information accessible?
• Are responsibilities clear?
• Can decisions happen without unnecessary delays?
• Does the workflow allow people to move forward without constantly stopping to resolve something unrelated to the task?

This is not about having any additional tools. This is about ensuring that the tools, processes, information, and people can all work together.

A powerful development environment means little if every deployment requires manual intervention. An AI agent won't help much if the information it needs is inaccessible or unreliable.

Improving a person's capabilities without improving the conditions around them can leave their actual performance unchanged.

That's an important distinction when we're constantly encouraged to learn more, automate more, and move faster.

Your team doesn't run at your speed

This becomes even more obvious when working in teams. You might be able to finish your part in two hours, but if the next step requires an approval that takes two days, the workflow still takes two days.

You can optimize your code, automate your tests, and become incredibly efficient at your own tasks. None of that necessarily removes the bottleneck. In software development, we already understand this principle. Optimizing a component doesn't guarantee better performance for the entire system.

Organizations work in much the same way.

But improving a workflow isn't as simple as removing approvals or automating every handoff. Some constraints exist for good reasons. And changing one process without considering the people who depend on it can create entirely new problems.

That's why optimizing work requires understanding the relationships between its components, not just making each component faster.

Don't confuse adapting with improving

There's another problem with difficult environments. Eventually, you get used to them.

You learn who to message when something breaks. You memorize undocumented procedures. You maintain personal scripts to fix recurring problems. You become the person everyone contacts because you know how to get around the system.

It feels like experience. And in some ways, it is. But you're also developing skills specifically to compensate for an environment that doesn't work properly.

Some of that knowledge disappears the moment you change teams or companies. Worse, the organization may never notice the problem because experienced employees have become so good at hiding it.

When getting work done requires more knowledge of the obstacles than of the work itself, something needs attention.

This doesn't mean every difficulty is an environmental problem. Skills still matter. Learning still matters. Taking responsibility still matters. But there is a difference between developing your abilities and becoming better at navigating unnecessary friction.

Maybe productivity isn't the first thing to optimize

We spend a lot of time discussing how developers can become faster, more knowledgeable, and more competitive. Those conversations are valuable.

But before adding another tool, learning another framework, or introducing another automation, it may be worth looking at what actually slows the work down.

Not every performance problem needs a better developer. Sometimes it needs a better environment.

That's the foundation of Work Enablement, one of the axes of the Power Series: understanding how the conditions surrounding work determine whether individual capabilities can actually produce results.

And it raises a question worth exploring further: If our tools and skills keep improving, why do so many of the same obstacles keep slowing us down?

Dive Deeper: Read the full, unabridged analysis on Work Enablement: Performance Is In Context.