This talk was presented at DPM Summit in October 2015.

Transcript

I want to talk today about how we approach working with other people on our projects. I think we all know that we can’t take a “my way or the highway” kind of attitude; we know we have to compromise and make adjustments, but it can be really hard to figure out where and how to make those adjustments.

Which problems are worth changing process over, and which ones should you dig in your heels for?

Spoiler alert: I think digging in your heels is almost always a bad idea. But that doesn’t mean you have to change everything; sometimes the small and the subtle changes are the most powerful. I’m going to talk today about how I approach these issues, and the method I use to find places where I can make adjustments that help projects run more smoothly.

Let’s start with a familiar story: I’m leading a team to make a thing. This is what I do; clients hire me to lead their teams to make things. We’re rolling along, checking off tasks, making progress towards our goals.

This project, like most projects, has some normal PM-type problems:

  • Deadlines that are just barely made or missed
  • I have to ask for something 3 times before I get a response
  • There are deliverables that aren’t quite up to snuff, so we need extra rounds of internal revision before showing stakeholders

Sometimes I feel a little annoyed and sometimes my team members feel a little grumpy. But overall, everything is fine.

These are very run-of-the-mill problems, right? They’re not extraordinary, or outlandish, they’re very normal and expected kinds of issues. They’re barely even worthy of the name “problem”; they’re more like “frictions”.

But small problems are still problems, and they’re tiring. Maybe not exhausting, but just a little wearying. To use the metaphor of an immune system, dealing with things like poor sleep and bad nutrition means that I’m worn down, and not up to the challenge when a big problem, like the flu – or last-minute CEO drama like Sara mentioned – comes along.

I started trying to dig into these frictions, and I found them really hard to pin down. They were slippery, and indistinct, and people couldn’t talk about them very clearly. And they’re small, so it was hard to justify spending a lot of time smoothing them over.

But they kind of stuck with me because I’m a problem solver, and these are small irritations; they seem like they should be fixable.

Things got a lot clearer for me when I started acknowledging just how much I was guessing about what was working for my team. We really do run our projects on conjecture and probability:

  • How long will this research take? I dunno,…two weeks?
  • Is there already a module for this CMS feature? Yes?, but it might need a lot of work?
  • Does the team assigned to this project have the skills to build it? They’ve built something similar in the past, so probably?

Long ago — I feel like this is one of the first lessons a PM gets — I learned that anything having to do with time is. Project plans, timelines, gantt charts: those are all based on guesses, right? Educated guesses, maybe, but: guesses. And, honestly, that’s fine. Because when you know that something is based on a guess, you adjust your level of confidence, you add in some padding, you know it can change.

And what I’ve come to understand is that, when it comes to working and communicating with people, everything is a guess. Their expectations, their skill levels, their fears, their motivations — I can make observations and take things at face value, but when it really comes down to it, I don’t have a clue.

What does this mean for those project frictions? Well, I was able to start unraveling some of them once I started looking at the things I was treating as fact, and recognizing that: those things weren’t facts, they were just more assumptions.

Assumptions like:

  • This communication is necessary.
  • Our junior developer doesn’t have this skill.
  • Weekly status meetings are crucial.
  • This team member isn’t paying attention to our goals.
  • That team member just wants to be told what to do.

And again: these were educated guesses, based on past projects and my history with team members – they weren’t just being pulled out of a magic hat. But they were still guesses, and I was treating them like they were set in stone.

One option, when I’m faced with an assumption that I don’t know the accuracy of, is to investigate! I can quiz that team member about their skills, or do a survey and find out how each person feels about weekly status meetings. If I’m faced with a guess, I have tools to find the truth!

Except, two things:

  1. Sometimes there is no capital-T truth. The answer might be something that’s in flux, or unfixed, or dependent upon the day. Not everything is cut and dry.
  2. And I think this is even more important: investigation takes time and energy. That can be fine for long-term changes, process adjustments that you want to make between projects, and just – bigger, deeper things. But launching an investigation is not realistic for every tiny friction that happens in the middle of a project.

For something like “do you want to come to this kickoff meeting”, it’s worth finding out the answer. But launching an investigation is not realistic (and sometimes, actually, not appropriate) for these tiny frictions that happen in the middle of a project.

If someone gives off just a little hint of frustration in a standup, I can’t put the whole project on hold while I delve into what’s going on for them. Maybe they’re having an issue with the client, or maybe it’s allergy season and they’re just feeling cranky. I could have a quick chat with them after the standup, but it’s not sustainable for me to go into full detective mode every time my Spidey-sense tingles.

So what can I do instead? I want to smooth these frictions out, but I can’t afford to do a deep dive on every single one.

What’s been working really well for me has been to

  1. Recognize and remember that my beliefs are assumptions, and then because of that,
  2. Make space for both the assumption and its opposite to be true.

