Community Synergy: How a Large IT Company Can Use Its Own Expertise

I often find myself asking the same question. How can a company employ thousands of people while one team spends months struggling with a problem that a colleague elsewhere has already solved?

Imagine a large IT company. Someone knows Oracle almost by instinct. Someone has spent years working with Teradata. Someone can untangle a difficult graph query. In one division, a team has finally worked out why its overnight data load failed every time the source changed. In another, people have been patching a similar ETL pipeline for six months, and the temporary solution has acquired temporary solutions of its own. Both teams may work for the same group, use the same corporate email system and never have heard of each other.

Now add several more teams independently writing similar modules, assembling almost identical pipelines and taking turns making familiar mistakes. People are busy, tasks move forward, and the reports show development in progress. Except that the company has already paid for some of that development in the next division.

I do not consider every overlap wasteful. Requirements, data, licences or acceptable risks sometimes differ enough to justify a separate solution. But I would like that to be a conscious choice. It is frustrating to spend six months building your own system, then discover over coffee that colleagues could have shown you a working one back in February.

That question led me to Tech Guilds. Behind them stood a broader idea: a Tech Hub that would help the company find knowledge, connect people with problems, develop missing expertise and reuse what it had created.

In this article, I want to examine how such an arrangement could work in a large organisation. I will begin with my own experience, then move on to organisational structure, money, workload allocation and the conditions of participation. Along the way, there are some uncomfortable questions to answer. Who will release a strong specialist to help another team? Who will pay to maintain a shared module? Why would anyone want to contribute? And what will remain when the organiser moves on to another project?

The proposal I want to discuss is concrete. Choose a few expensive, recurring tasks, allocate a limited amount of specialist time and test whether doing them together can reduce the total cost. A manager able to reconcile different teams’ priorities owns the result. Participants know the conditions in advance; the company knows its spending limit and when to assess the experiment. My experience gave me grounds to test this. Results across an entire corporation would still have to be demonstrated.

These tasks should be chosen together with the people responsible for IT strategy. If the company is retiring a technology, we should not build a new permanent platform around it simply because we enjoy developing it. A short, shared migration project may be needed instead. Elsewhere, the strategy may require faster product releases, making a common delivery tool more valuable than another independent service. The community needs room to propose solutions, and management needs a clear connection between those solutions and the direction of the business.

If your immediate priority is an investment decision, you can go straight to the calculation at scale and the conditions for a pilot.

How I came to Tech Guilds

I started thinking about this in the summer of 2022. I was interested in self-management, connections across teams and organisations that give people more influence over their work. I read, compared those ideas with the corporate life I knew and tried to understand what we could use.

I had no desire to rename departments, draw a new organisation chart and declare the company free. I had a practical operational problem in mind. A large group already has knowledge, people and experience. How can we bring them together with the right task more often?

I first tried these approaches while working with the graph platform team. In 2023, when I took charge of Big Data application services, the need became much more pressing. My portfolio included graph, geo and ML platforms, as well as NER services: systems that extract named entities from text. All of them needed to move forward at the same time.

Those short names concealed very different fields. Graph structures and queries, Spark and ETL, Go services, APIs, Kafka, frontend development and microfrontends, geographic layers and polygons. In one place we needed to understand an algorithm, in another the data, and elsewhere the realities of production operation. You cannot simply tell a team to “figure out Big Data” and consider the brief complete.

With a portfolio like this, you inevitably have to choose where to spend time: on a new feature, a shared engineering improvement or training the team. I wanted a broader view of the company’s capabilities when making those decisions. Colleagues elsewhere might already have travelled the ground we were only approaching.

This is where the difference between headcount and access to the right knowledge becomes especially clear. You can assemble a capable team and still lack someone who has dealt with this particular problem before. You can find that person inside the company without getting any of their time. You can get the time and spend it explaining context that nobody prepared in advance.

Through Tech Guilds, I brought colleagues into difficult investigations, design discussions and training. Participants helped us see a problem differently, shared their experience and supported educational programmes. That made it possible to move work that had stalled within the boundaries of a single team.

I consider the Guilds’ contribution a substantial part of my experience developing the area. Management decisions, the team’s own work and accumulated experience also played their parts. I am therefore more interested in explaining how the benefit arose than in attributing the entire result to one project.

My formal work on the initiative ran from March 2023 to November 2024. The idea came earlier, and the relationships between people did not have to end on the day my role changed. Those are different things, and the distinction matters if we want to understand how the project actually developed.

I intended to deliver the community synergy talk at Impulse, but it was removed from the programme. I did give the talk at Infostart; it is mentioned in the INFOSTART TECH EVENT 2023 recap. I now have the opportunity to explain the idea in more detail than a conference slot allows, and to consider it in light of what happened afterwards.

What happened between people

The most important part of Tech Guilds began with something simple. A person could bring a question that their own team lacked the experience to answer and reach other specialists.

A good technical conversation quickly establishes what is needed. Sometimes it is an overview of possible approaches; sometimes help reproducing an error or reviewing an architectural decision. A question may initially be about a particular tool, only for a closer look at the requirements to reveal that the tool is unnecessary.

That opportunity to talk was what I valued. Before large language models became everyday working tools, it was especially useful. Instead of another evening spent among disconnected examples, you could speak to someone who knew both the successful approach and the conditions under which it stopped working.

The community developed tools of its own. First came an assistant bot for programming questions; later, request tracking, including the option to ask anonymously. Eventually, we were discussing a case board and a bot working together. The purpose was practical: keep questions from disappearing between messages and see who still needed help. Understanding the problem and accepting the result remained people’s work.

By my estimate, community members resolved more than 1,000 engineering cases over the initiative’s lifetime. I recruited more than 20 senior experts for targeted assistance, while other members also answered questions, shared their work, and joined investigations.

