There is a tempting idea spreading through engineering organizations: if AI can make developers dramatically faster, the main challenge is getting everyone to use it.

Find the right coding assistant. Add the right workflow. Introduce the latest agent. Measure usage. Compare productivity. Repeat.

But that puts the technology at the center of a problem that is much bigger than technology.

AI can help people write code faster. It can generate tests, explain unfamiliar systems, automate repetitive tasks, analyze information, and help teams move through certain types of work more quickly.

What it cannot do is repair an organization where people do not trust each other, priorities constantly change, decisions require unnecessary approval, teams blame one another, or employees are afraid to tell leadership that something is going wrong.

In fact, AI can make those problems more visible.

And sometimes it can make them move faster.

The more important question is therefore not simply whether your team is using AI.

It is whether your organization is healthy enough to benefit from it.

Imagine giving a highly capable AI tool to two engineering teams.

The first team has clear ownership, strong communication, reasonable autonomy, good technical foundations, and a culture where people can challenge decisions without worrying about punishment.

The second team has unclear responsibilities, competing priorities, weak communication, constant approval requirements, and people who are reluctant to raise problems.

Both teams have access to exactly the same technology.

The results are unlikely to be the same.

The first team can use AI to remove repetitive work and spend more time on meaningful decisions. Engineers can share what they discover, experiment with new workflows, and help each other improve.

The second team can use AI to generate more code that nobody has clearly decided should exist.

That distinction matters.

Productivity is not simply the amount of work produced. More output is not automatically more value.

If a team is building the wrong feature, writing twice as much code does not solve the problem. If architecture is already difficult to maintain, generating code faster can increase the amount of complexity that eventually needs to be managed. If teams do not communicate, accelerating individual work can create more integration problems downstream.

AI changes the speed of execution.

It does not automatically improve the direction.

Tip: Before measuring whether AI makes the team faster, make sure the team is clear about what it should be building and why.

Conway's law offers a useful way to think about this.

The principle is commonly summarized as the idea that the systems organizations build tend to reflect the communication structures of those organizations.

That means the way people work together can eventually show up in the systems they create.

When teams communicate well, responsibilities are clear, and people collaborate effectively, those patterns can support better technical outcomes.

When teams operate in silos, constantly hand work across organizational boundaries, or avoid difficult conversations, those problems can appear in the resulting systems too.

Now add AI.

A tool that increases the speed of execution does not know whether the underlying organizational behavior is healthy.

It simply helps people execute.

If the team has a good process, that can be valuable.

If the team has a broken process, the organization may simply become more efficient at producing the consequences of that broken process.

That is why AI adoption cannot be separated from organizational design.

Technology may change how quickly work happens.

Culture influences how people decide what work deserves to happen in the first place.

Tip: When introducing automation, examine the process being automated first; removing friction from a bad process can simply produce bad outcomes faster.

Few messages are more damaging to an engineering culture than:

“We can build this now with AI, so we don't need as many people.”

Even when leadership intends to communicate efficiency, employees can hear something very different:

“Your contribution may no longer matter.”

That changes behavior.

People become less willing to experiment. They become more cautious about sharing ideas. They may avoid admitting mistakes. They may begin optimizing for self-protection instead of organizational outcomes.

Psychological safety suffers.

And once that happens, AI adoption can become even harder.

People may technically use the tools while avoiding the experimentation required to discover where they actually provide value. They may hide uncertainty rather than ask for help. Teams may compete over who appears most productive instead of sharing what works.

A much healthier message is simpler:

Great engineers have always adopted tools that help them do better work. AI is another tool. Learn it, experiment with it, and use it where it improves the work.

That framing keeps the emphasis on capability rather than replacement.

It also recognizes something important: technology changes, but the responsibility to produce good outcomes remains with people.

Tip: Talk about AI as a capability that helps people do better work, not as a threat hanging over the people expected to adopt it.

Another common mistake starts with a headline.

A company says its developers became dramatically more productive after adopting a particular AI tool.

Leadership sees the claim.

Then comes the question:

“Why aren't we seeing the same results?”

That question can quickly become pressure on engineering teams.

But productivity claims need context.

Who measured the improvement?

What work was being measured?

Over what period?

Was the comparison based on output, cycle time, completed tasks, revenue, quality, or something else?

Was the company selling the AI product being discussed?

Was the claim based on a controlled comparison or an internal estimate?

Without that context, a dramatic productivity number tells you very little about what another organization should expect.

This is especially important because companies promoting AI products have commercial incentives to emphasize successful outcomes.

That does not automatically make the claims false.

It does mean the incentives behind a claim are worth examining.

If a company says its product created extraordinary gains, the useful response is not immediate disbelief or immediate adoption.

The useful response is curiosity.

Understand the measurement.

Understand the baseline.

Understand the conditions.

Then determine whether those conditions exist inside your organization.

Tip: Whenever you hear an extraordinary productivity claim, ask who measured it, how it was measured, what changed, and what incentives the source has.

AI does not operate in a vacuum.

It works inside your architecture, processes, teams, documentation, permissions, development practices, and decision-making systems.

That means the quality of the environment around the tool matters.

Consider an organization with clear technical standards, useful documentation, understandable ownership, and consistent engineering practices.

An AI system working inside that environment has better material to work with.

Now consider the opposite.

Documentation is outdated. Ownership is unclear. Architecture has accumulated years of inconsistent decisions. Teams use different practices. Nobody knows which system is authoritative.

Adding AI does not magically clean that up.

The tool may actually increase the volume of work happening on top of those weaknesses.

This is why AI adoption should not be treated as a standalone tooling project.

The surrounding system matters.

Good architecture gives engineers and AI better boundaries.

Clear processes reduce unnecessary decisions.

Good documentation provides useful context.

