The worst project manager ever

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

Let’s start by talking about terrible project managers. I was working at a web design agency in 2006 and the project manager was not very intelligent, though he was a spiffy dresser. Stylish shoes. If I looked down at his feet I almost always felt envy. He traveled in Europe, and acquired a collection of fantastic dress shoes from various fashion capitols. But he was a bad manager. His disorganization would come across in conversations like this:

THEM: Hey, uh, you done with Task 5 yet?

ME: No, not yet. I haven’t even started on it.

THEM: Oh. Shit. When you gonna do it?

ME: I guess after tasks 2 and 3 and 4?

THEM: Oh, no, listen, it’s really important.

ME: Oh? Since when?

THEM: Yeah, like, I just got a call from the client. They need this by tomorrow.

ME: Um, what? I can do it by next week.

THEM: No, listen, okay? Listen, this is really important.

ME: I can stop what I’m doing now and focus on it.

THEM: Yeah, good.

ME: But I don’t think it’ll be done tomorrow.

THEM: It’s super important. You’ve got to get this done tomorrow.

ME: I don’t think it’s possible. Task 5 is really big.

THEM: This is super important. They will go bankrupt if you don’t get this done tomorrow.

ME: Wait, what? Uh, first of all, that can’t be true, second of all, have we been paid yet? Third of all, it isn’t our responsibility to keep them in business. Fourth of all, someone could have told me that Task 5 was important? Why didn’t we make it Task 1?

THEM: Cool, cool, I’ll tell them.

ME: Wait, what? You’ll tell them what? Did you hear what I said?

And then they walk away. Two days later they come back and we have this conversation:

THEM: Hey, are you done with Task 2 yet?

ME: No, I worked 16 hours yesterday on Task 5!

THEM: Don’t worry about Task 5.

ME: Wait, what? I thought the client was going bankrupt without Task 5?

THEM: Dude, that’s not even possible. And, really, is it our responsibility to keep them in business? Anyway, Task 2 is the important thing now, can you work on that?

ME: As soon as I’m done with Task 5.

THEM: Nah, c’mon, dude. Probably nobody really cares about Task 5. Can you focus on Task 2? You were supposed to be done with Task 2 by now.

ME: Yeah, if I hadn’t wasted 2 days on Task 5, then I might be done with Task 2 by now.

THEM: So, you’ll get it done today?

ME: I’m very focused on Task 5, having spent many hours figuring out the nuances of the request.

THEM: Yeah, man, that’s some stupid marketing thing. I think it’s probably been cancelled. They’re going to try something else.

ME: Okay, whatever. I’ll focus on Task 2.

THEM: Okay, great.

Two days later them come back to me and we have this conversation:

THEM: Hey, man, are you done with Task 5 yet?

ME: Tell me you are kidding.

THEM: C’mon man, I told you how important that was.

ME: But you also told me that Task 5 was cancelled.

THEM: I said I thought it was probably canceled, but you should have kept working on it till I confirmed that it was cancelled. Turns out it wasn’t cancelled. That’s your mistake.

ME: How is that my mistake? You’re the one who said it was probably cancelled.

THEM: Yeah, “probably”. You jumped the gun if you acted before that was confirmed.

ME: So you want me to work on Task 5 now?

THEM: No, man, they probably went bankrupt now. They really needed it at the beginning of the week.

ME: Are they bankrupt or probably bankrupt?

THEM: Oh man, what’s with all the questions? Do you know how much time I waste trying to track down answers for all these questions that you ask me?

ME: I waste your time?

THEM: I mean, can’t you figure anything out on your own?

ME: Am I allowed to talk directly to the client?

THEM: No, are you crazy? We have account specialists who talk to the clients. Engineers don’t know how to talk to the clients.

ME: I could ask them simply “Is this task your highest priority?”

THEM: You don’t know how to talk to clients. It’s a special skill. You need to figure out what kind of pain they are suffering, and then you need to figure out how we can help them solve that pain.

ME: I could ask them “Are you guys about to go bankrupt?” Then I could ask “Would Task 5 help you avoid bankruptcy?”

THEM: See, this is why no one enjoys talking to engineers.

ME: I’ll get to work on Task 5.

THEM: Thanks, man. Not sure why you had to have a meltdown over such a simple request, but thanks.

The next Monday he comes back to me and he says:

THEM: Hey, man, uh, what are you working on again?

