| title | description |
|---|---|
Working Groups |
How we work on cross-organizational issues |
Sometimes there is a problem to be tackled or something to be improved that spans multiple squads or areas of the company. When this happens, we gather people with different expertise to come up with a solution in a Working Group (WG).
Working Groups are short-lived, temporary teams of diverse contributors created to solve a cross-organizational issue. To elaborate:
-
Short-lived: Working groups must have a clear, planned end to their existence. They cannot run indefinitely.
-
Temporary: Working groups do not live on an organizational chart, and the group’s work isn’t anyone’s primary responsibility.
-
Diverse: The members of the working group all see the problem in different ways.
-
Cross-organizational issue: Working groups only address cross-org problems; otherwise, an individual team could manage the problem themselves. Worth noticing that these problems don’t need to be exclusively technical - they can be related to processes, practices, etc.
Although some product initiatives and services could be seen as “cross-organizational”, they shouldn’t be tackled by a working group because WGs, by definition, are short-lived, temporary, and tackle ownerless issues. Products and services must have a clear owner and must be handled inside one squad’s scope.
Working groups bring benefits not only for Loadsmart as a company but for us as individuals too.
Not all problems require a dedicated team to solve them. Sometimes, we just need a focused effort to address them and trace a new path that would prevent that from happenning again. This is where working groups thrive, ensuring people have space and support to solve the issue. For the company, this means that we can solve problems and keep developers engaged with the people we already have.
ICs can work with new people on different problems that have an impact on multiple squads across the company. This not only extends their network but also makes it easier for them to share experiences and practices. This undoubtedly contributes to their career path in the company.
Managers have another path besides day-to-day work in the squad to help their ICs grow and develop their competencies. This is also an opportunity to expand their reach through delegation, allowing them to influence important decisions being made outside their squad’s scope.
Before assembling a working group, there are some questions that we need to answer. Tip: if “no” is the answer to any of these questions, then a working group is not a solution.
Working Groups exist to solve a clear problem in the organization. Before anything else, we should ask ourselves if what we want to address is really a problem and how it affects us. List the consequences of this problem for the company or the broader group. If you find yourself with a bunch of nice to have items, maybe there is no problem to be addressed.
Is this something that affects other people at the company and/or engineering, from different squads and areas? If this problem only affects you or your squad then it shouldn’t be addressed by a working group - instead, talk with your teammates to build a plan to handle it in the squad’s context.
Sometimes although we see something as a problem, it doesn’t mean that it should be resolved at this time. Think about automating account set up for new hires: if we are small and hiring a couple of people per year, with a handful of services to manage, it could be a problem to not have it automated. At the same time, “resolving” this problem isn’t worth it. Talk with people across different squads and areas to gather their feedback about solving this problem now.
Now that we agree this is a problem that should be addressed now, the last question is to determine if this problem has an owner. For example, problems in services owned by a specific squad are this squad’s problem - and again, it should be handled in their context instead of a Working Group’s.
To participate in a Working Group it’s expected that you are affected by the problem somehow and have a clear understanding of it. Before committing to a WG, it’s important to have a few things in mind:
-
You have time to dedicate to it: others will count on you to help, so better to be planned to dedicate at least some hours per week to work on it. As mentioned before, WG work isn’t anyone’s primary responsibility so make sure to align expectations with your manager before committing to help.
-
You have the desired skills and experience: WGs are formed to address a specific problem. To reach their goal, there is a lot of research, coordination, and work to be done - so people joining this WG must have the desired skills to contribute to the solution. For example, if a WG is formed to address a backend issue, then it’s expected that backend engineers with compatible experience are in this effort.
-
You are interested in helping with this particular problem: participating in a WG isn’t required - although you will certainly collect benefits from it.
Every member of a working group is accountable for its decisions, so it’s important to dedicate the proper time to it. Keep in mind that although there are no lower or upper bond limits for a WG size, it’s important that we have the right amount of people - too few, we won’t be able to reach the goal; too many, there will be more noise and the group will move slower.
Each working group must have a leader. The leader is a member of the group - like any other member - and it doesn’t need to be necessarily the person who advocated for the creation of the WG (although there is no problem with that). It’s important to notice that all other requirements for group members apply to the leader as well - no special privilege here, just a different kind of work.
The WG leader is responsible for ensuring that the goal is attained, motivating the team, and being a resource that group members can reach out to for help. A leader must be chosen based on their leadership and communication traits and the knowledge of the problem the group aims to solve.
There is no management relationship between the group leader and other members or sponsors. The goal of the leader is to facilitate and help other members while serving as the accountable person for the WG progress.
To help the Working Group reach its goal, one or more sponsors are crucial. Sponsors can help in many ways: recruiting more people for the WG, reinforcing the group’s decisions to the broader company, clearing any roadblocks with squads or upper management, and so on.
Sponsors don’t need to be direct managers of the people participating in the working group. Ideally, they should be individuals that have some sort of authority over and/or are familiar with the problem that’s being tackled. The right sponsor can make a big difference in the success of a working group.
As short-lived, temporary initiatives, Working Groups must have a clearly defined mission (ie, the purpose of its existence) statement that will have a double purpose: serve as the objective of this WG and, when the objective is reached, will also work as the trigger to dissolve it. Because of what’s stated above, the mission is one of the most important things to do before the group even starts working. It should be defined by the WG members with the help of the sponsors.
The mission should be - preferably - a one-line sentence that clearly states the group’s objective and purpose. It must inspire members and provide the boundaries on what’s in the group scope and what’s not.
In order to reach the group’s objectives in a reasonable time (this is not a full-time job, you’ll still have your own responsibilities in your squad), it’s important to define a clear action plan, with milestones and deliverables. The same rules from product development apply - small and constant deliveries versus big releases (this allows the group to change strategies to reach the goal if needed).
Whatever the plan the group builds, the following requirements must be considered:
-
Discovery phase: do we fully understand this problem? Any additional analysis must be made before we start working?
-
Success metrics: what are the metrics that will be evaluated in order to say if the group reached its goal? It’s important to collect these metrics before and after changes made by the group, measuring the impact of group actions as closely as possible.
-
Ownership and execution: WG’s work will generate tasks for its members. It’s important to define clearly who is responsible for what, with clear deadlines. Missing deadlines and not executing tasks will delay the working group’s progress, harming the whole initiative. Depending on the kind of tasks, consider using a Jira board to track progress.
-
Dedicated time: how much time group members will dedicate to the WG? It’s important to remember that working groups are not anyone’s primary responsibility, so you would still have work to do in your current squad. It’s important to have a clear understanding of how much time each member should dedicate to the initiative per week, and this also must be aligned and agreed upon with their respective leaders. Generally speaking, WG work will count against the total time dedicated to the technical lane (at the time of the writing, 15%).
-
Day-to-day communication: for regular communication between group members, a public Slack channel must be created with the #wg- prefix. Although sometimes is tempting to create a private channel or communicate through DMs, having a public channel increases the collaboration between members, sponsors, and stakeholders.
-
Regular check-ins with sponsors and stakeholders: as with any initiative, the WG must also present its findings regularly - that includes the metrics chosen to measure the initiative, actions that are being taken, what’s the progress so far, etc. It’s recommended that these check-ins happen weekly or bi-weekly with sponsors and monthly with the broader organization.
Unless it’s a sensitive issue (eg. a security matter), an RFC should be created outlining the plan.
Not enough time
Sometimes the effort to solve a problem could require more time than the group has available. In that case, standard prioritization rules apply: reduce the scope in order and prioritize initiatives to deliver value as early as possible.
Working Groups don’t exist under any specific squad or squad group - but that doesn’t mean they aren’t accountable. They must constantly progress towards their goals and provides visibility to stakeholders and the broader company.
Although not required to follow the exact process recommended here, it’s important to understand why you’re doing (or not doing) something. The final outcomes shouldn’t change.
| Frequency | Weekly or bi-weekly |
| Participants | Working Group members + Sponsor |
| Recommended duration | 1 hour |
Check-ins are a way to keep everybody on the same page and ensure the progress of assigned tasks. It also helps to communicate about blockers and ensure the group is on track to deliver the objectives. If there is something that needs to be done, then it must be assigned to some group member and they will be responsible to have it solved before the next check-in.
Check-in meetings should have their notes readable to anyone at Loadsmart and should contain main topics discussed and actions for the next meeting. A member of the group must be responsible to write down the notes.
It’s almost equally important not only to solve a given problem but also to communicate to the involved parties the decisions taken. The best way to document decisions taken by the group and allow all members to contribute to the discussion is by creating an RFC document.
For every relevant decision, there should be an RFC document explaining what we are trying to solve and how we will solve it. It doesn’t need to be a long document - we must only ensure that whoever is reading it (even from outside the group) can understand why a given decision was taken. It also provides the opportunity to open up the contributions to all members.
It’s important to report to the broader company/engineering the progress of the Working Group. Since the time commitment could vary between each group and problem, define a cadence on what the progress should be reported: this will keep other people engaged and will make it easier to get help from them if needed.
In the progress report, try to show concrete actions that were taken to solve the problem. Show the evolution of defined success metrics and be honest about them - if actions didn’t generate the expected outcome, then recognize it and show what the group will do to make progress (change focus, execute other actions, etc).
The format of the report can be decided by group members on each case, but consider scheduling a presentation, especially if there is a lot of data to communicate or if the group reached a significant milestone.
Working groups are short-lived and temporary. This means that they can’t run forever and must have a clear understanding of when they are not necessary anymore.
The best way to say if a group reached its goal is to look at its mission: did the WG accomplished what it was intended to? If not, how far are we from that?
There is no hard rule for how long a working group should run but keep in mind that, as with any initiative, it must constantly deliver value based on its purpose. If that’s not happening, then the members - together with its sponsors - must have a clear conversation on what needs to be done to deliver the proposed value or if the group must be dissolved.
When the working group achieves its goals, it’s time to communicate and celebrate 🎉. Ensure all relevant parties are aware of the achievement and take some time to celebrate - after all, gathering a bunch of different people in the same “room” to solve an important problem is not a small feat 🙂. Make sure you organize a happy hour!
And now that everything is done, it is worth reminding that it is the perfect moment for a blog post. Stating the problem, going from the initial discussions, to the findings, to the approaches, to the solution. Everything. It tells the type of story that everybody is eager to hear. Stories containing unique company problems are the best cases to be told! Make sure you take the opportunity to share your and your group’s work with the world.
The first thing is to make sure there are no other WG working on the problem - there is no benefit to have 2 different WGs working on the same issue.
Make sure you answered the questions in the Validation phase:
- Is this really a problem?
- Are other people affected by this problem?
- Do people across the company agree that someone should address this problem?
- Is this problem ownerless?
If the answer to any of them is “No", we probably shouldn’t have a WG in the first place.
Your direct manager can help you with feedback and tips on the issue. They can also help you find peers that could be interested or affected by the same problem and point you to somebody that could be the sponsor. Use your manager to grow your network inside Loadsmart!
You must also align with your direct manager on how much time you can dedicate to the WG. We don't expect anyone to work after hours, so your activities in the WG must be conciliated with your daily work in the squad.