As an agile product consultancy, we often have to make adjustments to team sizes to accommodate new clients and optimize current teams. Our current scheduling process gets the job done, but it has its problems.
In our offices we have several people doing sales and scheduling and several other people serving as directors for designers and developers. Sometimes there is overlap in those roles and sometimes there is not.
We wanted to design an experiment to see if we could ensure that people doing sales and scheduling are on the same page as directors, specifically with regards to preferences and goals of designers and developers.
Current process
Members of the sales team, whoa are in some cases directors, are generally responsible for staffing. Once a new project comes in or a rotation has been identified we do the following:
- Determine fit based on skills and level of interest.
- Check availability.
- Book them on the project and announce it in our #schedule Slack channel.
This process works well, but it didn’t ensure that the person doing the scheduling had enough information about the preferences and goals of the designers and developers when staffing them on a project.
We list our skills, track our interests, and rate specific projects using an internal tool called Hub. The person doing scheduling would turn to this tool to determine fit, check availability, etc.
Hub isn’t always perfectly up-to-date and it doesn’t track each person’s individual goals. We could have directly addressed those problems by adding features to Hub and making an announcement that people need to update their preferences when they change. You can imagine the level of effort that would have required with a company of ~90 people. Instead, we opted to run an experiment to see if we could solve for those problems with less time dedication.
Designing the experiment
Hypothesis
A brief weekly stand-up for the sales team and directors of each office will allow us to share the necessary information among the sales/scheduling team to help make sure we all have complete information when staffing projects.
Experiment Design
Have a stand-up after our typical office-wide Friday stand-up to cover:
- Any new or restated scheduling preferences of our teammates
- New projects that need to be staffed
- Teammates that are due for a rotation
Learnings
We started this experiment in our Boston office, and extended it to our NYC and SF offices shortly after. The scheduling meeting was held on Friday, right after our office-wide stand-up. The meeting lasted 15 minutes and gave us a dedicated time to handle scheduling with better context.
Having the directors in the room with the sales people meant we were getting more up-to-date information about goals, preferences, desired rotations, etc. We discussed who would be happiest doing what with far more efficiency, and were able to quickly create action items to staff projects.
After one occurrence, the office manager joined. Her participation identified potential conflicts with desk space and gave us a head-start to prepare for incoming clients.
After the second occurrence, other team members who had availability coming up joined in. This was exciting because people were empowered to participate in their future scheduling and the in person format meant we work through the scheduling process faster and more thoughtfully.
Some other learnings:
We don’t actually staff during the meeting. Instead we create action items and assign them to the people in the meeting. At first, we tried to staff during the meeting. It felt wasteful to have multiple people watch one person make assignments during the meeting.
Other thoughtbotters who have availability coming up were interested in joining the discussion about staffing and could provide even more context.
The short 15 minute format meant it didn’t require a lot of time dedication. By doing this weekly, 15 minutes was ample.
This meeting helps us get on the same page about current utilization, and what future utilization looks like.
Summary
We will continue to run the weekly scheduling meetings. It has been an improvement on our scheduling process, requires minimal time and effort, and results in better outcomes with less back-and-forth.
From our current scheduling process we identified a problem. At thoughtbot we often build software to solve problems. But sometimes, software isn’t the answer. In this case we leveraged the tools we had, and altered our process to improve our results.
