Last week news broke that Adobe was buying Marketo in a deal that’s going to reverberate through the martech world for a while. For a while, I’ve been thinking about writing this piece about the place of design in companies, and this news presented an interesting case study. How do these giants treat their design departments? I went straight to the careers page — an imperfect tool for discovery, but one that gives us a good sense for the organizational structure of roles within companies.
Adobe is, of course, not only a marketing technology company. It’s also responsible for the tools that many designers, myself included, have spent countless hours working with. It’s not surprising then, that if you look at the Adobe careers page, you’ll see “design” as a standalone department. Marketo, meanwhile, is a classic marketing tool, and if you look at their careers page, design roles live either within “products & engineering” or “marketing.” The implication? For Marketo, design isn’t treated as an autonomous entity.
A Seat at the Table
Today, more than ever, users expect B2B software to be as well designed as their consumer software. In such an environment, design is prioritized by organizations and given a seat at the table beside their product and engineering partners. Giving equal weight to all three is where the magic happens.
This weight can manifest in different ways, with these three models being the most common I’ve seen:
-
- Centralized: where design has its own business unit with executive-level seat.
- Decentralized: where designers are part of “feature teams” or “tribes,” falling under engineering, product, or marketing (or sometimes all three).
- Centralized Partnership: this approach, articulated in Org Design for Design Orgs, is kind of hybrid. It has designers huddled together with a design lead, while also partaking in teams that are “skill-complete” and focus on specific aspects of the business.
This isn’t a question of right or wrong. A lot of these structural decisions depend heavily on the maturity of organization and product as well as the CEO’s outlook and executive support.
But there is a range of positives and negatives to organizing these ways.
The strength of a centralized org is the design team’s ability to focus on the holistic end-to-end customer experience. This tends to build a strong internal design culture, giving designers the ability to work on a range of projects. The downside is this can create silos and designers can get a bit far from the business.
Meanwhile, in a decentralized org, the greatest upside is that designers can be involved early and often, which fosters cross-functional team cohesion. On the flip side, designers can feel isolated in their role as the only design resource supporting a feature team. They might often feel that they’re the only ones championing for the customer or for design consistency amongst the rest of the application.
A centralized partnership is about blending the two, and therefore hopefully getting the best of both worlds. In my experience, this has fostered the most innovative work and happiest teams.
Connecting the Dots
Regardless of the overarching approach — to centralize or decentralize — designers must work together to create a holistic experience for your end-users. Your users consume the entire product experience, not just a piece of the product, so it should feel consistent. Particularly if design is decentralized, it’s important to make sure that features are not being built in isolation.
I manage a team of four designers, and we are part of the product team (which also includes PMs and a data scientist) that sits in a dedicated product pod. Each designer is responsible for a different mission. In the next pod over are the engineers. Recently, the question has come up: “why doesn’t design physically sit with engineering, since they’re part of this feature team?”
To me, at this stage of our team and the product experience, it’s really important that designers sit together to make sure we’re sharing our work and aware of what we’re working on. Since we don’t have a solid design system/library yet — and we move incredibly fast — we’re constantly sharing new components or user flows we’re creating. We collaborate a lot via Slack and Invision Freehand, Zooming in our teammate in Israel for regular design review meetings. We are trying to implement a centralized partnership model, and striking the right balance does require some trial and error.
The Third Way
I have personally experienced all of these organizational structures throughout my career—in brand and product roles—and I feel that it really comes down to individual companies and teams. Both styles have their pros and cons. But I think that the third way, which borrows elements from both, is actually the most effective. I really enjoy working alongside product managers and engineering partners, helping to collectively shape and influence product decisions. At the end of the day, we all want to create intuitive, delightful experiences that customers love. And regardless of where designers sit, they can really act as the connective tissue that brings products together.