ME: I got done with Task 5 and Task 2, so now I’m working on Task 3.

THEM: Oh, man, really? That sucks.

ME: Why does that suck?

THEM: Dude, tasks 2 and 5 were definitely cancelled, you were supposed to be working on Tasks 6 and then 7.

ME: Why can’t you keep any of this straight?

THEM: Me? What are you talking about? I’m not the guy who just wasted a week working on the wrong things.

ME: If I’m not allowed to talk to the client, then I’ve got to depend on you to tell me what the client actually needs.

THEM: I talk to the account specialist every day, and they talk to the client every day, so I’ve got a ton of notes about what the client “actually” needs. You want to see all of my notes? I’ve got a ton of notes.

ME: Well, why aren’t these notes being communicated to me in a timely fashion?

THEM: You want to see all of my notes? Look at this! I mean, seriously, just look at this! I’ve got a million notes about what the client needs!

ME: Okay, look, you seem like you understand what our client needs, but you are mismanaging this project.

THEM: Oh, man, what’s with the insults? I live by the rule “If someone tries to complement you, but says the word ‘but’, don’t listen to anything before the ‘but’.” So all I just heard was you saying “You are mismanaging this project”. That’s mean. You’re really mean, dude.

ME: Okay, how about this: “You are the worst project manager in the entire history of the universe, but I like your shoes.”

THEM: These are great shoes, right? I love these shoes. I got them in Europe.

I’ve been doing professional software development for 20 years now. The first 15 years I was a computer programmer, these last 5 years I’ve been a consultant helping companies engineer turnarounds and rescues, as well as architect new solutions.

During these 20 years, the best project manager that I ever worked with was a woman whose initials are SB. She worked at ShermansTravel.com, when I was there in 2011 and 2012. She oversaw the tech team, which at its peak had 7 people on it, plus an overseas team with another 5 people on it. Much of my “ideal project manager” is based on her habits.

Here are a few attributes of a great project manager:

Does not allow work to proceed until all dependencies are ready

SB had a rule that a computer programmer should not start working on a Task if that Task needed something that had not yet been provided. For instance, a web developer might have a Task such as “Change all icons in the shopping cart” but perhaps the graphic designer had not yet finished designing all of the icons. In those cases, SB would hold the Task in purgatory. Once all of the icons were done, then the Task could be assigned to a web developer to implement.

Likewise, a marketer might be asked to write text for a new product, before the top management had decided if they would position the product as a premium product or a value product. In such cases, it is best to keep the marketer from wasting their time.

Every time I teach people this rule someone responds, “You are trying to do things the old fashioned Waterfall way, but it is much better to do things with the Agile style, where everything happens at once!” My experience with “Do everything at once” is that it leads to a lot of confusion, a lot of wasted work, and a lot burnout. By all means, do things in parallel when you can, but if you try to take fundamentally sequential tasks and treat them as tasks that can be done in parallel, the end result tends to be frustration.

Most of the time, no one should be asked to work on a Task, when that Task depends on previous decisions, or work, that have not yet been made.

Fearlessly defends the team from management and clients

This rule could also be phrased as “Fearlessly defends the development process from arbitrary changes.”

When ShermansTravel.com was at its peak, circa 2008, it had 60 employees but it had outsourced all software development work. The management found outsourcing to be expensive and slow, so they decided to bring some of the software development work in-house. So they hired one software developer, then two, then three. There was no team lead, and no structure. When the CEO wanted some change made to the website, or the newsletter, then the CEO would walk over to one of the software developers, and ask them to drop whatever they were doing and instead focus on the task that the CEO now felt was important. Utter chaos reigned and the software became an unholy mess that no software developer could truly understand. There was no effort at a cohesive architecture, nor was anyone in charge of making long-term technical decisions.

When SB was hired, she was young and uncertain, but after a few years she had become confident, and she had become a warrior who was ready to murder anyone who messed with her team. A good process was developed for deciding which Tasks were important, and which were less important. SB defended the process, which is to say, she defended the manner in which decisions were made. She vehemently resisted sudden, arbitrary changes to the plan. The team worked in 2 week sprints, and if some manager wanted to change the Tasks in the sprint, half way through a sprint, SB would put the request through a rigorous vetting process. Only real emergencies were allowed to change the Tasks that the software developers were working on.