Strong communication helps people share what they learn.

Trust makes experimentation safer.

The technology benefits from all of these things.

Tip: Improve the environment around AI—architecture, documentation, ownership, processes, and communication—rather than expecting the tool itself to fix those weaknesses.

One of the easiest metrics to misunderstand is AI adoption itself.

You can measure how many people use a tool.

You can measure how many prompts they send.

You can measure how many AI-generated pull requests appear.

You can measure how frequently an agent is used.

But none of those numbers automatically tell you whether the organization is performing better.

A team could dramatically increase AI usage while producing little additional business value.

Another team might use AI selectively and achieve significant improvements because it applies the technology to the right problems.

That distinction is important.

The objective should not be to make every employee use AI as much as possible.

The objective should be better outcomes.

Maybe AI reduces the time required to investigate a production issue.

Maybe it allows engineers to spend less time writing repetitive code and more time improving architecture.

Maybe it helps a team test more ideas before committing to one.

Maybe it reduces the administrative work surrounding development.

Those are meaningful improvements because they connect the technology to actual work.

Usage is merely an activity.

Outcomes are what matter.

Tip: Measure AI by the problems it helps solve and the outcomes it improves, not simply by how often people use the tool.

AI changes too quickly for adoption to be a one-time executive decision.

New models appear. Tools change. Agents improve. Capabilities expand. Workflows that seemed impractical six months ago can become useful.

That makes bottom-up learning particularly important.

The people closest to the work are often the ones who discover where a tool is genuinely useful.

One engineer may find a better debugging workflow.

Another may discover that an AI assistant is excellent for test generation but unreliable for a particular architectural task.

Someone else may develop a useful process for reviewing generated code.

That knowledge needs to circulate.

Leadership can establish direction and boundaries, but the organization also needs a continuous exchange of practical knowledge between the people actually using the tools.

Forcing adoption from the top can create compliance without learning.

People may use the tool because they were told to, while never developing the judgment needed to know when it should or should not be used.

That is not meaningful adoption.

Tip: Give teams room to experiment, share successful workflows, document failures, and teach one another instead of treating AI adoption as a top-down rollout.

This is the deeper point.

AI is powerful partly because it can multiply the capabilities of people.

But multiplication works in both directions.

If you start with strong collaboration, AI can help that team move faster.

If you start with clear ownership, AI can help people execute more independently.

If you start with good architecture, AI has a better technical environment in which to operate.

If you start with thoughtful decision-making, AI can help accelerate exploration and implementation.

But if you start with distrust, confusion, poor communication, and unclear priorities, AI does not automatically remove those weaknesses.

It can amplify them.

That is why culture is not a soft issue sitting on the side of technology strategy.

It is part of the productivity system.

A healthy culture gives people permission to experiment, question assumptions, admit mistakes, and share what they learn. It makes teams more capable of using new technology responsibly because people are not constantly worried about protecting themselves.

And the signs are surprisingly practical.

Do people know what they own?

Can they make reasonable decisions without unnecessary approval?

Can they challenge leadership?

Do teams trust one another?

Are priorities clear?

Can people disagree without turning disagreement into conflict?

Are outcomes rewarded?

Do people understand why they are building something?

When something fails, does the organization look for the cause or immediately look for someone to blame?

Those questions tell you more about the foundation for AI productivity than another list of AI tools.

Tip: Diagnose the culture before diagnosing the technology because the quality of the organization determines how effectively new tools can be used.

The most useful question is not:

“How do we get everyone to use AI?”

It is:

“How do we build an organization where talented people can do their best work, and then use AI to multiply what they can accomplish?”

That changes the entire conversation.

Instead of starting with tools, start with people.

Instead of starting with usage targets, start with business outcomes.

Instead of starting with replacement, start with capability.

Instead of asking how much work AI can remove from a team, ask what valuable work the team could accomplish if repetitive work became easier.

And instead of assuming fewer people automatically means greater efficiency, consider what additional capacity, ideas, expertise, and execution could become possible when capable people are given better tools.

AI can absolutely change productivity.

But the technology is only part of the equation.

The organization still needs clear priorities.

People still need to trust one another.

Managers still need to create psychological safety.

Engineers still need to make architectural decisions.

Teams still need to communicate.

Leaders still need to provide direction.

And someone still needs to decide what is worth building.

That is why the strongest AI strategy may begin with something that has nothing to do with AI.

Build an environment where good people can think clearly, challenge one another, make decisions, learn quickly, and take responsibility for outcomes.

Then give them better tools.

Because AI can make a good organization faster.

But a good culture is what gives that speed somewhere useful to go.

Tip: Build the organization you want AI to amplify before asking AI to make that organization faster.

What’s your next spark? A new platform engineering skill? A bold pitch? A team ready to rise? Share your ideas or challenges at Tiny Big Spark. Let’s build your pyramid—together.

That’s it!

Keep innovating and stay inspired!

If you think your colleagues and friends would find this content valuable, we’d love it if you shared our newsletter with them!

As the world becomes increasingly digital, this question will be on the minds of millions of people seeking new income streams in 2026.

The answer is—Absolutely!

Thank you for taking the time to read today’s email! Your support allows me to send out this newsletter for free every day. 

 What do you think for today’s episode? Please provide your feedback in the poll below.

Share the newsletter with your friends and colleagues if you find it valuable.

Disclaimer: The "Tiny Big Spark" newsletter is for informational and educational purposes only, not a substitute for professional advice, including financial, legal, medical, or technical. We strive for accuracy but make no guarantees about the completeness or reliability of the information provided. Any reliance on this information is at your own risk. The views expressed are those of the authors and do not reflect any organization's official position. This newsletter may link to external sites we don't control; we do not endorse their content. We are not liable for any losses or damages from using this information.