My estimate is that around 5% were particularly demanding, another 15% were difficult, and about 40% were of medium complexity. The remaining roughly 40% were simple questions, often requiring only a short answer or a pointer before someone could get back to work. This is an approximate recollection, not a distribution extracted from a ticket system. The share of requests is not the share of effort: one difficult investigation could take more time than dozens of quick answers.

When the right person was nearby

In these accounts, I preserve the course of the investigation and its outcome, while leaving out system architecture, information about participants and the circumstances of particular projects. The technical explanations below help explain the class of problem; they do not reproduce internal documentation.

My team and difficult Scala code

I will start with my own team. We had a large amount of Scala code performing complex data transformations. A junior-plus specialist joined this area: he had some experience with the language, but was not yet an experienced Scala or ETL developer. The tasks ahead of him required that experience.

It is easy to make a management mistake here. A name appears beside a task in the plan, so we have found someone to do it. Yet there is a considerable distance between “knows the language” and “can confidently change a complex transformation.” Syntax can be learnt; understanding why another step changed the meaning of the data is much harder. Sometimes code runs successfully, which is precisely why it escapes suspicion for so long. This is a general illustration of the difficulty of this kind of work, without details of our system.

By our estimate, when we sought help, the employee had been investigating the problem for about two months without reaching a solution. I brought in a colleague who had spent years writing ETL in Scala and Spark. His analysis took a few hours, and in about eight hours altogether he prepared a complete way to fix it. By the end of the working day, the team had a solution, an explanation of its logic, guidance on potential bottlenecks and recommendations on what the employee should study next.

That is a benefit I did see in my own team. But the two months are elapsed calendar time, whereas the eight hours are an approximate estimate of the expert’s involvement. I do not have a timesheet for every attempt. The earlier investigation may have produced material that helped the expert understand the problem sooner, so claiming an exact fortyfold acceleration would be wrong. The management lesson is nevertheless clear to me: the task needed specific expertise, and access to it changed the outcome.

Now let us put some simple numbers to it. Suppose the developer earns RUB 200,000 a month and an expert day is valued at RUB 20,000. If the developer works exclusively on this task for both months, it accounts for RUB 400,000 versus RUB 20,000 for an expert day. These rates are hypothetical. I am comparing only the salary value of time: both amounts are before deductions and exclude employer contributions, overheads and a contractor’s margin. A company budget would need the fully loaded cost on both sides.

20,000 / 400,000 = 5%. The expert day costs one twentieth of two months’ salary. That is a strong reason for a manager to ask whether the team gets the right help too late. An expensive specialist hour can be an inexpensive way to get a task moving.

That ratio does not yet tell us how much the company saved. If the developer really worked exclusively on this task for both months, RUB 400,000 in salary cost is already attributable to it by the time help arrives. Adding the expert brings the total to RUB 420,000, before subsequent validation and implementation. The first RUB 400,000 has not come back; what has appeared is a way to solve the problem. If the task occupied only part of the working time, only that share of salary belongs to it. I do not have that breakdown for the historical episode.

Here is where I see the economics of earlier help. If an expert day on a similar future task avoids the entire two months of investigation, the difference is RUB 400,000 − RUB 20,000 = RUB 380,000, before preparation, validation and implementation costs. That is a strong assumption: the expert must receive the necessary context, and the result must pass the same acceptance checks. Two months without a solution in my account do not establish that alternative duration or prove that all the earlier investigation could have been skipped.

For a less successful case, the rule stays simple: the value of labour genuinely avoided, minus RUB 20,000 for the expert and the remaining assistance costs. At a salary of RUB 200,000 and an assumed 20 working days a month, a developer day costs RUB 10,000. With no additional costs, the help pays for itself in labour terms if it avoids more than two developer days. Preparation and validation raise that threshold. If payments do not fall, the gain remains time available for other work; cash savings require a change in expenditure. The value of removing a blockage and of learning can be assessed separately when there is evidence, without counting the same benefit twice.

We had several difficult tasks in different areas. Below, I move from a single investigation to the company: that requires accounting for the mix of requests and available expert time, rather than multiplying one successful case by the whole workforce.

That colleague and I became friends and still keep in touch. He now works on LLM projects. Sometimes finding a strong specialist is easier than keeping them in your team forever, but good working relationships can outlast a change of employer. For me, that is part of the Tech Guilds story too.

It is not always obvious that someone is stuck. They are learning a new technology, testing hypotheses and making some progress—until the task turns out to run deeper than it first appeared. Learning on the job is normal; deciding when a useful investigation needs help can be difficult. Nor is there a budget for a separate experienced specialist for every such task.

Today I would arrange a joint investigation sooner: if an agreed review date arrives with neither a verified explanation of the problem nor a meaningful next step, it is time to find additional expertise. That might be a brief consultation with a colleague. There is no need to expand the team immediately, but someone’s name in a plan is not a reason to leave them alone with a problem.

This case matters to me because it also changes the manager’s question. We can wait for someone to acquire the missing experience, hire an experienced specialist, or temporarily involve a colleague and get through a difficult stretch together. The choice depends on timing, complexity and available help. We should support people’s development, but cannot build promises to the business on the hope that they will learn everything necessary before the next delivery.

Two more investigations completed

In the first case, a team was investigating message delivery between data-processing components. The search was taking too long. Giving the engineer more time was an option: independent investigation develops expertise too. But repeating the same question in meetings was no longer helping. Through Tech Guilds, I brought in a colleague who knew the area well.

The useful contribution was the order of diagnosis. The expert split a large failure into testable parts: check communication separately, then a small reproducible example, then how one tool passes settings to another. Once the configuration was corrected, messages could be sent. The work finally had a verifiable result.

