Mar 5, 2020 6 min read

How We Assign Team Members to Projects as a People-First Agency

It’s called Tetris—and it’s awesome.

  • Build

At Highland, we’re on a mission to create digital products and experiences that actually make people’s lives better.

In my seat as Vice President, I have the pleasure of creating digital products and experiences for the Highland team itself. And gosh, we are demanding bunch.

In a conversation with a colleague the other day, I summed up the challenge with this formula:

Additionally, we value the “consensus” approach to decision making. While we’ve found that it gives you the best results, it also takes the longest. Other approaches to decision-making include “consulting,” where you ask for a lot of input then make the decision. There’s also “dictating” where you just make the decision. We only use dictating as a last-ditch fall back if we’re out of time or stuck on making a decision.

Today, I’m going to talk about designing our project assignment and scheduling system. We lovingly call it “Tetris.” We forked the name from our friends over at Punchkick. They got it from the game where you race against time and gravity to make all the pieces fit together. An apt metaphor for running a creative consultancy, indeed!

The Challenge

At the most basic level, the desired business outcome is to keep all of our practitioners assigned to projects. Anyone on “the bench” is undesirable—that means they aren’t researching, designing, or building cool stuff for our clients.

I think of our time as our inventory, and it is the most perishable inventory possible.

Additionally, the needs of each project are unique. We can’t simply move a whole team of practitioners from project to project, we have to disband and reassemble each time we start something new.

Other pieces of the challenge are lining up demand (sales), balancing travel demands on our team (people with families are less likely to enjoy extended travel), accounting for vacation schedules, and nurturing our network of trusted subcontractors. I won’t touch on these in this post, but they are helpful to keep in mind.

We think a lot about company culture at Highland, where our People First approach applies to our internal team as well as our clients. Learn more about how we—and some other Chicago Best Places to Work—build and sustain a remarkable company culture:

The Jobs To Be Done

There are two core personas to consider for this challenge. The first is the practitioner: a blanket term for designers, researchers, developers. The second is the scheduling team: a blanket term for leads, principals, directors.

Practitioners have a number of jobs to be done:

  • I need to know when my current project is going to end.
  • I need to request additional skills on my current or next project.
  • I need to know what project I am assigned to next.
  • I need to know who else is assigned to the next project.
  • I don’t like being surprised by any of the above points.
  • I like having input on what my next project is (especially if it is aligned to a business or cause I believe in.)
  • I don’t like having extensive conversations about projects that are never going to happen.

Schedulers also have a number of jobs to be done:

  • I need to know who is working on which projects right now.
  • I need to know when those projects are going to end.
  • I need to know what kind of team compositions future projects will demand and when they might be starting.
  • I need to clearly and effectively communicate project assignments to the Highland team.
  • I need to manage ad-hoc requests for currently in-flight projects.
  • I need to identify when we will have a shortage of practitioners and therefore will need to start dipping into our sub-contractor pool with sufficient notice.

When designing products and solutions to meet these jobs, our values of People First and Transparency are especially at the forefront of my mind. Admittedly, even when this process works perfectly, there is a decent amount of anxiety for all parties involved. Are the project start dates going to stay the same? Did we schedule the right team? Did we communicate everything to everyone who needs to know?

I could write a book about all the solutions and processes we’ve developed to address these points, so for now I’m going to share a single solution that addresses a couple of jobs.

The Tetris Request Form!

This form is designed to help practitioners request additional skills on their current or next project and help schedulers manage ad-hoc requests. We built it with Slack’s new Workflows feature.

I would imagine that to the beginner’s eye, this form looks fairly obvious. But before this solution, practitioners and schedulers would invariably have conversations like this:

Practitioner: “It looks like we’re going to need design help next week because so-and-so is sick.”

Scheduler: “When next week?”

Practitioner: “Monday and Tuesday.”

Scheduler: “All day or part of the day?”

Practitioner: “All day.”

Scheduler: “Is it in Chicago?”

Practitioner: “No, it is in New York.”

Scheduler: “What design skills are required…”

We had these conversations over and over. Sometimes, we’d forget to ask a key question and it would lead to anxiety and confusion. The Tetris Request Form standardized all these questions. Once you submit the form, it is posted in our #tetris channel which is open to everyone in the company. From there, schedulers can use Slack’s built-in tools like @-mentioning to and our “people allocation” dashboards to begin learning about each other’s availability.

Here’s one of the people allocation dashboards, another product I developed. It lets you sort and filter by person, project, seat, contract status, etc. Everyone in the company has access and can see what projects they have coming down the pipe.

Unfortunately, the Tetris Request Form can sometimes be in direct tension with the practitioner’s other JTBD around “not being surprised” but also “not having conversations about a project that’s never going to happen.” By building the form, we’ve incentivized behavior that leads to surprises and also maybe spinning people up about projects they won’t be assigned to.

But ultimately — because we value consensual decision making, being people first, and being transparent — I think this is our best solution yet.

In Conclusion

Designing products for product designers is a fun challenge! When they’re adopted and leveraged, it feels great—it is one of the most satisfying parts of my job.

Who do you design products for? Is there some challenge you keep running into that you haven’t been able to crack? Let me know.