Mapping how engineers actually ship — and where the organization gets in their way

Context

Namely was a fast-growing HR, payroll, and benefits SaaS in New York. By 2016 the engineering organization had outgrown the habits of a startup: multiple feature teams, a monolithic codebase with a few services breaking off, a growing SRE function, and a release process that had accreted one fix at a time.

The chief technology officer had a question that engineering metrics couldn’t answer: why does shipping feel harder than it should, and what would actually help? Velocity charts showed the symptom. Nobody had a picture of the experience of writing, testing, and releasing code from the engineer’s side — what they believed about the process, where they felt capable, where they felt stuck, and what they thought leadership misunderstood.

He asked design to find out. The brief was not “make engineers faster.” It was: understand how engineers think about the delivery process so the organization can support them properly, and so quality and security come out of the process rather than being inspected in at the end.

Problem

Engineering leadership and engineers were describing the same process in different languages. Leadership saw a pipeline — stages, tools, environments. Engineers experienced a sequence of moments: the part that felt like craft, the part that felt like waiting, the part that felt like a black box.

Three things made this hard to see from the top:

• The pain was distributed. No single stage was broken. Flaky tests, hand-run QA, merge conflicts from large release trains, a deploy nobody could see into — each was tolerable alone and exhausting together.
• Motivation and quality were being treated as separate problems. The org was discussing “engineer happiness” in one meeting and “test coverage and release risk” in another. The engineers never separated them.
• The people closest to the problem had never been asked as a group. Developers, QA engineers, and SRE each had a partial map and a theory about the others.

Approach

Treat engineers as the users, and the delivery process as the product. I ran the study the way I would run discovery for a customer-facing product: structured sessions, individual reflection before group discussion, and a synthesis the participants could check against their own experience.

Recruit across the whole delivery chain. Participants came from the feature teams, core services, QA, SRE, and product — the people who hand work to each other. Mixing them was deliberate: the hand-offs were where the mental models diverged.

Ask about feeling before asking about process. Each person answered the same eight prompts on paper: your role and who you work closely with; the tools you use and the tools you wish you had; when you feel rewarded in the development process, and when you feel frustrated; what you’re proud of, and where the bottlenecks are. The emotional prompts came before the process prompts on purpose. People will tell you what they believe about a process once they have named how it makes them feel.

Build the map in the room, not afterward. With the sheets on the wall, the group named the stages together — writing code, code review, QA testing, UAT, deploy — and then filled five lanes for each: what they’re doing, how they feel, which tools, which environment, and the bottleneck. Dot voting ranked the bottlenecks so the map reflected the room’s priorities rather than mine.

What we shipped

The deliverable was the synthesized journey map, presented to the CTO and the engineering leadership team, and then shared back to every participant.

A few findings mattered more than the rest:

• The emotional low points were not the hard stages — they were the opaque ones. Engineers were happiest writing code and reviewing each other’s. Morale dropped where they lost sight of what was happening: slow and inconsistent test runs, hand-run QA, and a deploy that, in one engineer’s words, became a black box the moment a pull request was created.
• Quality problems and motivation problems had the same root. Fragile tests, large release trains, and an unpredictable scope of change made engineers both less confident in the code and less invested in the release. The org didn’t need a morale program and a quality program; it needed the same fixes.
• Compliance and security were felt as interruptions, not as part of the work. Nobody disagreed with them. They arrived late, at UAT and deploy, with no workflow to meet them earlier, so they landed as friction instead of craft.
• Engineers already had the solutions. The yellow notes — a Git fork and release strategy, breaking the monolith into services, defining required test coverage, fixing every flaky test, documenting how teams merge code — came from the participants, not from a consultant.

The map grouped those into four opportunity areas with named owners: infrastructure (environments, standards, documentation), automation and tools (CI reliability, Git workflow, deployment automation), testing (coverage, flaky tests, the unit-to-acceptance ratio), and deployment impact (scope communication, client notification, compliance, separating deployment from release).

Outcome

• Engineering built a CI/CD pipeline for continuous release — the map’s biggest single opportunity, replacing the infrequent, fixed release train and the hand-packaged deploy that engineers had described as a black box
• Engineers and leadership reached a shared understanding of how to improve delivery efficiency, with one map to prioritize against instead of two vocabularies — the first time motivation, quality, and release risk were discussed as one problem
• The engineers’ own proposals — a Git workflow strategy, test-coverage standards, flaky-test cleanup, documentation on how teams merge code — carried into the improvement roadmap rather than being reinvented by leadership

What I’d do differently

I’d instrument the map. The study captured what engineers believed and felt, and that was the point, but I had no baseline for the mechanics — lead time, change-failure rate, how often a release was rolled back. Pairing the emotional curve with a few delivery metrics would have let leadership see the cost of each low point, and would have given us a way to re-run the map a year later and show what moved.

Why this matters more in 2026

Ten years on, I would make a broader case for this work to any executive — a CTO, a chief product officer, a COO — not only the one who commissioned it. The experience of the people doing the work is an operating asset. Mapping it the way we would map a customer’s journey is the most direct way I know to improve how an organization runs, and that shows up where executives care about it: in the quality, speed, and security of what reaches clients.

The map earned its keep in 2016 by replacing a management view of the delivery process — stages, tools, throughput — with the engineers’ own view of it. That is the method. The specific findings were about a release train and a deploy pipeline, but the pattern underneath travels: people do their best work where the process is legible to them, and they disengage where it goes dark. Every organization has a stretch of its operation that is a black box to the people inside it, and that stretch is usually where quality quietly leaks out.

In 2026 the black box has moved. Across technology organizations, an agent now drafts much of the code, and the engineer’s job has shifted toward specifying, reviewing, and verifying. The part of the work that used to be the reward is partly delegated; the part that used to be opaque — did this change do what it should, is it secure, what else did it touch — is now most of the job. If I were running this study today, I would expect the curve to have inverted, and I would want leadership to see that inversion before it shows up as attrition, rework, or a security incident.

What an executive gets from this is not a morale survey. It is a shared, human-centered picture of how the organization actually operates, drawn by the people who operate it, that puts motivation, quality, and risk on one page. In 2016 that page led to continuous release. In 2026 it would show where to make AI-assisted work legible — reviewable, testable, secure — so that the people building the product can stand behind it, and the clients on the other end get something better.

What I carry forward

Research the people who build the product with the same seriousness as the people who buy it. I lead a design organization inside a bank now, and I still run the same play: ask how the work feels before asking how it flows, build the map in the room, and let the people doing the work name the fixes. Improving how an organization operates in a human-centered way is the fastest route I know to better outcomes for the people it serves — and the fastest way to get a leadership team to see one problem where it had been managing three.