Skip to content
back to the discussion
Discussion summary2024CTO

Professional Communities in Corporations

The first offline meet-up of the Bezvotetogovotvsego channel in 2024, held in Rosbank's studio: Maxim Morozov from the Aston group, Alexander, chief technology officer at Tinkoff, Pavel Solomin from Sber and Alexander Denisov from Rosbank spend an hour on why corporations build professional communities, who shuts them down and how to measure their value.

Bezvotetogovotvsego9 min read

This summary is shorter than the full discussion; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

Voluntary at Sber, professions at Tinkoff

The host recalls first running into the topic around 2015, when squads and chapters were in fashion, and asks why companies build communities now and what counts as success. Pavel Solomin answers that Sber has no single answer and does not want to find one: there are already several dozen communities, membership is voluntary on principle, and a department for managing communities will never appear. One grew around the bank's single front-office system; another formed around Python and helps those who know the language less well — and someone quips that the pack does not cast out its weaker members. Across the bank he sees two reasons: an org structure of many small teams where you can be the only Python developer with nobody to talk shop to, and the expectation of more effective work. He declines to measure it: he has never heard of a bulletproof way to measure development effectiveness.

Tinkoff did not overthink the naming and calls these structures professions: Go developers, Java and Kotlin, and also product managers, designers and analysts of various kinds. Alexander explains this by the federated shape of a large company, where business verticals live by their own rules and horizontal links go missing; the cures: a development platform, sometimes called an IDP, and shared standards for a profession — how we hire, what we ask, what an ideal mid-level Kotlin developer looks like. The profession itself decides which tools and libraries are missing and reviews promotion cases. Maxim Morozov brings the conversation back to hiring: the top two employee requests are more money and a chance to develop, and the second cannot be met without a community. At Rosbank guilds started appearing in 2021 spontaneously — some took off, some did not; Alexander Denisov, one of the two leads of the admins' guild, recalls that some voted for the term professional community, but guild won, and he now calls himself its honorary member.

02

From tragedy of the commons to badges

Alexander frames engagement through the tragedy of the commons: everyone shares the field, everyone wants to graze sheep on it, and nobody wants to invest in the field. Everyone wants a competency matrix, orderly hiring and reviewed promotion cases, but not with their own hands. Beyond enthusiasm the answer comes from the assessment itself: it rewards not syntax knowledge beyond the compiler's but value brought to the company, and a contribution to the profession — the matrix, the tooling, interviews — counts alongside project work. It also puts a person on the radar: how they communicate with people who do not report to them, and whether they can lead while staying an individual contributor. Not everyone agrees; some feel you can grow into a top manager simply by doing ever more business tasks. Pavel adds Sber's expert track, where impact matters: do well for yourself, then help your neighbour, or the expert hits the ceiling of his own system and leaves for the next one.

Then the talk turns practical. Denisov describes his method without pathos — we gather, draw a pentagram and summon people — but in fact they invent content and varied activities, draw the invitations themselves instead of outsourcing, collect feedback at meetings and put up a QR code linking to the chat. The next hypothesis is to wire the guild into onboarding, so a newcomer lands in their profession at once — but then it must answer what it gives them, or people leak away. Belonging has its marks too: levels of participation — listener, speaker, expert — home-made badges in the internal social network, a separate hoodie for the most active people at Maxim's company, and Pavel still wears the sweatshirt of his first community from around 2016, which his wife has wanted to throw out for seven years. Even so, by his estimate more people are outside the communities than inside, and whether membership is theatre or reality stays open: dropping into a chat once is not participation.

03

Management pushback and the leader's battery

The most candid part of the discussion is about whom communities get in the way of. By Pavel's account, support exists at the top, but for a line manager a community complicates the picture: he used to decide himself who deserved more money, and now the case goes to the professional community and he waits for a verdict: part of his power has moved away. On top of that, active contributors do this during working hours instead of what the line needs — which is why many treat communities as a whim, a waste of the organization's time and money on top of which people build a personal brand at conferences. He admits he picks provocative examples. Asked from the floor about harm, the host jokes about a community that discovers its rights like a trade union; Pavel knows of no such cases, but the trusted environment inside is why Sber watches this centrally, while Alexander recalls Google, where some employees decided the Pentagon should not be dealt with, although the contract was probably a good one.

A separate pain is the fragility of the leader. Denisov quotes the head of one guild directly: the guild runs on my battery. His own guild has two leaders, a small staff of activists, and the chat handed to a dedicated person. Pavel calls this the core and answers the continuity question with it: if a core exists, someone usually picks up the banner when the leader leaves — though he knows cases where a core existed and nobody stepped up. Alexander recommends redundancy and responsibilities taken apart in advance: when architecture stopped fitting into one person, System Design interviews and course building went to others. Pavel calls metrics dangerous: whichever ones you set will be hit, while the community has been declared voluntary. They look at hiring and attrition, the number of events and page views, but Denisov trusts a qualitative signal more — the stories of the guild having helped someone — while for Alexander it is enough that the architecture community is already around two thousand people who ask and answer their own questions. Maxim brings a measured effect — developer tenure at his company grew by half a year, to a little over two.

Takeaways

What to take away

  1. 01A community is an extra layer on the org structure, and not a free one: if five Python developers can agree among themselves, or an appointed competency lead is enough, do without one.
  2. 02Growth on the expert track rests on impact beyond your own system: profession leads review the case, and speed on routine tasks is not enough — you may be up to Robin, but not to Batman.
  3. 03The main opponent of communities is not top management but line managers, who lose part of their decisions and their people's working hours; without an answer to what is in it for them the whole thing stalls.
  4. 04Resilience comes from a core rather than a charismatic leader: two or three like-minded people, responsibilities split in advance and delegated routine survive the departure of whoever started it all.

Sources