I’m gonna unpack that a bit, and give you some examples.

Let’s start with a Tale of Time Management. I was brought in as PM in the middle of a long-term project with an existing team. The setup was sort of… agile-ish? There was an infinite list of stories, and every week each developer would choose a set of stories – a set of tasks – that they wanted to tackle that week. (There was some rough prioritization, but honestly there were so many possible things to improve that it didn’t really matter much what specific tasks were getting done, as long as progress was being made.)

After a month or two, I noticed that one of the developers, Stewart, had a really consistent pattern: every week, he would claim five or six stories – tasks – as his own. And every week, he would complete… two, or maybe three of them. And the rest would get pushed to next week’s list.

I couldn’t cotton to that. I think many of you in the DPM audience will agree with me when I say that as project managers: to-do lists are sacred. You can’t just say you’re going do 5 things and then only do 3. That’s not right. And what’s more, I could never know which of the 6 stories would be done at the end of the week because who knows what he would finish?

Now, my first approach was, well: re-education. For a few weeks, we had a weekly meeting about his task selection. We’d walk through the tasks, and he’d tell me how long he thought each one would take, and then we’d come up with a list together. But, man – those meetings took so long, and, they weren’t even particularly effective: he’d add more things to his list partway through the week! And if we skipped the meeting, he was right back to 5 or 6 tasks.

It was… very frustrating.

Let’s take a step sideways for a minute and talk about a woman named Byron Katie. In the mid-1980s she developed a simple framework of questions to evaluate thoughts and assumptions that you’re working with.

(I first read about Byron Katie years ago; she was quoted in a book I was reading, and I didn’t really think much of it at the time. But apparently it stuck somewhere in the back of my brain, and resurfaced when I started thinking about these project frictions.)

So she developed a process of inquiry – which she calls The Work – that goes like this: You take a single thought, or assumption, or belief, and you examine it using 4 questions.

  1. Is it true?
  2. Can you absolutely know that it’s true?
  3. How do you react when you believe that thought?
  4. Who would you be without that thought?

My entire frustration was based on Stewart taking on more tasks than he could handle and me not knowing what he’d finish each week. I was frustrated because I believed that was harmful.

That Stewart’s behavior is causing harm to the team, or to the project, is a pretty big assumption. Let’s look at it against these four questions.

1) Is it true that his behavior was messing up the project?
Well…[sigh] maybe? Probably not. It messes up my project planning, because I don’t know which tasks are going to be done at the end of the week. But certainly no one else on the team cares – the other developers aren’t waiting on his work, and it doesn’t affect them at all.

2) Can I absolutely know that it’s true?
Uhh, no. No. Even with messing up my project plan – the quality and quantity of his work is on par with the rest of the team, and there’s no launch date because we’re pushing changes constantly, since this is an ongoing service. I think it’s annoying, but, it’s not harmful.

3) How do I react when I believe this thought?
If I believe, truly, that his behavior is messing up this project, then I really need to do something to fix it. Light education didn’t help, so I would need to start being pretty heavy handed. I’d have to start micro-managing, and double-checking to make sure he didn’t take more than he could actually do in a week. I’d be making him into — I don’t want to say “an enemy”, but I can’t imagine either one of us would like it very much.

4) Who would I be without this thought? What if I stop believing that his behavior is harming this project?
Oh, man. I’d be free! I don’t want to be that kind of manager. I don’t want to be frustrated, or to micro-manage, I don’t want to be paternalistic. I want to support my team to do their best work, not control them so they meet my expectations.

So: doing The Work, on the belief that “he was messing up the project” made it very clear that this was an assumption I needed to drop. It was’t serving me, it was turning me into the kind of manager I did not want to be.

So I dropped that idea, but: that didn’t actually solve the issue of me knowing which tasks would be done at the end of a week. I began wondering if the 4 questions could help me find a path through that, as well. I thought, OK, what other assumptions do I have about Stewart?

How about: he’s really bad at time management.

That seems pretty obvious, right? OK, so, knowing that what I want is a clearer understanding of what will get done each week, I went through the 4 questions:

1) Is it true that he’s bad at time management?
Yep.

2) Can I know it absolutely to be true?
…Well, maybe. I mean, it doesn’t seem like it bothers him to move an uncompleted task to next week’s list, so maybe he just doesn’t have the same relationship to to-do lists that I do. So… No, I can’t know it absolutely.

3) How do I react if I believe this thought?
Well, what I need to know is which tasks are going to get done this week. So if I assume he’s bad at planning out his week, maybe something that helps both of us could be… a priority list. He could continue choosing his 6 tasks, but if we agree on an order, then I, at least, can safely assume that the first 2 or 3 are actually going to get done.

4) Who am I without this thought?
If I’m totally wrong, and Stewart is great at time management (but just uses lists differently than I do), then I’m freed from the obligation to treat this like a problem. It’s not a problem that needs solving, it’s just a different way of working.

