ADRs sound scary! I saw one in my career, and that thing was like 50 pages long! 😃
But I really like this idea of guilds. It often happens that I DM people I know they know because of how the communication is set up in my current company.
The one I worked for as a freelancer before had these front-end and backend channels, and engineers were often encouraging me to ask questions there or even search the channel because someone likely asked that question before me!
A 50-page ADR is really scary indeed. At that point, it’s most probably losing its originally intended value. I perceive ADRs at their initial phases as effective conversation starters (what is the problem and its impact) and later as documents capturing agreed-upon decisions. Similar to PRDs for products. For example, if ADRs are discussed within guilds as part of an architecture review, it’s all about guild elders setting up the correct expectations.
You mention a great point about shared channels for communication. We have dedicated Slack channels for every guild, and at the same time, each guild has its own “wiki” space for core information, ADRs, guild goals, expectations from members, etc.
We too had this, knowledge sharing session with team and also with other teams. But apparently it all gradually dies and only one person has to keep pushing others to share something. I think at the end we need to invoke the willingness of people, and how to do that is the question
I can resonate with the article and most big companies have these chapters or something similar.
I don't necessarily understand that "Members have the freedom to choose projects they want to participate in based on their interests and career growth goals."
I mean, it's not that I don't understand it; I just think it's very difficult to implement, and telling it without doing it will probably cause a lot of frustration.
So, it would be great if you could expand on this topic. How easy is it to couple this freedom with the company's objectives?
Thanks for the question, Leo. You are correct. If the project space were unbounded, offering time capacity to any guild member for any project they want would be almost impossible.
The statement is tied to point 1: “All guild’s projects must be tightly related to the company’s strategic goals.” From these projects, guild members can pick (assign themselves to) what interests them or aligns with their goals.
The funnel we’ve built for projects looks something like this:
- We have a “board” where anyone can write any topic for the guild (e.g., architecture improvement, CI/CD optimization, new approach to testing, …)
- Every guild member can then vote for topics on the board, and the highest-rated topics are discussed in regular guild meetings.
- Some of these topics are resolved directly during the discussion, and some need more work, and they form input to the guild’s project planning
- Based on these inputs (problem, impact) and the company’s strategic goals, several are selected as “the next guild’s goals”.
This way, developers create and agree on what to do, and at the same time, because this work aligns with the general direction, leadership is more than willing to allocate resources for it.
ADRs sound scary! I saw one in my career, and that thing was like 50 pages long! 😃
But I really like this idea of guilds. It often happens that I DM people I know they know because of how the communication is set up in my current company.
The one I worked for as a freelancer before had these front-end and backend channels, and engineers were often encouraging me to ask questions there or even search the channel because someone likely asked that question before me!
Great writing both of you! 👏
Thank you, Akos!
A 50-page ADR is really scary indeed. At that point, it’s most probably losing its originally intended value. I perceive ADRs at their initial phases as effective conversation starters (what is the problem and its impact) and later as documents capturing agreed-upon decisions. Similar to PRDs for products. For example, if ADRs are discussed within guilds as part of an architecture review, it’s all about guild elders setting up the correct expectations.
You mention a great point about shared channels for communication. We have dedicated Slack channels for every guild, and at the same time, each guild has its own “wiki” space for core information, ADRs, guild goals, expectations from members, etc.
We too had this, knowledge sharing session with team and also with other teams. But apparently it all gradually dies and only one person has to keep pushing others to share something. I think at the end we need to invoke the willingness of people, and how to do that is the question
I can resonate with the article and most big companies have these chapters or something similar.
I don't necessarily understand that "Members have the freedom to choose projects they want to participate in based on their interests and career growth goals."
I mean, it's not that I don't understand it; I just think it's very difficult to implement, and telling it without doing it will probably cause a lot of frustration.
So, it would be great if you could expand on this topic. How easy is it to couple this freedom with the company's objectives?
Thanks for the question, Leo. You are correct. If the project space were unbounded, offering time capacity to any guild member for any project they want would be almost impossible.
The statement is tied to point 1: “All guild’s projects must be tightly related to the company’s strategic goals.” From these projects, guild members can pick (assign themselves to) what interests them or aligns with their goals.
The funnel we’ve built for projects looks something like this:
- We have a “board” where anyone can write any topic for the guild (e.g., architecture improvement, CI/CD optimization, new approach to testing, …)
- Every guild member can then vote for topics on the board, and the highest-rated topics are discussed in regular guild meetings.
- Some of these topics are resolved directly during the discussion, and some need more work, and they form input to the guild’s project planning
- Based on these inputs (problem, impact) and the company’s strategic goals, several are selected as “the next guild’s goals”.
This way, developers create and agree on what to do, and at the same time, because this work aligns with the general direction, leadership is more than willing to allocate resources for it.