Organization Development for Teams Too Small to Have an OD Department

Most people hear "organization development" and picture a large company with a dedicated team running engagement surveys and leadership retreats. That picture leaves out most of the organizations in the country.

The National Council of Nonprofits reports that 92 percent of U.S. nonprofits operate on less than $1 million a year. (That figure counts many very small filers; Candid's narrower count is closer to two-thirds.) Either way, most nonprofits, like most businesses, are small. They still have structure, culture, decision-making habits, and growing pains. They just don't have anyone whose job is to look at those things on purpose.

That is what OD is: deliberately shaping how an organization works, instead of letting it happen by accident. The classic definition, from Richard Beckhard in 1969, calls it a planned, organization-wide effort, managed from the top, to improve how the organization functions. The word that matters for small organizations is planned. You are going to have an org structure and a culture either way. OD is the choice to design them.

Small organizations don't skip OD. They do it by accident.

Every hire changes your structure. So does every new software tool, every Slack channel, and every "just ask Maria, she knows." In a small organization these changes happen fast and nobody writes them down. Two years later the founder is the bottleneck for every decision, three people think they own the same task, and nobody can remember deciding any of it.

Part of the reason is simple math. Each new person adds more relationships than people.

Here is the math. A one-to-one relationship is any two people who have to work with each other directly. On a team of twelve, each person has eleven colleagues, which gives 12 × 11 = 132. That counts every pair twice (you and Sam, then Sam and you), so you halve it: 66 separate working relationships. Add a thirteenth person and it jumps to 78. The number of relationships grows much faster than the headcount.

A five-person team has 10 of these relationships, and everyone can see all of them. At twelve people there are 66, and no one can watch them all. That is the point where informal coordination starts to fail and teams start saying things like "I thought you were handling that." The habits that worked at five quietly stop working at twelve, and nobody announces the change.

Growth comes in steps, and each step ends in a crisis

In 1972, Larry Greiner described organizational growth as a series of calm phases, each ending in a predictable crisis. The way of working that got you through one phase is the thing that causes the next problem.

Most small businesses and nonprofits live in the first two steps. In the creativity phase, the founder does everything and the energy is high. Then the founder runs out of hours, and the organization hits a crisis of leadership: someone has to set priorities and make the system run. The fix is direction, usually a stronger manager or a more structured founder. That works until capable people start asking for room to make their own calls, which is the crisis of autonomy.

Greiner's model is useful for small organizations because it reframes the pain. If your team feels stuck, it may not be a people problem. It may be the normal friction of outgrowing a phase. That is a design problem, and design problems can be fixed.

Nonprofits have an extra layer: two hierarchies and a funding trap

A nonprofit has a board that governs and staff who operate, plus volunteers who belong to neither chain of command. Who decides what between those groups is one of the most common sources of friction we see, especially during a founder transition.

Nonprofits also face a funding pattern that works against organizational health. In 2009, Ann Goggins Gregory and Don Howard of the Bridgespan Group named it the nonprofit starvation cycle.

Funders expect low overhead. Nonprofits feel pressure to look lean, so they underinvest in systems, training, and management, and they underreport what things really cost. Funders see those low numbers and expect them again. OD work sits squarely in the "underinvest" box. It is often the first thing cut, and the cost shows up later as burnout and turnover.

The practical takeaway: if you lead a nonprofit, name OD and capacity-building as a line item in your proposals. Many funders now say they want to support it. Give them something specific to support.

Where OD belongs on the org chart

In most organizations that have OD at all, it sits inside HR, often in a title like "Talent and OD." We think that is the wrong home, and here is why.

HR is responsible for the employment relationship: hiring, pay, policy, compliance, and employee relations. That work is essential, and much of it is reactive by nature. OD is responsible for how the whole system works: structure, decision rights, culture, and change. When OD reports to HR, it tends to get pulled toward HR's programs, like training calendars and engagement surveys, and away from the harder questions about structure and strategy. Those questions belong at the CEO's table.

Our recommendation: OD should report directly to the CEO or executive director, working side by side with three peers.

• HR / People. OD designs the roles and the structure; HR hires into them, pays them fairly, and keeps them compliant. Neither works well alone. A reorganization without HR creates legal and pay-equity risk. HR without OD fills jobs that may not be designed well.
• Strategy and Planning. Strategy decides where the organization is going. OD decides whether the organization, as it is built today, can get there. A strategy that requires a structure you don't have is a wish.
• Finance and Operations. The budget is a structure. Whatever you fund is what you have actually decided to be. Operations owns how work flows from step to step, and most OD problems show up first as an operations problem: a dropped handoff, a duplicated task, a step nobody owns.

We call these four the design table. A change in one is a change in all of them, so they should meet regularly and not only when something breaks.

The rest of the organization still reports to the CEO. OD does not manage these departments; it works with each of them on a dotted line. Marketing and communications carries the story of any change, inside and out, and makes promises the structure has to keep. Sales or fundraising hands work to the people who deliver it, and that handoff is where many small organizations drop things. IT and systems matter more than most people expect, because software permissions and workflows encode your org chart whether anyone intended it or not. Legal and compliance keeps a reorganization from creating risk in contracts, classifications, or licenses. Programs and delivery are where the work actually happens. Evaluation tells you whether a change worked. DEI and belonging work asks who is heard in the current structure and who is not. For nonprofits, the board, usually through a governance committee, needs a line into this work as well, since board-staff boundaries are part of the design.

In a ten-person organization, none of these are departments. They are hats, and the founder or ED may wear three of them. The reporting line still matters. Whoever holds the OD question needs the CEO's authority behind it, because OD's recommendations often mean changing the CEO's own habits.

Where AI governance fits

AI governance is the newest box on most org charts, and there is no settled answer about where it belongs. It means deciding which AI tools people may use, what data those tools can see, what a person has to check before AI output goes out the door, and who can stop a use that is going wrong. The NIST AI Risk Management Framework treats governance as cross-cutting: it touches every other part of how an organization manages AI risk. That is a good reason to be deliberate about where it sits.

We see four workable homes for it.

• A. Inside IT or technology. The case for it: the people who manage your systems already control access, security, and vendor contracts, so AI tools fit into work they already do. It is the right home if you are building AI into a product. The risk is that AI gets treated as a software purchase, and nobody asks how it changes people's jobs.
• B. Inside legal, compliance, or risk. The case for it: if you hold health, financial, or children's data, or your client contracts restrict how their information is used, the biggest AI risk is a legal one. The risk is that governance turns into a list of things people may not do, and they quietly use AI anyway on personal accounts, where nobody can see it.
• C. With OD, at the design table. The case for it: in most small organizations, the hard AI questions are not technical. They are about roles and decision rights. Which tasks does AI do now? Who reviews its work? Whose job changes, and how do we tell them? Those are design questions, and OD already sits with HR, strategy, and finance where the answers get made. The risk is that OD lacks technical and legal depth, so it needs IT and legal on call.
• D. A small AI council reporting to the CEO. The case for it: once AI touches every department, no single department sees the whole picture. A council with seats for IT, legal, HR, OD, and operations can. The risk is the usual committee problem: it meets, it discusses, and nobody decides. Give it one named chair with the authority to say stop.

For nonprofits and regulated businesses, the board should oversee whichever option you choose, usually through a risk or governance committee. That oversight sits above the placement; it does not replace it.

How to decide where AI governance goes

Start with size. Under about fifteen people, AI governance does not need a home of its own. The CEO or ED owns it directly, with a one-page AI use policy and a current list of the tools in use. Past that size, ask which AI risk would hurt you most, and put governance with the function that understands that risk best.

Our suggestion for most small businesses and nonprofits is option C: put AI governance with whoever holds the OD question, and bring IT and legal in for their expertise. At small scale, AI is mostly changing how work gets done and who decides what, and that is OD's territory. Our own rule is an example: AI can draft, but a person sends. That rule is not a technical setting. It is a decision about who is accountable for what leaves the building, which makes it a structure decision.

Wherever you put it, write down three answers. Who keeps the list of AI tools in use, and what data each one can see? Who can say stop? Who trains people on what is allowed and what a human has to check? An organization that can answer those three has AI governance, whatever box it sits in.

OD shows up in every department's work

Because OD looks at the whole system, it touches every function. Here is where the crossover usually happens.

Two of these surprise people. The first is marketing. Your brand makes a promise to clients or the community, and your organization has to be built to keep it. If your website promises a response within one business day, someone's role has to include answering, with coverage when they are out. The second is finance. Turnover, rework, and meetings that go nowhere are real costs. OD and finance working together can put a number on them, and a number gets attention in a way that "morale is low" does not.

For OD practitioners: your tools assume scale

This section is for the OD professionals reading. Many standard OD tools quietly assume a large organization. At small scale they break in specific ways.

• Anonymous surveys stop being anonymous. On a team of eight, a comment about "my manager" identifies the writer. Use facilitated group conversations or one-on-one interviews with an outside facilitator instead.
• Benchmarks stop meaning much. A score of 3.8 compared with a national average tells a nine-person team very little. Compare the team with itself over time.
• Your best data is already in the systems. Time tracking, ticket queues, calendars, CRM records, and who gets copied on which emails form a detailed record of how work actually flows. We call this "the system logs are the survey." It shows real behavior, not reported behavior, and nobody has to fill anything out.
• Structure lives in software. Melvin Conway observed in 1968 that systems end up mirroring the communication structure of the organization that builds them. In a small organization the reverse is also true: the tools you configure become your org chart. Who can approve an invoice, who sees which client folder, and which Slack channels exist are structural decisions, often made by whoever set up the account.

What we found when we ran OD on ourselves

Launch runs on the same kind of systems we build for clients, and that includes being honest about our own drift. Earlier this year we looked at how our software defined "who is on which team." We found four separate systems answering that question. Only one of them was actually connected to anything people used. The other three disagreed with it and with each other, and some team records had no members at all.

Nobody made a bad decision. Each system was set up at a different time, for a good reason, by a different person. That is exactly how structural drift happens in small organizations. We consolidated to a single source of truth and kept the old records archived until we were sure nothing depended on them.

The second thing we changed was how decisions get made when the founder is busy. That is the crisis of leadership in a very practical form: work stalls while it waits for one person. We now keep a shared decision log. When a question needs an answer, the person asking writes it down along with the assumption they are proceeding under, and then keeps working. When the answer comes back, it is easy to see whether anything needs to be revisited. Work no longer waits on a single inbox, and decisions that turn out to be standing policy get written into our knowledge base so nobody has to ask twice.

A one-page checkup

If you want a simple way to start, Marvin Weisbord's Six-Box Model from 1976 still holds up. Here is the question we ask small teams in each box.

You don't need a consultant to ask these. Pick the box that made you wince and start there.

Where to start this month

• Write down who decides what. A simple RACI chart fixes more confusion than most retreats. Our guide: What Is a RACI Matrix?
• Pick one source of truth for your team structure. One roster, one place that says who is on which team, owned by one person.
• Schedule a structure review at headcount milestones. When you pass 8, 15, and 25 people, stop and ask whether the way you are organized still fits.
• Give someone the OD question, with a line to the top. In a small organization this may be the CEO, the operations lead, or an outside partner. What matters is that it is someone's job and that person can raise issues directly with the CEO or ED.
• If you are a nonprofit, put capacity in the budget. Ask funders to fund it by name.

Organization development at small scale is not a big program. It is the habit of looking at how your organization works on purpose, a few times a year, before the next crisis arrives.

If you would like help with that, our Organization Development team works with small businesses and nonprofits on structure, change, culture, and founder transitions. Or come to one of our free Friday classes and ask us anything.

Sources: Beckhard, Organization Development: Strategies and Models (1969); Greiner, "Evolution and Revolution as Organizations Grow", Harvard Business Review (1972, revised 1998); Gregory and Howard, "The Nonprofit Starvation Cycle," Stanford Social Innovation Review (Fall 2009); National Council of Nonprofits, Nonprofit Impact Matters (2019, based on 2016 IRS data); Weisbord, "Organizational Diagnosis: Six Places to Look for Trouble" (1976); Conway, "How Do Committees Invent?" (1968); National Institute of Standards and Technology, AI Risk Management Framework 1.0 (2023).