In Transformation, It’s All Signal
Communication, Development, Project Management, Psychology, Social Theory, Sustainability, Urban Planning
In some media I’ve consumed recently, a woman speaker made a casual side remark that men act to act, and women act in context.
I don’t know if those two categories are gendered, but I do recognize them. I have seen them play out repeatedly in projects, and I have been particularly keyed to them in the past three years because of my formal graduate work in both community organizing and urban planning.
At the beginning of my graduate stint, I sent out an invitation to students who might be interested in collaborating on a sustainability project. The project is a big tent, with room for multiple disciplines – public health, sustainability, architecture, planning, organizing, policy, and more. My approach was to describe the current conditions, the proposed goals, and a little suggestive speculation about where it could go. Did the student want to support ongoing research, create a special studies proposal, select the project for practicum hours? All good; let’s talk.
The head of the Architecture Department called me, irate. I assume, by her tone, that because we were on the telephone and not across from each other, she made the wrong inference that I was 23 and felt compelled to educate me about “how it’s done,” instead of engaging me in a conversation about what her limitations were in her role, in her authority, in her worldview. In order for our students to be involved in something like this, she said, we (meaning her and me) would have to sit down and define a scope of work, create liability protections around it, develop a work schedule and do X, Y and Z before we could even put this out there as a possibility.
I assured her that I understood definitions would have to come. I understood also that perhaps in the field of architecture, the structure was front loaded…and there she interrupted me. It’s not ‘how it’s done in architecture,’ she admonished. It’s how it’s done, period.
Interesting. Informative. Incorrect.
You see, frequently in community organizing – the kind of community organizing that is based on transformative principles instead of utilitarian mobilization – that’s very distinctly not how it’s done. Instead, interested people meet. They talk. They talk about themselves, their interests, their projects, their experience, their perceived abilities, their perceived problems, the people around them, the people against them, the obstacles, the assets, what they had for breakfast. As we jointly explore this terrain, we start to build a map: a map of correspondence, of overlap, of synergy, of resonance, of antipathy. You and I, we are both working on a community garden. You and I, we both enjoy art. I had a bad experience at Citizens Bank; you hate Chase – different banks, but we get why banks suck. I am concerned that you clearly hold some beliefs that would alienate my allies; you are concerned that I don’t share your assessment of crime as the biggest issue that matters.
And from this exploration, we develop the project that meets both of our interests on which we can work, together. We didn’t sit down knowing; the idea came from our getting to know each other. And that’s “how it’s done” in transformational community work. It’s organic. It’s collaborative: not collaborative in a way which says, Here is my port. Plug and play, or I will move on to someone who can. Instead, it’s collaborative in a way that emerged as co-creative validation of as much context as we can viably share in the time we have. In fact, front-loading the structure, delivering a pre-made something that was formed outside of this dialog, is the antithesis of “how it’s done” in community work’s best practices.
Four experiences in the past few months are related and stand out as points in this theme. In two, I had meetings which I didn’t feel went very well. One was with a city councilman. In an introduction, I began by laying the foundation: this is what I’m working on. This is how it relates to your territory… He interrupted me. What is your “ask?” he prompted. I was stumped for a moment. If anything, I was coming with a “give.” But more, he had said nothing upon which I could yet develop an ask. What were his interests, goals, engagements? What feedback had he heard to which he would like to respond? What excited him about the project that I was spearheading? My “ask” was that we examine possible points of synergy and collaboration – but what those looked like, we didn’t yet know. My “ask” depended on what he could give, and I didn’t know that, yet. In this case, from my point of view, he wasn’t having a conversation, but trying to evaluate a proposal which couldn’t yet be formed.
This morning, I had a similar conversation with a sustainability executive. I asked for an informational meeting primarily to know what he was up to. What projects drove him? What interests did he advocate? What was his vision for how his role – either the formal one, or just as a human – would play out? This is not the conversation he wanted to have. He wanted an agenda, an action item, a point for response. Those would develop, with context, but I didn’t come with a script. I came to write together.
In my capstone, my primary advisor would sometimes get frustrated by my responses. He would ask for an update or my next step. I would begin to lay out the context: here’s the terrain I’ve learned since last we spoke; here’s what I think it means; here’s how it may apply to what we’re doing; here is what I propose as the action, based on all of previous information. He would frequently interrupt, trying to move me along to the upshot. He preferred the conclusion upfront, and he would ask questions to clarify if he felt they were needed. The problem is that he missed essential information with that approach, because he didn’t know what he didn’t know to know which questions he should ask. In my experience, this almost always results in misunderstandings that come up later.
In the beginning of the capstone, the faculty advisor directed the whole group to engage in a huge data dump, without first assessing what data was needed. What criteria were we validating with the data? In a pure research situation, it can make perfect sense to do a data dump at first. In that way, it functions much as what I am talking about: it assesses the ground so that we can start to see what questions should be asked, what discrepancies present for reconciliation, what interesting patterns present. But in a professional project, where the goal is substantially more narrow, it seemed to me that we were grabbing information without any strategy – it was action for action’s sake. It was a-contextual for the context, if you will.
So, many of you will say, Yes, well, these are busy people. Their time is valuable. They just need to know what is required in terms of resources in order to move the project along. Cut to the chase. Get to the point. Just tell me what I need to know. Sure. Moving things along is what we’re about: I’m an Explore/Execute, not an Explore/Examine. But we need to ensure we’re moving along the right path – not deliberative to the point of paralysis, no. But what you most need to know is the system in which you are operating. I am not suggesting that we stay in the context assessment phase indefinitely. But knowing what’s relevant informs us which correct action to take – and that, in turn, does affect the bottom line. Knowing what is actually relevant is the deepest understanding, the highest mastery in any field.
It affects the bottom line by ensuring the right road, but it does more than that. It also engages. It ensures meaning. It builds capacity. It increases buy-in and ownership. It refines experience and validates data consistency. In the end, it results in choices which are more likely sustainable, because they have integrated essential environmental information into their construction.
And interestingly, I find that all of my work circles around. So, what I have learned in community is what I have learned in business, particularly in project management. Because project management has for so long been a product of technical and manufacturing fields, it is often accompanied by a correlative mindset that is precise, essential, unembellished. I often hear comments in these type of discussions that people are off-point, over-thinking, getting too personal – all the various ways information is discarded as noise. A lot of people get particularly ruffled by Agile for these reasons: it can be a very personal engagement and its iterative approach kills the visceral sense of getting to the point (even though it is).
I assert that there is very little noise in any interaction: all of it is signal, if you are a master in your field. If someone says, Red is the best color, my response shouldn’t be, No, you’re wrong: it’s blue, and by the way, red is a bunch of horseshit. My response should be, Oh? And why does red strike you as best? Is there any situation in which maybe red isn’t best? What does red add? What happens if we used blue? Only by asking a series of probative questions can I understand what s/he means by “red is best.” Only by hearing the answers to those questions can I validate that my experience that blue is best still applies in this situation. What we must always remember – and practice, not just rhetorically acknowledge – is that precision is not accuracy. And if the best outcome comes from having the most accurate model, then we must factor in as much information as we can. We must understand the terrain as it is, not what we project onto it. Even if our purpose is to change the terrain, we have to fully understand what it is and what function it serves to make changes which are fruitful. Otherwise, people will say, That Marlena. She hits blue every time. And then they will say, But so what? We needed red, and all we got was blue.
Now you may say, Hey, man. All of this is obvious. Of course you should listen. Of course you should adapt. Of course you should know what you’re talking about. Indeed. Of course; we agree. And yet we don’t: some of us don’t even know how, or recognize that we’re not. Some of us don’t know that utility serves a purpose, but with returns we’ve limited by definition. Transformation serves a purpose that can have unlimited returns. In business and community, that is the higher mastery.
Years ago while studying problemsolving (in computer repair), the instructor asked us students how we should deal or solve a certain problem. Presented with 3 colors, red, white and blue wires, all possible wire combinations were exhausted while troubleshooting. “What next?”our instructor kept asking. I told her that since we started with incomplete data (only 3 line colors) we were sent on a Fools Errand. OUR PROJECT WAS DOOMED UNTIL WE DISCOVERED WE STARTED WITH WRONG ASSUMPTIONS!
I was presented with several lessons to be learned from this task.
robert on porter street