By Alex Billingsley, VP of Engineering at DeveloperTown

I’ve been at DeveloperTown for ten years. During that time, I’ve watched us evolve our organization more than once. Each change was driven by the same reality: the world around us moved, and our structure needed to move with it.

We started narrow and flat. We primarily worked within one technology stack, and one leader could hold most of the technical picture in his head.

That worked until the engineering landscape became broader and deeper. Front end, back end, mobile, and DevOps each demanded real specialization. We responded by creating dedicated practice areas.

That worked too, for a while.

Practice areas gave us depth, credibility, and a clear technical identity for every engineer on the team. But over time, we began to see the constraints hidden inside that clarity.

When people are organized around technologies, their careers can become attached to those technologies. Their manager is often also their technical authority. Their growth path runs through a single domain. Their professional identity becomes “I’m a front-end engineer” or “I’m a back-end engineer.”

That may work until the technology changes, someone’s ambitions broaden, or a client’s problem refuses to fit neatly into one of those boxes.

All three happen regularly in software consulting.

When the Solution Starts Looking Like the Org Chart

We had engineers who wanted to move in new directions but felt as though they would need to switch teams simply to explore a new framework or discipline. We had talented people whose interests had outgrown the practice they originally joined.

And, honestly, we had Conway’s Law quietly influencing our work: our solutions sometimes began to resemble the structure of our organization.

When front-end and back-end work belong to separate groups, it is easy for delivery to inherit the same division. One person completes part of the work and hands it to another. Each handoff introduces coordination, delay, and the possibility that important context will be lost.

That structure may be convenient internally without being the best way to solve a client’s problem.

Clients increasingly ask for “full-stack engineers,” but I think there is something more nuanced underneath that request. They want breadth, but they still need depth. They want people who can own more of an outcome while knowing when deeper specialist judgment is required.

A consulting firm’s only real asset is its people. We do not ship a product or sell licenses. When a client chooses DeveloperTown, they are buying the judgment, skill, and continued growth of the consultants working on their engagement.

If our people stagnate, our offering stagnates. If our organizational structure makes growth awkward, that is not merely a people problem. It is a business problem.

So we asked a simple question:

What if we decoupled career development from technology identity?

Enter Communities of Practice

Our answer was to move from traditional practice areas to a model built around stable professional-development managers and communities of practice.

A community of practice is a group of practitioners who improve by learning from one another’s real experiences.

It is not a training class; there is no instructor.

It is not a project team; there is no deadline.

It is not a staff meeting; no one is there to report status.

It is a space where people who care about the same craft regularly share what is working, what is not, and what they are still figuring out.

The key difference from our previous practice-area structure is that people can—and intentionally do—belong to more than one community.

Each DeveloperTown consultant participates in two:

• A “home” community focused on an area in which they already have meaningful expertise. Their role is to contribute experience, sharpen standards, and help define what excellent work looks like.
• A “growth” community focused on an area they want to develop. Here, they can absorb knowledge from others while introducing useful perspectives from the disciplines they already know.

Meanwhile, each person has a consistent manager focused on helping them grow as a consultant and professional.

The manager helps develop the person. The communities help develop the practitioner.

Those responsibilities are related, but they do not have to belong to the same person or organizational structure.

A full-stack engineer can participate in both front-end and back-end communities without a reporting change. A back-end engineer curious about AI can begin learning from that community without leaving their team. People’s careers can become bigger than any single technology while our collective expertise becomes broader and deeper at the same time.

Why This Model Matters Now

Two forces make this the right moment for communities of practice.

The first is the pace and breadth of technological change.

The days of choosing one stack and riding it for a decade are behind us. Our clients ask us to work across React, .NET, Python, Next.js, Power Platform, MuleSoft, and an expanding range of AI capabilities.

We will not try to be all things to all people. Focus still matters. But an organizational structure that locks people into a single domain cannot keep pace with the market.

Communities of practice allow expertise to travel across the company without requiring us to reorganize every time the technology landscape shifts.

The second force is AI.

AI will perform more of the execution work involved in software delivery. We do not see that as a threat; it is the direction we are actively building toward.

But it raises an important question:

Who decides whether the AI did the work correctly?

I do not mean merely technically correct. I mean correct as in: This reflects how experienced practitioners believe the work should be done. This is secure, maintainable, and appropriate for the client. This is something we are willing to stand behind.

That judgment lives with practitioners, and it becomes sharper when practitioners regularly compare experiences and discuss what good work looks like.

A community of practice becomes the circle of expertise that keeps AI-assisted delivery honest.

The community develops the knowledge. We encode that knowledge into standards and reusable artifacts. AI tools consume those materials. Practitioners evaluate the output and use what they learn to improve the standards again.

It is a loop, not a pipeline—and the community is what makes the loop trustworthy.

As consultants increasingly orchestrate AI agents alongside human specialists, the depth of craft knowledge inside these communities becomes a quality layer. The people participating are not merely learning from one another. They are establishing the standards against which our AI-assisted work will be measured.

Creating the Conditions for Better Work

The organizational structure is only scaffolding. What matters is what people build inside it.

Imagine an engineer working through a difficult problem on a client engagement—perhaps a state-management pattern that has become brittle at scale.

In a traditional structure, that engineer might contact someone they happen to know or simply power through the problem alone.

In a healthy community of practice, they bring the problem to the group. Several people who care deeply about that craft examine it together—not as a formal code review or a status update, but as practitioners wrestling with a real problem.

Someone may have seen it before. Someone else may not have, but asks the question that reframes the entire approach.

The engineer returns to the engagement with a better solution than they would have developed alone, and everyone in the room leaves knowing something they did not know before.

That is the environment we are trying to create.

Communities of practice allow depth and breadth to grow simultaneously.

Depth comes from creating space for genuine craft mastery: people pushing one another to become sharper at what they do.

Breadth comes from allowing people to participate in multiple communities and bring cross-domain thinking into their client work.

For a consulting firm, that combination is everything. Depth is what makes clients trust us with difficult problems. Breadth allows us to meet clients where they are instead of forcing their problems into our preferred technology stack.

The Work Is Just Beginning

We are still early in this model, and we are still learning.

Our rhythms will take time to develop. Some sessions will not land. Some experiments will not work. That is part of building a practice-oriented culture: we try, evaluate, and improve together.

But this is not organizational change for its own sake.

It is an effort to create the conditions for every consultant at DeveloperTown to grow faster, go deeper, reach broader, and do the best work of their career.

The technology will continue changing. Our clients’ needs will continue changing. Our structure should help our people move with those changes—not hold them in place.

Is Your Structure Keeping Pace?

If your engineering structure is limiting how your people grow (or making it harder to deliver across increasingly complex technologies), we would be glad to help. Contact DeveloperTown to discuss how stronger engineering practices, cross-functional expertise, and AI-assisted delivery could help your team solve difficult problems more effectively.