Task Assignment Queue
How might we build software for operational superpowers?
During my first year at Minerva, my team built workflows to support the many operational demands faced by staff as we raced to admit our first class of students.
As a company, we wanted our cost per student to drop by at least 10x each year. One way to do this was to keep a low headcount, even as we increased the number of applications, admitted, and enrolled students by 3-5x each year.
My team's challenge was to build better software so our senior staff didn't have to hire more and more support staff as we scaled. The idea was to solve entire staff roles instead of removing a few problematic pain points from their workflows. How might we build software that grants operational superpowers?
Minerva Schools, 2018
Why solve this problem?
Our software supported ineffecient workflows. Staff were busy, but not effective.
As part of the admissions process, our Application Processors (APs) help evaluate and verify incoming application data. Admins were the managers who assigned the tasks. Admissions processors (APs) were the on-demand workers who did the work.
To admit our first class of students we had 40 APs helping to process incoming data from more than 20,000 applicants, along with 3 admins. There were several dozen tasks required to processes each application. By assigninging items to APs one-by-one, admins had complete control and flexibility but the work was time consuming and required much more management time than expected. The following year we would have up to 3x as many apps and many more APs.
Scope: 6 weeks to build a new responsive single page web app.
Role: I led product design and project management as an individual contributor.
Team: I worked as designer and PM with 3 developers.
Type: Task flows, story mapping, prototyping, wireframes, mockups, project management.
Tools: Sketch, HTML prototyping, front end frameworks, InVision, Zeplin.
Discovery
To automate and improve complicated and time consuming manual workflows.
Rather than design software for faster workflows, we wanted to try to eliminate much of the work itself. Ideally, staff would drive effective processes and make higher order decisions with the software doing the heavy lifting. Staff would be able to focus on what matters most and be more effective and less busy.
To do this we set out to build two entirely different tools. The assignment queue tool would replace a high touch processes by automating the intake, prioritization & assignment of admissions related evaluation tasks by a manager. A second tool, would provide the admissions processors with targets, goals, and time tracking tools so they could better self-manage without 1:1 support from managers.
If it worked, we could extend this model to similar workflows in other departments. After that, we could continue to partner with staff to automate their high-touch workflows so that they could move on to solving the next problem. Solving new problems with software and not headcount.
As a team, we understood how important this idea of scaling with better software and not by incresing headcount was for the company. We were ready to make a difference, but weren't sure where to start and how to pull it off.
Early mocks for the AP dashboard view of assigned tasks.
Planning
At Minerva, I typically work a cycle ahead of engineering to better scope problems and prepare artifacts to help the team determine and align on the right problem. In this case, the idea of the auto-assignment queue came from an engineer who had been on the project before. The PM for internal tools, was busy with a few other things and asked me to fill in and kick things off.
I scheduled 3 whiteboarding sessions with some of the engineers so we could get deep into the details of how the system would work behind the scenes. As a group we aligned on the idea that a stack of rules that would sort the tasks on the back-end, match them with APs based on training and performance feedback. The workflow would switch from a push model— to an on-demand queue whereby the system would filter appropriate tasks (instead of the manager) and APs would be able to pull tasks as needed.
I set up a planning board so that collaboraters on the dev team could submit wireframes and help with discovery.
Who is this for?
The two primary stakeholders here were admins and APs. Admins were the managers who assigned the tasks. Admissions processors (APs) were the on-demand workers who did the work. I set up meetings with admins and APs and quickly prototyped out some of our ideas in high fidelity. These interview surfaced a number of issues and concerns and I worked with stakeholders to create storymaps to share with the team. A few important themes emerged:
Transparency— Processing applications during peak demand at deadlines was mission critical, time-sensitive, work that took in a tight window and little margin of error. If things fell apart, we wouldn't make deadlines and prospective students would likely choose other schools. Admins wanted to understand which rules were being used by the system at a given time and validate that they were correct.
Access— Admins wanted the flexibility to use manual overrides to flag certain tasks as important and to cover for common edge cases and emerging needs.
Control— APs were on-demand workers and might be working in a number of different contexts from a home office to a cafe. Some tasks were easier to pick up and put back down. Other tasks required audio & headphones. The plan was for the system to assign the tasks to individual APs based on a number of complicate rules, but the on-demand workers would needed to have input into the type of task as well or the system would fall apart.
Story mapping the manager workflow of assigning tasks.
Story mapping the on-demand workflow completing assign tasks.
Implementation
After identifying some key problems we wanted to solve with the front end. I began to prototype new concepts to help the team and stakeholders envision these improvements.
The admins were worried about how the software might fail. Their one job was to make sure everything got processed on time and they weren't inclined to turn things over to the software without extensive access to visibility and overrides.
To better align on the problems we were trying to solve, I iterated on the prototype quickly to capture new ideas I came up with the stakeholders and shared these artifacts with the product team.
Because it seemed user acceptance might be an issue, I decided to focus on the admin tools at the expense of the AP dashboard for self management. The critical task was to get the job assigned correctly. If the queue helped get all the tasks processed in time, than performance times of individual APs wouldn't be an issue and it was something we could look at later.
Prototype walkthrough for dev team and stakeholders (7 mins).
Outcome
After deploying the auto-assignment queue, we worked heads-down on the AP dashboard for the next few weeks and begin to test and roll this out with new groups of APs.
The good
The good news was that the system was a huge success. We increased the scale of operations by 3x without hiring any more admin staff. In fact, we designed a solution that completely took care of that job. We solved a big problem related to scaling which was a key business goal. The whole company took notice. This work became a succesful model that the company used to apply to many other problems.
The bad
In the end, the transparency and override tools we spent so much time working on were completely unnecessary. With the underlying solution— an automated rule-based assignment queue— tasks were completed by APs so quickly that prioritization was never a concern. In fact, the rules involved n automating the system were not needed either. With the new system, workers were completing the tasks so quickly that prioritization wasn't even needed.
We could have just built a system that was much less complex and simply assigned tasks based on simple rules about who requested them and whether or not they were trained for that task.
The ugly
Even though the company got a good outcome, I considered this project to be a failure. A full 80% of my time and more than 50% of the time of two engineers of two six week build cycles went towards building something that would not be used.
What I learned
I learned a few things from this. First, it's important to really listen to people who know most about a problem space. I did fight for the engineers idea, but added many solutions of my own. None of these were necessary. We could have just shipped his idea. Second, it's not always a good idea to solve all the problems you care about at once. Solving one problem might making solving others unecessary. Ideally a team solves the highest leverage problems that will help them learn more about the problem space.
Walkthrough of prototype for the AP performance dashboard (7 mins). After we shipped the admin tool, we still had two weeks left in the cycle to implement this dasboard.
More Case Studies
