The CTO’s Community of Practice

Your participation in both internal and external communities shapes who you become as a CTO. Neither is sufficient alone.

When a UK tech leadership coaching group surveyed 100 senior technology leaders in 2024, they called the results “alarming” and “in some cases, upsetting.” Almost 97% had felt lonely as a leader at some point, with 63.5% feeling lonely in their current role sometimes and almost 19% feeling that way all of the time.

The impact went beyond feelings: 86.5% reported issues with motivation and engagement, 44.6% said confidence when dealing with stakeholders was impacted, 34.4% struggled to lead teams, and 32.3% reported a dip in productivity and delivery.

Those numbers are catastrophic. Not just for the CTOs experiencing them, but for the companies depending on them to make million-dollar technology decisions while fighting through fog.

The loneliness epidemic among technical leaders isn’t new. Over 70% of new CEOs report feelings of loneliness, and former US Surgeon General Vivek Murthy noted that loneliness reduces task performance, limits creativity, and impairs executive function such as reasoning and decision-making. For CTOs specifically, often the only technologist in a C-suite of business-focused executives, the isolation runs deeper.

But isolation isn’t inevitable. There’s a body of research spanning three decades that offers a different model. One where learning happens through participation, where identity develops through practice, and where the antidote to isolation is belonging to something larger than yourself.

When Apprentices Taught Anthropologists About Learning

In 1991, cognitive anthropologist Jean Lave and educational theorist Etienne Wenger published research that would reshape how we think about professional development. They weren’t studying executives. They were studying apprenticeships: Yucatec midwives, Vai and Gola tailors, US Navy quartermasters, meat-cutters, and non-drinking alcoholics in Alcoholics Anonymous.

What they discovered challenged everything we thought we knew about learning.

Lave and Wenger found that learning isn’t primarily an individual cognitive process but a social one. People don’t acquire knowledge and then apply it. They participate in practices of social communities and construct their identities in relation to those communities.

They called this phenomenon a “community of practice”. Groups of people who share a concern or passion for something they do and learn how to do it better as they interact regularly.

Think about how an apprentice electrician learns. Not by reading manuals in isolation. By observing journeymen, asking questions, making mistakes under supervision, gradually taking on more complex tasks. The community acts as a living curriculum. The learning is inseparable from belonging.

Wenger calls this “legitimate peripheral participation”. You start at the edges of the practice, observing and contributing in small ways, gradually moving toward fuller participation as your competence and identity develop.

This isn’t just academic theory. Learning involves participation in the pursuit of valued enterprises—such as discovering scientific facts, fixing machines, growing up, being convivial. Knowledge is competence with respect to valued enterprises. Knowing is participating in the pursuit of such enterprises.

For CTOs, the valued enterprise is building technology organizations that deliver results. The question is: where do you participate in that practice with others who share your challenges?

Three Components That Make Practice Communities Work

Wenger identified three essential elements that turn a group of people into a community of practice:

The Domain: A shared area of interest that creates common ground and gives meaning. For CTOs, this isn’t just “technology” broadly, it’s the specific challenge of leading engineering teams, managing technical debt, navigating C-suite dynamics, and translating technology decisions into business outcomes.

The Community: Members engage in joint activities, help each other, and share information. They build relationships that enable them to learn from each other. This isn’t networking. A good conversation with a stranger on an airplane may give you all sorts of interesting insights, but it does not in itself make for a community of practice.

The Practice: A shared repertoire of resources, experiences, stories, tools, ways of addressing recurring problems. Members develop a shared practice through sustained interaction. This takes time.

Most CTO peer groups fail because they focus on networking (exchanging business cards) or content delivery (listening to speakers) without developing actual practice. You show up, you listen, you leave. Nothing changes. No identity develops. No shared repertoire forms.

