The Rise and Fall of the Professional Guilds at CyberArk — Part 1
It’s been over a year since we shut down our last full-fledged Professional Guild. I can’t help but feel a little sad looking back at our Guilds movement, which has finally come to a close.
But the bigger question is: knowing what I know today, would I still build guilds in the first place? The short answer is — yes.
Let me explain.
The Starting Point
When I joined CyberArk five years ago, I found an amazing group of colleagues, a great product portfolio and an impressive customer base. But I also found many disparate teams working on different products, rarely exchanging ideas and experience, and even holding different visions of the future. People were particularly cautious when new tools, programming languages or third-party products were discussed.
Everybody was busy putting out fires and trying to meet the imminent deadlines. For the most part, engineers were like voiceless and overworked factory workers trying to make ends meet. In our conversations, I could hear a glimpse of hope for the better days: A more modern technology stack and development processes, more creative freedom and more autonomy.
But those days were yet to come.
My main goal was to help establish the technology direction, align the technical leadership around it, and find a way to drive the changes needed to make it a reality.
It was clear to me that the engineers had to establish a new framework where they could meet their professional peers from other groups, discuss challenges and ideas and start creating a common vision for the future. This would also serve as a platform to learn new skills, new programming languages or techniques, to safely try out new third party tools and libraries. Most importantly, this framework would allow the engineers to step away from their day-to-day tasks and learn a thing or two.
Guilds 1.0 — Our Take on the Spotify Model
Professional Guilds, which were popularized by the famous Spotify Model, fit our needs nicely. We already had 15% of the engineering time allocated for “their tasks”, so it was not too much of a hassle to round it up to 20% and allocate one full day a week to the Guilds. Having looked at the engineering tasks executed during those 15%, I noticed that in the best-case scenarios, this time was used to pay back some of the technical debt accumulated over the years. More often than not, however, it was simply a buffer for any existing commitments.
We needed to change this to make everyone value their time spent in the Guilds.
I decided to modify the out-of-the-box Spotify model by imagining an elaborate system of the Guild’ management structure including a Guild Lead, a Backlog Owner, a Guild Day Owner, and even a Training Coordinator roles. This model was supposed to distribute the load from the Guild Lead to additional people.
I also came up with a Guild professionalism ranking model starting with a Member, a Practitioner, a Specialist, and finally a Master. In addition, I created a scoring system which encouraged members not only to participate in the Guild days, but also to give lectures, write content, take professional courses, or take on additional Guild leadership roles. All this was to encourage participants to advance in their Guild ranks, propel their professional expertise and reinforce the guild movement.
Focus
We started off with three Guilds: Frontend, Backend and CI/CD.
For each Guild, I needed volunteers willing to undertake leadership roles at the expense of their personal time, as we could not carve out more than the requested one day a week. I also needed to find the pioneer members who would be the first to join and help solidify the framework.
After explaining a lot to different groups of people, we started. Guild by Guild, we sat together and rolled up our sleeves. We built a list of knowledge and technical gaps where the industry advanced faster than we were keeping up, the things we wanted to POC but never had the time for, the tools we read in the news but never had a chance to try. For the time being, we tried to ignore the elephant in the room -– the unhandled and growing technical debt — which sooner or later had to be addressed. We almost immediately gave up on the different Guild leadership roles besides the Guild Leads, who became the driving force for the guilds’ day-to-day life. When I tried to explain the elaborate ranking model, I got blank stares, so it did not even stand a chance.
Creating Quick Wins
The early adopters of the guild were the most motivated and enthusiastic engineers from the larger group, the ones most likely to succeed in the volatile guild environment. This allowed us to build a structural and content base for the rest of the engineers. This was such a great experience — those guild members were sparkling with great ideas and the training list and backlog filled quickly. That is when we came up with a squad-based mechanism where the Guild would split to run several tasks in parallel, and each group would present a demo to the whole Guild upon task completion.
Expanding the Guilds
Once we felt confident with the early adopters regarding Guilds’ structure, roles, and backlog, we expanded each Guild to include additional engineers who easily fit into the classification of Frontend, Backend or CI/CD. We organized each Guild day to advance some of the backlog items, have a short sync, or a technical presentation by one of the guild members or guest speakers.
Over-Expanding the Guilds
After a few months of running in this manner, we needed to extend the Guilds to include all engineers from the R&D organization. More and more people heard about the Guilds and wanted to take part in this project — after all, wouldn’t any engineer want to spend 20% of his work outside “actual work”?
Yet not everybody in the R&D could be classified into the three existing Guilds. There were also UI/UX engineers, security researchers, kernel developers (for different operating systems), DBAs, product owners and quality engineers. There were team leaders, group managers, project and product managers who were left completely outside the Guilds movement.
So we made attempts to create a Product Owners Guild, Internals Guild (for kernel developers), Quality Guild as well as a UI/UX Guild. Each of these didn’t manage to stick for a reasonable amount of time, and had to close. To paraphrase Leo Tolstoy: “All successful Guilds resemble one another, each failed Guild has failed in its own way.”
Finally and somewhat surprisingly, even among the Frontend, Backend and CI/CD engineers, some people just did not want to take part. Some felt that Guilds did not contribute to them professionally, while others felt that it would delay their day-to-day tasks and they would need to put in extra hours to fulfill their commitments.
The Big Divide
This created a virtual divide in the R&D organization between people who were attending Guild days and those who did not. This in turn created distractions for the Guilds’ members. Despite all the Guild Leads’ and my requests, there were still unrelated meetings on the Guild days and other interruptions by the team members going about their regular non-Guild business. This in time started to weigh on the Guild members, especially if their team members were struggling to meet a deadline or fighting an urgent crisis while their Guild teammates were learning Kubernetes on Pluralsight.
Managers also started to actively pull their engineers away from participating in the Guilds, due to real or perceived urgent matters, promising “to return” that day when the situation calms down. For a while we actually followed up on these Guild debts until we realized this was a lost battle.
Trying to Make it Work
Our Guild Leads and I were determined to make it work, so we experimented a lot: We tried to physically separate the Guild members from their teams by seating them together (it was before Covid). I personally circled the office asking why somebody didn’t participate, or had non-Guild related meetings on the Guild day. We tried to combine two consecutive days every two weeks; we even once ran a week-long Guildathon.
After approximately a year, our Guilds movement maxed out at approximately fifty active members across all Guilds, which was less than a quarter of the total R&D organization. The Guild Leads were tired from the ongoing personal investment and the uphill battle of managing sparse participation. Guild members felt guilty for letting their team members down, and management was tired of missing key technical people one day a week.
That’s when we decided that we had to pivot. Giving the Guild members some time off, the Guild Leads and I started working on an improved version, which we called Guilds 2.0.
