Revisiting Agile Guilds: Charter Guilds
TL;DR: Jumpstarting Cross Team Collaborative Effort Requires Some Structure
- 20% time is a great rule for teams that have experience with self organization, but alone will not help you jumpstart this type of generative culture
- Traditional guild structures focus on sharing and learning, but don’t explicitly solve big problems or mitigate single points of failure
- Cross team groups have a habit of outlasting their usefulness and solving problems simply because they exist
- Charter Guilds are a new concept that have helped us create mission driven and aligned groups to solve our organizations’ biggest problems
The guild concept has delivered substantial mileage for my teams throughout my technical career — breaking down silos, creating consistency, and promoting specific proficiencies. That being said, there are many different ways to implement guilds, and those differences can optimize for different outcomes, some of which are not core problems that guilds usually solve for. Back in early 2017 I published A New Agile Guild Model, which outlined a distributed guild team model that we were successfully using at Yodle (which was acquired by Web.com). In the two years since I published that article I was hired by Policygenius as the head of engineering. At Policygenius, we’ve started experimenting with a new style of temporary mission driven guild that we call a Charter Guild.
…the tech debt…was there, and because there wasn’t an explicit framework for tackling it, it was accruing sprint by sprint without any mitigation
Identifying Problems
I started my new job with a 90 day mission to onboard myself and find where I could add significant value without stepping on anyone’s toes.
Some common themes started to surface in my tour of one-on-ones with the engineers and product managers:
- There was technical debt that engineers could never find time to work on
- Engineers were starving for ways to learn new technical competencies
- There was a fair amount of operational risk as a result of a few individuals who had unique roles and didn’t have any backups
Compared to other places I’ve worked, the tech debt wasn’t crushing, but it was there, and because there wasn’t an explicit framework for tackling it, it was accruing sprint by sprint without any mitigation. The company was coming out of startup mode where accruing tech debt was a feature, not a bug, but they hired me in part to help them transition the team from startup mode to growth mode, and part of that was finding a way to consistently pay down debt. As an engineering leader, the least you can do is abide Marty Cagan and carve out 20% of every sprint to give your engineers some room to work outside of sprint priorities. However, this situation needed a cultural and behavioral change. It needed a jump start, something more visible and with more support from peers and management.
As far as engineers expanding their skills, I saw plenty of opportunities for them to learn new technical competencies and have real impact while doing so. However, at the time, most of those opportunities were wrapped up in architectural improvements and in paying down tech debt, which, as previously stated, the team didn’t feel empowered to take on.
Lastly, there were a number of single points of failure. We had a single site reliability engineer (SRE), test automation engineer, and data engineer. They were all constantly on call — the team was accustomed to holding their breath when any of these three went on vacation — no one could review their designs or project plans, and no one could provide code reviews for their daily work. Yikes! The obvious solution was to hire more people into these roles, but we also needed a shorter-term solution since hiring engineers takes a while in the crazy New York City job market.
It felt like something guilds were meant to solve, but the existing implementations I knew left me with concerns
Concerns with Existing Solutions
So, that’s the premise — how can we solve all three of these problems with a single sweeping solution, while doing so with as much excitement and visibility as possible? It felt like something guilds were meant to solve, but the existing implementations I knew left me with concerns.
We could have used the classic Spotify model to create guilds that build backups for our unique roles, while also providing learning outlets for other engineers: an SRE guild, a test automation guild, and a data engineering guild. The concern I had was that I was still very new to the organization and creating constructs like these could have easily become permanent. What if I wasn’t seeing the whole picture yet and created the wrong groups? What if I matched the engineers to the guilds in the wrong way? I had only known the team for a few weeks after all.
There was also the inconvenient fact that this implementation didn’t address the tech debt or architectural augmentations that were needed. I also have a philosophical hangup with working groups whose only goal is to share and learn. From past experiences, the learnings are shallow and easily forgotten and group participation dwindles quickly. Charter Guilds to the rescue!
…each guild spent the first three weeks drafting their charters and choosing what project they would work on
How Charter Guilds Work
A Charter Guild’s membership is made up of people from different teams. Each guild:
- Is centered around a single competency
- Has a designated chairperson who is an expert in the competency and will facilitate the meetings
- Is temporary and should disband when they have achieved their primary goal or project
- Will self organize and draft a charter in the first few weeks of organization. The charter will outline how the group will organize, what their primary goal/project is, and what their secondary goals are
With this framework in mind, we created our first guilds, which were the DevOps Guild, the Quality Guild, the Data Engineering Guild, and the Front End Guild. The first three were chaired by our SRE, test automation engineer, and our data engineer respectively. The Front End Guild was made up of some of our more experienced React engineers. Each guild had preset secondary goals of spreading knowledge, creating backups, and creating a group that could review each others designs and code — thus mitigating our operational risk and helping other engineers expand their breadth of knowledge at the same time. The Front End Guild’s mission was slightly different — more focused around standard practices and evangelizing them on every team.
Additionally, each guild spent the first three weeks drafting their charters and choosing what project they would work on. I created these specific guilds because I generally knew that we had some meaty issues to solve around these four areas, but in the end the guild members chose where to focus based on internal ROI discussions. They chose impactful projects like Dockerizing our development environments, implementing a data streaming POC for our data warehouse, creating code standard documents, and squashing flakey integration tests and ensuring that new ones are automatically flagged. All of these were new advances that would not have been possible to prioritize previously.
In order to make sure the guilds were empowered we instituted a 20% time rule on every team, and each engineer was encouraged to use that time for guild work.
In order to make this as exciting and inclusive as possible, every engineer was drafted as a member of at least one guild. We may not repeat this in the future as we scale, but it had the desired effect for the first iteration.
…disbanding and reforming [guilds] allows us to change membership and to ensure we are always solving the most important problems…
Results
None of this is to say that this was an easy change to make — these types of changes seldom are. We had our share of growing pains and early learnings and are still working through some challenges now. The chairpeople had to learn to be chairpeople. The engineers had to figure out the best ways to split their time between sprint work (80% of their time) and guild work. This is why the most important element for success is having a motivated team who is bought into the process early. Each of the challenges they faced, they met head on and applied creative ideas to help solve, such as group coding sessions to help with shared technical learnings and to ensure dedicated time, or engineering wide brainstorming sessions to narrow down the multitude of projects they could work on. We still have a lot to learn and grow around the concept, but we did achieve results and will no doubt improve with each iteration.
We disbanded our first iteration of charter guilds in January, each having finished the goals that they had set in the beginning. Since then, we set new engineering department goals. The second iteration of charter guilds have become tools to help us solve some of our biggest objectives, and I hope to keep up this cadence in the future. The disbanding and reforming allows us to change membership and to ensure we are always solving the most important problems that we have right now and not keeping groups together artificially as they lose their value over time.
…charter guilds should be used when you want to solve some tough problems, want to train backups quickly, want to provide learning opportunities, and don’t want to invest in something long term that may have diminishing returns
Broad Application
Reflecting on what we’d achieved and how this structure is different from other guilds I’ve created in the past, I started to think about what other scenarios this might be applied to effectively. Most other guild structures require a certain level of expertise from their members and many times are made up of people who are highly specialized (e.g. a Platform Guild made up of SREs exclusively). This model works really well for larger organizations, which require ongoing effort in these specializations and have the headcount to support hiring this many experts — but for obvious reasons is very hard to justify in a smaller 10–40 person team. I think that the charter guild model can be instrumental in shifting your early stage tech team into the growth stage, when you will need to start consistently paying down tech debt and invest in cross team standards and learnings. However, I don’t think charter guilds need only be applied to growth stage teams. Their finality and goal driven approach can easily coexist alongside more permanent guilds at larger companies with hundreds or even thousands of engineers. In general charter guilds should be used when you want to solve some tough problems, want to train backups quickly, want to provide learning opportunities, and don’t want to invest in something long term that may have diminishing returns.
Policygenius is hiring in New York City. We’re a growth stage startup and are growing fast — our engineering team will be doubling in size over the next year. We’re big believers in modern engineering and product practices, which translates into a fully agile, dual track discovery based team, with engineers, product managers, and product designers making up cohesive squads. We pride ourselves on continually looking for better ways to solve problems (hence this article). We also pride ourselves on using modern technology with a fully cloud based approach (Web and Data Warehouse), automated testing built in, and an automated CI/CD pipeline.
If you’re interested or just want to grab coffee and chat, please take a look at our job boards and apply here.