Real communities of practice are different. The windshield wipers engineers at an auto manufacturer make a concerted effort to collect and document the tricks and lessons they have learned into a knowledge base. By contrast, nurses who meet regularly for lunch in a hospital cafeteria may not realize that their lunch discussions are one of their main sources of knowledge about how to care for patients.

The learning happens whether you’re conscious of it or not. But the impact multiplies when it’s intentional.

The Hidden Cost of Going It Alone

Let’s talk about what it costs to try to CTO without a community of practice.

Research from in-depth interviews with C-suite executives reveals that top executives are more prone to loneliness due to increased social distance, lack of social support, and exhaustion related to the role.

According to the Journal of Occupational Health Psychology, 26% of executives report symptoms consistent with clinical depression, compared to 18% in the general workforce.

You know what that looks like. The CEO asks if the new feature can ship by month-end. Your gut says no, but you have no peer to reality-check your technical instinct against. You say maybe. The team scrambles. Quality suffers. You take the heat.

Or the board pushes for a technology decision that conflicts with your architecture vision. You’re technically correct. But you’re alone in your correctness, and technical correctness without executive presence is just expensive stubbornness.

Or you’re making a hiring decision between two VP of Engineering candidates. One has the resume, the other has the cultural fit. Who do you ask? Your CEO doesn’t understand the technical nuances. Your team has competing interests. Your recruiter gets paid either way.

These aren’t abstract problems. These are Tuesday afternoon decisions that shape your company’s technical future. And you’re making them without the benefit of practitioners who’ve faced the same choice and can share what they learned.

Peer learning research shows what you’re missing. Studies across healthcare, education, and professional development consistently demonstrate that students in peer tutoring groups obtained significantly exceptional academic achievement compared to students who were not peer tutored. But the benefits go beyond performance. Peer learning creates spaces for emotional support, reduces isolation, and builds confidence in decision-making.

For CTOs, the cost of isolation compounds: slower decisions, more second-guessing, less experimentation, higher stress. You can be technically brilliant and still fail because brilliance without community is fragile.

How 7CTOs Functions as a Community of Practice

In 2013, after spending two years meeting with over 300 CTOs across four US cities, I kept hearing the same pain point. Technical leaders felt isolated. They lacked peers who understood their specific challenges. They had no structured way to develop their practice beyond trial and error in their own companies.

7CTOs was built as a community of practice, though I didn’t use that language at first. I just knew what was missing and what needed to exist.

The Domain: Technology leadership at scale. Not hobbyist programming. Not individual contributor work. The specific challenges of leading 10-120 person engineering teams through growth, dealing with technical debt, managing up to non-technical executives, and building systems that support million-dollar business outcomes.

The Community: 300+ vetted technology leaders who meet in professionally facilitated forums monthly. These aren’t casual happy hours. They’re structured sessions where CTOs bring real problems, share real failures, and build relationships over years. Brittany Cotton, our Chief Coaching Officer, has spent thousands of hours coaching CTOs through these peer groups. She knows what works: consistency, vulnerability, shared struggle.

The Practice: Frameworks like the CTO Levels, playbooks for team structure to deployment automation, shared stories of what worked and what failed, and a growing body of documented knowledge that members contribute to and draw from. When a CTO is facing a Level 4 to Level 5 transition (scaling from 20 to 40 engineers), they’re not improvising. They’re drawing on the collective experience of dozens who’ve made that transition before them.

This isn’t theory. Members report transformations that go beyond skill acquisition. One CTO told me it changed not just how he leads his company, but his entire relationship with technical work. Another said 7CTOs gave her the confidence to push back on the CEO’s unrealistic timeline because she had a forum to pressure-test her technical reasoning with peers before that conversation happened.

Communities of practice act as a negotiated regime of competence. Within such a regime, knowing is no longer undefined. It is defined as what would be recognized as competent participation in the practice.

When you participate in 7CTOs, you don’t just learn techniques. You develop an identity as someone who belongs to a community of practitioners. That identity shift changes everything—how you show up in C-suite meetings, how you make hiring decisions, how you handle pressure from stakeholders.