Why can this kind of investigation be difficult? Imagine integrating Spark with Kafka. Some parameters belong to the Kafka client and others to the Spark connector; they sit next to each other and look like a single list of settings. Yet Kafka parameters are passed with the kafka. prefix, for example kafka.bootstrap.servers, while connector-specific parameters such as subscribe work differently. The distinction appears in the official Spark guide. Without recognising those layers, you can spend a long time correcting the right value in the wrong place.

What interests me here is the management choice. Continue searching within the team, or spend a colleague’s time on a shorter sequence of checks? That decision does not require declaring the engineer weak. It requires understanding the cost of delay and being able to invite someone who already knows the common traps. In this episode, the help worked; we did not measure an acceleration factor for the whole project.

The second request sounded even simpler: help build a Python library. But the library depended on a native SDK, so an ordinary package installation was not enough. I brought the request to the community, asked for a fuller description and involved colleagues with relevant experience.

The first suggestions did not close the task. Each corrected error revealed another, so the conversation continued with a joint investigation. Eventually, the library built successfully; the cause was an incompatible SDK. The participant confirmed the result and thanked the colleague for helping.

Integrations of this kind, using native Python extensions, have several separate conditions for success. Python must load its part, the build must find the appropriate headers and libraries, and the native code must match the expected interface. Successfully installing the wrapper does not establish that the entire chain works. It therefore helps to test a small example with known dependencies first, then bring it back into the more complex application. This is an engineering lesson from this class of problem, not a claim that every one of these checks was performed in that episode.

Here, the community helped take a question through to a confirmed result. Sending a link would have been an intermediate step. My job was to keep the request from getting lost, give it the necessary context and bring it to people who could help. The specialists performed the build, and the organiser should not take credit for their work.

These episodes show the value of accessible expertise. On their own, they do not establish that a corporate platform pays for itself. At one point, someone asked whether we preserved the cases we had worked through, and I had to admit that we could not keep up with all of them. For the person receiving help, the task was finished. For the company, another job might only then begin: making the result useful to the next team.

After such an investigation, I would keep a short, verified note: the class of problem, the way it was tested, its limits and an owner responsible for keeping it current. No names, working data or access details. Months later, another engineer needs a dependable starting point, not a whole evening of someone else’s conversation and every false start it contained.

The conversations also contained a next step. A participant was looking for an approach to organising a document structure so that he would not have to build everything from scratch. I helped connect him with a colleague who already had something similar. The colleague offered to show the algorithm, and they agreed to work through it together.

It is a small but important moment: a need met an existing result inside the company. The agreement to review it is confirmed; I cannot claim subsequent adoption or measured savings from this episode. That is exactly where I would continue the investigation. Do the requirements match? Can the solution be shared within the applicable rights and access permissions? How long will adaptation take, who will do it, and who will confirm the result afterwards? Otherwise, an offer to show something useful can easily remain a pleasant conversation.

The community also lost people. Some stopped participating; others changed jobs or faced different circumstances in their lives. When a person left, access to a rare skill could leave with them. That is an important part of the experience. If an entire area depends on one enthusiast, the guild’s name may survive their departure while help in that area ends.

That is why I connect community development with the development of an operating system for the company. We need to find someone who knows the answer today and ensure that tomorrow the company does not have to start the search from scratch.

Seeing the company across departmental boundaries

A conventional organisation chart makes managers and reporting lines easy to see. It helps you work out who approves leave and who owns a department’s budget. It is much less helpful for finding someone who can handle a particular class of problem or a solution already available for use.

With my engineering background, I find another picture useful. Imagine the company as a cube, with professional roles, technologies and domains along its axes.

At one intersection is a data engineer who understands stream processing and knows banking processes. At another is a systems analyst with experience of industrial integrations. At a third is a developer who works with geospatial data. Even this simple picture helps us look across administrative boundaries.

Of course, a person does not fit into a single cell. They have several skills, different depths of experience and interests of their own. Their project, available time, permission to work with particular data and willingness to participate also matter. A real system therefore needs several related dimensions; the cube remains a useful way to explain the first step.

I would keep information about people, demonstrated practice, tasks, reusable solutions and time separately. “Knows Kafka” tells us little when assigning work. We need to know what sits behind it. Connected a client? Designed delivery behaviour? Investigated duplicate processing during recovery? Can explain what happens to an external system if an operation runs twice?

Knowing a technology does not replace understanding the domain. Someone may optimise a query beautifully without noticing that the change has broken the business meaning of the calculation. A difficult solution often requires several kinds of expertise, and the receiving team must retain the ability to validate the result.

In engineering problems, including those involving microelectromechanical systems, I have always been drawn to the way the whole behaves because of its connections and constraints. It is a useful way to think about an organisation too. Here, though, the elements have wills, interests and fatigue of their own, so mechanically allocating “resources” soon meets reality.

A skills map should help people find work and support. If it becomes a hidden assessment table where one outdated entry determines a career for years, people will embellish their profiles or avoid the system. They need a way to correct information, clear access rules and a point at which recorded experience should be reviewed.

What makes up a Tech Hub

Let us follow the next step through a hypothetical example. This illustrates how a Tech Hub could work; it does not continue the story of any particular team. Several products are independently building data-loading processes. An engineer notices the repeated work and proposes extracting a common part. For now, he has a good idea, his own sprint and a perfectly reasonable question from his manager: who will maintain all this?

A professional community or technology guild is a place to begin. It makes it easier to find colleagues with a similar need and check whether the problems really match. Perhaps nobody needs a shared module, but a set of tests would help. Perhaps one participant already knows a solution and is willing to show it. We have not yet reached the point of a budget or a new department.