There are moments when it is useful to have the engineers (or any kind of staff with specific skills) talk to upper management and talk to outside clients. But those discussions need to go through a specific process, they can not be allowed to happen randomly.

Hopefully everyone already knows this, but I’ll say it again just in case someone inexperienced has not heard this before: allowing the CEO to make any request of any person at any time is not healthy for an organization. A smart CEO knows this. A smart CEO knows that any large organization needs development processes, and the processes need to be held as sacred, and exceptions to a process needs to be very rare. Allowing the CEO to make any request of any person will lead to chaos, and weaken the organization. And the people who work for an organization need to fight for the long-term needs of the organization, not for the CEO (who might only be around for 5 or 6 years). Occasionally some particular CEO gets angry at me when I emphasize this too loudly, but everyone aside from the CEO typically understands the wisdom of what I’m saying.

Not afraid of the technical side

A project manager is not a computer programmer, but the best project managers are not afraid of the technical side of the work. They are willing to learn some basics of programming, if only so they can have insights about the deeper aspects of the craft.

This applies to teams that have nothing to do with software development. A project manager at a construction firm with also be good with spreadsheets, and might even learn how to write Excel macros, because they will need spreadsheets to keep track of finances and other resources.

Assume you need to send out a newsletter, but only to those users who are at least 18 years old. A good project manager is willing to learn this much SQL (this being the language for database queries):

SELECT first_name, last_name, date_of_birth, email

FROM users

WHERE date_of_birth < '2001-07-04' ORDER BY date_of_birth At ShermansTravel.com, SB would ask the engineers for help writing SQL queries, so she could get the data she needed. Every time an engineer wrote some SQL for her, SB would save it to a wiki, and write a note about how it worked. Over time, she got better and better at using SQL. She was never an engineer, but she was never afraid to pick up what should could about the technical side of things.

Analyzes team members and knows when they are lying or boasting

I’ll restrict my remarks to software development teams. Most computer programmers tend to be a bit macho about their abilities. Ask a computer programmer “How long will it take you to get done with Task 3?” and if a reasonable answer is “5 hours” then the computer programmer says “3 hours”. They like to strut around pretending they are faster than anyone else.

At the same time, there are some computer programmers who are afraid of getting blamed for a task that goes over-time and over-budget, so they offer bloated estimates. Ask them how long it will take them to do Task 3 and they will say “10 hours”.

When I was at ShermansTravel.com, SB did a remarkable job of parsing each computer programmer, and figuring out if they were the type of person who would boast or lie. She then adjusted their estimates accordingly. She knew that with some programmers, if they said “3 hours” then she should mark the task as a 5 hour task, whereas with other programmers, if they said a task would take 10 hours, then she should mark the task as a 5 hour task.

This is the very subtle human element of project management. I don’t think it can be taught, but it can be learned, from years of experience interacting with various people on various projects. One way to accelerate one’s own learning process is to make predictions, before any work is done, about each computer programmer and each task, and then carefully measure how wrong you were, and then update your understanding of people accordingly.

Finds multiple ways to keep track of progress

As suggested in the story I told about the terrible project manager, the worst project managers tend to keep track of a project simply by going up to members of the team and asking, “Hey, you done yet?”

It’s good to keep checking directly with team members, but it’s also important to have other ways of checking about progress. Some of these other techniques can include:

* if Team Member A needs to work with other people on the team, ask those other people if they’ve collaborated with Team Member A yet

* if Team Member A is doing research on a project, assume that research is being gathered somewhere online, and then check that source — maybe its a wiki, or Google Docs, or Dropbox, or Basecamp, or a chatroom.

* if Team Member A is writing software, then there software will typically go into some kind of version control system — look at that version control system and see if there have been updates from Team Member A

* if Team Member A is brainstorming creative ideas, again, encourage them to keep those online so you can check on them. (But don’t be critical of early ideas.)

* if Team Member A helps with sales, you probably have a CRM, and you probably ask Team Member A to record things in the CRM, and they probably hate the CRM, because all salespeople hate the CRM that they are asked to use. At some point they have to enter data into the CRM, but as a temporary and partial solution, encourage them to use the Voice To Text on their phone to send you email.

* if Team Member A is building something like software, try to use the software as soon as possible.

In other words, a good project manager works towards having a 360 vision on what their team members are doing. A project manager who simply asks people “Are you done yet?” is a failure.

