Building a Department from the Ground Up
akoyaGO | Philanthropic Technology | 2018–2022
What this is
akoyaGO builds database software for community foundations, family foundations, and donor-advised funds — organizations managing anywhere from a few million to hundreds of millions in philanthropic assets. The clients are sophisticated and the work requires an unusual combination of technical fluency and relational trust.
When I joined, the company was growing. New clients were coming in, the product was strong, and the infrastructure for supporting those clients at scale hadn't caught up. There was no Account Management department — just a loose collection of individuals trying to serve clients as best they could without shared systems, shared documentation, or a clear model of what client success actually looked like at akoyaGO.
The practical consequences were significant: client relationships lived inside individual people's heads, training was inconsistent, problems escalated before anyone caught them, and clients were dependent on us for things they should have been able to do independently. Dependency like that isn't good for clients and it isn't sustainable for the team carrying it.
Why this approach — and not another one
The most obvious intervention would have been to hire more people. More hands on client relationships, more capacity to absorb the support load. I didn't recommend that, because adding headcount to a system without structure doesn't fix the system — it just distributes the dysfunction more widely and makes it harder to see.
The second obvious intervention would have been to standardize the existing support processes. But standardization without a clear theory of what success looked like for each client would have just made the inconsistency more official.
I started with documentation because it forced a different question: what do clients actually need to know, and by when, to run their own operations independently? That question reframed the work. The goal wasn't to support clients better — it was to make ourselves unnecessary for the things they should own. That distinction changes everything about what you build.
The learning management system came from a specific diagnosis: clients weren't retaining training because they had no way to return to it. One-off sessions, however good, evaporate. The LMS wasn't a technology choice so much as a memory architecture choice — building the infrastructure so that client knowledge accumulated in their organizations instead of requiring us to re-deliver it repeatedly.
The 20+ customized data management systems came from a similar principle. A single standardized workflow wouldn't have worked here — client foundations vary significantly in how they structure their grantmaking, their reporting, and their internal roles. The customization wasn't scope creep; it was the point. The goal was always workflows their teams could actually navigate independently, which meant they had to be built around how each organization actually operated.
Building the account management function as a formal department was the structural piece that made the rest sustainable. What had existed before was informal and person-dependent. I made the case internally that the company needed an explicit function — not because it would look better on an org chart, but because without named ownership and shared infrastructure, the quality of client relationships would remain tethered to which individual happened to be staffed on the account.
What would have broken
The dependency problem was real and underappreciated. If I had prioritized relationship quality over structural independence — which is a natural instinct in a relationship-driven industry — clients would have gotten better service in the short term and remained just as dependent in the long term. High support volume would have continued even as the team grew, because the underlying dynamic hadn't changed.
The documentation-first approach carried its own risk: documentation nobody uses. Process maps and training materials only work if they're built around how people actually work, not how you wish they worked. Early versions of some materials had to be rebuilt because they reflected our internal logic rather than the client's. That was a real cost.
The account management structure also required the company to make a bet about what kind of company it was becoming — one where client relationships were a strategic function with its own standards, not a support overhead. That's a leadership decision, not a process decision. I could build the infrastructure, but I couldn't make that bet for them. Getting alignment on it early would have made some of the structural work faster.
What I learned
The work taught me something I've carried into every engagement since: the most expensive thing an organization can do is keep doing something in a way that only works because of who's doing it. Person-dependent systems feel like relationship strength from the inside. From the outside — from the client's perspective, or from a new hire's perspective — they're a liability. Making knowledge institutional is an act of respect for everyone involved: the client, the team, and the organization's future.
I also learned that the case for structural change is most effective when it's made in operational language, not organizational language. "We need an account management department" is a harder sell than "here's what's breaking and here's specifically what would stop breaking if we built this function." The second conversation is about the work. That's where I try to stay.
Outcomes: Client organizations moved from dependent to empowered. Support request volume decreased as self-serve adoption increased. Knowledge moved out of individuals and into systems. The team had the infrastructure to scale without the burnout that comes from carrying relationships without support structures underneath them.
