Productive, empowered designers are essential to building a great product. But there’s an art to integrating designers into your team. Done wrong, designers can get siloed away from the rest of the team, affecting design quality, flow, and overall team cohesion as a result. In this video, I’ll walk you through a common scenario product teams face when hiring designers.
Read as an article
Welcome to our small team of skilled software developers.
They’ve got a great startup idea, but they have a problem. They really need to hire a designer, so they do. They hire Felix.
Felix sits with the team and pairs daily with the developers, and their product begins to get traction. The team hires two more developers.
At this point, the team is pulling work from one list. Felix adds his magnets to the work items that involve design, most do. The teams adds more developers.
Felix has his hands full, but he’s able to manage. If he has a sense of what is in the to-do list, he’s able to juggle how he spends his time and energy.
At a certain point, it becomes hard to operate as a team of eight developers, so the team splits into two teams of four.
The changes for Felix are subtle. A couple examples, he now has to go to two stand ups, and the other shared meetings.
He also has to scan two boards for their respective to-do lists. Felix’s context switching and administrative overhead increase.
Whereas before Felix could confidently start together with his fellow team members, now he is tempted as his schedule gets more hectic to get upstream, and grapple with, and finish design work before handing off the work to developers. This is not ideal, but he had to, otherwise he can’t confidently manage his time.
Are you designer? We’re hiring!
__Check out our current openings: __
What starts to happen, in fact, is Felix begins to run his own list. Items in his list link to items in their list.
He still sees himself as a team member, but he’s becoming slightly less connected.
We start to another problem. Felix is left wondering about the relative priority of the items in his list because he doesn’t have a way to do an apples to apples comparison of potential value.
Felix’s time is precious, so it becomes increasingly important to estimate and converge on work, so Felix can try to pack it all into his schedule. Felix gets forced into Tetris playing, which means that Felix has even less flexibility to be available for ad hoc requests and opportunities to collaborate.
At the same time, the team is packing its schedule. Combined, this even further discourages collaboration and iteration.
Whereas before they were shipping frequently, iterating, and focusing on outcomes, now they’re delivering projects in a single bath, and then moving on immediately.
What you start seeing is a very gradual slide. We see Felix going increasingly upstream and converging on solutions in a vacuum. We see more handoffs and playing Tetris with schedules. Given the Tetris, people pack more work into batches. Might as well, right? Batch size goes up, and experimentation and iteration go down.
All of this results in decreased design quality, less impact, lower team cohesion, and reduced flow and cadence.
Now you’d think that this would all be obvious, and the start up would simply hire more designers to embed on teams. Not so fast. When these symptoms kick in, the common response is to try to hire more developers instead of designers.
One reason is that Felix has probably raised the red flag a couple times, but he’s also pragmatic, and he’s adapted. It doesn’t feel too broken. As team size increases, productivity starts to level off, efficiency rises at first, and then starts to drop overall.
As team size increases, productivity starts to level off, efficiency rises at first, and then starts to drop overall.
Everyone’s ability to make sense of the system drops. That last part is critical. It becomes increasingly harder to understand what is going on.
When Felix finally hires some other designers, he finds it doesn’t really help as much as everyone expected.
Why? The whole organization is optimized for how things currently work. Felix’s situation probably isn’t unique either. The same thing often happens to other contributors like ops testing, data science and project management.
In each case, it is very easy to misread the situation and try to fix symptoms. What can we do here? Is this just inevitable? Let’s recap.
Felix started as a true team member. Then he started splitting his time between two teams, but managed to embed to the best of his ability.
Then as demands and team size increased, he started to run his own list, fielding requests from other teams. Finally, Felix installed himself permanently upstream.
The first thing you can do is to visualize the whole system.
Whenever people are shared between teams it creates one big team whether you like it or not.
I think about it this way: Whenever people are shared between teams it creates one big team whether you like it or not. We can quickly see that Felix is super busy.
Notice how this hybrid board covers missions and what teams are doing to try to realize those missions. Visualizing work this way helps you see what is actually happening. We see the space between the work. What we think is limiting us may not be limiting us.
Another thing we can do is to review our product decisions. Did the work work?
Say only 20% of efforts actually generate results, efficiency output probably isn’t your problem. Adding developers won’t help. Prettier pixels will probably not help. You need to make better product decisions.
You need to make better product decisions.
Designers empowered to do research and discovery along with enough designers to embed on teams will help with that. We actually want better outcomes with less complexity. We want to learn faster. We don’t want to add more complexity.
One temptation is to try to stabilize the situation by getting upstream as Felix did. This does actually ensure that design is not left out of the loop. It gives design control. If teams are in pure delivery mode, it does ensure some oversight, but this is a bandaid. It doesn’t get at the real issue. Then the team optimizes around the bandaid.
Instead, figure out how to scope work into meaningful missions. Start together. Do a kick off together. Do discovery together and work together. Measure outcomes. Even if you can do this on just one effort, it’s worth it.
Figure out how to scope work into meaningful missions.
In summary, remember that the drift into failure is often slow and hard to perceive. You need to actively resist. Often, you’ll need to do what doesn’t make sense, slow things down, embrace messiness. Visualize the work across the whole team. Inspect and adapt. There’s no one right way.
You may even need to run multiple concurrent operating models. Whenever possible, start together and work together, and come on now, hire more designers.
Download the deck on slideshare
from
Are you designer? We’re hiring!
__Check out our current openings: __