I’ve been having an extended conversation on project governance, organizational change, and inclusive leadership with a friend who’s been trying to help an organization move from “stuck” to meaningful change. It’s been great to see progression from “leadership can’t even tell me what problem we’re trying to solve” to “today someone told me they feel like we’re really getting things done.”
Specific ideas they’ve brought to their organization in the past few months include:
- Decision-making frameworks (like DACI).
- Continuous improvement (but not open-ended faux experiments).
- Intentional change management (which is the subject of a longer post I’m just now getting outlined).
- Being curious about the ways in which a seemingly benign process doesn’t work for the intended beneficiaries.
People don’t always associate those things – decision-making frameworks, change management – as enablers. Instead, they see a mountain of forms, process docs, and specialists asking them to start from the beginning so “the process” can have a chance to work.
I’m not here to write a defense of process, because too many people have a lived experience of process that is indefensible. The kind of people I have spent most of my career working with or managing don’t need to read a defense, anyhow: operations teams, IT groups, and services teams all understand the value.
Instead, I’m here to talk about some practices cross-functional leaders can apply to their work and behavior to foster inclusion and help everybody do their best work. This applies to be people whose roles are inherently cross-functional – they lead a centralized service of some kind – and people who are stepping up to lead from within their day-to-day work in a functional group.
As that conversation I am having about governance, change management and inclusion has unfolded I have heard a lot about an organizational history full of weaponized, disempowering process. Conversations around new initiatives were full of distrust, nobody wanted to bring in supporting specialists from finance or HR, and every meeting was stacked with senior leaders who didn’t participate or contribute but weren’t willing to turn their back on the situation.
As we talked things through, I identified some key mindset and practices that have helped me as I’ve led cross-functional initiatives over the years, starting with three key attitudes.
Clarity, curiosity, generosity 🔗
I have a practice of going through my calendar and making pre-notes for meetings at the start of each day. I write down the purpose of the meeting, then I answer the question “how do I want to show up?” Over a year of doing that, I found three words showing up more than any other:
- Clarity: I want to focus on what’s important and help keep other people focused, too.
- Curiosity: I want to understand what the people around me need and how they may see things differently from me. I want to learn more about how they work and what their jobs require of them. I want to understand how their version of “common sense” differs from mine.
- Generosity: By knowing what’s important to me, I can be generous: I can share control, or information I might otherwise hoard to keep control of things that don’t matter, or show flexibility to change how I work because my particular processes and practices aren’t good unto themselves; they’re only as good as the outcomes they enable.
These are all aspirational states, for me at least, but when I leave a meeting or 1:1 feeling like I kept them all in sight and honored them in some small way, that goes down as a “firing on all cylinders” interaction. They’re the foundational mindset of leading inclusively, helping me to welcome people in and behave like someone people want to collaborate with.
Being clear on what matters 🔗
Our needs and incentives don’t always align with the people around us, even in very directed, disciplined organizations. We may share the same top-level OKRs or goals, but underneath that are all the contradictions that come with multiple specialized groups with different jobs. Being clear on what we need for ourselves and our own teams at the start helps remove a lot of distractions and ease the tendency toward uninclusive behavior.
When I’m sitting down in front of a blank piece of paper thinking about how to start building out an initiative or describe a project, I like to ask myself one question before any other:
“What problem am I trying to solve?”
It gives me a moment to think about where I need to end up. It focuses me on the thing at hand, helping me disentangle this particular work from all the other things I’ve got to think about. When I don’t start that way … when I start with a list of outcomes or a set of preconceived milestones the writing takes on an improvisational air as I try to cover all the elements of a vision I still only see as an aggregate.
This is useful as a way to focus and think, and it’s also key to showing up well when working with stakeholders. Knowing what you really need going in – understanding what problem you’re trying to solve, what outcome you need to achieve – helps you remember what’s important and set aside things that aren’t. In return, the list of things you have to control or worry about shortens, and you can act with more generosity.
Cast a wide net 🔗
Grounded in your goals and objectives, you need to cast a wide net as you organize your stakeholders.
This is less a question of “what:”
- People working in other business units with a stake in the outcome who have to contribute and even drive parts of the work.
- People working in support functions (e.g. finance, HR, IT) who can provide support in the form of communications best practices, access to centralized resources, or just smoothing out the path through things like tool adoption or expenses that have to be shared.
It’s more a question of “how:”
- Talking to the obvious stakeholders ahead of time and asking them if you’re missing anyone in their organization, or someone they regularly work with in another.
- Sharing your stakeholder list early, ahead of any kickoffs, so the network you just created for your project or initiative can help you fill gaps.
I like to think in terms of “day 0”: Pre-kickoff socialization and check-ins, before the story goes from you asking, “should I include you?” to them saying, “I heard there was a meeting I wasn’t invited to.” I know which conversation starter I’d prefer.
Communicate roles and responsibilities clearly 🔗
Another part of “day 0” is taking an initial swing at understand roles and responsibilities: Describing where everyone fits in, how they can best contribute, and where in the work they should be shifting between offering input or consultation, or actually owning and driving.
It’s helpful to learn how to think in terms of the DACI decision-making framework, even if you never sit down and write up an actual DACI matrix:
- Who decides this is done to standard?
- Who makes sure things are getting done?
- Who needs to be consulted for this to be successful?
- Who needs to know what we’re doing (or what we decided)?
It’s helpful to distribute this ahead of a kickoff, too, along with the initial agenda. It will often jog peoples’ memories about other potential stakeholders, and it will give them a chance to have the conversations they need – with their teams or leadership – to get clarity on their own goals, or to speak up if you missed how they can best contribute.
Assertiveness is okay 🔗
Assertiveness about roles and responsibilities sometimes feels like the opposite of “inclusive” or “welcoming.” You’re telling people where they fit into a project or process. Sometimes, if you’re being realistic, you know they might not like what you have to say or they may be working for a leader who coaches toward keeping control of a situation.
Remember a few things:
-
They might not even react that poorly. People are often relieved when they learn that all you want is consultation, provided they also see a good-faith effort to listen and act on what they told you.
-
Some people are resistant to “merely” being informed because they’ve lost confidence that that will even happen, and that they’ll miss out on something important to them. That’s why you take the time to cast a wide net in the first place: You’re on a better footing to build trust if you included them to begin with.
-
Being clear on what you need makes it easier to say “you know what, for this part of the process where you’re the one doing most of the work you should drive design and approach – what matters to me is over here, and I’ll drive that.”
It’s a fine balance, being assertive around roles and responsibilities while also remaining curious, and generous. The clearer you are on what you really need, and the less attached you are to an abstract conception of what it means to “be in control,” the easier it is to be a kind of “assertive” people respect.
Be ready to negotiate 🔗
In organizations trying to scale up there are a lot of business processes unique to each group that were never built with other groups in mind. Specialists in support services layer on processes and practices meant to smooth out their own work. They’re also frequently oversubscribed, and struggling to figure out how they can participate. Sometimes they can come off as rigid or disinterested in deviating from their particular processes. Curiosity is a useful mindset. You can ask:
- If we need to move faster than your process allows, which parts matter the most to you?
- Can we do some of this in parallel?
- Will you accept a commitment to do a fast followup and “fix it in post” if we need to deliver something before all your work is done?
Just lead with the goals and objectives you made sure you were clear on before you even sent out the first invitation and make clear you’re curious and interested about their own goals and objectives.
Record and communicate your decisions 🔗
Once you’re up and running with your stakeholders, there’s still a possibility you’ve missed someone:
- A person who should be participating but isn’t – your network just didn’t catch them.
- Someone who’s affected by what you’re doing and needs to be informed, even if they aren’t in a position to make decisions about your work.
People become anxious and controlling when they’re not informed, and the people who need work on consistent communications learn the wrong lessons from the anxious and controlling people around them: They double down on their uncommunicativeness and unwillingness to include people. It’s the worst kind of negative feedback loop.
To head that off, you should be documenting your decisions in the open, whether that’s a regular communication in the right forum or just making sure your decisions are captured in a wiki or accessible project board.
It’s helpful to think of project meetings and documentation in a manner similar to the “sunshine laws” you find in government:
- Meetings and communications in the working project group are relatively privileged: People should feel free to express concerns, address potential management and communications challenges, and “think aloud” in a way that enables creativity.
- Agreed-upon actions and decisions have to be publicly communicated in a forum that allows feedback.
I like RFCs because they make the ideation and decision-making process more transparent, and because they provide an opportunity to explain roles and responsibilities up front. Seeing the history of a decision – then seeing who made the decision, and understanding whom to appeal a decision with – gives people more confidence in the decision. If they feel like they are valued stakeholders in the process who are being informed about things that might affect them they’ll feel better about participating.
As with every tool that adds an element of structure and formality, people might feel uncomfortable:
It’s sometimes hard to work in the open, especially if there are trust issues to deal with. It often helps to book time with people new to written collaboration and talk through expectations, or to share prior art as a model. It also helps to simply take a few minutes to let people talk out a concern they’re struggling to commit to writing. We often experience tension between telling people what we need and framing it in a way that’s okay in the context of showing up collaboratively. Giving people a little space to just say it out loud helps them figure out how to think about it more constructively.
Another tool to consider is a simple decision registry: A place where decisions are consistently recorded, including who made the decision and links to supporting documents or meeting notes, for anyone to review.
Learn why passive voice isn’t just a grammar teacher’s hangup 🔗
In a nutshell, “the passive voice” involves sentences where nobody does anything and everything is acted on by … something or someone unspecified.
The grammatical reason to avoid the passive voice is that it is usually less efficient and elegant:
“It was decided to proceed with the alternative proposal” is a poor choice when “Joan decided to proceed with the alternative proposal” is sitting right there.
The social reason to avoid the passive voice is that it obscures accountability, dilutes responsibility, and hides the decision-makers. People sometimes think it is a trust-building choice because of a mistaken belief that it sounds more formal and business-like, but it has the opposite effect.
The operational reason to avoid it is that it makes a process document impossible to read or use, because people start from “what is my part in this process?” It is very hard to search for your team’s responsibilities in a document that never says who’s doing anything.
Be ruthless in eliminating complexity 🔗
If you’re a process person – if you thrive on thinking through a flow chart, covering all the angles, de-risking each step – then you are more likely coming from a place of comfort with a certain kind of complexity, and of some familiarity with all the systems you have to interact with.
That is not everybody.
As I’ve worked on an essay about a change management document I have used a lot, I’ve thought a lot about the times I put that document in front of a leader trying to figure out how to make a needed change then watched their faces fall as they saw two pages of questions and tables. I pared it down over time as I reminded myself of the idea that “if it’s not obvious to the person you’re trying to help, it is not obvious.” The version I’m looking forward to sharing shifts a lot of the questions people were expected to answer completely to prompts they could think through without writing a novel.
One team I joined had a particular JIRA workflow that couldn’t start until the customer successfully completed a 12-question form that substantially repeated itself and made clear that no matter what you said in each of the “three or four paragraphs recommended” fields, you were going to have to re-explain.
When I was put in a position to do something about that, I changed the twelve questions to three:
- What problem are you trying to solve?
- (Optional) Have you identified any solutions you’d like to try?
- Does your departmental leader know you’re asking for this?
Anything else we could handle by sending a business systems analyst or architect to ask, and we stopped the practice of making people fill out associated tickets: BSAs, project managers, and other specialists knew what we cared about and offered to capture that in a meeting where people could just talk out their needs.
I wish I could have collected better metrics about that change, but it was easier to toss the old workflow with all of its conditional logic and triggers than try to preserve the 25 (!!!) tickets one customer request would generate. What I do know is that group reviews of the backlog shifted from months-old requests languishing to a more frequent “we opened this last week, did we …” “Yes, it’s moving on to a PoC.”
When you’re working hard to make the process more accessible to the people you’re supporting, most of them can tell. That makes asserting roles and responsibilities easier, and it makes communicating decisions easier, because you’re building trust that the process is there to serve and accommodate them, not marginalize and disempower them.
So, bias toward simplicity, and if you’re responsible for designing or driving a process, take some responsibility to ease peoples’ interactions with it. If you know writers or UX designers, they’re great people to bring in for a quick consultation: Writers can help clarify language and expose faulty reasoning, and good designers excel at taking workflows apart and considering how people can interact with them more successfully.
… and be patient 🔗
Part of an cross-functional leader’s job is untangling mistrust and resistance. Getting people to participate in a more inclusive process can be challenging because they may have learned over years that “The Process People” are best worked around or avoided, or that they have to think in terms of control instead of outcomes.
When I first introduced RFCs to a group as a way to make ideation and decision-making more transparent, some people didn’t participate: They didn’t see the point and hadn’t seen cross-functional conversations about shared problems work. Within a quarter, though – having seen a few play out and having learned they could talk through things like a disagreement about roles and responsibilities – people who’d been conspicuously silent were kicking off their own RFCs and driving accountable behavior around them.
When I first introduced decision registries to a governance group, the initial few responses around the company were “who the hell put this group in charge,” but because we were sharing meeting notes and tickets publicly, and then writing down our decisions, people went from that early hostility to, “I’m affected by this decision and I don’t see myself in any of the docs, can I be included?”
Of course they could. We wanted to help everyone do their best work, and that started by trusting people to be collaborative, and making sure they saw the structures we built and the way we worked as something that enabled their participation instead of locking them out.