A Key Player on a Wicked Team

Thrilled to have been accepted into the workshop (one of a handful of non-PennPraxis or PennIUR students in the room), I entered the experience with significant apprehension. Could I, as a digital design professional (and a project manager to boot), contribute anything of value to the dialogue in this room full of Ivy League graduate students – students who are perpetually immersed in the practice of exploring the use of design as a solution to large scale societal and cultural issues? As it turns out, I could.

“New Wicked Problems Demand New Wicked Teams”

At the core of Mau’s problem solving methodology (24 Hours to Massive Change) lies the principle that the very techniques we use to explore design challenges with clients can be used as a “critical methodology” in the exploration and resolution of any problem, at any scale, and in any discipline. In exactly the same way that I help facilitate client workshops at Happy Cog (in which we use a very similar series of exercises), I was able to encourage and push my workshop group (comprised of urban planning and architect experts) through what often ends up being an exciting, if sometimes uncomfortable, boundary-pushing process. The cumulative expertise at the table is what Mau refers to as “renaissance teams.”

As the consummate generalist, I often wonder about the value of my role vs. the role of an “expert” on my team. In reality though, at the core of the digital project management practice lies the requirement that the project manager be an “expert” in synthesizing a wide range of personalities, levels of expertise, and subject matter, in an ever-changing technology landscape. We know when to ask the right questions and when to pull in the appropriate “experts.” The expert generalist in me love’s Mau’s bio line, “Bruce Mau is not any one thing.”

Wicked Teams First Articulate Problems, Not Solutions
At the beginning of the workshop, Mau assured us that we weren’t going to come up with a “magic bullet” solution. That was not the workshop’s goal. In fact, that would almost assuredly NOT happen. He emphasized that this room full of brilliant minds would likely not come up with one astounding idea, previously unimagined. However, in order to generate MANY ideas in a short timeframe, we needed to start by articulating the problem – something anyone at the table, whether urban planner or digital project manager, could likely do quite well. Often, Mau explained, clients do not start a project with a clear articulation of their problem. Rather, they say, “This is what I want. This is the solution.” It’s up to us to ask the right questions.

“Sketch: Hey everybody, let’s fail!”

I’d like to give you a surprise ending to the workshop story and say that one team came really, really close to resolving at least one aspect of inequality in Philadelphia. But that’s not true. And that’s not the point. As each of the workshop teams dove into the infamous, sticky note, rapid-fire idea generating portion of the workshop, it became clear that this was going to do what these workshops do best – each group, of very mixed professional areas of expertise, was able to fill page after page with ideas and facets of ideas. Eventually, a couple of ideas rose to the top and were drafted into more refined concepts. Urban planners were talking digital marketing and epidemiologists were talking fundraising. At no point did anyone shut another practitioner down because of a lack of expertise. Lesson re-learned. I don’t have to be Dan DeLauro to have insights into the dev process. I don’t have to be Amanda Buck to think of a great solution to a specific design dilemma. Problem solving starts with wicked nuggets from a renaissance team that, under expert attention and care, grow into full blown systems and revolutions.

Back to Top