Why “Clear Responsibilities” Can Lead to Chaos.
I’ve been thinking a lot lately about how organizations work, and specifically about the impact of something we often take for granted: roles. You know, the neat little boxes we put people in — “Product Manager,” “Engineer,” “QA,” “Marketing,” whatever. We assign responsibilities, set goals, and define boundaries. It seems logical, right? How else do you know who does what?
But based on what I’ve seen and experienced, this seemingly sensible practice might just be one of the most destructive forces in organizational performance. Let me explain why.
Chapter 1: The Illusion of Control in a Chaotic World
The goal of any organization, ultimately, is to achieve some kind of success. Business success, impact success, whatever flavor you’re going for. And there are a ton of factors that affect this. Some are obvious, some are not. No matter which, the point is, the business environment is inherently unstable and full of variables. And we, as humans, tend to crave control and predictability. This often leads us to introduce structures that feel like they provide control — like clearly defined roles with clear definitions, responsibilities, goals, and those ever-popular OKRs. On the surface, it looks responsible. Everyone knows their lane, presumably, and things should run smoothly.
But, as I’ve observed, this exact practice of rigidly defining roles and responsibilities can be the most destructive thing you can do. It seems counterintuitive, right?
Chapter 2: My own mistakes
I learned this the hard way when I was creating my first business. I made a bunch of mistakes early on — went “big right away” with a team. See, my main profession is actually elsewhere, and I knew I didn’t want to get bogged down in the day-to-day operations of this new venture. My approach was to hire people who were better than me at the things I needed done. The business itself was something I didn’t intend to spend all my time on.
So, I hired several people and thought, “Okay, I’ll give them clear areas of responsibility. This person will be in charge of X, this one Y, this one Z.” I created a clear separation, a hierarchy of sorts, with someone basically designated as the overall director responsible for the ‘place.’ I set goals for the director, expecting them to drive the business forward. My thinking was, this gives clarity; you know who to hold accountable.
Initially, everything felt a bit chaotic, in a good way. Especially in the beginning of an organization, everyone’s doing a bit of everything. Opportunities are everywhere, and everyone is learning like crazy.
But as my structured roles settled in, something felt off. I started noticing that the people under the director were actually the ones pushing for change, taking on more responsibilities, and trying to make things better. Meanwhile, the person I’d explicitly put in charge, the director with the clear role and responsibilities, seemed… limited. They weren’t driving things the way I expected. In fact, they were sometimes even limiting the opportunities for other people, perhaps by sticking too rigidly to their defined lane or telling others not to step into theirs.
This was painful. It quickly became obvious that my initial structure wasn’t reflecting the team’s actual skills or their potential for impact. It was the structure itself, the clear separation of duties, that was getting in the way. We ended up having to change things, shuffle responsibilities, and essentially allow people to go back to doing whatever they could do best, regardless of their initial title.
That’s when I had a realization: this particular separation, this clear designation of who is responsible for what, was actually a terrible idea. When people have too clear roles and responsibilities, it’s not great. Business isn’t some perfectly mapped highway where you just follow the lines. It’s a constantly changing landscape where you need to tackle unexpected problems, pivot on a dime, adapt, and survive.
Real-world problems, whether in product development or dealing with people, almost never fit neatly into pre-defined boxes. You don’t need clear guidance on what specific task to do; you need a clear understanding of where you’re trying to go and the freedom to experiment, make mistakes, and figure things out along the way. Freedom to follow a plan is not the same as freedom to succeed.
Chapter 3: The Waterfall of Wasted Potential
Let’s look at an actual use case to make this concrete. Imagine a standard product development flow, simplified to just a Product Manager (PM) and Engineers.
A PM goes out, talks to customers, gathers information about pain points, maybe analyzes the market and competition (perhaps even “stealing” some existing ideas — hey, it happens!). They work with a designer on mockups, assess risks, figure out financial limitations. Then, they package all of this up into a nice, extensive document — often a PRD (Product Requirements Document) — detailing what the product should look like and do.
Once the PRD is ready, the PM hands it off to the Engineers. From here, the Engineers take the document and build the solution. After implementation, the product is (hopefully) delivered to customers.
This might seem efficient. It’s a clear flow: PM defines, Engineers build, Customer receives. But this is a classic example of Waterfall. People often think that Waterfall is about very long planning sessions and year long implementation plans, but it’s actually is about the direction of information. The water (the work, the information) flows only in one direction: from top (Customer/PM) down to the bottom (engineering/implementation). It never flows back up.
The big issue here is the separation into rigid stages with specific roles tied to them. No matter how quickly this happens, the separation is the problem. The deep understanding of real customer pain points, gathered by the PM, often escapes the Engineers who are now heads-down building. Conversely, the practical implementation limitations and complexities discovered by the Engineers escape the PM, who’s likely already jumped onto defining the next project.
The interaction becomes shallow, often just “here’s the document, build it.” There’s no natural feedback loop where the Engineers can easily say, “I think during customer calls we should also ask question X”, because they are not aware of this conversation. Engineers are left alone with a document, not the living problem it represents. They focus on building the solution as defined, not necessarily solving the underlying problem.
Customer feedback after release goes back to the PM, but reaches the Engineers (if at all) much later, often only as formal “follow-up feature requests” or “bug fixes.” It feels like an annoyance because they thought they were “finished” with that product. The direct connection, the shared sense of purpose beyond building tickets, is lost. Engineers become completely separated from the human side, lacking that emotional or sympathetic connection to the customer’s reality. They see requests as just more work, not opportunities to refine or fix something fundamental.
So, how can this be changed, even with just a couple of roles? Here’s a very simple rule that works wonders: The whole team must work on one project at a time.
No seriously, this is the biggest advise I can give in this article: The whole team must work on one project at a time. Together. From start to finish.
Let’s say we’re starting our first project. If the whole team (PM and Engineers) starts with discovery, there’s nothing else to do but participate in discovery. This doesn’t mean everyone does the exact same thing — some might look into technical feasibility, others into market needs, the PM might lead customer interviews with only one engineer (if we assume customers would feel ambushed by the full team). But everyone is exposed to the problem space together.
Crucially, anyone on the team can also dive into the existing business processes, even manual ones. Practicing how things work now, solving current problems with existing tools, is a vital practice. It’s not just busywork; it builds a deep understanding of the “status quo” and the actual pain points. It gives everyone, including Engineers, an emotional connection to the complexity and the customer’s reality.
By doing this early on, the team gets the idea flowing, surfaces potential limitations (“Yeah, building that will be a nightmare”), and the feedback loop is established from the beginning. The PM is completely available to work daily with the Engineers on this project, clarifying doubts immediately, reviewing early prototypes together. The focus shifts from defining a perfect solution upfront to understanding the problem deeply and iterating quickly as a team.
The PM could even build simple mockups (without needing coding skills) in parallel with engineers building rudimentary functional pieces. This creates early visuals and shared understanding of the vision.
Chapter 4: Beyond Product vs. Engineering, Beyond Control
Where do we go from here? If rigid roles, especially the standard ones, are so detrimental to the work, how should organizations be structured?
First off, let me clarify: I’m not talking about eliminating people management roles. I see people management as a separate track, focused on people’s development, well-being, and culture. Hierarchies in that sense can absolutely make sense and contribute to a great environment. What I’m railing against is the idea that the work itself requires a rigid structure of specialized, separated roles with defined handoffs and limited scope. Work doesn’t require high-level management or control in that sense.
The fundamental unit of work, in my view, should be a team focused on solving a specific problem for the customer. And that team is measured primarily by its output — the value it delivers — not by whether they followed a specific process, used certain tools, or stayed strictly within their defined roles. If the outcome is great, if the company benefits, that’s what matters most.
This has big implications for hiring. When you hire a specialist — say, a designer, a data scientist, or an engineer with a specific backend focus — their responsibility shouldn’t be just their particular technical area. Their responsibility should be contributing to the overall product development and solving the customer problem the team is focused on. They need to be involved in everything, not just their narrow slice. This will already allow you to eliminate some of those pesky roles, let’s say FE and BE and just focus on Engineering.
Get Artem Ishchenko’s stories in your inbox
Join Medium for free to get updates from this writer.
Of course, people have different capabilities and specialties. That’s where hiring specialists is valuable. But this doesn’t mean they should be confined. It means they bring expertise that can benefit the entire team. Limitations can be mitigated by encouraging learning across areas and, crucially, through collaboration like pair work. A specialist paired with someone from a different discipline can both teach and learn, bringing diverse perspectives to the problem and getting broader exposure. This isn’t just about skill transfer; it’s about ensuring everyone has an impact on the broader area of development. Think of engineers highly involved in product discovery and design, or product managers getting their hands dirty with development tasks.
The goal is to have responsibility shared within the team working on that problem, and to remove the need for top-down, controlling structures for the work itself. We expect the team to deliver, and we empower them to figure out how, leveraging everyone’s skills broadly.
Chapter 5: If everyone is responsible, then no one is responsible.
An interesting side effect also arises from this division. Organizations of all sizes expect every member to be fully committed to their success — otherwise, why hire them? This commitment means being constantly engaged, proactively providing feedback at any observable opportunity for improvement, and generally being responsible for the overall outcome, not just one’s immediate area of expertise. This expectation already becomes challenging when people are unaware of anything happening outside their “black box.” Moreover, conventional wisdom states: “If everyone is responsible, then no one is responsible.”
This leads to a situation where, to make a team truly accountable, it is often assigned a representative, such as a Team Lead, Product Manager, or someone in a similar role. Now we arrive at the pinnacle of absurdity: not only are individuals expected to be 100% committed, but they are also implicitly not trusted with that commitment. To make matters worse, this dynamic creates internal tension, as the Team Representative often becomes the primary target for all negative feedback from external sources and, in turn, must internally “police” team members to persuade them to improve.
When the whole team is focused on one project, you get “all hands on deck.” Everyone learns about everything (nobody’s an expert in all fields, so there’s constant learning and immense personal growth). You get real team performance, dynamics, engagement, commitment, and responsibility from everyone in equal measure. Instead of blaming one person when things go wrong, negative feedback becomes valuable information that dissolves inside the whole team.
This approach, where you work on a solution as a whole rather than just working on your specific area, has worked wonders in my experience. Eliminating rigid roles and responsibilities and embracing shared ownership creates incredible team dynamic and effectiveness.
Chapter 6: Cheat Sheet
How can this approach be implemented in a larger corporation?
You obviously cannot implement an organization-wide change immediately, but you can start with a single team.
- Find volunteers and a small project.
- Provide all necessary expertise (e.g., Designer, Product Manager, Engineer, QA).
- Let the process emerge naturally. Don’t provide strict instructions to follow; instead, make one rule clear: one project at a time.
- The team will need to figure out for themselves how to keep everyone productively engaged.
- Learn from this experience, then scale.
What about “too many cooks in the kitchen”?
From my experience, the issue is usually the opposite. However, it’s true that ensuring everyone remains consistently engaged on the project will require effort. Non-engineers will need to learn more technical details to stay involved during implementation iterations. For example:
- Prototyping an interactive application might require learning low-code tools.
- Testing before a UI exists might require understanding APIs or diving into SQL.
Engineers, in turn, will have to delve into business processes and spend time with operations, support, sales, etc.
What about team leads?
Honestly, I’m not entirely sure about the necessity of this role. To me, it often seems like a synthetic position — not directly people management, nor purely work-focused. Its purpose can sometimes appear to be primarily about imposing control, a concept we’ve discussed previously.
On the other hand, I recognize the power of good leadership, and promoting leaders can offer certain benefits. My recommendation is to start without a designated team lead. Observe what your particular setup requires and see what necessary roles might emerge naturally.
The important principle here is: never blindly follow frameworks; instead, stick to the values you find important. For example, don’t try to mechanistically apply Scrum, Lean, or other methodologies. Instead, consider understanding and applying the philosophy behind them.
Conclusion: Erasing the Lines
In conclusion, the traditional, rigidly defined roles we so often see are less about enabling effective work and more about creating a misguided sense of control and hiding issues. They separate people, create knowledge silos, stifle feedback, and ultimately lead to a worse customer experience because no single person or role has full ownership or understanding of the whole.
The alternative is to see the organization as a collection of teams focused on solving specific customer problems. The team is everyone working on that problem, regardless of their title.
This approach can be extended boldly. Instead of thinking of operations, business, sales, product, and engineering as separate departments with separate roles, think about who needs to be involved in solving a particular customer problem from end-to-end, and include them in one cross-functional team focused on that problem. This might mean including a “business person” or “sales person” directly within a product development team. Their responsibility becomes contributing to solving this problem, doing whatever work is necessary (technical or manual), alongside their teammates.
If you can afford this deeper integration, if you can erase those traditional department boundaries within teams focused on problems, you will unlock massive benefits. While it’s not always easy and can be hard to transition, especially for resource-constrained organizations, the technical reality is this: everyone working on the same problem for the customer is part of the same team (no matter how they’ve been split, they are on the same team), and they need to work as one unit.
Creating specific roles for specific parts of the solution or specific disciplines within a problem-solving team has a huge chance of backfiring. It creates artificial division, hides fundamental issues in your processes by assigning blame to a narrow area, and detracts from the shared goal of delivering value to the customer.
You have to be brave. You have to push those lines away. Try to pull people together and remove the artificial boundaries that prevent them from participating everywhere their skills and perspective are needed.
Stop seeing roles as a given, a “natural thing” that must exist. Stop thinking that hiring good people for good roles automatically solves your problems or that roles are a “necessary evil” because you lack resources. That default approach, just applying existing team structure templates, is a recipe for failure.
Your organizational structure, and the roles within it, must be an emergent decision driven by your company’s specific needs and the problems you’re solving. If you’ve already got a rigid list of roles before you’ve even started tackling the work, you’ve likely already built a structure that will create division, lower quality output, and hide the very issues you need to surface.
Remember, real problems don’t fit into neat little boxes, and neither should the people solving them.
