Project management is a diverse and complex topic, and each company handles it differently. To achieve better results, companies usually build a multi-skilled team with engineers, managers, product owners, and QA testers. With so many people, what is the actual role of software engineers in project management, then? How much involvement should non-technical and technical people have in each other's areas of influence? These are questions without a universal answer — but patterns do emerge, especially as AI tools make the line between "who decides what to build" and "who builds it" increasingly thin.
This is my take on that, based on real experience across very different environments.
Some foundation - What I understand as Project Management?
Project management is the practice of planning, organizing, and guiding work toward a specific goal, within constraints like time, budget, and scope. It's not just about Gantt charts and status updates, but making sure the right people are working on the right things at the right time, and that everyone actually knows what "done" looks like.
Today, engineers are expected to participate in planning and project management, by estimate their own work, flag risks early, communicate progress, and sometimes even define the scope of what they're building.
The Competencies: Where Engineers and Project Managers Overlap
A project manager's core competencies typically include things like stakeholder communication, risk assessment, timeline planning, resource allocation, and scope management. A software engineer's core competencies include system design, implementation, debugging, code review, and technical decision-making.
These seems like two distinct skill sets, but they are closer at some strategic points, and that intersection is where the most effective engineers tend to live.
- Estimation is one obvious overlap. Engineers estimate technical complexity and project managers translate that into timelines and resource plans. But a good engineer doesn't just throw numbers to story points: they understand why the timeline matters, what business decision depends on it, and how to communicate uncertainty in a way that actually helps the team plan.
- Dependency mapping is another. Knowing that your feature depends on a backend endpoint, a design decision, and a third-party API approval isn't just project management, it's engineering survival. Engineers who think in terms of dependencies and unblock themselves proactively are invaluable.
- Communication might be the biggest one. Writing clear tickets, giving useful status updates, and knowing when to escalate a risk. These feel "soft," but they have very real consequences on project outcomes.
The intersection, in short, is ownership thinking: the ability to care about the outcome of your work, not just the output.
My Experience: What Different Companies Actually Expect From You
I've worked across very different contexts, big tech companies, consultancies, and open-source projects. What "project management for engineers" means is different in each.
Big Company: Coordination as a Full-Time Sport
In a large organization, the sheer number of moving parts means that getting anything done requires a surprising amount of coordination. Cross-team alignment, stakeholder approvals, dependency tracking, and navigating the tension between what engineering wants to build, between technical excellence and controlling tech debt, and what the roadmap says.
In this environment, I worked closely with designers and product managers to figure out what could realistically be delivered and in what timeline. My job wasn't just to build, but also to make sure what I was building actually landed inside the system within the established procedures.
This taught me a lot about bureaucracy as a communication problem. All that process exists because people need to stay aligned across a large, complex organization. The engineers who thrive learn to work with the process - and occasionally, strategically, to work around it.
Consultancy: Being the Bridge
Consulting is a different world entirely. The diversity of projects means you're constantly context-switching between different clients, tech stacks, and team cultures. But there's a common thread: you are always, in some way, the translator.
In my time at a consultancy, the teams were large, the clients had their own ways of working, and the gap between "what the client asked for" and "what we understood them to ask for" was a constant source of risk. My role shifted toward being the bridge between our technical team and the client's expectations in some projects. That meant coordinating with my team on priorities, and constantly calibrating based on what signals were coming from the client side.
What this context taught me, specifically, was how to read silence. Clients rarely tell you directly when something is off. You learn to catch it in how they phrase feedback, what they don't ask about, and when enthusiasm drops. That's a skill that doesn't show up in any job description, but it shapes how I communicate to this day.
Open Source: Full Ownership, Minimal Structure
Working in open source is, in many ways, the purest form of engineering ownership I've experienced. There's no product manager telling you what to prioritize.
In practice, this meant taking full ownership over what to build and how to build it, of course, within the broader directives of the project, but with significant autonomy. I decided what was most important based on my own findings when I talked to users. I shaped the roadmap, communicated it, and executed it. The bureaucratic overhead was almost nonexistent, and the trust was remarkably high.
My Personal Flavor: Design and User-Centered Perspective
Most of what I developed came from being thrown into situations where it was needed, and from someone seeing something in me that I hadn't fully articulated for myself at those times.
Looking back, what seems to resonate with the people I've worked with is a combination of things rooted in my background: I came into engineering with a design background and have always been user-oriented. Those two things shape how I approach technical problems: I think in terms of how things will be experienced, not just how they'll be implemented.
One specific habit that keeps coming up: I like to create visual elements — boards, diagrams, maps — as a way to make sense of complex projects. I do this first for myself, to understand the shape of what I'm working on, but then I use those visuals when presenting to non-technical stakeholders. The goal is to give people an entry point into the technical conversation.
I also bring a certain orientation toward education into how I communicate. I try to translate technical concepts without dumbing them down, which is a harder balance than it sounds. The goal is always to make the other person feel more informed and more capable, not more confused or dependent. That usually involves meeting people where they are, using analogies that fit their world, and then carefully building toward the technical layer.
And maybe most importantly: I genuinely care about relationships. I want to know the people I'm working with, I want to talk to users. I want to understand who I'm building for, not just what I'm building. That sounds soft, but it has very practical consequences. When you understand who your users are, your technical decisions get sharper. You know what's worth over-engineering and what isn't. You know what "good enough" actually means.
Conclusion: It's Not a Separate Skill Set - It's an Extension
If there's one thing I'd want you to take away from this, it's that project management isn't something you need to become a different kind of person to do. It's an extension of the curiosity and care you already bring to your technical work, just pointed outward, toward the team, the stakeholders, and the users.
Different companies will need different things from you. But the underlying thread is the same: take ownership, communicate clearly and early, and care about the outcome, not just the output.
Top comments (0)