The Question Worth Asking
You've probably seen it happen. A firm invests in a new system — case management, billing, document automation, the works. Six months later, the team is still coordinating on WhatsApp. The accountant still maintains a separate spreadsheet. Someone still prints the cause list every morning. The system is there. It's running. But nobody is living inside it.
And then there's another firm — similar size, similar practice areas, similar budget — where the system has genuinely changed how work gets done. Deadlines don't depend on memory. Client communication is consistent. Billing is accurate and timely. The team trusts the platform because it reflects how they actually work.
Same category of software. Very different outcomes.
What made the difference?
What the Research Tells Us
The Standish Group's CHAOS report — one of the most comprehensive studies on technology projects, analysing over 50,000 projects globally — found that 66% of technology projects end in partial or total failure. Two out of every three. Not because of bad technology or insufficient budgets. The software worked. The money was there.
KPMG found that 70% of organisations suffered at least one project failure within a twelve-month period. McKinsey found that 17% of large IT projects go so badly that they threaten the very existence of the company. And perhaps the most telling number: research shows that 45% of features built into software projects are never used. Nearly half of what gets built sits untouched.
So IBM studied over 1,500 change practitioners worldwide to understand why. The answer wasn't technical. The biggest barriers to success were human:
Changing mindsets and attitudes — 58%. Corporate culture — 49%. Lack of senior management support — 32%.
The researchers noted something important: these challenges were flagged as more difficult to solve even when given sufficient resources. Money doesn't fix them. More features don't fix them. Only human commitment does.
This is the dividing line between systems that transform and systems that collect dust.
How Systems Quietly Become Filing Cabinets
It usually starts with good intentions. A managing partner recognises the firm needs better systems. They research options, sit through demos, approve the investment. The software gets installed. The team gets trained.
And then daily life takes over.
The managing partner — the busiest person in the firm — steps back into their caseload. The associates attend training but return to the habits they know. A senior partner asks for something printed because that's what feels reliable. Someone starts a WhatsApp group for a matter because it's faster than learning the task management module. The accountant keeps their Excel sheet running alongside the billing system, just in case.
None of these decisions feel wrong in the moment. Each one is a small, rational response to time pressure. But they accumulate. Within months, the firm is running the new system alongside all the old ones — WhatsApp groups, printed documents, Excel sheets, email chains, physical diaries. Not two systems. Eighteen parallel systems. More complexity than before, not less.
The system didn't fail. It was never fully adopted. The firm bought a new tool and continued to think in the old one.
Why Law Firms Are Especially Vulnerable
This pattern can happen anywhere, but law firms face a unique combination of pressures that make it almost predictable.
Everyone is stretched. Managing partners carry enormous responsibility. Associates juggle multiple matters. Support staff keep the firm running hour by hour. Finding time for a technology project — real, focused, thinking time — is a genuine sacrifice. The irony is that the people who most need the system to work are the ones with the least time to invest in making it work.
The profession rewards caution. Lawyers are trained to verify, to document, to rely on precedent. When a partner says "I need a printed copy," it often reflects a legitimate professional instinct — physical documents feel verifiable and defensible. In Kenya, where many court processes still require physical filing, that instinct is frequently correct. It's wisdom, not stubbornness.
Trust is earned through experience, not installation. When someone prefers their WhatsApp group over an automated reminder, they're making a reasonable judgment: "I trust a human response more than a notification from something I haven't fully learned." The system needs to prove itself through daily reliability before it can replace the habits that currently keep the firm safe.
These aren't obstacles to be bulldozed. They're realities to be respected — and designed around.
What Actually Makes the Difference
If the research points to one thing consistently, it's this: the systems that transform firms are the ones where leadership stayed involved.
Not as a sponsor who approved the budget. As a participant who helped shape what the system became.
This doesn't mean a managing partner needs to become a technologist. It means they need to be present — at least periodically — when the important questions are being asked:
What are our firm's values, and how should they show up in our daily workflows? What does consistency look like across our practice areas? How do we want to handle client communication? What policies should the system enforce — and which ones are we not enforcing today? Where are we losing time, trust, or talent because of gaps in how we work?
These are leadership questions, not technology questions. And they can only be answered by the people who carry the firm's vision.
The system then becomes the mechanism that holds those answers in place — daily, consistently, without fatigue. It's not the software that transforms the firm. It's the policies and values embedded in the software that do. But those have to come from the firm's leadership. No vendor can invent them for you.
What a Transformed Firm Actually Looks Like
When the commitment is there — when leadership invests the time and the firm embraces the change — the results are quietly remarkable.
A new client walks in. Their information is captured once — not scribbled on paper to be entered later, but recorded at the point of contact. A matter is opened. It's linked to the client, assigned to an advocate, and structured around milestones that reflect how the firm actually delivers its services. Every instruction from the client is logged with dates, details, and the responsible person. Nothing depends on someone remembering.
A deadline approaches. The system surfaces it — not as a notification that fires into the void, but as part of a visible workflow where the team can see what's pending, who's responsible, and what's been done. The managing partner doesn't need to chase anyone on WhatsApp. The information is there.
A bill goes out. It's generated from actual work recorded against the matter, guided by the fee structures the firm has set, with a complete audit trail. The accountant isn't reconciling between three spreadsheets. There's one source of truth.
And perhaps most importantly — when a new associate joins the firm, they don't spend weeks trying to figure out how things work by watching and guessing. The system itself teaches them the firm's processes, standards, and expectations. The way the firm works is documented not in a manual that sits in a drawer, but in the workflows they use every day.
This isn't a fantasy. It's what happens when a firm treats technology adoption as a practice transformation — not a software installation.
The Partnership That Makes It Possible
Here's something worth knowing about how this actually works when it works well.
The firms that succeed don't just buy a system. They enter a partnership. The process usually looks something like this:
It starts with understanding — a genuine assessment of how the firm operates today. Not a features checklist, but a conversation about workflows, pain points, practice areas, and culture. What's working? What's breaking? What do the partners care about that isn't being enforced?
Then comes configuration — working alongside someone inside the firm, a subject matter expert who understands the daily reality of the practice, to shape the system around how the firm actually works. Not a generic template. Not best practices borrowed from a firm in London. The firm's own processes, made visible and consistent.
And then comes the hardest part — the transition. Changing habits. Learning to trust the system over the workarounds. Having the managing partner reinforce the new way of working, not just approve it from a distance. This phase takes patience, support, and genuine commitment from both sides.
The firms that get through this phase are the ones that transform. The firms that skip it are the ones whose systems collect dust.
How I Ended Up Here
I didn't start my career in legal technology. I never even thought it existed. When a client first approached me with a legal tech project, I was reluctant — genuinely reluctant. I told them I don't understand this and I don't want to do it. I let them go get it elsewhere. They did. They came back. I said no again. They came back a third time.
Maybe there was something this person saw in me that I didn't see in myself. But I didn't finally say yes because I suddenly understood legal tech. I said yes for two reasons: I could see her business was genuinely suffering, and I wanted to help. But I also needed assurance — real assurance — that she would give her all to this project. Because honestly, to me this was more of a sacrifice than a business opportunity. I was in the middle of parallel projects. I didn't care how much she would pay me. What I cared about was whether she truly needed this and was willing to do what it would take.
She had already tried twice with other providers and failed. She was desperate. I did not want to be the third failure — one that would ruin our friendship and damage her business beyond recovery. So I had to do everything possible to make sure this would work. I knew budget wasn't her problem. And my technical ability wasn't the obstacle either. The obstacle would be in communication, commitment, dedication, patience, and the willingness to change.
So before we wrote a single line of code, I asked for something unusual. I asked for a four-hour meeting. Tuesday. 8am to 12pm. For an advocate of her standing, that was a serious overstretch — an advocate will almost never give you that kind of uninterrupted, quality time. But I needed to understand her priorities. I needed to know what mattered to her, not just what she thought she wanted in a system.
Before that meeting, I sent her a thirty-page document. Not a proposal. Not a quote. A framework for thinking through what we were about to build together. And I insisted on one principle from the start: systems are built by engineers, but they are architected by those who need them. Everything I asked of her had nothing to do with budget. It was about extreme dedication, sacrifice, and commitment.
Contracts are important — they protect interests. But sometimes they are also one of the biggest obstacles to genuine partnership. What held this project together wasn't a legal agreement. It was a mutual promise to show up.
The first few months were overwhelming for her. And this is where I learned something that changed how I work forever. As developers, we instinctively want to abstract everything — simplify, hide the complexity, make it easy. And that's often where we fail. Because when you shield your client from the process, they never develop a relationship with what you're building. But when you develop with them — when they're in the room making decisions, seeing the system take shape around their own thinking — something different happens. They develop a sense of ownership. They feel part of the system. And once something tangible is up, they embrace it naturally.
All I did as an engineer was write the code. My client decided she wanted the button green, not blue. She wanted a task called an "instruction," not a "task" — because that's what advocates call it. She dictated almost everything. The system became hers, not mine.
Seven months later, the project was done. What started as an overwhelming sacrifice turned into a business opportunity and a masterclass in how to develop systems that people actually want to use.
But is it sustainable? Can you do this with two hundred firms? Honestly, no. You cannot do this at scale. And that's exactly where the philosophy for Sisu by Lenhac came from — one law firm at a time.
When I went back to evaluate all my failed projects, the pattern was undeniable. It was never about money — I've been fortunate to work with clients where an invoice is never a point of contention. It was about time. The decision-makers who signed the cheque and disappeared were the ones whose systems collected dust. The one who stayed in the room, who fought through the discomfort of changing how her firm operated — hers was the firm that was transformed.
Before You Decide
That experience — and every project since — taught me that the questions worth asking before a technology investment have very little to do with technology.
Whether you work with us or someone else entirely, here's what I'd invite you to sit with:
What problem am I actually trying to solve? Not "go digital" — that's a direction, not a problem. What specific friction, risk, or inefficiency is costing your firm right now?
Am I ready to invest my own time? Even a few hours a week, consistently, over months? The managing partner's presence — even periodic — changes the entire trajectory of a project.
Have I thought about the policies and values I want this system to enforce? Technology is a container. What matters is what you put inside it.
Am I prepared for the discomfort of changing habits? Not just my own, but my partners' and my team's? Ways of working that have been good enough for years will be challenged. That's uncomfortable. It's also where transformation begins.
Am I willing to be part of building this — not just approving it? The systems that work are the ones where the people who need them helped architect them. A green button instead of blue. An "instruction" instead of a "task." These details seem small, but they're the difference between a system your team tolerates and one they embrace.
If these questions energise you rather than exhaust you — if reading them makes you think, yes, this is the kind of thinking our firm needs to do — then you're ready. Not just to buy a system, but to build something that genuinely changes how your firm works.
Comments (0)