Doreen described a collision between frog’s creative culture and Aricent’s Information Technology culture. This IT culture is typical of big system integrators, like Tata, Infosys, Cognizant, Wipro (who acquired Cooper), and Capgemini (who acquired Idean). These companies work on massive back-end system integration efforts, or installations of solutions like SAP or Oracle, or rollouts of Salesforce, and so-on. In these integration efforts, a focus isn’t on creativity and innovation; it’s on predictability, efficiency, and cost minimization.
Innovation is about making things the world hasn’t seen before, and while those things can be exciting, they also carry a tremendous amount of risk. People who are comfortable with taking innovation risks are typically comfortable with ill-defined problems, organic processes, change, failure, and incremental improvement.
Integration is about doing things that are proven to work: following a tested, repeatable and rock-solid process. People who are comfortable with this type of rigid structure are usually equally at-ease when they have a well-defined problem, clear constraints and expectations, and most importantly, a clear view of a goal and a set of objective criteria upon which to judge success.
When a company full of risk-takers and dreamers crashes into a company full of operators and experts in efficiency, the cultural implications can be enormous. Similar words have very different meanings; “following a process” carries dramatically different implications to someone drawing storyboards as it does to someone responsible for a five-nines availability service-level agreement. And while these boundaries aren’t rigid and people can change and adapt, there is inertia in both cultures towards doing what they’ve always done, because it worked. frog was acquired because they were good at being designerly. Aricent was in a position to acquire them because they were good at being efficient and effective. Expecting either of these organizations to change quickly seems silly and shortsighted.
A cultural collision doesn’t just happen when design meets IT. Phil Barrett and Max Burton both described the way their agencies ran head-first into the world of operational consulting and accounting (as Phil described, “If you actually think about and ask, ‘What’s the matter here?’ The matter is, if you’ve got an organization created by accountants, for accountants, operated by accountants, and you take those systems and try to apply them to design, they don’t work very well. That’s the truth of it”).
And the culture clash is evident even when a creative company encounters another creative company! Christian talked about how LRW had made several acquisitions before T3, and when they began to integrate all of these creative companies, cultural differences crept up quickly. He attributed the difficulty in change to the fact that the founders of the various companies were still employed, still viewed their companies as “theirs,” and still pushed the same approach and way of thinking that they had pre-acquisition. His example of title collision is a simple but clear way in which these issues manifest: if I’m an Executive Creative Director after 20 years in the business, and you’re an Executive Creative Director after three years, we’re bound to have an emotional reaction to the idea of working side by side.
When you start to think about selling your company, planning for a cultural collision is perhaps the most important thing you can do. You won’t know exactly what you’re in for before an “integration effort” begins, but these are some of the differences to expect:
Design problems are, by definition, always unique. As design agencies take on bigger and more complicated client problems, projects become more expensive, have higher internal visibility, and become perceived as riskier. That means that the sale cycle to close these deals becomes more individualized and more relationship driven. During the business development process, the sales team—typically, creative directors or, as described by many of these founders, the founders themselves—spend time to understand the unique needs of the clients and tailor a program to suit those needs and address those concerns.
That’s entirely at odds with the way the design leaders I spoke with described how their parent buyers thought about sales. Phil explained that at Deloitte, his sales efforts became just a small part in a much larger deal; as he described, he would be asked to include design in an existing bid on a program because, “It’ll make us look really good.” He might not even have a chance to explain the value of his small bit of the proposal, because it would eventually be presented by someone else entirely. Matthew echoed that experience with Capgemini, where their sales team would say, “Hey, here’s my spec sheet and I got all this stuff. Which ones do you want to buy?” That’s kind of how they sell their work.
And, as Doreen described above, it’s inevitable that a bigger company moves slower than a smaller company, but agencies are accustomed to responding to potential new business extremely quickly, because innovation budgets are rarely planned and may disappear as the company questions the risk and reward of creativity.
Design is about dreaming. There’s no right or wrong way to dream. And while design eventually becomes super pragmatic and practical, during an implementation phase or during sprint-work, it’s still about creating things that don’t yet exist, and there’s rarely a playbook or a set of rote processes to follow; in fact, if there were, most designers would leave, because they would feel their creativity stifled. Creative directors see patterns over the course of their project experiences, but typically come to terms with the flexible and iterative nature design.
But an IT rollout of Oracle—while always unique—is expected to be much more structured, planned, and contained. I don’t know any IT project lead who would feel comfortable saying, “And then we’ll synthesize requirements for a few weeks and draw; I’m not sure what will come out of it, but it will be pretty great.” And the whole point of an IT install is to get it right the first time, not to hang out in the spin cycle of exploration.
There’s also a fair degree of fuzzy-ness in staffing. The team that’s specified for a project may need to change, and the bodies aren’t interchangeable; while interaction designers may do some visual work, and visual designers may be conducting research or brainstorming strategies, craft really is specialized. Doreen explained that “Aricent couldn’t understand that; it just didn’t make sense to them. They wanted us to just give them the man-hours. But there’s no such thing. You give the client a price and it’s based on a whole bunch of particulars. By the time you get into the project, the particulars have already changed.” Those particulars impact deliverables, and that changes the people and skills that need to be involved in the project.
This cultural class isn’t just true with design and IT. I’ve observed a unique difference in the way operational consultants work and the way designers work, too. Different disciplines have tools that they gravitate to, because they are comfortable with them. Designers feel at-ease with drawing, and with digital tools that help them visualize things. Consultants from the “big five” are comfortable in Powerpoint and Excel, and so a designer may want to explore a problem visually while a consultant may want to explore it through financial modeling. In a perfect world, these skills complement one another. But in large companies with thousands of financial consultants, it’s hard for a visual designer to find a voice or to be heard. Instead of making thoughtful and considered design solutions, they may find themselves, as Doreen explained, “painting pigs.”
Sometimes designers bill hourly, but many design consultancies tie their rates to deliverables. When research has completed, they may invoice for research, and when the exploratory wireframes are completed, they may bill for interaction design. “Completed” is, like everything else in design, fuzzy; there’s rarely an official acceptance or signoff of deliverables. Instead, the creative team and the client feel that a project is done.
That’s just not how it’s done in big strategy consultancies or IT integrators. Accenture and Deloitte are known to bill hourly, and an IT project has a pretty clear set of criteria for completion.
Additionally, costs are highly variable for designers. I don’t know any design shop that bills by the wireframe, and while many shops have a unique bill rate based on the amount of experience a designer has, design agencies often find themselves fitting the cost of the project into the budget of the client.
Since many designers are driven by the experience of creating, I’ve seen agencies discounting their work tremendously, simply to get to do the project at all. I spoke with one design lead at Argo who said, only half jokingly, that he felt like sometimes he would think, “Just let me pay you to work on this, since it’s so cool.” Max echoed that sentiment; he wanted a carved-out budget to bring in client work that wasn’t financially lucrative, but was fun for the team. The competitive and financially-motivated firms like Deloitte work in the other direction; as Phil said, the rate increase post-acquisition was “astronomical.”
There’s also a large difference that you’ll likely experience in the mechanics of billing. This has less to do with the type of acquirer, and is instead based on size. In a small company, when it’s time to invoice, you fire up Quickbooks and send an invoice. It takes 30 seconds, and there’s no approval process, because the person sending it is probably you, the founder. But in a bigger company, you’ll find yourself intertwined in big and often arduous IT systems.
During our first three years of operations, pre-acquisition, we took our team on vacation at the end of the year. We went to Costa Rica one year, Mexico another; it seemed fair that, after working hard, the partners shouldn’t be the only ones to benefit. Additionally, we offered a revenue sharing program. At the end of each quarter, bonuses were based on how much money the company made, and these bonuses were relatively large.
Matthew explained that Idean took a company trip every year—once even taking all 1,000 people to Iceland. Chris Conley explained that they had a similar model at gravitytank; the company would wait until the end of the year to see how the finances looked, and then make decisions on how to share the wealth with the team.
These types of flexible rewards just aren’t a common part of a large company, often for very logical reasons: they are too expensive to execute at scale. But spending is based on prioritization, and even at the scale of close to 1,000, Idean found a way to make it work. Pre-acquisition, it’s entirely a question of what you value as a founder. Post-acquisition, it’s entirely out of your hands.
Celebration is also not always about money. Max described that a small and inexpensive tradition of tea time disappeared, and that type of cultural ritual was something that tied the team together. I wouldn’t think to put “tea time” in writing in a sale agreement, and you probably wouldn’t either. But these are the types of small things that have big cultural impacts, and if too many of them change, you’ll experience the cultural collision that ultimately led Doreen to leave frog.