Consulting as a Co-Creation Conversation

Consulting is a paradox of power dynamics.¹ By defining a consultant as one who guides, teaches, and works alongside clients to make a sustainable change so that they themselves are no longer needed, it becomes necessary to analyze the structure of the power relations that exist. How does one offer expertise without being overpowering? Overpowering creates dependence, and our goal is to drive client independence. What does it mean to be empowering in the context of consulting?

In my experience as an engineer and consultant at VMware Pivotal Labs, I often find various situations to be driven by the power dynamics at play.

As consultants, we have power because we were hired to be experts. We have power because we do not work for our client company—we can say things that our clients are unable to say and are able to identify pain points and inconsistencies. We have power because we can push back against senior management, and they cannot have us reassigned, demoted, or fired when we disagree with them.

At the same time, we consultants don’t have any power at all.

We can’t be fired by their senior management, but we can have our consulting contract terminated if we act on bad terms. Within the company dynamics, we are outsiders, lacking the knowledge of how the company operates, its internal affairs, the domain knowledge of its systems necessary to do any work within the company. We rely fully on our clients to provide us with physical necessities (machines, data, passwords, access) and also domain knowledge (understanding what it is we are being asked to build, and the context in which it exists).

We dance this line, wielding some power and lacking some power. In the context of this power dynamic, how can we successfully achieve lasting outcomes for our client teammates? How does one best guide and teach within this framework?

An aside: in this post, and the upcoming section, I talk a lot about power and especially “structural power” or “systemic power”. For those unfamiliar, some quick term definitions. When I speak of a “system”, I mean a collection of people, things, rules, relationships, flows, and goals (e.g. a company: its goal is to make profit, there are people which create things and relationships that flow according to a set of rules, in order to achieve that goal). Systemic or structural power comes from the rules and goals of the system. A CEO does not inherently have power, they have power because the intra- and inter-company system is organized in a way that bestows and recognizes their authority. When I say systemic power, I mean that the social system in which a person operates recognizes them to have legitimate power or authority, outside of that individual’s sole control.

Sharing Knowledge From a Position of Power

In a traditional educational setting (like a school or university), a teacher has power and a student does not, due to the assumption that the teacher has some knowledge or information, and that their responsibility is to transfer that to the student. Many modern educational theorists call this the “banking model” of teaching, as per the analysis of Paulo Freire,² because teachers are seen as “depositing” information; the students are passive receptacles. This view of the learning relationship disempowers the student, takes away their autonomy and individualism, and negates their own experiences and expertise. Why? Because according to the dynamics of power, the teacher is the one who knows, so the student must listen.

Another common example of this power paradigm is in social innovation work. A well-meaning student, volunteer, designer, or other privileged outsider enters into a community to which they do not belong, a community with less structural power and some identified problem (such as being considered “in need” or “underdeveloped”). They draw upon their wealth of knowledge to identify a solution, and impose it upon this community. Often, communities are cynical to these efforts. They recognize that outsiders do not have the context necessary to understand their unique struggle and provide an adequate solution within their social or cultural fabric. However, they are disempowered from acting because the outsider has power (often in the form of capital - be it monetary, social, economic, knowledge) and they do not. This is how we end up with, for example, NGOs that provide clever but worthless tools to underdeveloped countries that become quickly junked.³⁴

In both cases of banking model of education and failed design interventions, you see a situation of power with a side-helping of paternalism—an outsider saying “we know what is best for you”. They provide a solution and they hand it over, saying “this is what is best for you.” The student, or the community, is the passive recipient.

As consultants, we should acknowledge that we have the power of knowledge—someone in the client company hired us because they are interested in our expertise and what we have to say. Someone out there paid money because they would like to hear us say “we know what’s best for you, and here’s what it is.” However, framing this relationship as the banking model of knowledge transfer leads to ineffectual change, because we don’t want our clients to be passive recipients.

It’s been shown that students learn and develop better when they are actively involved in the learning process.⁵ It’s been proven that design works better when the intended users are involved in the design process (see large swaths of research on User-Centered Design). It is the same for consulting—it works better when we involve our clients in the process for which we have been hired: our process for looking at a problem and designing and implementing a solution. We cannot impose a solution, it has to come organically from a unique collaboration of us and the clients.

The first step to achieving this collaboration requires being humble. Sure, I have knowledge. I’ve worked on eight separate projects since joining Pivotal. No two have been alike, yet all have some common threads from which I’ve learned, and from which I can draw upon for future experiences. Yet, with that alone, I can’t solve a problem for a new client! I may know nothing of the client company’s domain, the thing in which they are an expert for their customers. I know nothing of their internal processes, their hierarchies, their politics, or the bureaucratic rules that must be navigated skillfully to get work done without drawing wrath upon the team. But you know who does know that? The clients! They are the ones who have been doing exactly that—working and existing within these social structures of their company, knowing how to navigate them, and becoming experts in the domain in which they work.

Therefore, in order for a consulting engagement to be successful, it must be a collaborative experience that draws upon the expertise of both consultant and client. To me, this requires a shift in mindset from transmission of knowledge (from consultant to client) to something else.

The Road To Co-Creation

Transmission means leveraging the established power of the consultancy role. It says: “I am the expert and for that reason, you should listen to my opinion.” It reinforces the power dynamic. It turns our clients into passive receptacles for our opinions about pairing, testing, or product principles.

That may not sound so bad, you might think. Isn’t that what we’re hired to do? To teach these principles which we know and they do not? No, because our goal is not to dump a textbook’s worth of information about test-driven development and dependency inversion onto our clients.

