Managing designers comes down to managing time scales. Almost all conflict or problems on design teams comes down to what time scale the team is operating on.

Take all the work a team is doing and map it against these time scales.

1-2 weeks

The first unit of time is 1-2 weeks. This is a typical sprint or time scale that many teams use to decompose immediate work. If you ask designers what they are working on for the next 1-2 weeks they should be able to tell you with high accuracy. If they can’t then that is a warning sign that something is wrong. 

Work being done in the 1-2 week time scale means that it will most likely get shipped inside that time unit. Work done on day 1 will most likely find its way into a build by day 14.  

2-4 weeks

The next unit is another 2 week increment. It is one sprint ahead of the first unit. Work being done here won’t get shipped for about 2-4 weeks from the time it is being worked on. 

1-6 months

The third unit is much longer but the 6 month time scale lines up with half a calendar or fiscal year.. Many companies do bi-annual planning and this scale fits inside that. While you can break this into smaller units (e.g. quarterly) you need some time scale for work that just takes more effort.

Work being done on this time scale is more ambiguous, it needs more discovery and refinement before being ready for the nearer term time scale work (1-2, 2-4). User research often needs months to prepare, execute and analyze. It can't be done inside a single sprint. There are times where Design needs to move through multiple iteration cycles before being ready for engineering and shipping.

Managers operate in this time scale (although ICs will also do work here). For example, recruiting and hiring manager need to think and act a few months ahead. They can’t hire on a 1-2 week time scale. Managers need to be thinking more about what is happening over a larger time scale to enable teams to operate closer to the backlog. 

6-12 months

This is thinking on a time scale outside a half but inside the next half. Some work doesn’t cleanly fit into the half.

One of the most helpful framings for thinking on this time scale is from Chris Cox. He would ask teams “What will people be able to do in 12 months that they can’t do today?”. This forces you to think out on this time scale. 

1-2 years

Thinking out 1-2 years and doing work on this time scale is typically the responsibility of org leadership.

Where do we need to be in 1-2 years and what are we doing today to help us move towards that? What do we need to be successful a year to two years from now? What do we need to implement today to make that happen? What org practices, processes or skills development do we need to be successful? What products or features do we need to start building now to win in the future?

Thinking in 1-2 year arcs isn’t solely reserved for leadership but teams should be judicious of how much time they spend in the 1-2 year time scale.

2-5 years

This is the time scale of long range planning and more speculative work like Research (scientific). Infra efforts, like building data centers, may fall into this time scale. Most product teams should nor be operating on this time scale in any meaningful way.

5+ years

Where does the company need to be in 5+ years to be successful? This is the domain of CEOs/founders and the board of directors.

How to apply this framework

Whenever looking at a team’s work try to place it somewhere on this time scale. Is their focus in the right time scale for the most impactful work they need to do? 

Teams get in trouble when they aren’t working in the right time scale.

Problem #1 - Working behind the backlog

When designers are unhappy it is often because they are working behind the backlog. On any given day, engineering provides a built feature and asks them to design it so it can ship. This is when design is treated as a service. 

If you determine a team is working behind the backlog, you want to debug why. There are only two reasons why this is happening.

1. Lack or resources - team is understaffed and so there is more work than designers

2. Lack of process - team has no agreed workflow of how and when designers should be involved.

Depending on which of these two (sometimes it is both) you can take action accordingly. 

Problem #2 - Working too far out on the time scale

Designers will often want to do work that projects further out on the time scale. Whenever a team starts using the words “North Star”,“ Vision”, “Design Sprint” it is essential to understand what time scale this work will sit in. Is the team trying to imagine the future one year from now or five years from now? In my experience, when pressed, teams are typically thinking in the 2-3 year time scale. This can leave them susceptible to Three Miracle Problems.

Encourage teams to stick to a 12-18 month time scale. This is long enough to not be constrained by short term thinking but not so far out on the time scale that it turns to design fiction. 

Design teams who project out to the 2-5 year scale often have difficulty getting others to find their work valuable. This leads to North Stars that are wholesale ignored by teams, not because the ideas are bad but because they can’t connect it to a more near term time scale.

Problem #3 - Jumping between time scales

It is takes a lot of cognitive energy to move between time scales. If you are spending all your time working in the 1-2 week time scale and then are suddenly asked to do work on 1-2 year time scale, it is difficult to switch your brain to this mode. 

Yo-yoing between time scales is exhausting. When you bring conceptual longer time scale work to someone who is focused on the 1-2 week time scale, you need to let them mentally adjust. Someone who is near term focused will be more likely to reject further afield concepts because they can’t see how to get it done in their time scale. You either need to get them into your time scale OR present the work inside the context of their time scale.

Healthy Design Teams

Try to keep teams in the green

A Designer that spends too much time out on the time scale is unbounded and drifts. A Designer working too close on the time scale is myopic and burns out trying to run in service of the backlog. 

A manager’s job is to know when to push a team out on the time scale and when to reign them back in. This means deftly riding the accelerator and the brake, knowing when to employ each.

I prefer software teams to operate in the 2-4 week time scale. Once or AT MOST twice a year these teams should pause and do concentrated work on the 12-18 month time scale.

2-4 weeks allows for Design to be out ahead of Eng but not so far out they can’t react to new information or insight. It is enough time to do some research or exploration but bounded so that it doesn’t become too abstracted from reality.

This team will drift out to 1-6 months at times or for specific activities that require a longer time horizon but if the whole team is only working on things that will make there way into the product in 6 months it can mean a disconnect between Design and other disciplines who may be working closer to the backlog.

Once or twice a year, the team should stop and think further afield. This should be concentrated time where the team stops thinking on the short term and projects out.  When teams only design on 2-4 week time scale, they are at risk of going astray. This is like walking while looking at your feet. You will move forward but you may not be heading in the right direction. All teams need to look up at some point and plot a point on the horizon. 

Now this doesn’t mean that at moments, design won’t drift into the 1-2 week time scale or even behind the backlog (e.g. SEV) for periods of time, this is ok. Managers should be aware when their team moves into this zone and have a plan to get them out. Teams staying in this time scale are at risk.

At select points, it might be necessary for a team to drift further a field from 2-4 weeks and do work that is in the 1-6 month or 6-12 month time scale. This has the inverse risk of staying too close to the backlog. Teams that sit too far a field can alienate other disciplines by doing work that is too disconnected from shipping or lacks implementation details. 

Time scales is the best tool I’ve found for quickly assessing how a design team is operating and debugging problems. It also creates a shared framework for talking about work. Being able to place ideas and designs on a time scale makes it much easier to create alignment and agree on how we will build and ship products.