In the 12 or so years I’ve been a member of the working world, one of the things I’ve struggled with in various jobs is understanding what exactly my role is sometimes on different projects. This is likely a problem very unique to me, I’d imagine, and typically it emerges from a couple of things I’ve talked about on this blog from time to time: namely, most managers aren’t very good, and they kind of sloppily communicate the intent of a new project down the chain, and the person “tasked” with the new project views themselves as busy with other things, so typically you get a bunch of people together and they kind of talk around the beginning of an issue and clarity is ill-defined for a while, and then eventually some kind of random solution is forged, typically more “satisficer” than “maximizer.” That’s often been my experience on how projects get rolling, but it’s not necessarily everyone’s experience — everyone is different, after all.
There’s one rather small, kind-of simple change I think could be made to project management at the outset: simply defining roles more clearly. It’s very fraught, though.
Here’s a personal story.
Years ago I was working on this project related to a new website for a company — every company always wants a new website, you know? — and there were maybe 5-6 people involved total. 2-3 were pretty high up on a chain, and the rest were middle managers or rank-and-file. In this specific context, I was most assuredly rank-and-file.
If you’ve ever worked on a website project at a standard company, you probably know the first part of this equation: the higher-up people are never really that engaged. With very limited exceptions, websites don’t bank a ton of money for companies (e-commerce being a notable exception, etc.) Higher-ups tend to focus on bigger wins that they can upsell to their bosses; website re-dos are small wins that can be inserted in presentations, but not big $$$ wins. So the executives show up and say the right things, but they don’t often 100 percent care. I’ve done probably 12-15 of these at all different kinds of companies, and that’s pretty consistently true across the board.
The biggest problem on this project was really simple: the roles weren’t clear. One guy thought he was a designer, even though that wasn’t his background and he was supposed to be doing UX. One guy thought he was the project lead, but he wasn’t. One guy was totally checked out and periodically would say “impactful” in meetings, regardless of context. The first meeting led nowhere, as did the second, the third, and the fourth. A deadline had creeped up and literally no one had done work, so there was a CTJ — Come to Jesus — meeting and everyone was talking over each other.
I was by far the lowest-ranked person in this crew, and I said at that meeting, “Maybe it would be helpful if we defined specific roles for people…”
What happened next was incredible. Instead of this idea — which is seemingly logical on surface — being acknowledged, everyone got their talons and fists up and was basically in a rush to justify their job. It felt like something out of Office Space, but playing out in real life.
“Well, I’m the designer.”
That guy’s boss: “We need him designing, not delegating! He’s the designer!”
Clearly defining roles at work, even when no one looks like a real human, is valuable.
The Justification Index — which is a 1-10 score I created in my 20s to see if the value of a meeting was to justify the meeting itself or existence of the people in the meeting, or the value of the meeting was actual productivity — was about an 11.
I see articles like this on Fast Company all the time about how to fix communications and meetings when things break down, and I always roll my eyes at part of it — because invariably, those articles always say “… start with defining roles.”
That’s actually much harder for most people than you think it is.
Consider:
- Defining a role means you have to transparently admit what you do all day, which some people aren’t 100 percent aware of about themselves.
- It means you might have to admit you’re not as busy as others; “busy” is the currency of the modern age.
- It means you might have to cede control of some aspect to another person; this is why people don’t like collaboration.
- Overall, it involves a level of transparency and openness that people aren’t fully comfortable with at work.
There’s 210 million results for “defining results at work” on Google — here’s an example of what you get back — but despite that search volume, I don’t think people really stop and consider what it means, or how hard it can be, to define roles on a project. People have been working for 100s of years, and we’re still pretty unclear on how to actually set goals for people. Goals and roles are more than just fun rhyming words — they’re things people need to think about it, but don’t actually think about it.
Heard this about work culture a few years ago, especially in America: at work when there’s silence or lag time, we rush to fill it. That’s how projects seem to get started too. There’s no broader appreciation or approximation of the context behind it, or what needs to happen. It’s just busy busy busy rush rush rush, and that leads to a lack of clarity — starting with roles.
Seems simple to me that the first meeting on any new project should be a sit-down (with remote via Skype/Google) that ends with two goals:
- What is the goal of the project ultimately?
- Who is working on what?
That said, I’ve never really even been a middle manager, so I may know very little here — but what I’m saying above sounds fairly logical to me.
