Dissolving Boundaries: The Death of Linear Work
We likely are observing a fundamental shift away from a division of labor model in software development in a traditional sense and towards a hyper collaborative culture focused on co-creation. Here, I’ll explore some of my thoughts on this evolution and how it can come to life within organizations.
Before: Sequential waterfall masquerading as agile
Even at its most efficient, the process for building software is still largely linear, whether you’re doing Kanban, Agile, Waterfall or some mix of all these smashed together as most of us are accustomed to
Product spec → Design mocks → Engineering tickets → QA —> Release —> Repeat
When handing off work, there’s inherent lost context and waste that is difficult to quantify and has become all but expected.
Soon/Now: Real-time collaborative execution - seeing, reacting, adjusting in real-time
Example: Designer manipulating live code while PM adjusts business logic in natural language
Engineer prototyping directly with customers while researcher captures insights programmatically
The medium of creation becomes shared, fluid and more instantaneous
To consider: Can Conway's Law become obsolete when the communication structure itself becomes fluid; the inherent ability to collaborate more in real time should help to ease the pain of Conway’s law on organizations but requires openness towards this method of working by teams
From Collaboration to Co-creation
As we experience this shift, we’re actually moving from functional collaboration within teams and towards co-creation within teams. This starts to tear down traditional barriers and boundaries, many of which typically create some comfort within teams because members know their lane but also create a real amount of friction and frustration.
Traditional model: Deep expertise in narrow domains
Engineers who "don't do design"
Designers who "can't code"
PMs who are "just the business side"
Key shifts that become enabled:
The "latency collapse" - as iteration cycles go from days to minutes
The death of artifacts as boundaries (PRDs, design files, tickets); these may still be useful but as real-time inputs to generate alignment and discussion and to drive a usable output
The closer the cost of experimentation moves towards zero, you spend less time planning and more time testing and iterating on feedback more immediately
AI-enabled model: Domain expertise applied through universal tools
Everyone becomes a "builder" with different lenses that underscore their deep expertise and background, so the power and applicability of specialized skill is not negated, but how it is applied heavily evolves
Example: A designer using their spatial reasoning to architect system flows
Example: An engineer applying systems thinking to user journey optimization
Example: A product manager directly building a feature to solve a known customer problem
Natural Language becomes standard for human-computer interaction:
English (or team's agreed upon language) as the programming language isn't metaphorical. It is literally how the team is collectively engaging with the interface they’re manipulating. We are and will move to natural language as the programming language of the future, with the syntax and output in terms of code being just a bi-product vs the primary knowledge base.
New team dynamic: "Socratic development" - progress through questioning will evolve, and therefore the ability of teams to communicate effectively with each other and operate in a low ego way will be critical. High engagement, low attachment must become the norm and expectation of teams.
The emergence of "linguistic code reviews" to understand what functionally must change vs what must change from a syntax standpoint. In this regard, the code itself is yet another temporary artifact, despite it “living” within the shipped product. The primary work product itself is not the code but the solution it enables. Yes, code is still shipped, but less of the focus is on the nature of this artifact itself.
Beyond the natural language itself it underscores the key skill needed to succeed - Communication. While effective communication, empathy, soft skills and the like have been increasing in importance for years, they are now going to be table stakes for high performance in every function and situation.
This will fundamentally challenge certain worker types and teams and require material change and evolution
The Paradox of Increased Agency / The Ownership Paradox
Everyone can build anything → Curation becomes critical
We will make a shift from "who has permission" to "what should we build” as a collective perspective from the team.
New role of taste and judgment becomes critical as execution is commoditized. Taste and judgment become more important than ever. The ability to ship instantly or more instantly could lead to a proliferation of terrible ideas making their way to production if teams do not take care to emphasize things like taste and judgment in their work. These qualities become key skills, not just squishy sounding words.
At the bottom of this, shared ownership should actually increase perception of agency vs diminish it, although it will not feel that way at first. Pride of authorship has always been a bug not a feature, and now we can further eradicate this.
Speed of iteration changes decision making:
When a strong decision making framework is in place and there’s high trust within the team you can move from:
"Let's plan this carefully" to "Let's try three versions"
A/B testing at the ideation phase
Example: Testing 10 landing page concepts in an hour vs one in a week
Experimentation cultures have elements of this today, but this moves experimentation even further up in the flow towards ideation.
How to measure this shift:
Begin to focus on outcome velocity, iteration count, user impact speed, which are not solely novel, but novel in that the entire team would now be measured against these metrics in a more focused way. More on this later.
Organizational Antibodies and Adoption Patterns
The identity crisis: When everyone can do everything, who am I?
PMs threatened by the ability for everyone to be testing and learning
Engineers threatened by PMs shipping features
Designers grappling with engineers making aesthetic choices
Mitigation: Celebrating lens diversity over tool ownership, meaning that the varying perspectives on the team are still incredibly important but tools / functions are less sacred.
We have long talked about the three-legged stool, but ironically those legs never quite touch or intertwine except to hold up the seat…interestingly a very apt picture of three separate functions coming together at the end of a process to achieve an outcome, so we’ll need a new metaphor for what we’re creating here wherein the collaboration is much more intertwined and the functional lines are more blurred. Jazz ensemble, triple helix?
New performance metrics needed:
Moving from "lines of code" or "designs shipped" to "customer problems solved"
Attribution becomes collective vs individual by default
Incentives for teams must be aligned to value creation, problem solving vs traditional box-ticking to enable the next step in the assembly line
The biggest barriers aren't technical but cultural and structural…
Traditional performance reviews break in a no-ownership model. No more “well I did my job” sufficing to incentivize and reward an individual, so much more measurement moves towards the collective. This becomes a management challenge to better evolve assessment practices to understand how each team member is contributing to the key outcomes desired and whether team members are making the people around them better as they move through the creation process.
The threat to middle management and technical gatekeepers. There’s plausible continued movement towards a world with fewer full time middle managers and technical gatekeepers. I do not believe this means that management as a skill goes away, that architecture goes away, etc. I actually think that this evolves towards someone who has acumen in each area and a high level of ability to be a player coach. Many organizations have long moved away from the ivory tower approach, and I simply see this as furthering that. Ample space and value must be placed on skilled leadership and management in this new model, however paradoxical that may seem.
The "expertise identity crisis" - when your specialty feels commoditized, what’s your identity within a team. As stated earlier, I do not believe that this erodes the value of unique skills, backgrounds or perspectives, but it does challenge and morph it in ways that will reward those who are eager to see the collective succeed and punish those who want individual credit at the expense of others.
The New Team Topology
Teams reshape around problems, less around functions. The most valuable member of the team becomes the “glue person” who brings the team together, achieves shared context, and helps guide towards outcomes and away from task execution prowess. This is already happening with the notion of Pods, Durable Teams, etc. but this likely becomes a much more standard way of working. Teams may sustain in order to maintain chemistry but their flexibility is more around a problem / opportunity space than a depth of technical background. ie we begin to move away from “but x is the only one who understands this system, so they have to be on this team” and towards a world where teams are formed and maintained based on their collective expertise of solving a real problem. Finally, leaders will fundamentally be X shaped in nature much more than has been true to this point in time.
Building blocks:
Engineers: From syntax masters to system thinkers and constraint definers
Designers: From pixel pushers to experience philosophers and pattern recognizers
PMs: From requirement gatherers to context providers and success definers
"Problem pods" that form and dissolve more dynamically, particularly as the speed to solve a problem goes up and the cost goes down.
The rise of the "context keeper" role
New skills: “prompt architecture” to align teams, such that the inputs are clean, therefore ensuring the outputs are clean
Expertise becomes about knowing what to ask for, not how to build it
New hiring criteria: curiosity quotient over technical prowess
The Competitive Advantage of True Collaboration
Speed compounds differently and we look for different 10xers:
Traditional: 10x individual productivity = 10x output
Collaborative: 10x individual productivity = 100x exploration space
The traditional definition of any single 10x individual somewhat dissolves. Conversely, the dynamics of the team itself become much more critical. Think a pro sports team metaphor. Every player is fluent in the sport, but optimized for not only their specific depth of skill but as to how they contribute to a winning team.
Emergent innovation from boundary dissolution:
Best ideas come from intersection of disciplines
Example: Designer's mental model improving database schema
Where to Begin?
Strategies for gradual transition without organizational rejection. A material risk here is that organizations that are fully optimized for the traditional way of working may face real challenges in evolving, as it will feel like moving the cheese, forcing an arbitrary change that is unnecessary or devaluation of skills. This is largely a mirror of human nature in change resistance. To overcome, we’ll have to find champions, create an environment of shared success and rewarding learning and incentivize the behaviors that we want to see. This is true in any organization, but one that is being asked to fundamentally change even when things are “working as they should” has to be approached thoughtfully.
From ownership to stewardship:
Code/designs/specs as community gardens where everyone can engage productively
Ego dissolution exercises (pair / swarm everything)
Celebration of collective wins only vs individual heroics
New hiring profiles:
Curiosity quotient over domain expertise becomes the norm and expectation
Comfort with ambiguity is a must, because the inherent nature of co-creation means that the level of concrete thought and detail going into many executions will be lower than before
Systems thinking ability is a must have to lead. If you cannot understand how pieces come together and respect and assist those things, you will struggle to lead.
Pilot program structure:
Ideally start with a greenfield project if possible to test this while limiting “drag”
Mixed skill pod of 3-4 people who exhibit collaborative tendencies, communicate well, have high skill and low ego. You may quickly find you run thin on people who match this criteria per the points above about what we optimized for before vs what we will optimize for in the future
Shared KPIs, no individual attribution - this will be really hard, but where the team succeeds, celebrate and share the wealth of that success
Weekly rotation of who "drives" different aspects while respecting the domain expertise each team member brings to the table
Embrace discomfort throughout this process
Tool stack considerations:
Choose tools that are becoming ubiquitous or that may be already in limited use in the org to ease the learning curve:
Cursor/Windsurf for collaborative coding
Figma's Dev Mode as early example
Evolved use of Jira / Confluence: Natural language requirement tracking - moving from strictly tickets and more towards collective inputs —> shared outputs
Emphasis on more synchronous collaboration and more real time feedback being welcomed
Building blocks:
Start with "AI pair programming" sessions across disciplines
Create "role rotation sprints" where team members use AI to work outside their specialty and are welcomed in and taught
Focus on "outcome ownership" instead of "feature ownership"
Build "learning loops" that are faster than "development loops" - rapidly learn to not only speak each other’s language but to productively ask questions, learn and adapt quickly
Measure "time to user value" not "time to deployment"
Key Tensions I’ll Explore Further in the Future:
How do we maintain quality when everyone can ship?
What happens to senior/junior dynamics?
How do we preserve institutional knowledge without silos?
Where does accountability live in a collective model?
In Closing:
Ideally, the future is not looked at as a completely zero sum game wherein AI just replaces all of us and our effective working model completely collapses. More ideally, it helps to dissolve boundaries between roles and within teams. The teams that will win will be those that embrace this dissolution and rebuild their collaboration culture from first principles. This is not about moving around people on existing teams, it’s about fundamentally rethinking what it means to build and create and be a part of a team altogether.
Useful reference materials
Reference: Marty Cagan's discussion of feature teams vs empowered teams and follow on post
Use case: Replit Teams
Reference: Anthropic's Constitutional AI
Reference: Kevin Kelly's "1000 True Fans" applied to internal product decisions
Reference: IDEO's "T-shaped" professionals concept, but evolved to "X-shaped"
Reference: Ethan Mollick's research on "Cyborg Centaurs" vs "Cyborg Minotaurs" summary
Case study: Replit's multiplayer coding as precursor
Reference: Stuart Kauffman's "adjacent possible" in team dynamics
Josh Comeau's thoughts on AI and web development evolution