As I wrote in One-on-one meetings are underrated, whereas group meetings waste time, one on one meetings are very effective in allowing people to talk about other people on the team. I am not implying anything negative when I say this, and I am not suggesting that people should be expected to say critical things of each other. But it’s also true that if Team Member A is disappointing everyone on the team, having a one on one meeting with those other team members is a great way to hear about Team Member A’s under-performance. You can then work with Team Member A to figure out what the problem is.

Aggressively confronts under performing team members

Great project managers are polite, but direct. If someone repeatedly misses targets, a great project manager will ask them why. No doubt the person has many excuses. It is important to drill down past all of the excuses. None of the excuses matter, all that matters is the question, to be put to the failing team member, “What needs to change so that you live up to expectations?” A good project manager knows how to remain polite, while also pushing hard to get that question answered.

Fearlessly fires those team members who fail to improve

This comment is mostly for the USA, where managers are granted considerable freedom to fire people. Obviously one doesn’t want to build a company where people are fired for arbitrary reasons, as that would damage morale, and cause the best people to quit. But when you’ve worked with someone to improve their performance and they have not improved, a good project manager will try to protect the rest of the team by getting rid of those who have disappointed repeatedly.

Speaks well when in front of an audience

A project manager will constantly be defending her team to upper management, and then, later on, they will be defending the wishes of upper management to their team. It is essential that a project manager can feel comfortable when in front of small groups. It is rare that a project manager needs to talk to a packed stadium with 1,000 people in it, but talking to groups of 10 to 30 people is something that project managers will do often. They need to be able to speak clearly, speak loudly, speak candidly, never get flustered by tough questions, and always be polite but firm, even when someone is being aggressive towards them.

Where is the conversation about Scrum, Agile, Kanban, PMP and CAPM?

At this point many of you are wondering, where is the conversation about all of the formal methodologies regarding project management?

I warn you, I am about to say something controversial.

I have not personally noticed that credentials (such as Scrum Master or PMP) are associated with real skill as a project manager. The key things that make a great project manager tend to be psychological:

* Does this person have moral convictions necessary to take a tough stand against upper management, for the benefit of the overall company?

* Does this person have the confidence necessary to fire a poor performer, for the benefit of the overall team?

* Does this person have perceptiveness to correctly read team members, and so know when they are lying or boasting?

Certain people gain these attributes as they gain experience, but these attributes tend to be things that are not emphasized in formal credential courses. Strong moral convictions tend to be picked up in childhood and are only learned slowly in adulthood. In formal credentialed courses the focus on various rote processes tends to shift the focus away from the things that are really important.

Whenever I say this, upper level managers then ask me:

But if we can’t rely on credentials, then how do we reliably hire top tier project managers?

There is a hiring process that delivers reliable results, but it does not focus on credentials. My thinking on this subject has been influenced by Brian Williams, who for many years had the reputation as being the best technical recruiter in New York City. Despite the fact that he lacked the technical skills to evaluate computer programmers, he always knew who the best computer programmer was for any given job. What was his secret? He started by making friends with a few engineers who had built impressive things, and then he asked them who they thought were the best computer programmers. And then he went out and he became friends with the people who had been recommended. And then he asked those new friends who they thought were the best computer programmers. And he kept going, building a graph of who the best programmers thought were the best programmers. In other words, he started with something similar to the Google PageRank algorithm and he applied it to people. And this gave great results to him and his clients.

If you are hiring, I urge you to contact Brian Williams’s company, HiveFive.ai. If you can’t use HiveFive (maybe you are in a different country) you can still get similar results by using a similar algorithm. Tell your HR department to start with two or three project managers who they know are good (perhaps because they’ve accomplished great things in the recent past) and ask who they would recommend. Your HR department can then build it’s own graph of the best project managers. I can guarantee this process will deliver results that are more reliable than simply scanning people’s resume and looking for particular credentials.

————————————–

Having said all this, you might be looking for a specific plan that will give your software team good results, so check out my essay The Right Way To Do Agile. That essay is shorter than this one.

For further reading, you might also like The Agile process of software development is often perverted by sick politics which goes into the history of the Agile movement in software development, and goes into much more detail about how “Agile” tends to go bad.

Do you need help rethinking your technology team, both its technology and its workflows? Contact me at lawrence@krubner.com

Also, check out my books:

.

also:

Source