Our goal is to set them up for sustainable success such that when the consultants inevitably leave the team, the clients are fully empowered and capable of continuing to work in the way that works best for them. We, as consultants, cannot define the way of working that is best for others. Thus, the focus should be on a process of co-creating that way of working with our clients.

At Pivotal, pairs of engineers do this daily without even realizing it. At a workstation, the conversation flows seamlessly between two people, each one stepping effortlessly between the roles of learner and teacher. I might explain my strategy for testing, and in the very next sentence, ask you what that Angular code that you just wrote does. I might describe a theoretical practice, and you’re the expert on implementing it in a particular language. You might question why I wrote a line of code, and in defending it, we both come to a greater understanding of why we make the choices we make than either of us had before the question was asked. We learn through teaching, and teach through learning.

This process of being simultaneously learner and teacher, mentor and mentee, questioner and answerer —this uses the knowledge and skills of two individuals to create something greater than the sum of its parts. To me, this sometimes looks like non-linearly exploring every stage of the “I do, we do, you do” framework of leadership development.⁶ We are co-creating a solution that works for the two of us, based on bouncing ideas back and forth.

The consultant who considers themselves a teacher without being a learner, or who doesn’t expect to learn anything from their clients, is the consultant that closes themselves off to growth, and at the same time, closes their entire team off from successfully co-creating their working practice. That is the consultant who creates who adopts practices without understanding - which leads to a team whose practices fall apart when the consultant leaves.

Models of Co-Creation

What does it mean to co-create a learning experience? What does it mean to co-design with a community, not for them?

In literature on education, Roger Hart approaches this question from the context of children’s participation in the educational structures which impact them.⁷ He describes a “ladder of participation” with eight rungs, each describing a level of participation from a population regarding decisions that impact them. At the bottom is outright manipulation, and decoration, and tokenism. It stretches upwards to include “consulted and informed” to inverting the power structure on its head - at the very top is when the decisions are child-initiated. This is meant to drive Participatory Action Research (PAR)⁸ — research which is co-created with young people. It is about avoiding merely sharing research with young people, or involving them at arm’s length, but rather, creating a space in which the young people are the driving force behind the research which impacts them.

In social innovation work, there is a strategy called Asset-Based Community Development (ABCD), which is oriented around upturning traditional power dynamics of outsider and community, and instead creating environments where communities can drive the development process themselves by identifying the unique assets which they bring to the table.⁹ The role of the designer is not about what outside resources (knowledge, capital, etc) they can bring in, but rather, is in identifying what assets (whether physical, social, relational) already exist within the community, so that they can intentionally step back and allow the community to control their own development process.

Both of these theories —educational and social-developmental—suggest an upheaval of the power structure, and centering the experiences of the one who was previously the recipient. They encourage “stepping back”, they encourage asking questions rather than giving answers, they encourage acknowledging and leveraging existing gifts rather than overpowering and overriding.

In both Participatory Action Research (PAR) and ABCD, the strategy involves taking an acknowledged power dynamic (the teacher or researcher has systemic power over the young person, the outsider has systemic power over the underdeveloped community), and taking action to purposefully deconstruct that, with care. As a consultant, I would like to take the power given to me by the contract of our companies, and carefully deconstruct it to center the experiences of the clients instead. Drawing from ABCD, our project will succeed if we leverage the existing expertise of the clients, supporting, growing, and building on those prior assets. Drawing from PAR, our project will succeed if clients are not manipulated (obviously) nor simply informed or consulted for decision-making, but involved such that the decisions come from them more than from us.

This strategy of stepping back, of raising up client voices, of taking what we know and using it to support the goals of clients is co-creation. Prioritizing decision-making to come from all, especially those without power, is co-creation. Leveraging your structural power as a consultant to purposefully empower others is co-creation.

How to Implement a Co-Creation Mindset

On a day-to-day level: what does it look like to prioritize co-creation? Let’s say your engineering team is having a full-group discussion about strategy—for example, we’re about to add a new type of user to the application, and we’re brainstorming the ways in which our architecture might have to change to support these new use cases. You have some opinions about what it should look like, whether it should all be in a shared database, or split out into separate tables, and other possibilities. What is your role here?

To start, a useful heuristic for a conversation like this (I’ve pulled this from the guidelines for write/speak/code¹⁰) is to ensure that two people talk once before you speak twice. This is a conversation—not your soapbox for speeches about database architectures.

It’s okay to have opinions, but as a consultant, you are not the one to decree and impose the “right” way to do things. What is right for you might not be right for the team. What is right for the team might be some evolved version of what you, and five others, think is right, because you’re adding your experience, the rest of the team is drawing on their own knowledge, and together we’re co-creating the best solution for the current context.

There is a fear on many teams that if we do not pick the “right” database architecture for this new user now, we will be stuck with the consequences of this bad decision for the rest of our lives on this product. More often than not, this is not the case. It’s okay to let a team get burned a bit, if the choice is between that and imposing your opinions as the wielder of power.

If the team decides upon a solution which you think is incorrect, and you’ve already voiced your opinions enough—let the team try something else. If it goes sideways, code is changeable and easier to fix than a fraught client relationship. Either way, the client, the one who will be the one maintaining the product well after you leave, will have a complete understanding of why decisions were made each step of the way. They’ll have made a decision, faced consequences, iterated, and pivoted. That’s empowerment. That’s active learning. That’s the opposite of being a passive receptacle for your database ideas.

Be humble. Give up control. Listen. Step back.

This is how we can spread wisdom, empower people, and make change.