Hello, Hacker Noon people! Technology guilds are a popular but still fresh way of implementing communities of practices in companies. Still, there are many questions, especially related to guild responsibilities and organization. Together with Andrew Kozin, I've prepared this post for you as a summary of our personal experience and understanding of the role of a technology guild nowadays.
Transfer of knowledge, technologies, and experience between engineers of the same company can be done in many ways. It is essential to have such processes, because a good specialist is learning and researching during the whole life. Developers also like to increase their contacts network. They often try to keep up with the community and keep their professional context wider, then a current project scope.
That’s where the so-called “guild” comes up.
A technology guild by itself is a community within the company, all members of which are developing using the same technological stack, but on different projects. For example: a Front-end guild, Back-end guild, Android guild and so on.
In charge of the guild is either a single person (Technology Lead / Competence Lead / Guild Master / Guild Coordinator) or several equal skilled professionals with this role (Core competence leading team).
The main responsibilities of the guild:
Let's explain each responsibility item in more detail.
Each technology stack in IT has its worldwide community and every self-respecting developer tries to track it.
There are well-established best practices, such as OOP, OOP patterns, FRP, Clean Architecture, SOLID principles, and many others. Such type of knowledge is not that hard to obtain since there are many resources including famous books and authors like Robert C Martin.
Also, there are highly specialised best practices for a particular technology or framework or project. In terms of specific projects, such best practices are the most valuable. But they often and fast become obsolete. They require continuous monitoring, ranking, and retrieval of the most relevant of them. To get them you need to track conferences, meetups, read prof. news feeds, etc.
The guild should regularly monitor and extract from all this endless stream of information best practices that are suitable for use within the company.
It must be clear for all guild members that they are also part of the community because they adopt the experience gained in the world, successfully implement it and increase their unique expertise. Such expertise parts (in a volume that will not violate the NDA) can be shared in articles and speeches. Thus they also contribute to the further development of the community. This is one of the motivations for being in a guild.
Some successful and generalized solutions that are born inside the guild can be pushed into open source. After all, some unique development expertise could be shared with the community, following the example of how Google, Facebook, Airbnb, Wix, and many others did it. If a company not only keeps in touch with the community but also contributes to its life, this brings it to a radically new level of prestige.
The following standards should be explicitly described within the guild:
Convenient access and navigation should be provided to all these standards so that new employees can familiarize themselves with them as soon as possible when starting work.
The main principle here is to automate everything possible.
Basic code style is automated by configuring code formatting tools.
All used frameworks, tools, package managers should be easily and quickly set up on working machines, sometimes with the help of prepared guidelines. It is also possible to automate the creation of individual modules / components / units in the project code via templating tools.
CI/CD pipelines configs and many other receipts can be carefully stored in the guild sources.
Things that just can’t be automated, should be checked during the code review and mentoring processes.
Every experienced engineer knows about the harm that can bring the technical debt. Having a guild in the company, engineers can use it as the leading broadcaster that enlightens all others (management, customers, sales team, e.t.c), about technical debt, how to deal with it and what are the consequences of ignoring this problem.
A very important standard is communication between guild members. Guild management must prevent any toxic communication, comments on someone's skills. Each developer should feel like a worthy member of the team.
All comments about technical debt elimination should be reasonable and correct. At the same time, it is crucial that the guild strictly follows the interests of best practices implementation and can correctly substantiate to less qualified engineers why their solutions are not appropriate, require rework, or cannot be approved.
All relationships between guild management and guild members must be built on trust.
The guild should support development of new projects using a modern technology stack. It should also try to update the stack for existing ones whenever possible. This is a huge motivational component for both: the developers themselves and for the customer of the product. Global expertise is growing, and more flexible, productive and functional solutions are emerging. The guild should be a trendsetter within the company in this regard. The guild must be able to find, implement and justify new solutions and frameworks, programming languages and tools. Moreover, the choice should not be hype, but thoughtful and rational in terms of stability and further support. Therefore it is strongly recommended to do guild practical part of work to be based on internal company projects with real and measurable goals.
Guild's estimations should be built on correctly defined architecture and this definition should be based on understanding of existing relevant cutting edge technologies. Besides, existing proven solutions libraries of a guild can be also used as a “ready to go” option.
All team members must train their estimation skill, the higher the qualification, the more voluminous things can be given to evaluate (from micro-tasks to entire projects).
By features estimating, it is necessary to understand its implementation steps. In most cases they are the following:
Guild expertise should be based on planning and execution of internal projects, where new technologies, approaches and methodologies are used. The projects can be sample and have study purposes only, but it is preferable to try to apply any project to either specific internal company needs or even develop and implement an idea of a commercial project. This concept also helps to utilize and grow expertise of existing bench resources and apply the obtained cutting edge technology knowledge to regular commercial projects.
A codebase of released commercial products can be also a useful source for the guild expertise. Some of the features (modules) can be implemented with a possibility to reuse in future projects. Such cases should be registered and cataloged in the guild’s proven solutions library.
It is essential to cultivate a culture of communication and mutual assistance for those who need help. In large companies, the number of members at one guild can be quite big. That’s why guild leadership team must not only mentor but also know how to delegate mentoring duties among the most qualified engineers.
Mentoring should be one of the necessary skills of senior-grade developers. Developers say that you can’t feel like a truly senior, if you don’t work with lower grade teammates.
Guild members need to be continuously developed. The guild should give motivation, provide its members with roadmaps, checklists, and transparent assessment procedures. Relevant training and workshops should be performed on a regular basis. Skills assessments should be done in terms of guild projects execution. Assessment must be carried out in such a way that the final result is reasonable, measurable, unbiased, honest and understandable to the engineer himself.
The guild should select top notch specialists that can provide high quality job interviews.
As we can see now, a technology guild has many duties. We understand that some of the statements described above, can’t be implemented immediately and in full. Sometimes, in the real world, you have to deviate from rules for the sake of the result.
Nevertheless, we think that technology guilds should serve companies in achieving the following goals:
The released products should have decent quality, made with love and modern approaches, a small amount of technical debt, which is registered and can be eliminated if necessary.
Having guilds, companies can easier unify technologies usage and delivery processes across various accounts and departments.
Offer proven solutions for standard as well as for non-trivial tasks. The guild expertise should grow and help to solve engineering problems more and more effectively .
Significantly raise engineers retention in a company. It’s good when the guild creates a large number of successful developers who are grateful for their expertise.
The expertise of the company itself must be carefully stored, cataloged and be accessible to reuse. And some of its innovative components should be presented to the community to promote the company as an active participant in its life.