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:

1. How do we maintain quality when everyone can ship?

2. What happens to senior/junior dynamics?

3. How do we preserve institutional knowledge without silos?

4. 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

I have expressed interest in picking up medium format film photography for some time, and for my most recent birthday my wife purchased me a Mamiya 645 Pro with a 80mm f/2.8 lens, and a prism viewfinder. She did a ton of research, chatted with folks on Reddit and ended up buying the rig from KEH, who were very helpful in the process. She’s obsessed with the details, as am I, so her efforts were rewarded with a beautiful camera, and I was rewarded with an incredibly thoughtful gift.

We found a manual here that someone had graciously uploaded. You can find these around the internet, and it’s really awesome that people are helping to keep this type of information flowing. Additionally, there are some great YouTube resources for getting started. I may go back and create some short form videos for particular aspects of using the camera in the future as well.

Now, I quickly took the camera on a long weekend trip to Healdsburg, CA and was so excited to get the film back and develop it.

Quick tip: when flying, you can easily request a hand inspection of your film and camera, so you can avoid running it through the scanners. Regardless of ISO, I have now done this several times, and it’s really simple, so I’d just do that to be safe.

Learnings: this is not 35mm film. Now, for those more familiar, this will be incredibly obvious, but when you finish a roll of 120 film, you effectively lick it like a stamp and seal the roll to avoid light getting to the film itself. I did not do this. My film was ruined from this trip! Also, let go of things quickly. I was so disappointed, but at that point there was nothing to be done.

I had another chance to practice, this time in Seattle, WA. During this trip, I succeeded in shooting a couple rolls and coming back with a half used roll. I dropped the finished rolls at Glazer’s in Seattle before flying home. They were very helpful and easy to work with, and I received a WeTransfer link with my photos in the time they estimated and my negatives in the mail shortly thereafter. This time, I was happy with the results! Sharing a couple here, and you can find more here as well.

Getting started, I really focused on some basics of recalling the ins and outs of manual focus, and I utilized the metering from the prism viewfinder, focusing mostly on adjusting aperture for depth of field and light control. This simplified the number of variables up front and made acclimating easier.

The thrill of shooting film vs digital is never lost on me, but I also take lots of photos with my iPhone and due to the expense of film will always mix approaches, using film sparingly for the shots I think most effectively will translate to the medium. That said, there’s no substitute for taking 15+ photos and not knowing what you achieved until you see the results for the first time. Quick tip: while leveraging a light meter such as a Sekonic L-308S is a great way to ensure you’re exposing accurately, you can also snap a few photos on your iPhone to check and adjust settings prior to setting up your film capture. For me, it’s mostly an exercise in just trialing the camera and seeing what it produces and learning to tweak and adjust as I go.

I shot the following film while there and was very pleased with the grain structure and saturation: Kodak Ektar 100 color; Kodak Portra 400 & Ilford HP5. Shooting 100 ISO is awesome, but just be sure you really have sufficient light if you’re going to be shooting handheld.

My next purchase is likely to be a plunger, and I’ll share more about my initial gear setup in a future post. In addition to the gear setup, I edited in Lightroom and am also relearning that tool as well after quite a long time! I’ll write a follow up that includes some learnings and observations from using Lightroom for these photos. I’ve only scratched the surface thus far.

Subscribe now