S02E05 — MAY2020

Design Team X

Hello world and welcome to the seventeenth edition of this rather oneiric newsletter. 

Don’t know about you but I’m still a bit post-quarantine-fatigued. It’s getting better and I’m getting out of it, but noise pollution is bothering me the most. Just when I got used to the lock-down silence, my super-noizy-next-door neighbors Tamara and Marija are back for college, renovation of the apartment below continues and works on the construction site across the street are again in full swing. It’s as if someone pressed “play” on everything all at once. Damn.

Ok, let’s do this.

✦

There’s no successful design team without the alignment with the rest of the company. This alignment often means the permanent and unpleasant state of change. Design teams should be shapeshifters — always ready to adapt to the ongoing organizational situation in order to extract the most value out of it.

Shapeshifting means moving between: 

• Vertical — common for engineering teams. They have strict boundaries around their part of the tech stack and full ownership over the domain they are solving.
• “T” (both vertical and horizontal) — common for devops/infra teams for example. They are building their own stuff while supporting the rest of the engineering.
• Horizontal — common for customer support teams. They are not building tech per se, but instead working with all the teams on resolving customer issues.

Shapeshifting is challenging in and of itself. In our case, it was additionally torn between two deceiving currents: 1/ the surrounding engineering culture and 2/ a dystopian design propaganda. The former you see each day, the latter you only dream about. Let me give a bit more context.

In the first current, we have the fact that being in the engineer's nest you need to act like one of the hatchlings. And this is totally fine when everything is fine. Some differences in how the team operates should exist and when you are about to make those changes things get less fine. Sunken in the well-established engineering culture, your peers and team members won’t always have an understanding of what are you doing or why are you not doing it the same way as the other teams.

In the second current, we have the fact that we live in a different realm than design teams from Silicon Valley’s tech unicorns. Their Medium publications usually speak about success stories and success stories only. A classic example of American corpo marketing. Designers around the world romanticize and take for granted these stories without thinking about their own context. 

It's exactly the gaps between those expectations and our version of reality I found myself in a couple of years ago when we were shapeshifting. We started as vertical and ended up as a totally horizontally-organized team by its mission and the type of work we were doing.

Multitasking VS Monotasking
“Why don’t we set aside 6 months for 2-3 of us to do this right?”, “Do you know it’s scientifically proven that multitasking is not possible and it’s only harming productivity?” 

The belief that a person should work on one thing only at the time is super strong. Every interruption is seen as chaos. My attitude that juggling between 2-3 projects of different nature and expected deliverables should be a standard for our team, was seen as blasphemy.

The situation was similar to what is known as “the magical weekend”. You spend the whole working week without finishing what you’ve started, with the idea you’ll use the weekend to make the deadline. Yeah right, it almost never happens.

Then we tried to box out as much of uninterrupted time on projects as we could. A new issue emerged — some folks would overinvest and overengineer, which resulted in delivering late. They had more than enough time to spend with the problem and naturally would get overwhelmed by it.

After about 2 years of trial and error, we eventually learned how to scope projects and multitask without side anxieties. 

Stack VS Value
“Look at what this team at BigTechCo did?”, “Look how good this design system is, why don’t we invest more in ours?”, “We should rewrite ThingA and automate ThingB.”

There was this period when the team was bigger but not big enough, and when we overestimated ourselves a little bit. We overinvested in “stack” because every other engineering team had one. Even though their stack played an active role in the product we were building, ours yet, not so much. The return on investment was smaller than we had expected. But we were so proud, standing shoulder to shoulder with our engineering counterparts. It felt good because we had something tangible.

Engineering teams are building services and infrastructure, design teams are making that tech understandable to users. This value is often hard to measure or unconvincing. Ultimately it was my responsibility and mistake for granting wishes and not steering the boat to what was important at the time.

Once we woke up from this delirium, it was hard for us to accept this mindshift. We got back on mindfully balancing between solving problems for our customers and nitpicking things in “our vertical”. 

Pipeline VS Islands
“There are clear responsibilities in every team, why don’t we have the same? For example, one person can be responsible just for UI, another just for CSS, and yet another just for user interviews, and we could operate as a real team for once.”

Traditionally the whole team was sitting together. Even then I was against this strict division of work but rather pairing up folks with different skillsets or doing some rotations. Nonetheless, I started getting feedback on the notion of “islands”. “We sit together but we don’t work together. We don’t supplement/complement each other's work.”

When we were mature enough and started horizontalization and integration of designers into other teams, this gap was visible on a more physical level. The ones who went to sit with other teams felt lonely because they were new there, and the ones who left their native teams felt lonely because they were missing their buddies.

After some time working in this mode, we realized two things:

• By sitting within new teams, designers had a bigger influence on decision-making because they were constantly brainstorming about various ideas.
• Distributed designers were learning more about specific domains they were in charge of and they were sources of knowledge for the whole design team. While “isolated” whey always knew what the rest of the team was up to.
• Those teams started to be more inclusive towards the rest of the designers. Communication was noticeably better.
• There was a bigger appreciation for design pair-ups when they happen.

Probably none of these juxtapositions are unique, but they were very unique to me. I'm sure that all of them were solved before in a much-sophisticated manner, but looking back now I'm satisfied with how we as a team managed to overcome them. Sometimes you win, sometimes you lose. And that’s OK. Onward.