The Case for Being Close to the Work

At arm’s length is exactly how things get built in most organizations. Engineers deliver based on specifications that have lost almost all context about the “why” as it travels down the chain of command. Shipping a feature turns into an expensive game of telephone. Unfortunately, this is by design. The handoffs are long, the chain of command is deep, and the work that gets approved is the work that's least disruptive to approve.

When I broke into software, I had no idea that I was operating inside a rare exception to this pattern. Exposure to this startup-like environment early in my career cultivated a mindset in me that set a standard for what “shipping fast” and “impact” meant, but I found that very few organizations are structured in such a way to bring these results out of people.

Boot Camp

At Morgan & Morgan, the largest personal injury firm in the United States, I worked on systems that powered the firm's daily operations. Not as part of a team; there was no internal R&D department at the time. I operated as a sole contributor working directly with individuals on solutions. Almost all projects were greenfield, and I got to see how my efforts transformed how my users worked in real time. I got used to figuring out how to solve problems and deliver solutions quickly without any hand-holding.

Sometimes that meant walking up to paralegals and case managers in the office and interviewing them about pain points they were experiencing with a piece of software. Other times it meant Sunday morning calls with the firm's CIO, COO, CEO, and other senior stakeholders, working through planning, timelines, and the occasional production issue on systems I was building.

That kind of access was essential. I was lucky enough to work with a CIO who understood this and trusted me enough to drive projects and deliver. This gave me the perspective needed to understand problems on a deeper level and put me in a position where I was allowed to move fast.

When you're solving an operational problem at a firm of that scale, the only way to deliver a system that works for the firm is to cut out as many unnecessary players in the game of telephone as possible so that the person who has the pain is as close as can be to the person implementing the fix.

Most consulting engagements never close this gap because the consultants either don't have the breadth of skills needed to understand the problem and solution, or they don't have the vertical access to see the actual problem in full. The engineer who lives inside the operation can, if they are allowed to and have the grit.

Taking the Firm Paperless

One of the most ambitious projects to come out of my time at Morgan & Morgan was the implementation of a system for sending and receiving documents completely electronically. On this project I was again allowed to take full ownership of the architecture and implementation of the system. The inbound mail portion revolutionized our operations and pushed my engineering ability further than anything had. Because there was no one else to discuss design decisions with I could iterate quickly, see what worked, discard dead ends and build on. I could spend two days ideating on best practices before implementing. Because there were no experts, I became the expert.

The pitch was simple. The execution was not.

Mail came in physically, got scanned by a third-party document processor (Docufree), and needed to land inside the firm's case management system, classified automatically and attached to the right matter. At the time, that system was Aderant Total Office. Attorneys and paralegals shouldn't have to worry about manually integrating another SaaS product into their workflows. The documents needed to appear in their case file, flagged as new and ready for review.

Aderant didn't have a public API for this. There was no integration vendor to call. No documentation that explained how case documents lived inside the system, what database tables they touched, or how the "new document imported" flag was set when staff scanned things in manually. I had to reverse engineer system behavior: the data model, the table and column names, the bit that triggered the staff notification. Finally I was able to build an integration that wrote into that model directly, set the flag the way Aderant set it, and made the result indistinguishable from a manually imported document.

I stood up an API endpoint that Docufree could submit to, secured by best practices. From the staff's perspective, mail just appeared, indexed, in the right place, on the right matter, with the right notification. They never knew there wasn't supposed to be a way to do that.

Outbound was implemented right when COVID started and couldn't have come at a more critical time. Offices were closed and lockdowns were in effect. We needed a way for our attorneys to be able to communicate with clients in order for the firm to continue operations. I finished the outbound mail system in two weeks working from home.

That's the work behind the dollar figure. A conservative estimate puts the savings at over $100,000 a year in the Atlanta office alone, in the labor of the full-time runners the system replaced. By the time I left, it was trending toward firm-wide adoption, which would push the savings into the millions annually.

This is what ownership of the whole problem produces.

Migrating the Firm

