Musings on Six Months as Head of Design Operations @Automattic – Part One
Coming into my role as Head of Design Ops from a prior career in design consulting building out similar types of practice areas (think Program Management / Project Management / Production) I had some pretty definitive notions that I could basically apply everything I had learned as a client partner to the work I would be doing on the inside. As a consultant I remember constantly thinking “Why is this so hard? What am I not doing to help them understand? Why does our work never see the light of day?” I always chalked it up to the fact that even though a client had hired a big guns design consultancy, they weren’t actually ready for what we recommended they needed to do to make it happen.
It wasn’t until a few years ago that I realized it’s so easy to come in and tell someone what’s wrong and what they should do to fix it, but the real work starts when the people with the blueprints actually have to make it happen. This is when I began to understand the emotional complexities behind the work that is change management and what it really means to shift not just ways of working, but organizational behavior. That making change in an organization requires more than a single vision, or a few workshops, it takes careful orchestration throughout the organization to become a part of the working fabric of day-to-day operations.
In my first few months at Automattic I did a listening tour to start to understand our designers and our design organization. At the same time I began to build relationships across the company with a handful of the engineers. My idealistic mind thought – if I could just bring them all together, that’s when the magic will happen. And then… as I began to uncover a bit of resistance I was forced to reckon with the fact that design and development didn’t necessarily collaborate based on a the cultural legacy of Automattic being an engineering driven organization. This is not uncommon, but for me, the sheltered NYC design studio ideologue, I had hit my first blocker. During all my years at frog and the like I had only seen through my own orchestration the beautiful music that a cross functional team could make together. Not without hiccups mind you, but always with a shared understanding that we could get through it together. This comfort in ambiguity was the fabric of what made up all of our project work and created a sense of responsibility for each subject matter expert on the team to really bring it.
During this time I was fortunate enough to meet Joan Shigekawa who wisely suggested said to me that perhaps I should spend some time researching and reading about the science of an engineering mind, to try to understand better. I have never been so interested in Behavioral Neuroscience. As I started to read the book Behave by Robert Morris Sapolsky much of what I read validated how I have been trained to respond as a Design Thinker which is to never assume there is one right way, that we as humans must always think in an interdisciplinary way in order to most effectively relate to and understand other humans.
Now six months in I can reflect on my “Discovery” phase of the work done to date and see that some of it still holds true, and some of it doesn’t. I have begun to understand a bit better the people that make up Automattic as a whole and what it will take to earn their trust. I have made a few significant missteps along the way but not without invaluable lessons learned which I believe will allow me to better align my vision with an execution strategy that while not perfect (Design Ops as MVP!), will be better suited, custom-made, and allow for a true model of growth and sustainability for Automattic Design.
Automattic Design 