Before I moved from BORN Group to Cognizant, I thought I understood the difference between agency work and enterprise consulting. The obvious version: agency work moves faster, enterprise work has more process. That is true, but it is not the part that changed my day-to-day thinking.
The bigger difference is this: in agency work, you build for delivery. In enterprise consulting, you build for continuity. Those sound like a small distinction. They are not.
Agency work: build it, hand it over, move on
Agency work teaches a particular kind of sharpness.
At BORN Group, projects like Xcite.com, Dakine, Mapemall, and Mothercare all had real delivery pressure. A launch, a scope boundary, a client timeline. That environment is good for learning quickly. You see multiple industries, multiple codebases, multiple ways that teams make tradeoffs under pressure. A few years of that calibrates your judgment fast: what matters for launch versus what can be deferred, what “good enough to ship” looks like when the clock is running.
What agency work is less good at is making you feel the full weight of long-term ownership. Post-launch support exists, there are maintenance retainers, clients call when things break. But the emotional operating model stays closer to delivery than to becoming part of the ongoing memory of a system. Once the code is handed over, someone else carries it forward. That handoff is both a freedom and a limitation, and the limitation is not always obvious until you stop doing it.
Enterprise consulting: you’re living with this for years
Moving to Cognizant and working on Newell Brands changed the time horizon completely.
The question was no longer only “can we deliver this well?” It was also “are we willing to live with this design for the next few years?” Those are not the same question, and they produce different decisions.
Once the horizon is long, shortcuts acquire a longer shadow. Naming matters more because the next person to read the code might be you in eighteen months. Documentation matters more because decisions that seem obvious now become mysterious once the context is gone. Upgrade paths matter more because the system will have to move forward, and whether it can do that cleanly depends on choices being made right now.
The most concrete change: what I was suspicious of. In agency delivery I was more willing to accept “this works and fits the deadline.” In enterprise consulting I started asking “will the next engineer understand why this exists when they touch it six months from now?” That is a genuinely different filter.
The documentation habit
In project-delivery mode, documentation is easy to treat as secondary. You are building toward a launch and the most important thing is that the code works.
In long-term systems work, undocumented decisions do not disappear. They come back as slower debugging, slower onboarding, and weaker ownership. The engineer who inherits the system six months later — often you, or someone you care about — has to reconstruct context that should have been written down. That produces code comments that say “not sure why this exists” instead of “this handles the edge case where X.”
The habit I built was minimal but specific: before leaving a non-obvious decision, write a sentence about why it was made this way rather than another. What assumption does it rely on? What breaks if the underlying condition changes? Not a lot of text. Just the text that prevents a future debugging session from taking four hours instead of thirty minutes.
Stakeholder communication
In agency environments, communication has a delivery shape. Project managers, milestones, status updates, client expectations tied to scope and timeline. Technical engineering questions and business questions are often separated by a project management layer.
In enterprise consulting, that layer is thinner or absent. You are working continuously with the client’s team rather than delivering to them. The conversation becomes about stability, tradeoffs, and operational confidence. You need to explain why a technical choice matters over a longer time horizon, why a shortcut is a risk, why consistency in one area prevents a whole class of future problems.
That requires better technical communication, not louder. The ability to explain consequences clearly to someone who does not live in the code every day became part of the engineering skill set. I was not good at this when I started at Cognizant. The first time I had to explain to a non-technical client stakeholder why the right fix was a larger refactor rather than a quick patch, I did not have a convincing way to say it. That got better over time, but it required deliberate work.
What changes and what doesn’t
There are things I still value from agency work. The variety of seeing many different businesses and codebases in a short period is hard to replicate in a long engagement. The sharpness that comes from building toward a visible launch is real. Delivery pace forces prioritization in ways that slower work does not always demand.
What long-term consulting forced me to respect more deeply was the second half of software life: maintenance, evolution, the quiet accumulation of clarity or confusion in a codebase over time. Agency work optimizes the first half. Enterprise work teaches you to think about both.
If I had stayed only in agency delivery, I think I would have remained good at building things that work on launch day and not as good at building things that hold up over time. The move did not make agency work wrong. It made my picture of software development more complete. I started understanding what the handoff actually cost when the people on the receiving end had to maintain what I built.
That is a useful thing to understand before you stop being the person who builds and become the person who has to maintain.