Taking the firm paperless proved what one person could build. Migrating it proved what one person could be trusted with.

When the firm decided to move off Aderant onto Salesforce/Litify, decades of legal documents had to move with it, totaling petabytes. I was responsible for the tool that made the migration possible; long-running jobs that searched databases for files, pulled them from their physical locations on disk and uploaded them to S3. The tool had to run for weeks at a time, enduring outages, API rate limiting, disk-read errors, request timeouts, and more. If it crashed or the system lost power, it had to resume exactly where it left off, without missing a single byte. And all of it had to happen without once breaking privilege or chain of custody, two things law firms can never get wrong.

Migration tooling was one slice. The harder slice was data model mapping. Aderant's internal model and Litify's are not compatible by default, and a clean migration is the difference between the new system being adopted and the new system being abandoned. I worked alongside the Litify migration team to map the firm's existing workflows (the way staff actually moved cases through the old system) onto the new one, so attorneys and paralegals didn't have to relearn their jobs the day the cutover happened.

I built Litify-specific features the platform didn't ship with: inbound and outbound mail handling, document preview before send, and the kind of operational glue that makes a platform feel native to the firm rather than imposed on it.

The stakes were high. So much could have gone wrong, and yet the firm trusted me to do it anyway. Not because they couldn't have brought in outside experts, but because I had already built a track record of execution. They let one person build the tool that moved every file Morgan & Morgan had. That is an enormous responsibility to hand to an individual, and handing it over is exactly the kind of trust that produces this kind of work.

What Came After

Eventually, the role itself was the thing that changed. The firm decided to formalize what had been a role led by trust and proximity into one of distance. The thing that had made the work fast and the impact outsized was being structured into a job with the usual layers of managers, process, and chain of command. That structure is a defensible choice for any growing organization. It just wasn't the work I had signed up for.

So I left, expecting to find the same conditions somewhere else. I didn't.

The next chapter was a year at a consulting organization that turned out not to be the right fit. I delivered anyway. While I was there, I scoped, architected, pitched, built, and handed off a full automation engagement for Elon University, solo, without support from my team. The university was thrilled. The engagement proved I could carry that level of ownership outside the firm. It also proved the team around me wasn't the source of my impact, and never had been. It was always proximity to the stakeholder, to the people whose pain I was working to remove.

I left within a year and went to a much larger organization. More money than I'd ever made. Less meaning than I'd had since I started my career. The work was real, but it was downstream of so many decisions, made by so many other people, that the connection between my code and the people it served had been severed entirely. I became a cog in a machine, and I could feel it.

Every organization I moved to was already structured the way the firm had been moving toward when I left. Layers, queues, managers, process. This is what scaling well is supposed to look like, and for most organizations it genuinely is. It just isn't where my kind of impact comes from. The conditions that had produced my best work at the firm weren't the industry default. They were the exception, and almost nobody was building them on purpose.

The Thesis

The realization was simple but it took the detour to land: outsized impact requires specific conditions. Proximity to the people who feel the result. Ownership of the whole problem, not a slice. Permission to move fast and ship. Those conditions don't exist inside most large organizations. They have to be built intentionally.

That's what Tenologik is.

Tenologik exists to recreate the conditions that produced the work above and point them at clients who can't build that capability internally. Law firms that are leaking billable hours to manual processes. Professional services firms drowning in administrative drag. Operations-led SMBs that need one well-built system more than they need a fifty-person internal IT team.

Nothing in the years between has felt as alive as those early years did. That feeling set the standard for the kind of environment I'll work in, and the kind I now build for other people.

Most organizations respond to growth by adding another layer of management, another approval, another step between the person with the problem and the person who can fix it, and then wonder why output keeps dropping. I've come to believe the answer was never more oversight. It's more trust and more autonomy to build what matters. The clients worth working with already sense this; they just haven't found someone who can build for it.

If your operation is leaking time and money to work that should already be automated, and you've felt the distance between the people with the problems and the people who can fix them, let's talk. I've built the alternative from the inside, and I build it for a living now. Book a Discovery Call →