This is close to Etienne and Beverly Wenger-Trayner’s description of communities of practice: a shared domain, interaction and a developing practice. Subscribing to a channel is not enough. Value appears when participants regularly put knowledge to work.

Now suppose the products really do need regular assistance. They rely on a response time and make their own commitments accordingly. That calls for a competence centre or another service with assigned people and paid time. The name can be whatever the company is comfortable with. A binding response time cannot depend on volunteers’ free evenings.

In my design, the Tech Hub connects those choices with the company’s plans. Shared work gets a sponsor, experts get agreed time, and product managers can choose between consultation, temporary assistance and a shared component. An architecture community helps assess the technical option; a platform team may take on development and maintenance. If those functions already work, we should connect them rather than build another administrative layer.

Sandboxes and research tasks let people test an idea before it reaches a production system. The educational part develops second and third specialists in areas currently dependent on one person.

Initially, the same people can perform several functions. But somebody must regularly reconcile demand, availability and commitments already made. In a pilot, that may take an allocated part of the initiative leader’s time; as demand grows, the workload must be reassessed. Calling it free because an enthusiast currently manages it strikes me as strange accounting.

Project teams continue to own their products. Before assistance begins, they and the expert agree on the consultation’s outcome, its completion criteria and the scope of any follow-up review. Advice must pass the agreed checks, but that does not turn the specialist into a permanent support service. The team takes responsibility for implementation and operation; further maintenance receives a separate allocation of time.

Freedom people can rely on

Ideas about teal organisations influenced my approach to management. In Frederic Laloux’s book and materials, I am particularly drawn to self-management, being able to remain yourself at work and an organisation evolving with its purpose. I do not treat these ideas as instructions for every company, but they help pose a useful question: which decisions could adult professionals make for themselves?

Return to the engineer in our hypothetical example. Colleagues have confirmed their interest in a shared part of the data-loading process, but production adoption is still some way off. He needs to test the approach on anonymised data and estimate the effort. If that experiment must pass through the entire approval process for a future platform, the idea may end before the first test.

Sometimes there is a substantive answer to such questions. Personal data is involved, contractual obligations apply, or system reliability could be affected. Then the restriction should be explained and a safe way to experiment designed. Sometimes the answer is simply that the rule once suited one manager. That kind of rule can be reconsidered.

I would give this experiment clear boundaries: agreed time, permitted data, someone responsible for checking it and a date for deciding whether to continue. The engineer then knows what he can do independently. The manager will not unexpectedly discover that a month went into a universal system instead of a promised product task. And an unsuccessful result can bring the experiment to an end without a search for someone to blame: testing the hypothesis was the point.

Frank Martela’s analysis of self-managing organisations offers a useful reminder that task allocation, coordination and direction are still necessary. Removing management layers does not remove those responsibilities. It changes how they are carried out.

Why people join, and why they stop

People enjoy creating things. I saw it in my own team and among the initiative’s participants. Understanding a difficult problem, proposing a solution and seeing it work can be satisfying in itself, especially when people listen and you have colleagues you enjoy thinking with.

I have met strong specialists who enjoyed consulting and helping colleagues develop. Sometimes there was time for a short answer between tasks; sometimes we could arrange a separate paid investigation. But the eight hours in the Scala case are a working day, and that time must come from somewhere. A person may offer an evening or a day off on clear terms; I would not turn that willingness into a mandatory source of capacity. Nor can someone’s presence in chats tell us how much time they genuinely have available.

But a person has a life outside the company. A mortgage, children, health, fatigue, the wish to spend an evening at home. An interest in technology cannot be assumed to pay for everything else.

I often return to Maslow here, although the familiar pyramid image invites an overly rigid conclusion. In his original paper, needs do not have to be satisfied completely and in strict sequence. People can create and help one another under difficult conditions. That does not mean a company can plan regular work around someone else’s willingness to endure hardship.

The practical meaning is simpler for me. The less support, time and predictability a person has, the more carefully we should treat additional commitments. Youth guarantees nothing either. A junior specialist may have plenty of energy, or a second job and relatives to care for. Age is no substitute for a conversation.

What does participation offer? Challenging practice, opportunities to learn from strong colleagues, recognition, influence over decisions and new professional relationships. Sometimes it offers a route beyond a narrow role in which someone has stopped growing. All of that matters if it is actually available.

Marylène Gagné and Edward Deci’s work on work motivation helps explain the importance of autonomy, a sense of competence and connection with others. Those needs are visible without questionnaires when a specialist first gets both permission to propose a solution and the support needed to test it.

Regular contributions should also receive material recognition. Allocated working time, a bonus, training, a conference trip, equipment or a broader role: the company can choose an appropriate combination. The participant needs clear conditions, rather than the hope that somebody will eventually notice their effort.

Small gifts and discounts are pleasant. But if someone spends months helping other projects, a mug does not settle the question of pay. It is worse still if that help then counts against their productivity in their main job.

A community notices contradictions like these quickly. People may carry on out of habit for a while, and then its most active members disappear. From outside, it seems mysterious: the channel exists, meetings continue, and management is supportive. From inside, the explanation is simpler. The promised exchange has stopped working.

What the manager releasing an expert should receive

A line manager has a reasonable objection. They promised a result to a customer based on their team’s capacity, and now they are being asked to share strong people for the benefit of the whole group. The benefit is shared; the missed deadline is theirs.

That objection deserves a substantive answer. If an expert gives four hours a week to other projects, those hours must disappear from the main team’s promised capacity. Otherwise, we have simply added four hours to their work.

The team providing the expert should also see a benefit. It might receive help in return, access to a shared solution, training for a second specialist, agreed funding or recognition of the contribution in its manager’s performance measures. The mechanism depends on how the company manages budgets.

