The Tech Work Has Changed Again

Today’s tech work has turned many engineers into part-time project managers. Almost always unwillingly.

So, “project managers” may be a stretch. More like people trying not to drown in shifting priorities, expectations, blockers, and decisions they cannot control.

Of course, organizations did not intentionally design it this way. For a long time, a simple division of labor seemed to work: engineers build, managers worry about everything else. With this “clear responsibilities” approach humans built factories, supply chains, and sent rockets to the moon.

But tech and knowledge work in general needed to move faster. And when you need to move faster, you don’t have time to send every issue upward for review. You need to make decisions here and now. This is how the industry started talking about flat structures, cross-functional collaboration, self-organizing teams, distributed ownership, Agile, SCRUM.

The ideas were beautiful, but in practice this did not land gracefully on top of a century-old management mindset built around specialization and hierarchy.

Companies forced SCRUM everywhere. Standups, backlogs, story points — all the formal elements.

Teams were supposed to self-organize, except very few people were ever taught how to do that in teams larger than five people.

So central coordination still happened somewhere: through tech leads, over-involved product owners, scrum masters chasing task completion, or even formal project managers like in the “old times”.

What AI Adds To The Equation

AI is not making this any easier. One engineer can suddenly produce much more output. Teams become smaller, delivery speeds up. Companies are questioning whether coordination still requires dedicated roles, and are happy to cut costs.

But projects themselves are not becoming simpler.

And project navigation is more difficult to separate from technical work itself. That creates a new pressure many organizations still haven’t fully grasped:

Modern technical work increasingly requires engineers to become better at the project side of the work.

In other words, it may finally be time for everyone to become “a tiny bit” of a project manager — just enough for self-organization to become something teams can do naturally.

The Hidden Expectations From Engineers

The funny part is that this kind of project thinking is already expected, even though it is not properly named. Today, it is considered normal for tech people to:

• deal with unclear goals
• navigate changing priorities
• estimate ambiguous work
• coordinate with others
• notice risks early
• remove organizational blockers
• protect their focus time
• make decisions with incomplete information

But very few people are actually taught how to do this.

Instead, these abilities are treated as “common sense,” “seniority” or simply “being good at their job.”

People get dropped into increasingly complex project environments and are expected to magically figure out how collaborative work behaves under uncertainty. As a result, many smart people end up interpreting this overwhelm as personal failure.

And when they struggle, the assumption is often: “they lack soft skills” or “they need more experience.”

Instead of recognizing that they may simply need guidance that is empathetic to the reality of their work.

What's The Right Amount Of Project Management Skill

I think treating project management as common sense is part of the issue — because if something is considered “common sense,” people stop treating it as something that needs to be taught. Another problem is that we still treat project work as something happening around technical work, instead of recognizing how deeply embedded it already is within it.

And no, I do not think the answer is turning every engineer into a project manager.

Traditional PM frameworks alone are not the answer for today’s “faster-than-Agile” tech environments. They still rely heavily on process and methodology, while these innovative projects depend on people figuring things out together.

But I do think modern technical work requires lightweight project literacy: basic understanding of how to work with risks, dependencies, stakeholders, feedback loops, trade-offs, priorities. Basically, some shared language for talking about project work.

The Ability To Think In Projects

Most importantly, engineers need the ability to think in projects. It helps in two ways.

First, they may be able to manage their own work better. Even individual technical tasks are often complex enough to require clarifying the goal, planning, prioritization, adaptation, and feedback on their own.

Second, they become much better at contributing to the coordination of the larger initiative — naturally, without seeing it as pure overhead.

And for that, people do not need another project management crash course full of generic theory detached from their reality. What they need is a better way to understand what is actually happening inside collaborative work.

The ability to recognize patterns. To articulate why a project feels chaotic. To notice risks, unclear ownership, broken feedback loops, invisible dependencies, or planning that stopped being useful. Because a surprising amount of project frustration becomes easier to address once you can clearly see the underlying dynamics instead of experiencing everything as pure chaos.

The goal is not to teach engineers how to do things “right”, but to give them enough of a starting point so they can figure out what “right” means for their own situation.

What people actually need is the ability to think more clearly inside complex projects, adapt intentionally, and participate in coordination without seeing it as somebody else’s job.

Let’s call that ability Project Thinking.