Growth challenges the structure of any organization. In my experience, it’s easy to let those changes sneak up on you. As part of our recent work on structure, we’ve decided to adopt the “consultancy matrix” that Shawn Crowley’s written about recently.

One of the early milestones in our recent structure refactoring journey was to identify what I call the architecture of our company. Our architecture is simple, with just four abstractions, and clear relationships between them. But like our vision to be a 100 year old company, it’s proven surprisingly useful in making day-to-day decisions. Just like with software, having the right abstractions and relationships makes implementing a system feel easy and natural.

Abstractions

Here are the four abstractions in our company architecture. We refer to our architecture internally by the acronym ATOC, pronounced “ay-tock”.

Atom

The individuals of Atomic.

Responsible to:

Satisfy our few, basic, expectations. Solve problems for clients, create great products, and/or keep the business running. Seek mastery of their craft. Gradually but continuously improve themselves. Share and live by our six values. Work autonomously and collaboratively. Resolve their Fear, Uncertainty, Doubt, and Anger. Give and receive feedback effectively. Innovate. Help market the company. Think like a consultant.

Team

A group of Atoms with a clear purpose.

Responsible to:

Deliver on our two-sided brand promise: great product for the client, great project experience for the customer. Self-manage. Spend wisely. Be predictable in time and money. Create value. Innovate. Organize work in projects. Collaborate.

Office

A co-located group of Atoms, and the physical space where they work.

Responsible to:

Provide a comfortable, safe, inspiring space for teams. Keep makers busy on client work. Sell our services. Contribute to and engage with the local community. Grow individual Atoms. Socialize.

Company

A service provider to Atoms, Teams, and Offices.

Responsible to:

Tell the company story effectively. Keep the books straight. Manage ownership matters. Select and hold office leadership accountable. Represent the company as a whole. Maintain and communicate vision, mission, and values. Push when and where necessary. Make investments for the future. Manage structure and growth. Define and maintain legal entity, brand promise, service offering, employee benefits, and expectations.

What it Looks Like

Here are a few different ways of representing our architecture graphically. The first is suggest the compositional relationship of the abstractions. The second is inspired by a network protocol stack. Neither is a perfect representation, but both capture some important aspects of the architecture.

Utility of Our Architecture

If our ATOC architecture wasn’t useful to us, it wouldn’t be worth naming, or writing about. Utility means helping us make business decisions, clarifying responsibilities, suggesting possible growth paths, and flagging things that don’t fit. Here are some examples of that utility.

• Scale – Adding offices would appear to allow the company to scale 2-4x without restructuring.
• Brand – Each office conforms to the same brand promise and brand standards, as defined by the Company.
• Accountability – Managing partners in one office neither report to nor are responsible for other offices.
• Hiring – Makers in one office shouldn’t influence or be responsible for hiring makers in another office. Hiring standards and employee expectations should be the same.
• Project Management – Project management is a maker role within the team, not an independent role outside the team.
• Profit Sharing – Profit sharing should be aligned with the autonomy and performance of an office. (This is an example of ATOC pointing out an inconsistency in our legacy structure; we have a centralized profit sharing scheme.)
• Facilities – Facilities management and improvements may be outsourced, but ultimate responsibility lies with Office leadership.
• Budgets – Teams, whether internal or external, manage their own budgets. Work is organized in projects, whenever possible.
• Space – Office headcount is constrained by physical space and office leadership capacity.
• Skills – Reference checks and so-called “soft” skills count as much or more more than technical skills, given our model of highly collaborative teams directly connected to clients.
• People – Atoms are our only tangible asset with the potential for creating future value. We should invest in them accordingly.
• Solo Work – Atoms working alone consistently will feel isolated and culturally misaligned.
• Location of People – Remote workers don’t match the definitions and dynamics of Team and Office.

Like any abstract architecture or taxonomy, there are a few exceptions and corner cases that don’t fit perfectly. We don’t let these small deviations from the model get in the way of the overall value of the model. Our model is powerful both in what it suggests as good decisions, and what it flags as potentially bad decisions.