You cannot measure divisions solely by their own results and then be surprised when they are reluctant to invest in their neighbours. The assessment system tells people which behaviour is actually rewarded. An email about the importance of cooperation usually loses to the quarterly plan.

Let us continue our hypothetical example. An expert has agreed to review the shared data-loading approach on Thursday. On Wednesday, an urgent task appears in his own product. Every agreement has looked reasonable so far, yet someone will have to wait. Who decides which work moves?

I would establish in advance where the consequences for both products will be compared. If the managers can agree, good. If not, someone responsible for the shared priority must decide, with visibility of commitments and the cost of delay. The participating product managers must recognise that person’s authority to change agreed plans beforehand; access to a shared spreadsheet alone provides no such mandate. The receiving team gets a new date or a replacement, and the cancelled promise remains visible.

The expert should not have to arbitrate this conflict. They should not choose which of two managers to disappoint, then make up for that choice in the evening. The organisation must be able to allocate its own commitments.

These episodes also help diagnose the system. If help is constantly cancelled because the main job is urgent, the allocated capacity does not really exist. Either change the plan or honestly reduce the service. Listing someone in an expert directory is much easier than making them available.

How conversation becomes an operational result

A company can have a very pleasant technical chat that barely affects its work. The reverse is possible too: a short conversation changes decisions in several teams. I want to understand what happens between a request and a result.

Suppose the review does take place. Participants like the idea of a shared component, and the meeting goes well. It is still too early for the manager to record savings. We need to find out what changed for the team afterwards: whether it could apply the approach, what had to be reworked and who will take on the remaining work.

Nobody needs to write a ten-page specification to ask a question. It is enough to explain the problem, constraints, previous attempts and the required result. Logs and data should be prepared without exposing anything beyond the permitted access. A few minutes spent creating a minimal reproducible example can save hours of discussion.

In our example, abandoning the shared module could be a perfectly useful outcome. Perhaps the requirements differ too much, but the teams agree to use the same set of checks. Comparing approaches was not wasted effort: it avoided an expensive development project and preserved the part that would actually help.

But if we promised to help solve a problem, closing the request as soon as a link is sent is premature. We should find out whether the material helped, what constraints appeared and whether adaptation was needed. Otherwise, the expert accumulates answers while the team keeps its original problem.

Repeated requests gradually create another kind of work. If the same question keeps coming up, perhaps we need a guide, a library, a deployment template or a change to the platform itself. This is an important management transition. Instead of repeatedly treating the same pain, the company can invest in its cause.

Shared material also needs editing. A discussion thread is usually too long and contains tentative explanations. Six months later, a reader needs the conditions, the chosen solution, verified limits and someone responsible for keeping it current. The conversation remains useful history, but it need not become the entire user manual.

How to calculate a solution for the whole company

When several thousand employees are involved, it helps to move from individual acts of assistance to the allocation of operational capacity. There is project demand, available knowledge, time constraints and solutions that can reduce repeated work in the future.

I want to consider those things together. Optimising consultation speed alone could put every strong specialist on answering questions and stop product development. Looking only at reuse could force teams to adopt a universal module whose adaptation costs more than building their own. Pursuing full utilisation alone would leave the company unable to respond to anything unplanned.

The model below therefore describes choices for a hypothetical company. It is intended to compare options and expose assumptions. It is not a description of an optimiser we implemented or a promise of a particular saving.

Management first determines what result the company needs and which commitments it accepts. The model helps choose how to complete that agreed set of work. It does not decide which market to enter or maximise the whole company’s profit: choosing between different business goals requires a separate assessment of their value and risks.

We can now state the problem fairly precisely. The company has a portfolio of work, several ways to complete each item and limited specialist time. A shared component requires investment upfront but may reduce the cost of subsequent adoptions. A consultation costs less than a complete component, but each new request consumes expert time again. Sometimes an independent implementation is the most sensible choice.

These are the options I would compare. An instruction to “reuse everything” does not itself optimise anything.

I will now break this problem down as I tend to approach it as an engineer: options, constraints, calculation and a check of where the calculation stops working. If you are more interested in the management implications, you can leave the mathematics collapsed and move straight to the scale of the effect. If you want to check the reasoning, open the section: all the calculations are there.

H = n × (b − a) − F

n > F / (b − a)

Minimise C = Σⱼ Σᵣ cⱼᵣ xⱼᵣ + Σₖ Fₖ yₖ

For each task j:         Σᵣ xⱼᵣ = 1
For an infeasible path:  xⱼᵣ = 0
If a path requires k:    xⱼᵣ ≤ yₖ

For each person i:
Σⱼ Σᵣ hᵢⱼᵣ xⱼᵣ + Σₖ gᵢₖ yₖ ≤ Aᵢ − Rᵢ

xⱼᵣ, yₖ ∈ {0, 1}

ρ = λ × s
Wq = s × ρ / (1 − ρ),  0 ≤ ρ < 1

L = λ × W

Training also matters for resilience. If several people can support an area, one person’s leave or departure no longer stops the work. But hours associated with different skills cannot simply be added to a common reserve. A specialist with three skills still has only one working schedule.

What might change with a hundred, a thousand or ten thousand employees

For company scale, I propose an open calculation using hypothetical inputs. You can change them and see where the idea stops justifying its resource costs. The case-complexity shares above are not converted into these coefficients: that would require effort and outcome records for each investigation.

Take one year and an IT workforce of between 100 and 10,000 people. For the example, assume 1,600 available working hours and a fully loaded annual cost of RUB 4 million per employee. That gives RUB 2,500 an hour. These are values chosen for the calculation, not salary information from my company or market averages. For now, every hour costs the same; if expert assistance is more expensive, that needs separate treatment.

