Impulse 2023: Community Synergy — Boosting the Output of IT Teams
A talk from the Impulse 2023 conference: how horizontal links, tech guilds, and mentoring boost the output of IT teams and save millions of rubles.
Three teams, one library, zero communication
November 2022. A random chat in the shared channel after a call — the kind that happens when people are in no hurry to hit "leave meeting." A colleague from a neighboring cluster is complaining about an integration with an internal service. I listen and feel déjà vu. Because my team had written the exact same integration a month earlier. And, as it turned out five minutes later, so had a third team.
Three teams were writing the same library in parallel. Design three times, code review three times, tests three times. Person-months of work straight into the trash — simply because people in the same company weren't talking to each other.
That episode was the trigger. Over five months we launched a system of tech guilds that delivered the company a measurable impact, with savings north of six zeros — and that's only what we could count directly. The real effect was several times larger.
At the Impulse 2023 conference I told the story of how we did it. This is the extended version.
The scale paradox: more people, less output
Research shows that in a team of seven, individual effectiveness drops to roughly 50%. Not because people are lazy, but because the cost of communication, coordination, and sign-offs goes up. You hire more people to get more done — and each additional hire brings a smaller return.
In a five-person startup, you are 20% of the company. In a five-thousand-person corporation, you're a rounding error. And that breeds three pains I hear from developers and analysts all the time.
"Nobody notices me." You built something great, but outside your team exactly zero people know about it. Recognition is limited to the annual review, where your manager fills in a score from a template.
"My results don't matter." You closed the sprint, shipped the feature, optimized the process. At the company level — invisible. The corporate machine grinds individual contribution into faceless metrics.
"I have no idea what the teams next door are doing." The three-libraries story all over again. The team next door is solving the same problem. Another team stepped on the same rake six months ago. But there are no horizontal links — only the vertical chain through management, which isn't across the details either.
The root cause is one and the same: no horizontal communication.
How the guilds got the green light
The idea isn't new — Spotify described guilds and chapters back in the early 2010s. But between "reading an article about guilds" and "launching them in a company with thousands of employees" lies a chasm.
I got lucky with the context. The tech-guild project kicked off under the mentorship of the CTO of T1 Group — as part of the cluster I built from scratch. Not "I proposed it and everyone agreed" — no. I came to the CTO with concrete numbers: here are three teams, here's the duplication, here are the lost person-months. Here are similar cases across other technologies. Here's a plan to fix it systemically, not point by point.
The CTO gave the go-ahead and, more importantly, gave political cover. Because without top-down support, any horizontal initiative dies in week two — the moment participants are told "your sprint is on fire, what guilds?"
Three formats: from standards to action
We identified three formats of horizontal links — each with its own role.
| Format | Formalization | What it does | Example |
|---|---|---|---|
| Center of excellence | High | Sets standards and best practices | "We document all APIs in OpenAPI 3.0" |
| Community | Medium | Horizontal knowledge sharing | A Kafka meetup: who hit which rake |
| Tech guild | Practical | Concrete tasks, measurable results | A shared integration library in 2 weeks |
The three formats don't compete; they complement each other. The center of excellence defines "what's right." The community discusses "how to apply it." The guild just goes and does it.
The guilds we built
Over six months we launched guilds around key technologies and practices. Not abstract "interest clubs," but working groups with concrete tasks.
| Guild | Focus | First result |
|---|---|---|
| AirFlow | Orchestrating ETL/ELT processes | Shared DAG templates, a unified approach to monitoring |
| Camunda | BPM and process automation | A library of reusable workers |
| Kafka | Stream data processing | Message-schema standards, topic-naming conventions |
| PostgreSQL | Databases, optimization | An indexing guide, a migration-review checklist |
| Backend development | Architectural patterns, code standards | That very shared integration library |
| Analytics | Documentation standards, data quality | Unified spec templates, a 30% drop in rework |
Each guild is 5-15 people from different teams who meet once every two weeks for an hour and a half. Not to "wax philosophical," but to solve a concrete task. From the very first meeting — an artifact as output.
The Kafka guild, for instance, started by gathering in one place every rake that different teams had stepped on while running Kafka in production — including the experience from our realtime platform. The result was a 20-page document — I'm not kidding. Twenty pages of pain, each of which cost someone a night on call.
A six-figure impact in five months
How did we measure it? With concrete cases.
The backend developers' guild: three teams pooled their efforts on the integration library. Minus two person-months of duplication. The analysts' guild: they standardized documentation templates, onboarding time for new analysts dropped, and the number of spec bounce-backs fell. The PostgreSQL guild: a shared indexing guide prevented at least two performance incidents that, the previous quarter, had cost the team nights on call and hotfixes.
The direct savings were measured as a percentage of the budget, with a figure north of six zeros — and that's against costs that were orders of magnitude smaller. And then there are things that are harder to convert into rubles but worth more.
Business effects you can't count in rubles
A talent incubator. A guild is a natural proving ground where leaders become visible. The person who takes the initiative in a meeting, explains complex things in plain language, helps colleagues from another team — that's your next team lead. Without guilds you learn about such people by accident. Or never at all.
Two of our guild members were promoted within six months. Not because "they took part in a guild" — but because the guild made their achievements visible.
A competency pipeline. A new hire joins a guild and gets access to accumulated knowledge: meeting recordings, solved cases, experts ready to answer. Knowledge isn't lost when key people leave — it's captured in the guild's artifacts.
Bottom-up standards. Standards imposed from above get sabotaged. That's an axiom. When a guild agrees among itself on code style, a testing approach, a documentation format — people follow those agreements because they made them. The difference between "I was told to do it this way" and "we decided to do it this way" is enormous.
Diagnosis: when a community is dying
Not every community takes root. I've seen enough dead chats labeled "X Guild" to put together a diagnostic table.
Quick test: two or more symptoms and the community is at risk.
| Symptom | Cause | Cure |
|---|---|---|
| People leave after the 3rd meeting | No concrete tasks, only "discussion" | Every meeting = an artifact as output |
| The same 3 people keep showing up | No management support | Explicitly carve out time in the sprint |
| The chat exists, activity doesn't | Created as a box-ticking exercise by a manager | Reframe the KPI from "launch it" to "results" |
| Discussions with no decisions | No facilitator with authority | Appoint a guild lead and give them the right to decide |
| Participants stay silent in meetings | Fear of criticism, or politics | Introduce a rule: the first 3 meetings — no managers |
| Results don't reach the teams | No process to spread them | The guild lead presents outcomes at team standups |
The most common killer is the absence of concrete tasks. If a meeting boils down to "well, let's share some experience," people stop coming after the third time. They're not bored — they're out of time. They've got a sprint. You have to give them a reason to show up that outweighs the pressure of the backlog.
How to launch a guild: a battle-tested checklist
If you want to try it yourself — here's the minimum that works. Tested on real people in a real corporation.
- Find a pain, not a topic. Not "let's make a Kotlin guild," but "three teams are writing identical integrations — let's join forces." Pain is a motivator. A topic is not.
- Assemble a core: 3-5 active people. You don't need dozens. You need people who'll generate the agenda and do the work between meetings.
- Get management on board. Two hours a week per participant. Without an explicit agreement, people will choose the sprint — and they'll be right.
- First meeting = a concrete task. Not "let's get acquainted and discuss the format," but "let's build a shared template for X." An artifact at the end of the first meeting is a signal: this isn't a talking shop, this is where things get done.
- Measure and show. Hours saved, libraries merged, approaches standardized. Show the numbers after a month. To management — so they don't shut you down. To participants — so they see the point.
- Don't be afraid to close it. If a guild has solved its task — close it. Better three living guilds than ten zombie chats.
The hard part isn't launching it — it's not killing it
Any manager with a shred of charisma and a contact list can launch a guild. But making it live longer than three months — that's actual work. Constant, tedious, thankless work of keeping the fire going.
You have to find tasks. You have to mediate conflicts. You have to protect participants' time from their own managers. You have to show results upward so that the political cover doesn't evaporate.
A separate headache is member rotation. The person who was the driving force of the Kafka guild leaves for another company. And it turns out the group's entire energy rested on a single enthusiast. The meetings carry on by inertia two or three more times, then turn into a formality, then quietly die. We stepped on this rake twice before we introduced a rule: every guild has at least two co-leads, and every three months one of them rotates out. It's not elegant, it's bureaucracy. But it's the kind of bureaucracy that saves a living community from dying when one person leaves.
A community isn't an event, it's a process. Those ready for the process will get results. Those waiting for it to "just start working on its own" will get one more dead chat in the corporate messenger. And three teams in neighboring offices will keep writing the same library.
Based on a talk at Impulse 2023 (T1 internal conference).
Yours, DPUPP
Related Articles
Cooperative vs Employment: A Conversation the Community Was Ready to Have
Notes from conversations with RAD-KOP, a Russian cooperative IT community. Not 'here's my pitch' but 'here's where the dialogue took us': a comparison of models, real-world examples, and an honest look at the downsides.
Red Flags in Hiring, Through a Lead's Eyes
Behavioral patterns in candidates I've learned to spot over years of hiring. Not an HR checklist, but the view of a manager who builds teams.
FAANG the Russian Way: The Cult of Canon and Antipatterns Born of Good Intentions
Why "we want architecture like FAANG" so often turns out to be the beginning of the end. On the cult of canon, antipatterns born of good intentions, and one short word that saves projects more reliably than any pattern.