A technical person. More delivery cycles than I care to count. More scars than certifications. This one has been building for a while.
I want to be clear upfront. This is not an attack on all project managers. Some of the best people I have worked with carry that title. They understand the terrain, ask the right questions and make the engineering team’s life easier rather than harder.
This is for the other kind.
The kind I have been in rooms with for most of my career. The kind who walk into a sprint planning session with a fully formed idea, a slide deck and absolutely no interest in hearing why it will not work the way they have drawn it. The kind who learned one technical metaphor sometime around their first project and have been applying it to every situation since.
I am tired. We are all tired. And since nobody says this clearly in the retrospective because we are all too professional, let me say it here.
You Work in an IT Company. Please Learn What IT Is.
This is the one that keeps me up at night.
You are a project manager at a technology company. The product you are managing is software. The team you are managing builds software. Every decision you make either helps or hinders the people writing that software. And yet, years into this career, you still speak about technical work the way a tourist speaks about a country they visited once on holiday.
Nobody expects you to write code. Nobody needs you to understand pointer arithmetic or the difference between synchronous and asynchronous processing. But there is a baseline. There is a level of technical literacy that your role requires and that your team deserves from you. “I am not technical” is not the permanent get-out-of-jail card it is treated as.
When you manage a construction project, you learn enough about materials and load-bearing structures to know that you cannot put a fifth floor on a building designed for four. You do not need to be an engineer. You need to know enough to not make decisions that make the engineers want to walk out of the room.
The equivalent in software is not complicated. Learn what an API is. Understand the difference between a front-end change and a back-end change. Know why a database schema change is not the same as updating a label on a form. None of this requires a computer science degree. It requires three months of genuine curiosity and the humility to ask questions before making pronouncements.
At some point I stopped believing this is a knowledge problem. I think it is a priority problem. And that is harder to fix.
Coding Is Not Picking Fruit. Please Stop Treating It Like That.
Here is the mental model I suspect many project managers are operating with.
The codebase is an orchard. The features are fruit. When you want a new feature, a developer walks in, picks the relevant fruit off the relevant tree and hands it over. If you want to put a feature from one tree onto another tree, you just move the fruit. Simple. Fast. Why is this taking three weeks?
This is wrong in ways that are almost poetic.
Software systems are not collections of independent objects that sit cleanly in place and wait to be rearranged. They are webs of dependencies, assumptions and context. A piece of code that handles user authentication was written with a specific data model in mind, specific session management behaviour and specific error handling patterns. You cannot lift it out of that context and drop it into a system with a different data model, different session handling and different error patterns without it breaking. Not because developers are bad at their jobs. Because that is how software works.
When a developer says “that will take two weeks”, they are not being slow or dramatic. They are calculating the actual cost of untangling the assumptions baked into existing code, adapting it to a new context, testing that it behaves correctly in that new context and making sure they have not broken anything that was working before. The fruit does not move cleanly from one tree to another. It has roots.
The faster you accept this model, the more useful your timelines will become. And the fewer times your developers will have to explain, in a meeting in front of the entire stakeholder group, why “just copying the code” is not a thing.
Where Exactly Are These Ideas Coming From?
Every tech lead has a story. One of mine arrived as a chat message before the morning standup. An idea that had clearly been developed over the weekend, fully formed, complete with a proposed timeline.
The idea was, to be charitable, ambitious. It involved integrating three external systems we had never worked with, redesigning a core workflow that tens of thousands of users depended on and delivering the whole thing in six weeks because there was a client presentation in seven.
When I asked how this solution had been arrived at, the answer was that the PM had read an article. About a different company. In a different industry. Using a different tech stack.
I want to be precise about the problem here. The issue is not that PMs generate ideas. Ideas are good. Ideas are necessary. The issue is that ideas generated without any understanding of the technical constraints of your specific system are not project proposals. They are wishes. And the job of turning a wish into a delivery plan falls to the technical team, who now have to do that work while also trying to not laugh or cry in the standup.
If you have an idea, bring it as a question. “I came across this approach and wondered if something like it might work for us. What would you need to evaluate it?” That is a sentence that starts a real conversation. “We are doing this, here is the timeline” is a sentence that starts a long, exhausting negotiation that will eventually arrive at something much smaller than you originally proposed, after a significant amount of everyone’s time has been burned.
Your Decision Is Not the Same as a Technical Decision
Project managers make decisions. That is the job. Timeline decisions. Prioritisation decisions. Stakeholder communication decisions. These are real and important and the team relies on you to make them well.
What they are not are technical decisions. And the boundary matters.
When a PM decides that a feature will be delivered in week three rather than week five, that is a prioritisation call. It has technical implications and the team should be consulted. But ultimately it is a project management decision.
When a PM decides that a feature will be implemented using a specific approach, a specific library or a specific architectural pattern, that is a technical decision. It should not be a project management decision. Not because your opinion is unwelcome, but because the consequences of getting it wrong will be lived by the technical team for months or years after the delivery date you are focused on has passed.
I have seen systems that are genuinely difficult to maintain today because of technical decisions made by people who were not going to be around to maintain them. Quick decisions about which database to use. Decisions to reuse a module that was never designed for reuse. Decisions to skip the test coverage because the deadline was next Friday. Each one felt reasonable at the time. Each one is still costing someone time and money right now.
You do not get to decide how the code is written. You do get to decide what gets built and when. That is a meaningful scope and it is plenty of work. Stay in it.
Legacy Code Is Not Free. It Has Already Been Paid For. Badly.
This one is special.
There is a belief, persistent and almost impossible to kill, that reusing old code is always faster than writing new code. It sounds logical. The code already exists. Someone already did the work. Why would you do it again?
Here is why.
Legacy code was written for a different problem, in a different context, by people who are often no longer at the company, with technologies that may have been deprecated, with assumptions about the system that may no longer be true and with documentation that ranges from sparse to nonexistent. Reusing it does not mean inheriting a finished product. It means inheriting all the decisions, compromises and shortcuts made during its original development, most of which you are about to discover for the first time.
There is a term for this. Technical debt. It means the code works, but only in the way that a house works when several things have been fixed with gaffer tape and goodwill. You can live in it. You will have to deal with the tape eventually. When you reuse that code and build new functionality on top of it, you are building on the tape.
The question is never “does this code already exist?” The question is “is this code in a state where reusing it will cost us less than writing something fit for purpose?” Sometimes the answer is yes. Often, particularly with older systems, the answer is no. The technical lead is the person best positioned to make that call. Not the project manager. Not the stakeholder. Not the client who heard a competitor did something similar in a month.
Let the team assess it. Give them the time to assess it properly. And please, for the love of everything, do not say “but the code is already there” as though its existence is the same as its readiness.
Different Project. Different Niche. Different Code. This Is Not a Hard Concept.
The final one. The one that comes up most often and somehow surprises people every time.
You ran a successful project recently. It was a consumer-facing platform. The development was clean, the timeline was respected and the client was happy. Now you are starting a new project. It is a healthcare records system. Different client. Different data model. Different regulatory requirements. Different everything.
And yet here we are, talking about reusing the authentication module from the consumer platform.
The consumer authentication module was built for customers who forget their passwords. The healthcare system needs authentication that meets clinical data protection standards, handles role-based access for doctors, nurses and admin staff separately and generates a full audit trail of every login for regulatory compliance. These are not the same problem. Putting the e-commerce module into the healthcare system does not save time. It creates a new category of risk while giving everyone the false confidence that a corner has been cut successfully.
Codebases are not interchangeable components. They are products of the specific problems they were written to solve. Taking code from a logistics project and transplanting it into a fintech project is not reuse. It is organ transplant without a blood type check. It might work. It probably will not. The surgery will take longer than starting fresh.
The Developer Already Knows. That Is Literally Their Job.
Let me say something that should not need to be said.
A good developer knows when they can deliver their best work. They know when a deadline is tight but achievable. They know when it is technically possible but will require corners to be cut that will hurt later. They know when the timeline is simply not connected to reality in any way. When they tell you which one applies, believe them. They are not negotiating. They are reporting.
A good developer also knows which code can be reused and which cannot. This is not instinct. It is a skill they have developed over years of doing exactly this work. They have read the code in question. They understand its assumptions. They know where it will hold and where it will crack under a different load. When a developer says “we cannot reuse this”, that is the conclusion of a technical assessment, not a preference or an excuse.
So when that happens, the correct response is to reassess the situation. Not to push back. Not to ask if they have really looked at it properly. Not to mention that the last team reused something similar. Reassess. The developer has done the analysis you asked for. The answer is the answer.
On the library question, the same logic applies. Developers know which tools will speed up their work. They read the documentation. They follow the ecosystem. They know which library is well-maintained, which one has the licensing risk, which one their team already understands and which one will require three weeks of onboarding before it saves anyone any time. When a developer suggests using a specific library, they are not picking one at random from a list. They are making a considered recommendation based on context you do not have.
Here is the uncomfortable flip side of all of this. If you find yourself in a technical conversation trying to tell a developer something about their own codebase, about what can be reused, about which library to use, about why something should be faster than they are saying: stop. Ask yourself honestly: am I telling them something they do not already know? Because if you are not, you are not contributing. You are just adding noise to a conversation where they are the subject matter expert.
The thing developers genuinely do not know. The thing they genuinely need from you, is the business side. What is the client’s actual tolerance for delay? What is the political situation with the stakeholder who keeps changing their mind? What is the budget pressure driving the six-week timeline? What did the sales team promise that nobody told us about? That information lives with you. That is the thing we cannot figure out from the codebase. That is where your knowledge closes a real gap.
Tell us that. We will listen. Tell us about our own code and we will smile politely and wait for you to finish.
So What Do We Actually Want?
We want you in the room. We want you managing the stakeholders, running the timeline and keeping the chaos at bay so we can build things properly. That is valuable work and we genuinely cannot do it ourselves.
We want you to ask us questions before presenting the plan. Not after. Not in the retrospective. Before. Five minutes of “does this make sense technically?” before a client call will save three hours of backtracking after one.
We want you to trust that when we say something will take the time it takes, we are not padding the estimate to protect our weekends. We are protecting the delivery. The estimate is based on experience with what actually goes wrong, not what the happy path looks like on a whiteboard.
And we want you to read. Not technical documentation, not tutorials. Just enough to hold an honest conversation about what you are managing. One book. A few long articles. Something that moves your mental model of software from “fruit on a tree” to something closer to the reality your team lives in every day.
That is not a lot to ask. Somewhere past year seven, I am still asking.
This article was written at the end of a long sprint. No PMs were harmed in the writing of it. Several requirements documents were, however, significantly revised.