How does design strategy work within a large enterprise?
Last October, I visited my alma mater, the School of Visual Arts Masters in Branding program, which teaches graduate students about the intersections of business & design. Whenever I visit, there’s always students that have questions about what I do, both as an IBM’er and a Design Strategist. Most recently, I was asked by a student “How does design strategy work within a large enterprise like IBM”?
In order to answer that question, you need to consider the context. IBM isn’t just one organization or company, it’s a company within a company within a company, ad nauseum.
With a structure similar to this, it means that one operational strategy cannot apply to all situations. In order to practice design strategy, one must consider the structure & direction of the organization, be open to a wide range of tactics to consider, embrace the role of self-education & advocacy, and to tolerate whatever situations may arise.
Who are your stakeholders?
Abstractly, the image above outlines my stakeholder map. As you can see, some of the roles and teams are closer to mine than others, and they all can influence each other (you’d be surprised that some of these teams don’t know this), and they might not even know who I am. When it comes to the development of a product or an offering, it’s important to consider this hierarchy, which can determine roadblocks, innovations, pivots, and most importantly, collaboration opportunities.
I’ve discovered that offering teams often don’t have the agency to pull their heads out of the weeds of their offerings and see the holistic view around them. Luckily, that’s why you exist, right, Design Strategist?
To be tactically proficient means that as a strategist, you need to embrace multiple tactics & constantly be learning. For example, you might be working with an unproven or new machine learning technology, which means that your assumptions about the overall user experience are reliant on the engineers & researchers who are working alongside you, and you might not get what you want in the end. To solve that, constant communication & alignment about what you want to do and what you can do is vital.
This is where education is vital. If you work in AI and are unsure about how Machine Learning works, at least from a conceptual level, it impacts your team. As a designer, it is assumed that we do not understand the technology…it is impressive to demonstrate that you do understand the role of annotation and the time it takes.
Read books, blogs, Medium posts, watch lectures. For example, in the few last weeks, I’ve been reading through Superintelligence, taking deep dives into the IBM Cognitive Model, and reading about the many ways that Healthcare could be modified by AI. Note that none of this involves “design”.
All of this educates me further on not just the subjects of machine learning and artificial intelligence, but the experience of enabling those technologies on an offering level & a design level.
As another example, over the last two years I’ve also learned about how Laws are written, how contracts are structured, the processes that guide both, and the environments they’re created in, all for eventually producing a machine-learning enabled service that can serve in those walks in of life.
This domain knowledge increases my worth, and will most likely be helpful in future projects.
Designer + Educator
Despite the image on the left, I’m not necessarily saying “be a design facilitator”. The phrase “Design Facilitator” has become very popular, in part because of IBM + AIGA, and it’s a bit of an umbrella term, hence why I chose to focus on the phrase “Designer+Educator”.
Over the last two years, I have facilitated dozens of Design Thinking workshops, but I’ve also educated my stakeholders on traditional UX design processes, the value of Design Research & what happens without it, Lean & Agile philosophies, and the value of cross communication & collaboration.
These experiences have given me much empathy for Educators, because it is tiring, yet rewarding the second you don’t have to remind a Product Manager about the correct Personae, or when they advocate for writing Epics.
Despite everything I’ve written above, there are still moments where the system breaks. An executive comes in and performs a “swoop and poop”, or a client with excessive power makes demands that reshapes the product, or an unstable business plan changes our delivery model. Over the last few years, I’ve worked with some great people that can work around these kinds of situations, but more often than not, I’ve worked with those who decide to complain rather than improve, which creates toxicity in the team, the product, and the individual. It’s like Error-Tolerant design but at a behavioral level.
Another way to mitigate this is through the frequent usage of Retrospectives. It gives your team an opportunity to reflect on the work done, in an environment that is open & fair, along with suggestions to improve. Besides, if we’re operating in an Agile fashion, the work is never truly done, and can always be improved.
I realize that I’ve provided surface level insight here. In the next few weeks, I’ll dive into each of these topics with first hand stories, including my successes and failures.