Communities Inside and Beyond Your Company

Communities of practice don’t only exist at the organizational level. You can and should cultivate them inside your company too.

Inside your engineering organization, communities of practice form around shared technical challenges: your frontend developers who meet to review architectural patterns, your DevOps engineers who maintain shared runbooks, your engineering managers who discuss team dynamics over lunch.

Nurses who meet regularly for lunch in a hospital cafeteria may not realize that their lunch discussions are one of their main sources of knowledge about how to care for patients.

The same happens with engineers. That Slack channel where senior developers debate testing strategies? That’s a community of practice. The weekly architecture review where teams share their design decisions? Community of practice. The informal gathering where engineering managers commiserate about difficult 1-on-1 conversations? Also a community of practice.

Your job as CTO isn’t to manage these communities directly. It’s to recognize them, legitimize them, and remove obstacles that prevent them from functioning. Give them time. Give them visibility. Make participation in these communities part of what it means to be a senior engineer at your company.

But, and this is critical, internal communities can’t meet all your needs as CTO. You need external communities too. Because inside your company, you’re the leader. You’re the one who’s supposed to have answers. The power dynamic prevents the kind of vulnerable learning that happens when you’re among true peers.

External communities like 7CTOs create space for a different kind of participation. You can admit you don’t know. You can share failures without worrying about undermining confidence in your leadership. You can ask stupid questions. You can pressure-test ideas before bringing them to your team.

The primary focus of community of practice theory is on learning as social participation. Participation refers not just to local events of engagement in certain activities with certain people, but to a more encompassing process of being active participants in the practices of social communities and constructing identities in relation to these communities.

Your participation in both internal and external communities shapes who you become as a CTO. Neither is sufficient alone.

What Happens When You Join

If you’ve never been part of a real community of practice, the transformation can feel disorienting.

First, you’ll notice how much faster you can make decisions. Not because someone tells you what to do, but because you have access to pattern recognition from dozens of similar situations. Someone in the community faced this exact architectural choice last quarter. They can share what they learned. You don’t have to repeat their mistakes.

Second, your confidence changes. Not arrogance but rather confidence. The kind that comes from knowing you’re not making it up as you go. You’re drawing on a shared practice. When you push back on a bad business decision with technical reasoning, you’re not just defending your position. You’re representing what the community knows to be true.

Third, your identity shifts. You stop seeing yourself as an isolated problem-solver and start seeing yourself as a practitioner in a larger community. We all belong to communities of practice. At home, at work, at school, in our hobbies we belong to several communities of practice at any given time. And the communities of practice to which we belong change over the course of our lives.

The loneliness doesn’t disappear overnight. But it transforms into something manageable. You’re not alone anymore. You’re part of something.

Your Monday Morning Next Steps

If you’re reading this and recognizing yourself in those loneliness statistics, do this:

This week: Identify one internal community of practice that already exists in your engineering organization. It might be informal. Make it visible. Acknowledge it. Ask how you can support it.

This month: Reach out to one CTO outside your company who faces similar challenges. Not for advice. For connection. Share something you’re struggling with. See if they’re willing to do the same. That’s how communities start.

This quarter: Evaluate whether you need structured participation in an external community. Whether you’re a CTO of a 120 person engineering team or a team of 3, 7CTOs might be right for you. If you’re earlier stage, look for communities built around your specific level. The critical question isn’t whether the community exists—it’s whether you’re willing to participate.

Learning is an intrinsically social process and one of the primary sites where learning occurs is in communities of practice. You can try to CTO alone. Many do. Some even succeed for a while.

But the research is clear, and the lived experience of hundreds of CTOs confirms it: the isolation isn’t necessary. The struggle doesn’t have to be solitary. There’s a community of practice waiting for you to step into it.

The question is whether you’ll let yourself belong.

Etienne

PS if you’re drawn to all this, head over to 7ctos.com/community and join us.