So we changed up our process a bit: we started each week by setting a priority order for everyone’s tasks – not just Stewart’s. It was useful for everybody on the team. Whether someone chooses 2 stories or 10 stories, it’s still a good idea for all of us to figure out together which are the most important.

The first assumption I went through, that Stewart was messing up the project, it just wasn’t true. So my work, was to realize that, and drop the assumption, because it wasn’t helping me. But the second one, that he was bad at time management, I couldn’t actually know if it was true. And so I found a path forward that left space for both options to be true:

  • If he was really bad at time management, then prioritizing the tasks is a great first step to understanding how his time gets spent.
  • And if he was great at time management, prioritizing tasks is, at best, helpful, and at worst, neutral. And since Stewart is actually involved in setting these priorities, I’m not micro-managing, and I’m not handing it down from on-high.

And, no matter which one is true, I get more of what I need, which is a sense of what will be done at the end of the week.

I find these four questions really helpful, so I started using them to look at all kinds of project frictions, to examine the assumptions I brought to the situation.

How about this one: a deliverable — in whatever form that takes: a design library, or editorial calendar, or live prototype — that wasn’t quite up to par with expectations.

I ran a project last year where we had this come up with web fonts. We were working within a performance budget and had space for basically: ~2 fonts with 2 weight variations each. When the designer showed us his first mockups, there were 4 fonts and each one was using 3 or 4 variations.

Now, again: this was not some catastrophic error, this was the first draft, so we had plenty of time to fix it. It was not that big a deal. But how did we end up here in the first place? The project brief included the performance budget, everyone knew about it.

I looked back over our communications, and realized that at no point had anyone actually explained what a performance budget was, or how to calculate how fonts fit into it. My assumption, on this project, was that the designer was already familiar with everything that we were doing, and I didn’t need to explain anything.

It’s a funny thing, about our industry moving so quickly: this is a terrible assumption. Someone who’s incredibly skilled and is really into the minutiae of something like, CSS animations, is not necessarily also going be completely up-to-speed with something like web fonts or responsive images.

In fact, the next A List Apart event is a live panel about the crazy breadth of skills that all fall under the generic label of front-end developer.

It’s become impossible to know where that line is, about what’s become ‘standard practice’ vs cutting-edge, specialized knowledge.

Assumption of expertise is something that pops up in a lot of projects. [on the one hand] If I assume that someone doesn’t know what they’re doing, then I’m going to explain everything, and that can waste a lot of energy if they already understand.

[on the other hand] But if I assume that they’re an expert, then I don’t really explain much at all — because I figure they already know it. And if it turns out they didn’t, then I get work that’s not the quality I want.

It feels a bit like we can’t win, right? Both sets of assumptions are crappy. And that’s kinda true: both sets of assumptions are crappy.

What can I do instead? How can I simultaneously give novices everything they need to know, and not flood experts with details that they’re already on top of? For me, it comes back to looking at my assumptions, and recognizing them for the guesses they are.

Here’s my assumption: my team member doesn’t understand this thing (this particular technology, or project style, or whatever).

1) Is it true, can I know it to be true?
No!

2) How do I react if this person is a novice?
If I think they’re a novice, I’ll write out more of the background information. I’ll give them full explanations of the requirements and whatever terms we’re using.

3) What do I change if my assumption is wrong?
Hmmm… If they’re an expert, then I’m wasting my own time by writing out these explanations, but I’m also risking really annoying them, and maybe even insulting them by over-explaining the basics. So: I double-check my language for anything that sounds patronizing, and I make sure that the message is formatted in a way that’s easy for them to scan really quickly if they’re not finding it useful.

That’s a pretty small change, right? Formatting my messages differently? But it’s a change that accommodates both beliefs simultaneously: maybe this person is brand new, and needs all this explanation, or maybe they already get it and they can skim right by this email.

Now in this case I had actually made the opposite assumption: I assumed expertise where there wasn’t any. I assumed this designer understood performance budgets and knew how to calculate the impact of web fonts.

1) Is it true that they’re an expert; can I know it to be true?
No, not really. I can’t know that.

2) How do I react if this assumption is correct?
If I get a sense that they’re an expert, then I streamline my explanations and summaries. I make note of the requirements, but I don’t explain them.

3) What do I change if this assumption is wrong?
My gut and past performance are telling me this person is an expert. But remembering that it’s just a guess means that I’m careful to explicitly create a project culture where asking questions is OK.

If I’ve guessed wrong — or, maybe they are an expert, but they’re curious about my approach, or I’m using a term in an unfamiliar way – I want to be sure to create a space where they feel comfortable asking for the information they need.

