Being a fast-growing tech company, Workiva has steadily been adjusting its organizational structure to account for the changing demands of a larger development organization and a higher number of development releases. To date, we have hundreds of developers collaborating on a wide range of technical topics every day. Our developers frequently ask these questions:

• How can we make timely decisions?
• What are the principles, standards, and best practices that should drive these decisions?
• How can we ensure that our developers continue to improve their decision making?

These are some questions that drove our architecture organization to consider the guild structure used by companies such as Spotify and Trivago.

In this article, I list the pillars of a guild, describe how we run them, and share the outcomes we hope to achieve.

Four Pillars of Guilds

Scalable Decision Making

Workiva developers make dozens, if not hundreds, of software design decisions every single day. Most of those are small, localized decisions that don’t require any in-depth discussion or cross-team coordination. For those with extensive impacts or competing perspectives, RFDs (Request for Discussion) have become the most popular mechanism for resolving and documenting decisions.

When a complex or contentious topic emerges, an interested developer typically creates an RFD document that explains the topic and proposes one or more potential resolutions. They find anyone who is interested in that topic, collect input and capture them in the RFD doc, and then call a meeting to make a final decision.

The RFD process works well when the decision is relevant to only a small group of invested developers. It’s been less successful for topics that impact a much wider audience (e.g. changing a communication protocol in services that affects hundreds of developers). It’s difficult to gather all of the necessary stakeholders across different teams/offices to make these decisions on time. Moreover, with the increased focus on software reuse within our development organization, more and more of these cross-cutting topics emerge, and their ownership is unclear.

• What decisions rise to the level of requiring a cross-team RFD?
• Who should drive the creation of that RFD content?
• Which stakeholders need to contribute or know about the RFD?
• Who determines when the RFD has resolved?
• Who is ultimately responsible for making a final decision?
• Once a decision has been made, who is responsible for the execution or implementation?

For most RFDs, a relevant guild will be responsible for answering all of those questions. By bringing subject-matter experts from all across Workiva together to collaborate as part of a guild, we can scale these critical decision-making processes more efficiently, while ensuring that important RFDs are not forgotten. Developers can bring new topics to the guild, create new RFDs as needed for documenting decisions. Guild members can then disseminate those decisions to their teams to guide future work.

Standards and Best Practices

Our developers are regularly studying the principles, standards, and best practices of our industry, including exploring emerging technologies, techniques, and trends. No single developer or architect can keep up with all of these efforts single-handedly, so there is significant value in guild members sharing the relevant results of their exploration with the guild. Their efforts pay off when the guild can collectively promote the use of specific standards or frameworks that apply well to the majority of Workiva developers. The guild should aim to establish best practices that reduce ambiguity, enhance consistency, and enable developers to make appropriate choices. Ultimately, the guilds improve software quality by partnering with engineering management to establish and advocate for standards and best practices within their domains.

Cross-Group Collaboration

At Workiva, we value diversity and believe it can improve our decision-making process and risk mitigation. While our developers participate in making many decisions, we also want input from product marketing, product management, engineering management, user experience, delivery management, and other cross-functional groups as stakeholders where appropriate. The guilds encourage collaboration with the different groups and break down knowledge silos. The work of the guilds ultimately spans across R&D and the rest of the organization.

Technical Mentorship

We believe that when we bring developers of diverse experiences and skill sets together, we can create a network of mentors and build up each other’s skills. By forming a guild in each domain area, our developers have a space for targeted research and discussion in a group setting, allowing them to develop their skills in a supportive atmosphere.

Running A Guild

A guild operates with transparency. It has regularly scheduled meetings with a pre-published agenda, advertised communication channels (including a chat room and a group mailing list), and published meeting recordings and artifacts that are accessible by anyone in the company.

Each guild has a designated leader, typically the Lead Architect for that domain. The leader regularly calls meetings to discuss challenges and coordinate on items that require consistency across that technical domain. The guild establishes standards and best practices so that there is a framework to drive decisions via RFDs. Relevant Architects, Principal Engineers, and Tech Leads are required members of the guild, though any Workiva developer can attend guild meetings and contribute to discussions and RFDs.

Working Groups

At the request of any guild member or upon identification of a topic that spans multiple guilds, the guild leader can call on subject-matter experts to form a working group. The purpose of this group is to meet, discuss, research, document, and present a specific topic within a limited time frame. Throughout the lifetime of this group, developers teach and share knowledge with everyone involved. After achieving its stated goal, the working group will disband.

Open Community

Guilds are open for anyone to join, especially for those who are interested in the domain or want to be an architect someday. Since access to guild meeting artifacts is available to everyone, regular attendance at guild meetings is optional for some members. Each guild charter clearly defines the responsibilities of their members.

Results Matter

Forming guilds is a strategic move to cultivate technical excellence at Workiva. As we establish and evolve our guilds, we should ensure that they result in effective decision making, delivery of high-quality software, and better developers.