In the base scenario, a quarter of the work is suitable for a shared solution or reuse. Over the year, the programme actually reaches 60% of that part and eliminates 40% of its previous effort. That is 6% of the original time budget, not 40% of the whole company. Expert assistance, initial preparation of shared solutions, adaptation, validation, maintenance and coordination must still be deducted from the gain. Hours are eliminated at comparable outcomes and quality; time spent correcting new errors does not disappear from the calculation.

Before calculating, the product manager confirms demand, engineers and experts independently estimate the shared component’s initial development, assistance and adaptation, and the budget owner identifies specific payments that could change. Those estimates need to come before choosing the desired benefit.

Here is the base scenario’s result. The resource column values the released capacity at the chosen rate, less external expenditure. The second requires an additional condition: 20% of the net capacity must genuinely allow previously necessary payments to be cancelled at a comparable cost. For example, a team takes on work that would otherwise have required a paid contractor. These columns must not be added together.

All table amounts are RUB million for the illustrative year.

For a thousand people, we can unpack this without complicated mathematics. The starting time budget is 1.6 million hours. Of those, 400,000 are suitable, 240,000 are actually covered, and 96,000 hours of previous work are eliminated. Assistance, initial preparation of shared solutions, adaptation and maintenance take 33,600 hours; coordination takes another 8,560. That leaves 53,840 hours, or 33.65 of one employee’s annual time budget. This is distributed capacity, with different skills and calendars, not 34 positions ready to be cut.

At our chosen rate, that capacity is worth RUB 134.6 million. Additional payments for tools and external services total RUB 9 million, so the resource result is RUB 125.6 million. If confirmed avoided payments amount to only a fifth of the net capacity’s value, that is RUB 26.92 million; after the RUB 9 million of additional expenditure, the cash result is RUB 17.92 million.

If payroll and other payments remain unchanged, the cash result is minus RUB 9 million. The company has paid for the programme and gained the capacity to do more useful work. That may be sensible, but the decision then needs to be justified by the value of that work. Without suitable tasks, even released hours remain an opportunity nobody uses.

For a thousand people, the adverse scenario produces a resource result of minus RUB 12.4 million and a cash result of minus RUB 9 million. The programme consumes more internal time than it releases. If additional work must be paid for to maintain the previous output, the cash outcome gets worse: the table does not assume that lost capacity is replenished for free. That is a reason to change the approach or stop the programme.

G = N × 1600 × q × a × g                — gross hours eliminated
L = G × (e + d + m)                     — assistance, preparation of shared work, adaptation, maintenance
K = 0.25 + N / 200 + 0.1 × (N / 1000)²  — annual time budgets for coordination
H = G − L − 1600 × K                    — net capacity, hours
X = 1 000 000 + 8000 × N                — additional payments, RUB
V = H × 2500                           — value of net capacity, RUB
Eresource = V − X                      — resource result, RUB
S = r × max(V, 0)                      — avoided payments, RUB
Ecash = S − X                          — cash result, RUB

What a billion-rouble effect would require

For a company of 10,000 employees, our model’s hypothetical annual labour cost is RUB 40 billion. In the strong scenario, 35% of the work is suitable, average annual coverage of that part reaches 80%, and half of its previous hours are eliminated. Together, that is 14% of the original time budget: 2.24 million hours a year. That requires changing a large volume of work, rather than simply repeating a few successful consultations. After assistance, adaptation, maintenance and coordination, the remaining capacity has a calculated value of RUB 3.959 billion. It still needs to produce useful work or genuinely reduce necessary payments.

If 40% of that net capacity becomes confirmed avoided payments and the programme’s external expenditure is RUB 81 million, the annual cash result is RUB 1.5026 billion. Reaching a billion with the other strong inputs unchanged requires cash realisation of at least 27.31% of net capacity. That is a demanding threshold: it requires suitable demand, sustained adoption, available expertise and expenses that can actually change. The base scenario with the same 10,000 employees produces RUB 182.8 million, not a billion.

Let us test the sensitivity to one assumption. If cash realisation in that same strong scenario is 20% rather than 40%, the result falls to RUB 710.8 million. At zero realisation, the cash result is minus RUB 81 million. Lower coverage or higher assistance costs would also reduce the capacity to which those percentages apply.

Here I am working backwards: what conditions would produce a billion? Arithmetic answers that question, but does not establish that this combination is attainable in a particular company. I have no measurements that would justify calling it an expected result. The “base” scenario is also chosen for comparison, not as the most likely forecast. All scenarios concern an IT workforce; 10,000 employees across a group do not automatically mean 10,000 participants in this model.

In a discussion with an owner, I would keep the billion as a test of the proposal’s scale. An investment decision needs different entries: which work will stop being duplicated, which payment commitments will disappear, and what the reorganisation costs. If those do not add up, a large total in the table will not rescue the project. One Scala investigation cannot fill in those entries for an entire corporation.

A budget decision needs three separate reconciliations: what changed in available capacity, which payments actually changed, and which amounts were recognised in earnings. The detailed calculation is available below.

A shared solution must be easy to adopt

Reuse needs clear boundaries. A component should explain what inputs it accepts, what guarantees it provides and who owns changes. Otherwise, ten teams acquire ten implicit dependencies on the library’s author.

I find Carliss Baldwin’s discussion of modularity and platform design helpful: the ability to change parts of a system relates to its architecture and the organisation of work. I take a practical question from this: where does a shared boundary actually reduce dependencies, and where are we simply moving complexity to another team?

Suppose the community has found several similar problems and helped create a shared component. The interesting work is only beginning.