Everyone on our teams has a different skill level, and our industry moves so fast that skill levels are shifting constantly. I have to start with my best guess, about how much detail I need to give people, and then I have to remember that it is just a guess, and create avenues for people to ask questions or skip ahead based on what’s right for them.

Let’s look at one more example.

I’ve been talking about this stuff with my friends, and I’ve been looking for places where they felt like poor assumptions caused friction in their projects.

I have two friends who both write a monthly column for the same online magazine, and they – completely independently of each other – told me the same story. They both said, “ugh, I get this monthly deadline reminder email from my publisher, and it’s so awful; it really bugs me.”

And I thought, oh-ho! Let’s take a look, let’s see what odd tone and poor assumptions are embedded in this email! Ready?

Just a reminder that your next post is set for August 19 (ideal due date: August 17). Let me know if you need anything.

Uhhhh… what? How could you get annoyed by this? This is the most bland reminder email I’ve ever seen. There isn’t even any tone to be offended by.

But they were both like, “yeah, it’s so annoying”. And I thought, what is going on here? What assumption is causing this friction?

It turns out that they were both really irked by the assumption that they would need the reminder at all. Because neither of them, in their entire tenure with this publication, has ever missed a deadline. Never even come close to missing a deadline! They both usually submit their pieces at least a week early.

So, from a project management point of view, this is a really interesting puzzle. Because, I’m the project manager: I have to send that reminder email. Even if they’ve never missed a deadline in the past, reminding them of their dates each month is absolutely a reasonable and appropriate thing for me to do.

But apparently, that can be annoying. So, as a thought experiment, I ran through the questions. The assumption I’m making, when I send a deadline reminder, is “This is helpful: this person needs this reminder.”

1) Is it true?
I have no idea.

2) Can I know it to be true?
No.

3) How do I react if I believe this is true?
I send the reminder email. Which, as I mentioned before, is going to happen no matter what. I’m a project manager; I am going to remind people of their deadlines. It’s my job.

4) What if I give up this thought?
Well, if I’m going to send the email anyway, but I’m not certain the person on the other end actually needs it… I think I would add in a bit that acknowledges that. Maybe something like:

I know you’re always on top of your deadline, but just a reminder that your next post is set for August 19 (ideal due date: August 17). Let me know if you need anything.

That’s a very small change. I showed this to my friends, and both of them were like, “Oh, yeah, totally. That’s way better.” It is literally 10 words. But that tiny bit of introspection and those 10 words change that email – which they see every single month – from being annoying to being supportive. That’s a pretty good return on investment.

In all of these examples I’ve shared, there are 3 things to point out:

  1. The changes are really small. These aren’t massive rewrites, they’re not huge shifts in the way I do my work. It’s a couple of sentences, here and there. It’s a tiny bit of rewriting, a few key word choices.
  2. These examples aren’t about fully exploring two opposite paths, and then presenting both avenues to my team. It’s much less involved than that: in recognizing that I’m making assumptions, I need to make sure that I am allowing space for the opposite to be true. I don’t have to spell everything out, especially if I’m making an educated guess, but I do have to be deliberate about not closing doors.
  3. You may have noticed that in basically all of those stories I told, the end result was better for everyone. The adjustments in tone, the formatting, the extra bits of information — those are things that improve the experience for everyone, no matter which assumption was true.

I don’t think any of this revolutionary. Each one of these frictions? The solutions aren’t mind-blowing. But, here’s the trick: The hard part isn’t figuring out the solutions. That’s not that big a deal. The hard part is remembering that the friction is your problem to deal with in the first place.

We’re all basing decisions on assumptions all the time, and that’s not inherently a bad thing. It’s a shortcut, it lets us get things done without having to deeply investigation everything we come across. But we also tend to get lazy, and we treat those assumptions like they’re truth.

It’s important for me to be mindful of that: to stop, and to recognize that I’m guessing. That doesn’t necessarily mean the next step is to find evidence about the truth of my guess. Mostly it just looks like being deliberate about the path that I’m choosing. Acknowledging that I am making a choice in how I react to things.

It’s really easy, when we’re working with other people, to believe that the problem is on their end. If he delivers you crappy wireframes, it’s because he’s bad at his job. If she keeps over-promising and under-delivering, it’s probably because she’s terrible at estimating effort (or, she’s a really slow worker). If part of the team is annoyed at my helpful communications, it’s probably because they’re harpies.

Here’s the thing: if I believe that, I’m stuck. I’ve painted myself into a corner; there is nowhere to go. If I believe that the source of a problem is another person, I have given up all power to change the situation.

Because I can’t change another person. I can only change myself. When something goes wrong on a project, if I want it fixed, then I have to fix it. I can’t magically grant a team member CSS skills, or make someone a morning person, or force them to love gantt charts. But I can adjust my approach – in the way I talk, in the way I plan, in the way I manage. It’s my job to be aware of my assumptions and make space for those team members to do their best possible work.