5 Tips for Revitalizing Your Dev Guild
Developer guilds are becoming commonplace in IT companies. These are a kind of informal interest clubs that help improve processes, exchange experiences and develop participants. The potential of such communities is very high – they can trigger changes at the level of the entire company. But what to do if activity in the guild has decreased and it has become unclear why it is needed at all?
My name is Sasha Kiverin, I am the leader of the Python guild in Cyan. There are currently more than 60 developers in our community. Over the past 2 years, we have jointly completed a number of cool projects. We transferred the monolith from Python 2.7 to 3.12, created a library for external calls, and implemented an automatic microservice health checklist. 5 simple tips helped us get it all to the market, which I will share in this article. I hope they will help revive your guild too.
I'll start with the basics – why is all this needed? If you already know, feel free to skip to the first tip.
Why does a company need a guild?
The first question that is worth asking yourself, and which stakeholders will probably ask: why should a company support third-party developer activities if you can direct their efforts to the product and get results right away? Here are a few reasons why this is important:
Developer Experience (DevEx)
To understand what developers need and what their problems are, you need to look at the situation as a whole. Without sharing experiences, you can get a false impression of the current state of affairs or, even worse, waste resources on projects that no one needs. The Guild helps create a culture of feedback, which provides many useful insights for improving DevEx.
Platform as a Product
Any product needs feedback for development. In the case of the platform team, the entire guild is the client. Feedback should be timely – it is best to receive it immediately after the release and in large quantities. By creating new channels of communication with developers, we speed up the transition to new versions of libraries and receive faster feedback.
Developer Retention
Developers can get tired of routine business tasks. We cannot transfer everyone to the platform team, but we can offer them interesting projects within the guild. This allows you to change activities without having to change your team, which reduces turnover.
Growth
Developers need to grow, and our task is to help them do this. The Guild provides opportunities for growth through internal projects that can be larger and more complex than the tasks of the main team. Sharing experience also speeds up the search for mentors, which helps to develop faster and better.
Employer-brand
The guild directly affects the speed of hiring. It provides a forum for sharing experiences internally, which helps developers move more easily to external gigs. Even if the contribution to external activities is insignificant, the guild still strengthens your Employer brand – the interview story about how your development works becomes brighter and more convincing, especially when there are real internal projects and tools behind it.
Why does the guild need company?
Can a guild exist separately from a company? With plans for sustainable development – no. Without transparent planning and communication with leads, large projects simply will not move forward – there will be no one to implement them, since the developer simply will not be released from his team’s projects. And if projects are not related to the company’s goals, then over time stakeholders will no longer see the point in them.
The conclusion is simple: for the guild to work successfully, you need to work closely with the company. Work openly, connect your projects to company goals and show results. In return, receive the resources and support you need.
Now let's get to the heart of the changes: establish communication channels with the community, collect useful ideas from them, monitor important company and market indicators. Delegate tasks and promote planning among developers and their leads.
Tip #1. Start regular meetings
Regular meetings are an important component of a successful guild. Without them, focus is lost and developers gradually lose motivation. Meetings help synchronize work, exchange important information and identify problems that need to be solved.
Pull meetings are rarely useful because developers may underestimate the importance of their topics and move discussions to chats. The topic table remains empty in most cases.
The frequency of meetings and their length will vary depending on your company, but it's important to remember that long meetings are time-consuming and can be intimidating to participants. For example, we have come to the format of a weekly sync for 25 minutes.
When choosing a time for a meeting, try to take into account the schedules of all teams. It is advisable to have at least one representative from each, who can then convey important news, tools and practices to colleagues.
Understanding that not all developers will be able to attend, record meetings and save them along with notes in the guild channel. Use transcription and ChatGPT to create short abstracts to escape the daily routine. In our case, 30-50% of developers visit weekly synks, so channel notes are a great way to reach the rest.
Bonus tip: Separate your guild channels into informational and discussion channels. We use #python-dev for questions and discussions, and #python-info for notes from meetings, important announcements and notifications about releases of internal libraries. This helps keep developers focused on key launches and increases their engagement.
Tip #2. Make a meeting template
What to discuss if we have moved away from on-demand meetings? Create a standard meeting template and follow it every time. Discuss the status of internal projects, recent launches, problems in production and collect feedback from developers. A template will help you stay on track even if there are no interesting topics to discuss before the meeting. It is important to monitor participants' reactions and ask open-ended questions to extract as many useful ideas as possible.
From our experience: at meetings we discuss current internal projects, advertise useful activities, talk about the latest launches and share plans for the future.
Don’t forget about people’s achievements—don’t hide them behind general phrases like “such and such features appeared this week.” If someone has implemented a new tool, highlight this in the meeting and give the person the opportunity to share their experience. If someone has completed training and has become an independent interviewer, note this too.
Also always invite and introduce new developers. This will help them adapt faster and make onboarding more comfortable. In our experience, new employees are more likely to become involved in the life of the guild if they are familiar with its culture from the very beginning.
Tip #3. Collect a project backlog and task digest
Regular meetings and discussions are good, but without specific tasks and projects to keep members busy, guild activity will begin to decline. To keep developers interested and engaged, it is important to have a constantly updated list of tasks on hand that you can offer to participants.
Where to get projects from? Here are some ideas:
Someone else's experience. Study what other companies or neighboring stacks in your company are doing and adapt it to your needs.
Trends. Follow the trends. This doesn't mean you need to attend every conference under the sun. Sometimes it is enough to study the technical radar once every six months, for example, from Thoughtworks.
Automation. If there is routine manual work, try to automate it. For example, we introduced automatic re-opening of tasks on CI in case of insufficient coverage, which previously had to be done manually.
Problemswhich the developers themselves talk about. Before tackling them, consider the relevance and importance of these issues, as well as their relevance to the goals of the guild. Even if they immediately come to you with an idea for a solution, try first to pinpoint the problem where the need to change something came from.
Don't delay projects if some members don't support the idea. Work with their objections, try to understand their reasons. If after clarification only subjective arguments remain, continue working on the project. For example, when we introduced automatic code formatting, there was a lot of controversy over style. But over time, everyone got used to it, and now 100% of our active services use ruff.
Another important point is the barrier to entry into working on projects. Large problems are often associated with uncertainty, which can discourage developers without successful experience in solving such problems. To help them decide, follow these simple rules:
Always describe the project in detail and clearly state the end result. This way the task will become more understandable and tangible.
Finding time for a task in one day is easier than for a week-long project. Therefore, we created a task digest, including small tasks up to two days. The list is available to everyone, and any developer can choose a task to his liking. Additionally, you can add improvements to the digest that turned out to be outside the scope of your main guild projects.
Try to involve as many developers as possible in working on internal tools. We use the good-for-introduction label for tasks that do not involve large risks and help you get comfortable with a new code base. These could be minor edits or documentation improvements.
Tip #4. Look for talent
The project is good, but to implement it you need a hero who will take on the main role. Start your search for an artist with the person who proposed the idea. He will most likely have the highest motivation to complete the project. To make it easier for him to cope with the task, involve other guild members and create a working group. However, do not let them go freely right away – help them at the start, limit the scope of the project and clearly formulate the definition of done.
Another source of potential performers is active guild members. Over time, you will have developers who are more likely to participate in discussions, attend meetings, and share their ideas. Don’t forget also about those who have already successfully implemented projects – you can rely on them. Contact one of them and you won't go wrong.
Promote free projects in general meetings and in notes – promote them through technical difficulty and benefit to the community. This is especially important at the end of the quarter, when teams are planning work and developers may have slots that can be filled with guild projects.
Bonus tip: The guild leader doesn't have to take on the largest amount of tasks. It is much more effective in the long run to focus on increasing the number of active participants and delegation. Make it your job to do as much non-DIY work as possible. The productivity of one lead cannot be compared with the work of several dozen guild members, even if only 20% of them are actively participating. However, it is still useful to take on individual tasks to maintain overall context and connection with the developers.
Tip #5. Work with transparency
It often happens that a project starts, but does not reach the finish line or moves very slowly. To maintain motivation and momentum, you need to avoid two main problems: lack of results and feedback after the work has been done.
There may be several reasons for the lack of results:
Non-transparent planning. If a project is poorly planned as a team, it has to be done in parallel with main tasks or even outside of working hours, which harms both the project and the developer. Before starting a project, make sure you have allocated time for it. Ask the developer to discuss this with the lead or do it yourself. Even if the project is scheduled for the end of the quarter, it is better than working without a plan at all.
Blockers. Sometimes a project is delayed because technical or organizational assistance is required. The best way to minimize such problems is to identify them early. If there has been no news on the project at a regular guild meeting for a long time, this is a sign that you need to discuss the situation with the developer.
Too much work. Try to reduce the scope before the start of the project and re-decompose it after, if necessary. The sooner the project is completed, the sooner the developer will have his first “success story”, which will become motivation for further work.
When the project finally reaches users, it is a success. But over time, the developer may lose motivation to take on new tasks. Why is this happening?
No sense of significance of the project. Invite the developer to talk about his experience and the difficulties he encountered. Such stories usually generate interest in the guild and increase the developer's sense of usefulness. For example, we periodically hold internal meetups instead of regular synches, where we share such cases. By the way, such meetups are then conveniently converted into speeches at conferences and articles.
Lack of influence on career growth. The possibility of upgrading is a strong incentive for developers. To better evaluate your performance review contribution, separate your team work from your guild participation. We did exactly this ourselves and equated participation in the guild in importance to product development.
Additional motivation. A new grade is good, but why not add something else? For example, once a quarter we select the most active guild members, whose contributions were especially memorable, and reward them with internal currency that can be spent on merch. This may seem like a small thing, but this approach significantly improves your mood and motivation.
Let's sum it up
So, what we got:
Regular meetings: Organize regular meetings, record them and make notes for those who were unable to attend. This will help keep developers aware of the life of their stack.
Meeting Template: Create your own meeting template. Include discussions about active projects, Python and company news, and be sure to recognize contributors' accomplishments. Don't forget that the purpose of the meeting is to collect as many insights as possible, and not just to discuss interesting topics.
Backlog and task digest: create and regularly update a project backlog and a digest of small tasks. Look for ideas in trends, other companies' experiences, and challenges developers face. The backlog and digest should always be complete.
Search for executors: invite the authors of ideas to bring the project to completion themselves. If this is not possible, involve active guild members and help them form a working group and set the task correctly.
Transparency and motivation: Work transparently, planning projects along with product tasks. Support the idea that community work should be valued by the company on a par with its core business. And don’t forget about additional motivation – reward the most active participants.
Of course, this list can be continued, but then it will be details. If I had to describe the entire guild experience in one phrase, I would say: value people, their experiences and their problems. Good luck on your journey to the perfect DevEx!