A consuming team needs to understand whether the solution fits, how to adopt it, what limits to accept and what to do when it fails. If each adoption takes a week of conversation with the author, development savings can disappear into integration. If documentation is outdated, the next consumer will travel the same path again.

I would treat a shared solution as an internal product. It has users, tasks, interfaces, a version, support and a reason to exist. This is consistent with DORA’s guidance on internal platforms: teams’ needs and feedback should shape platform development.

Teams need the opportunity to try a solution in a limited area. They should be able to understand requirements, assess migration and test load and recovery quickly. If a common tool becomes useful only after a large mandatory migration, the company takes on risk before gaining convincing experience of its use.

Maintenance needs an owner too. Who fixes a vulnerability? Who pays to support the previous version? Who accepts a breaking change? How does a consumer learn that development is ending? As long as the answers depend on the original author’s goodwill, we have something useful, but not yet a dependable shared service.

A shared component should not become mandatory for everyone. A team may have a justified exception: latency requirements, data-handling arrangements, technical constraints or customer commitments may differ. Discuss an exception in terms of costs and consequences, rather than as disloyalty to cooperation.

The opposite extreme is familiar too. Every difference is declared unique, and every team continues writing everything for itself. A joint review helps establish what really differs and what can become common. Sometimes we reuse a library; sometimes a testing approach, migration method or selection criteria. The benefit does not have to take the form of a single platform.

I want the economics of a solution to cover its whole lifetime. Development, consumer adoption, operation, support, migrations and retirement. A shared library might begin to deliver value only after its third adoption, then become expensive if every new consumer needs a separate branch.

The number of installations alone therefore says little about success. What matters is what teams gained and how much total work remained for the company after adoption.

What changed with LLMs

Today, some of the search can be done much faster. A large language model helps outline options, examine documentation, compare approaches, prepare a test or explain unfamiliar code. I use these capabilities extensively myself.

But having an answer available does not remove the organisational problem. A model may suggest an apparently suitable component that fails our requirements. It may not know that internal restrictions rule the approach out, that the licence is unsuitable, or that a neighbouring team recently tested it and rejected it.

Even a good, ready-made piece needs to be integrated into a particular product. Data, resilience, security, the consequences of repeated processing and maintenance costs need checking. Code that is easy to obtain can be very expensive to bring into production.

We could launch a million agents. Someone still has to decide which tasks they are allowed to handle, where their data comes from and what counts as an accepted result. If several teams independently build identical assistants, the company again acquires duplicate solutions, costs and maintenance commitments. The familiar Tech Hub problem has not disappeared; the catalogue now contains new performers and new kinds of error.

Even if management has planned a 20–30% headcount reduction, the decision itself establishes neither a productivity gain nor preserved quality. This is an assumption in a management scenario, not my market forecast. To deliver the previous amount of work, the company must check how much the system actually takes on and how much remains for people to supervise, handle exceptions and correct errors. Cutting necessary expertise too early may remove precisely the people capable of performing that check.

For a financial comparison, I would put two ways of obtaining the same accepted result side by side. The new option includes subscriptions or computing infrastructure, processed tokens, data retrieval, integration, quality evaluations, operational monitoring and human review. Retries cost money too. The cost of adverse outcomes needs separate assessment; a mandatory requirement does not become optional simply because the estimated probability of violating it is low. I will leave a complete model of people and agents working together for another discussion. Here, the point is not to lose these cost items when savings are first promised.

To check the cost categories, we can look at how AWS Bedrock prices models and associated capabilities separately; for a risk inventory, there is the NIST Generative AI Profile. Self-hosting changes the cost structure, but does not eliminate computation and operation. Neither source establishes the effect of a particular implementation. In the calculation above, LLM use would change the cost of assistance, validation and tools; an independent “AI saving” percentage cannot be added on top for the same tasks.

When I recall the investigations we did not preserve, this is where I especially want to use LLMs. An assistant could draft a note from permitted material, identify the chosen approach and leave disputed points for participants to check. This is a proposal for how the system could develop, not a description of results already achieved by our bots. The goal is material an engineer has actually checked, rather than a knowledge base quickly filled with convincing retellings.

The assistant could also clarify a request, find similar internal solutions within access permissions and suggest possible experts. Search in such a system must not reveal material a person cannot access directly; sending text to an external model requires a separate permissible basis. A recommendation needs verifiable sources, and a participant needs the ability to correct it.

If an assistant refers to internal practice, it should show where its conclusion came from and how current the evidence is. Without confirmation, leaving the question open is better. A confidently repeated guess in a technical catalogue is particularly troublesome: the next employee may mistake it for a corporate standard.

I also do not want such an assistant used to rank people secretly. Low chat activity may reflect a heavy project workload; a lack of public answers may mean work in a restricted environment. Those traces do not reliably establish who is a strong specialist and who is not.

LLMs accelerate some activities and change the cost of searching. At the same time, selection, verification and responsibility for an accepted solution become more important. A community can help here by collecting practical experience and discussing mistakes that one person could easily miss.

How not to kill something that has started working

A community has a quality managers may find inconvenient. You cannot establish it once by decree and then treat it as a permanent asset with fixed productivity.

In my story, this became clear as my own involvement changed. When I had less time for support, I looked for people willing to continue the organisational work. Having a board and a bot did not answer the question: who would investigate new requests and honour commitments already made? I had encountered a limit of a design that left too much to personal involvement.

I drew a rather uncomfortable conclusion for an initiator. As long as organisational work exists only in that person’s calendar, the project’s resilience is limited by that calendar. It needs paid roles, substitutes, knowledge transfer and a clear scope of commitments. Otherwise, an impressive name may survive while the reason people came disappears.

Participants change too. They move to other teams, grow tired, start families or simply find something more interesting to do. A community must be able to survive those changes without treating departure as betrayal.

