CREATING WITH SYSTEMS

DESIGNING TEAM
FLOW

CONTEXT // 01

THE CHALLENGE

Integrating complex functionality into a financial services platform is tricky to design and just as nuanced to execute. Anyone who has worked on large software systems knows that projects that span across multiple subsystems, domains of expertise, and involve entire teams can get very complex very fast. And when business strategy is positioning itself around an on-time delivery, the stakes for a smooth delivery are high.

When I worked on an enterprise software team I was assigned to lead such a challenge. We had big advantages already, the team was amazing; talented, motivated, high-trust and our leadership was top-notch. However, for long-running, highly complex builds like the one we were facing, I understood that bottlenecks, miscommunication, late-stage surprises can throttle even the most excellent teams. Furthermore, with the right approach, we could get things done with greater quality and speed, and holistically improve the software system throughout the process.

METHODOLOGY // 02

THE APPROACH

My role was both software engineering and as the assigned leader of such an initiative, keeping the team coordinated and the project on track. I recognized early that this required designing two deeply interconnected systems: the production software itself, and the ephemeral, human system that would build it.

To design these two systems effectively, I relied on a few principles:

Design the teamwork and the system together: Conway's Law identifies that the teams that build software and the software they build are deeply connected in subtle and mutually reinforcing ways which are critical to consider when balancing process and implementation. Team Topologies provides a practical guide for working with the human factors of teamwork in the software industry. I treated both as the same problem: designing an enabling human system naturally shaped around the software we needed.

Mental Models and Maps: A shared layer of understanding is essential in all human systems: something devs can use to coordinate, leaders can use to report and audit, and everyone can use to communicate. System maps are one of the best tools for creating this layer.

Pull over push: Push systems work well when the path is predictable and linear. Ours wasn't. We had a creative team and non-linear work, so a pull system fit better: work taken up via self-organizing rules, ideal for parallelization and autonomy. But pull only works if the system is legible, trustable, and accessible to everyone who needs to act on it.

EXECUTION // 03

THE PROCESS

Making the Maps

The first map was the technical architecture. On Miro I mapped every component, interface, and integration point, then reviewed it with all the main stakeholders until we could confidently talk through the entire flow. This surfaced assumptions, improvements, and consensus early and gave us a shared language for design decisions.

Interfaces turned out to be a key insight. They mark natural seams for slicing work, and here's why that matters for team flow: when a developer works within a bounded interface, they can own their implementation for as long as possible without needing to coordinate or think at a higher level than what the interface asks of them. They become a temporary specialist in that region, and the interface itself protects their focus. This is also what unlocks parallel work: multiple people can build simultaneously within their own bounded regions, confident their work will connect cleanly at the interfaces.

With the shape of the software architecture now understood, and the seams identified, I could use that original architecture map to give shape to the human system. I created a second map: a dependency map showing units of work and how they connected and built off each other. Units were defined functionally (encouraging ownership), and hard dependencies were explicit (so anyone could see what was blocked or ready). The overall sequence retained enough linearity to track true completion, test holistically, and mark milestones. And the whole thing was legible enough that team members could pull work without needing to understand the entire design.

Communication and Facilitation

A map is not a system. The dependency map only becomes useful when people trust it, know how to read it, and start expecting other people to know how to do so as well. So I presented it often, kept it current, answered questions, and made sure it stayed trustworthy. Over time, it became what's sometimes called an "information radiator": an artifact that actively broadcasts information that people can coordinate reliably around.

This is where the principles came together. Because the map's shape matched both the software architecture and the team's working patterns, they built off of each other and became a shared mentality, which ultimately translated into enablement: each person throughout the process had exactly the information they needed to act, exactly when they needed it.

OUTCOMES // 04

THE RESULTS

No unclear assignments, no convoluted status meetings. Just clear, visible work and ready visual aids and language for when we needed to focus in on tactical problems.

We delivered on schedule, with the whole team building in parallel and minimal coordination overhead. The team was talented, motivated, high-trust; but even with such a great team, I don't think that happens automatically. What I'm proudest to have contributed was the scaffolding: a system grounded in systemic design principles that let that excellence of the team express itself with as little friction as possible.

REFLECTION // 05

THE LESSONS

A lot of work goes into making things feel effortless in the face of complexity, but there are real tools to do it: the nuances of Conway's Law, mapping techniques, the human factors of teamwork as expressed in Team Topologies, a solid grasp of interfaces, and the basic skills of facilitation. These aren't just theories for intellectual exercise; when you know how to weave them together, they become the material of impactful infrastructure for the team to move inside of.

PERSONAL NOTE: On a more personal note, this was an early instance of me realizing how much I loved systemic design and what this particular set of skills can achieve. A lot of this is specific to software and software project management, but delving deeper into how to summon the fundamental ways things work together and applying it to a specific domain goes beyond just project management or software engineering and becomes something more; something I have been pursuing ever since.