I would watch several signs particularly closely. An ever-smaller group answers questions. Requests repeat while solutions go unrecorded. The organiser manually reminds everyone of every action. Meetings continue, but participants bring no problems of their own. Help takes place in the evenings, although the plan still lists management support.

Another quick way to lose people is to make technical conversation a place for public humiliation. IT has plenty of bluntness, and extensive experience is sometimes used as permission not to explain a position. “That’s obvious” is especially convenient for someone who has not had to reconstruct the whole context from scratch.

It is possible to challenge a solution rigorously and speak respectfully to its author. “What happens on redelivery?” helps the project. Demonstrating someone’s incompetence in front of the whole chat will make them stay silent next time.

In Amy Edmondson’s research on teams, psychological safety is associated with learning behaviour. For my purposes, the practical point is that someone should be able to admit a gap before it becomes a production problem. That requires rules and consistent responses, including to the behaviour of the most valuable experts.

Participation must allow pauses. People are entitled to stop consulting when their circumstances change. To prevent that from destroying an entire area, we need a second specialist, a clear handover and knowledge that has not remained solely in private conversations.

When organisers change, some very ordinary things deserve checking. Who owns the channel and bots, who can access working materials, who pays for infrastructure, and who continues the commitments to teams?

How I would test the broader idea today

I would begin with a few areas where repeated problems, available expertise and interested managers are all visible. I would not spend the first month trying to describe every employee and build a perfect company catalogue.

For each area, I would check its connection to IT strategy: which company capability it develops, which architectural choices it is compatible with and what happens if priorities change. Management support here means allocated time, the authority to coordinate work and a sufficiently stable horizon. Approving an idea at a meeting is not enough.

First, I would trace several real requests. How did the team look for help, how long did it wait, what did it try alone, who joined, and what happened after the investigation? Alongside that, I would examine repeated development: which efforts are truly similar, which share a common part, and which merely have the same name.

I would first compare the proposal with the simplest option: agreed hours from a few experts and request tracking in existing tools. If that is enough, there is no need to build a separate platform; its cost must be justified by work that the simple assistance arrangement can no longer handle.

I would record the launch decision on one page. Which recurring problem are we testing, who has authority to agree on a shared priority, how many hours and how much money are allocated, who accepts the result, and on what date do we decide the pilot’s future? Alongside that: permitted data, conditions for declining a request and a way to resolve conflicting plans. Participants agree the values for their particular pilot; those limits cannot quietly expand at the first difficulty.

In a pilot, I would examine three outcomes together. Did the team gain a useful change? Did the participant receive the promised conditions and professional benefit? Did the company’s total work decrease after including expert, organiser and maintenance time?

In the results, I would report the types of benefit already discussed separately: additional team capacity, changes in cash spending and reduced dependence on scarce expertise. Each requires its own evidence. A successful consultation must not quietly become a platform that has paid for itself in the report.

Before-and-after comparisons also need care. The team, workload, tools and priorities may have changed in the meantime. I would record the original assumptions, validate the result with the receiving team and compare similar tasks where possible. One successful example justifies further testing, rather than declaring a result for the entire corporation.

Suppose the help is in demand, but coordination consumes the gains. I would defer expansion, narrow the service or change how we help, then test the result within the remaining limit. If there is no demand, or the outcome does not justify the cost against available alternatives, close the area or choose another approach. New spending requires a new decision, not an obligation to prove the author right at any cost.

Return to our illustrative data-loading example. Testing might show that the products’ interfaces differ too much for a shared library, while a common set of validation scenarios would still help them. I would then propose ending the library experiment, keeping the verified tests and agreeing who maintains them. That is a pilot outcome too: the company gains a usable shared asset and stops funding an unsuitable design.

After the first complete cycles, we can discuss scale. Which areas are ready to grow, where people constrain progress, what coordination costs and which shared solutions teams actually adopt. That gives management a much stronger investment basis than a promise that good culture is bound to pay for itself.

What I take from this experience

I still like the idea of Tech Guilds and the Tech Hub. The part we managed to apply delivered practical results and exposed shortcomings in my own work. Finding an expert and helping a team is already useful. Preserving the result, agreeing on regular work and preparing successors proved to be a separate, much longer task.

My management context is different now, and I also have a book, personal projects, LLM work and consulting. I choose where I can make a serious commitment. Promising a major initiative continued development without time for it would be an odd conclusion to an article about resource availability. If I returned to the full idea, I would want it to have an internal sponsor, a sufficiently long horizon and a willingness to honour mutual commitments.

For me, the strength of a large IT company is especially visible in a simple working moment: an engineer discovers there is someone to ask, and a manager can genuinely allocate time for that help. Several such encounters then produce solutions others can use. The participant grows, the team moves forward, and the company gains more from capabilities it already has.

I believe in people’s desire to create and in the freedom that allows it to become work. My job as a manager is to understand what gets in the way, provide the conditions and check the result. Tech Guilds were one such attempt. Not everything we intended came about, but the experience changed how I see a large company: its people already know how to do much of what it needs. What remains is to make it possible for them to use those capabilities together.

If you recognise a challenge from your own company, get in touch. I have more experience and examples than could fit into this article. I am happy to discuss them within my confidentiality obligations, explain how the work was organised, and help apply the approach in your organisation—from reviewing the current situation to organising a pilot.

P.S. For a long time, I could not find the time to turn this experience into one detailed text. Materials and ideas accumulated while the time available for my earlier channels and substantial publications kept shrinking. LLMs have now helped me organise that material and finally prepare this article. I remain responsible for the experience, explanations and conclusions presented here.

Revised on 22 October 2026. This article develops the subject of my talk at INFOSTART TECH EVENT 2023.

Yours, DPUPP