In part 1 of this series, we looked at the underminer product manager. In part 2 we talked about the dinosaur. In part 3, we looked at the erratic driver. In part 4, we looked at the micromanager. In this post, we will discuss the Dread Pirate Roberts product manager.

The Dread Pirate Roberts manager threatens people in a misguided attempt to motivate them.

This is the final post in this series on product management anti-patterns. While it seems outrageous, and maybe amusing, I can assure you it is not the least bit funny to the people who suffer under it.

SPOILER ALERT.

In the book (and movie adaptation) The Princess Bride, there is a character called The Dread Pirate Roberts. Another character, Westley, is captured by the Dread Pirate Roberts. Every night, the Dread Pirate Roberts says to him: “Goodnight, Westley. Good work, sleep well, I’ll most likely kill you in the morning.” The Dread Pirate Roberts never does kill him, but this goes on for three years.

END SPOILER.

Dread Pirate Roberts

The character in the movie is fantastic and likeable, but if you analyze their behaviour, much of it is deplorable. This scene is so memorable that I have named this particular anti-pattern after it.

There are some product managers who think this pattern is a good tool. “We can’t let people get too comfortable, and there is nothing like a threat to motivate them, right?” Well no, fear is a terrible motivator. You’ll get a minimal level of compliance, but you will not motivate people at all. In fact, you’ll do the opposite and demotivate people. (You might also might end up being disciplined by HR, or by legal authorities if you do this.)

Here is an example.

I was helping a software company with some process tuning and advisory work. I would drop in for a couple of days a week and help them with whatever came up. They had created a new team to work on emerging technology, and they worked independently from everyone else on a brand new product line. It was an experiment to try to jolt some new thinking into a company that was resting on past success a bit too much. They had assembled a young, inexperienced but highly talented and motivated development team. They also had communications, marketing, PR and visual designers from the rest of the company working on the same floor. The office was in a gorgeous brick building that was a former factory and it was warm and inviting. The team used an open environment that practiced hot-desking, meaning no one had assigned space. You arrived, plugged in your laptop into a docking station, and claimed that space for your own that day. The next day, someone else might be sitting there, and you would find an alternative.

The development team had staked their claim on one side of the office and found it more productive to sit together. They would pair, diagram, brainstorm or play with nerf guns or have foosball tournaments to ease some stress. The marketing, sales and PR folks claimed another area on the other side of the office. The kitchen was closer to them, and they laid claim to a couple of vintage arcade games for stress release. Everything else in between was a free for all. There was a bit of an empty gap between the teams, but they tended to sit closer or further away depending on what they were working on, and there was a lot of positive energy and good natured joking.

One day that all changed for the worse.

I walked into the office that morning and instantly felt tension and stress. Heads were down, conversations were short and hushed, and the product owner had stopped working in the dev area and set up shop on the other side with the marketing ands sales people. The visual designer dragged herself into the office, clearly fighting the flu. Normally she would have spent the day in bed or worked from home. There was nowhere else to sit, so with reluctance, she set up near the developers. A mountain of kleenexes began to build around her and there were copious amounts of hand sanitizer being used by by everyone else. She looked nervous and afraid.

When the daily standup started, the individual reports were short, guarded and the usual joking and camaraderie was completely absent.

The product manager had returned that morning from a two week trip out of town visiting various client sites. Obviously, they had done something to throw off the team. Whatever they had done was clearly having a negative effect on productivity. The build server was quiet and when I checked the feed for source control, there wasn’t the usual pace of checkins. When I checked the productivity software, stories weren’t moving through the process like usual.

This was odd because they were self-organizing team with strong DevOps practice and they usually pushed several builds to a staging server every day. There was at least one production push per week that included bug fixes, new features and other things that customers and stakeholders were interested in.

Over the next couple of weeks, there were no pushes to production. I monitored source control and build machines, and found code check-ins to have slowed down considerably. The quality of conversations on new designs lacked the creativity that they did before, and the product owner would only show up briefly to clarify or discuss an issue, then would scurry back to the other side of the building. Everyone got sick because they were stressed and working too much, and they would struggle to work from home, or drag themselves in to meetings.

I couldn’t get much out of anyone other than “Talk to the product manager”, so I made sure to track him down. I asked what was going on and that I had noticed some changes with the team. He explained that senior managers weren’t happy with the team’s productivity, so he called a team meeting and threatened them. He told the team that he had picked each of them for this project, and he could easily get rid of them and replace them with other people who were coming off of other projects in the company, or hire new people. He had created this team and he wasn’t afraid of tearing it down and starting over if they didn’t start working faster.

“Are they afraid for their jobs?” I asked.

“They should be.”

Wow.

You can imagine my reaction. I tried to be calm and not ask if he was ****ing crazy, and if he really wanted the product to fail. Well, I did say it, but in much more diplomatic terms. The product manager told me he was directed by senior management to “put the fear of God in the team” and they wouldn’t relent. They understood it was killing productivity and it had a negative effect, but they were just doing what they were told.

The product manager felt the approach was drastic, but appropriate. When I also talked with senior management, they said they had no intention of letting people go, but if they feared for their jobs, they would work harder. No matter that people were so stressed out now that they were getting sick, no matter that productivity had plummeted, no matter that some team members weren’t even hiding the fact they were looking for new jobs, no matter that the development team had packed their belongings in boxes, waiting for the inevitable tap on the shoulder from HR. They felt that eventually people would work faster and do exactly what they wanted.

The opposite occurred. Productivity cratered, and people did get some work done, but the creativity, unique and amazing solutions disappeared. (There go some of your product differentiators.) After advising that this was abusive and not a suitable way to treat people, I left the project. It seemed that leadership were far more interested in feeling in control than creating a great product and having a productive, happy team. Their egos were stroked by controlling people, so that trumped everything. (This is likely why the Dread Pirate Roberts behaved the way he did in the movie threatening and toying with a captive.)

As you can imagine, the product didn’t succeed. Yes they managed to force compliance, but they created a weak imitation of their competitors’ offerings and it went in the market. People on the team left the project and most eventually left the company for more suitable working environments. (ie. non-abusive ones.)

As a team member, if you feel a constant threat hanging over you, you are going to feel fearful and not at your best. All this brain power is needed to deal with your fear and worry about what might happen instead of using that brain power for problem solving. It is horrible to experience. In fact, it is a form of abuse. People will respond to abuse in non-deterministic ways. ie. you have no idea how they will react, but it won’t be good. It won’t be good for the individuals, the team, the product or the company. It won’t be good for you either, if you are the abuser.

Threats and fear are tools that will enforce some level of outward compliance, but they are terrible motivators. Managers who think that they will increase productivity or get products or features out the door faster if they use empty threats are abusing their colleagues. Much like in the movie The Princess Bride, they may feel a sense of control and justify using empty threats. That was a movie though, in real life, pirate behaviour is abuse at best, and criminal at worst.

The Dread Pirate Roberts:

• Makes threats, either explicit or implicit
• Never follows through on said threats
• Believes in antiquated management theory (ie. that fear is a good motivator)
• Manipulates people to get their way
• Changes their mind all the time so you never feel like you can make them happy
• May deny making the threats when confronted, expecting you to doubt your own version of events. (Also known as gaslighting.)
• Is likely a psychopath, or is directed by one

In another case, I witnessed an accidental Dread Pirate Roberts, but the outcome was the same: demoralized staff who weren’t as productive as they could be.

I had worked with the CTO of a rapidly growing startup at a couple of other organizations. We weren’t close, but we had mutual respect for each other. He told me that their product teams needed some help, but wanted to make sure there was a good fit with me and the VP of Product at his current venture. The VP of Product was a big, good natured man, with full sleeve tattoos and a shaved head with a large beard. He looked intimidating, even though he was kind hearted. He played up the look, wearing black t-shirts, designer work boots and a wallet on a chain. He joked that he was the king hipster of the company. He had a loud voice and a loud laugh, and because he had a nagging shoulder injury, he frequently crossed his arms when talking or listening.

The office, like many software companies, was dog friendly, and he brought his Rottweiler in to work every day. The dog was large and imposing, but quiet and would stare at people. Since it didn’t have much of a tail, it was hard to tell if it was happy to see you or not. It silently followed him around. It was an intimidating creature, especially if you weren’t used to dogs.

Prior to working at this company, I had heard rumours of this “big biker type VP” who would walk around the office with his dog yelling at people. I chalked it up to campfire project horror stories that programmers tell to scare each other. When I met with him and other leaders, I didn’t find him intimidating at all. He was open minded, kind hearted and quick to laugh. Reputations usually have a grain of truth to them though, so I was wary.

It seemed like a good fit, so I was brought in initially to help with User Experience (UX.) The UX folks had done a fantastic job, but the VP of Product had decided to forgo usability testing prior to shipping. The CTO asked me to come in and do an expert review and a heuristic evaluation. My work product was a report, and I made a few recommendations. I was careful to back up all the recommendations with at least two citations from UX experts. The UX team loved the report (I independently verified their concerns), but I was a bit worried when a nervous CTO told me to be careful, the VP of Product might need to be “treated delicately”.

The next morning, the VP of Product marched into my office, with his dog right behind him. His huge frame filled my doorway, and he threw a printed copy of my report on my desk and started yelling at me. His dog peered from behind him, and it felt like the dog was scowling at me too.

Picture in your mind a large, slightly heavyset man with a trucker hat, large framed glasses, Harley Davidson t-shirt, full sleeve tattoos with crossed arms yelling at you. His mouth was open wide and his large beard was wagging. Not to mention both he and his large, intimidating dog are blocking your only exit.

The horror stories were true! I was witnessing it in person. I could hardly believe it and I almost burst out laughing at the absurdity of it.

I can’t remember everything he said, but I got the gist of it: my report was garbage and he was going to rip up my contract and send me on my way. Once I got over my initial shock, I told him that his behavior was unacceptable, and I wasn’t going to put up with it. That escalated the situation, so I invited him in (so he wasn’t blocking my exit) and I asked if he would sit down. He declined, but he did at least come in to the office and loom over me. I was rescued by a call on his mobile, (which he took and talked at length in front of me) and that seemed to calm him down. When he returned to me, I distracted him by asking about his tattoos. Eventually, we found some common ground, had an awkward conversation about tattoos and then he picked up the report he had thrown on my desk and walked out. The dog gave me a look over its shoulder as it trotted after him. I almost felt like it was trying to get in the last word and give me one last scolding.

I’m not easily intimidated, but it was an incredibly unsettling experience. As a consultant, I had a lot of power and could walk away. What about employees who weren’t used to people who dressed and acted this way? What about subordinates or others who felt they had to do what he said to keep their jobs? This would be frightening to endure.

I immediately walked to the CTO’s office and told him what happened and that behavior was completely inappropriate. I said I would not work in an environment like this. He agreed, and asked what we should do. I said we needed to meet with the VP of Product and see if there was a way we could deal with conflict in a more healthy way.

The next morning I met with both the CTO and a now contrite VP of Product. We explained how his behaviour was intimidating, and that the threats, no matter how empty they might be, were distressing and abusive. We also explained that having his dog around while he behaved like this made it the situation worse. It was bad enough for us dog lovers. People from cultures that aren’t obsessed with dogs like North Americans are found it absolutely terrifying. He was shocked and visibly upset. He said he knew he had a temper problem, and that he was working on it. He said he had become angry because he felt that my feedback had criticized the product, and it was his heart and soul, so he felt personally threatened. When we explained that my job was to help the product be better, and not to tear anything down, and I asked if there was anything I could do to help with delivering the information so it felt less threatening. He said he had over reacted, apologized and asked for help.

As we talked, he told us that his father was a successful entrepreneur, and was a big “Theory X Management” believer. He felt that employees are inherently lazy, and need proper motivation to work for you. That upbringing had rubbed off on him, so he resorted to it at times.

In his father’s factory, in another era, it had worked. (Or so he claimed.) However, software companies tend to be egalitarian, and technical people prefer meritocracies. You might be able to yell and scream and get your way, but it isn’t the only factory in town. They can leave. Conversely, theory Y management works well in knowledge fields, where you assume people are intrinsically motivated, and with proper encouragement will work hard and thrive. He mimicked his father’s management style, and when you combined that with his large size, loud speaking, intimidating mannerisms (not to mention his large, intimidating sidekick dog), he tended to get his own way a lot.

He was asked to leave his dog at home for a while during office hours, and to not behave aggressively because of the way it made team members feel. If he felt threatened or angry, the CTO said to come into his office and talk to or yell at him first, if needed. Once the emotion was vented, he should then have the uncomfortable conversation with a peer or subordinate.

At first there was a dramatic improvement, and he really tried hard to adjust and grow personally. Eventually, he was able to bring the dog back to the office, but didn’t bring the dog with him to meetings or when he wanted to confront someone.

I would love to tell you that this story had a happy ending, but it doesn’t. Even though he said the right things, and seemed to sincerely want our help, he quickly grew to resent it. As time went on, the behaviour came back as his attitude soured. He had trouble taking responsibility for his actions, and while he would feel terrible after each outburst, he would rationalize it. He said that people knew that he didn’t mean it when he threatened them anyway, it was just his style. But not following through on threats is even worse than following through with something drastic. At least people know where they stand and what to expect. Furthermore, empty threats cause people to lose respect for you and your ability to tell the truth.

He was eventually forced out of the company, and it took a terrible toll on him afterwards. This was a case of someone really needing to grow up, it didn’t seem like the behaviour was intentional. His motivations aside, the company rightfully saw him as a liability, and got rid of him. Sadly “the Veep with the dog who yells at people” story was spread by every employee who left the company. (And for a while, there were a lot of people who did.)

I don’t have much to say about how to deal with the Dread Pirate Roberts product manager, other than to run away when you encounter it. Unlike the movie (or book by Goldman), I have yet to witness a happy ending. (Sorry for the spoiler.) I have seen this sort of abuse many times, and it never ends well for anyone. If you’re a product manager and you ever feel the need to threaten someone, don’t. Just don’t. Stop yourself and do something to distract yourself to get yourself under control. Take a walk. Count to ten. Drink a glass of water. Go home for the day and collect your thoughts. If you do this regularly, get some counselling and take a courses on managing people.

Bottom line: this behaviour is abusive and you should never do it, even if directed to by someone else. It isn’t worth the cost to the person you threaten, and you’ll not only destroy the people who you inflict it on, you will eventually destroy yourself and your reputation.

In part 1 of this series, we looked at the underminer product manager. In part 2 we talked about the dinosaur. In part 3, we looked at the erratic driver. In part 4, we will look at the micromanager.

A micromanager refuses to trust other team members to do their work properly. Micromanagers can’t let go of their projects, and don’t give people enough time and space to complete tasks on their own.

This is the most challenging management anti-pattern to write about because it has been talked about to death by people a lot more qualified than me. However, it is so common on software teams and so destructive that it needs to be addressed. While micromanagers are often concerned about positive project outcomes and making team commitments, their behavior has the opposite effect of what they intend.

I repeat: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND.

There are usually two different kinds of micromanagers:

1. Outcome obsessed. They are overly concerned with budgets, timelines, resources and logistics
2. Insecure. They are distrustful, lack confidence in their own abilities and project those feelings on to others

Early in my career I worked with two very different product managers: Mike and Jenn. Mike was a micromanager, Jenn was not. Both were programmers who were put in charge of their own products. They had developed new product prototypes on their own, and after there was sufficient customer interest and company buy-in, their job was to manage the product overall. That meant they talked to customers, did work on research, assisted with pricing models, and helped oversee product development and lifecycle management. It also meant they had to win over team members who worked on cross-functional teams to commit to working with them.

Mike was charismatic, an effective communicator, and had an overwhelming positivity about getting projects done and out the door. In brainstorming meetings, if someone said “it can’t be done”, Mike was the first to disagree and offer to try. He usually failed, but his efforts would inspire the team to figure out that there was indeed a way forward. Without his fearless efforts and inspiring manner, many useful ideas would not have been pursued. Mike was able to inspire others, and get them on board with his ideas, so he had a lot of initial team support for his product. However, he took any kind of criticism deeply personally, and would argue with people who didn’t appear to agree with him.

I was part of a small technical team assigned to both products, and we were closing in on shipping a version 1.0 of both within weeks of each other. It was hectic, and we could also be called in to help with customer concerns or high risk production issues at any time. The team was quite diverse; there were eight of us with different backgrounds and various levels of industry experience. It was up to the product managers to negotiate our time (within limits) and we had a senior project manager overseeing tasks and budgets and logistics. We were using two week sprints, and the project manager would meet with each of us at the end of each week to get a sense of where things were at and to see if we needed any help. The rest was up to the product managers.

Jenn worked on her own deliverables, and had publicized, daily office hours when we could stop in and ask questions without scheduling a meeting. She also wandered around and talked to each of us individually at the end of each day to see if we needed help. She let us determine the length and frequency of daily standups. Mike was militant about the daily standup, but the meeting would run over time because he would question absolutely everything anyone said. Mike also wandered around to check on us, but it felt like he was never not around. He would walk up behind us, stare at our screens over our shoulders, and ask what we were working on right then. He would then second guess our decisions, and argue with us.

At the end of each sprint, Jenn held us accountable for our commitments, and if we missed something, she would step in and help us adjust. If we felt we weren’t going to meet a commitment, we told her immediately, and she would work with the team to help us get back on track. Mike on the other hand held long, painful sprint demo meetings that could last for hours, mostly with him expressing disappointment in what we had done. We told him that he was getting in the way, and he needed to give us some protected time to actually deliver something instead of interfering all the time. He kept insisting that it was his ass on the line and that was that.

The micromanager:

• second guesses everything
• is distrustful of team members skills, their decision making, and their use of time
• never seems happy with anything you do
• focuses on the small stuff and loses sight of the big picture
• complains about people arriving late, leaving early, and taking too much time on breaks
• seems obsessed with up to the minute statuses
• loves heavyweight processes and lots of documenting of everything
• requires a lot of time entering and justifying time spent on tasks
• obsesses over measurement tools and metrics
• spends excessive time working and insinuating themselves in as many meetings as possible
• causes people to feel like someone is always watching them over their shoulders

As time went on, and Mike’s product was losing out to Jenn’s for time, focus and attention, his behavior worsened. We did everything we could to try to talk to him about it, but nothing seemed to help. Finally, out of desperation, all eight of us added an “arguing with Mike” item to our timesheets. After a week, the project manager came marching into the office to ask what the hell was going on. Why was there an “arguing with Mike” item in our timesheets, and why was there a team average of 8 hours per day being spent on it? It turned out that each of us were averaging at least an hour a day dealing with his micromanaging behavior. That averaged out to 40 hours a week! It was an expensive waste of time. This triggered a senior management intervention, and they talked to Mike. He was upset with what we had done, but understood we had run out of options. Eventually, his project was so far behind, he lost funding and Jenn’s project shipped. He was given two more opportunities, but in spite of a lot of senior management support, the behavior persisted and he was demoted and let go. Mike’s efforts had the opposite effect of his intentions. What went wrong?

There are some important negative outcomes of micromanaging to be aware of. First of all, when you don’t allow people the freedom to make decisions about at least some aspects of their work, they’ll be afraid to be creative and their work products won’t be as good. When they feel that you don’t trust them, they will resent you and will only do the minimum required. If they feel that you are counting every minute they spend on a particular task, and how long they stay for the day, they will count every minute they spend on your projects. When they have finished counting, you won’t get a minute more of their thoughts and efforts. If you second guess their decisions, they will lose confidence in their own abilities. When you measure at the micro level, you will miss the important things, like deadlines, budgets, key feature deliverables and even shipping the product itself. The last point might seem counter-intuitive – if we are really concerned about deliverables, budgets and timelines, won’t micromanaging help, even if people don’t like it? The answer is a resounding NO!

Measuring the small stuff causes everyone to lose sight of the big, important stuff, like features, deadlines and budgets. There are only so many hours in a day, and of those, only so much time where people can focus on project logistics. If you spend all that time worrying about things on the micro level, there won’t be any time to work on the macro level items. Furthermore, if you measure people at the micro level, they may deliver, but it won’t be in alignment with the rest of the team. They (and you) will lose focus and you’ll have what I call a “bucket of features”, but not a cohesive product.

The human cost is brutal as well. You will have people who only work for the time they are paid for, will be unable to be creative, won’t think about problems on their own, and will be worn out and fearful. Most of your team will actively look for another job. Creative people who are outspoken will at first display anger and find another job as quickly as they can. People who have more responsibilities and others depending on their salary will stay longer, but they will shut down and only do what they are told. Team morale will plummet, and you as a product manager will have to work ten times as hard to get anything out the door.

I’ve worked on teams that were dedicated, creative and had great cohesion and were in alignment with senior management, only to have a micromanager join the company. One example was a cutting edge startup that was well capitalized and was on a huge growth trajectory. I helped them with some basic growing pains, and it was a great place to work. People arrived early, stayed late, and the place was a constant buzz of energy. They loved their work and to be at the office with their coworkers. The problem was that people were doing too much, so they had to put in rules about how many hours a week you should work (so you could rest and be refreshed and productive) and to take your vacation. Employees still researched on the side, and took online courses to learn more to bring to the table. There was a quicksilver of creative problem solving that was infectious.

Six months later, I returned. The once bustling, busy office environment was quiet as a tomb. Management complained that people only put in minimal time and effort. The lunch room and break rooms, once hubs of knowledge sharing and teamwork were dead zones. People would rush in, get what they needed and leave. No one arrived early, and no one stayed late. (NOTE: This can be abused too, so don’t expect people to work overtime for you without pay. When people want to spend a few minutes here or there extra, try to reward them for it.) Productivity was down, and senior management had to put in a lot of overtime and have a lot of meetings to repeat goals, and supervise product development. A bit of investigation revealed that they had hired a micromanager and put them in a significant position of power. One project that year shipped on time. Product quality suffered, clients got upset, and staff turnover went through the roof. On some teams, people would stay for an average of three months. It was horrific to witness. One bad hire ruined the company and they never quite recovered.

What do you do instead?

• give people enough time to meet deliverables – days, not hours
• leave people alone to get stuff done! (unless they need help)
• be visible, available and encouraging in case they need to ask you questions or need encouragement
• make lost time due to micromanagement (especially your own) visible
• empower people and trust them to do the right thing. Just because they do things differently than you like doesn’t make it wrong
• people make mistakes. If they are honest mistakes, use them as learning experiences, don’t hold a grudge.
• pick battles: live with some outcomes that you may not like, but move the process towards shipping instead of nitpicking
• measure value points at a higher level such as features delivered, products and services shipped rather than individual tasks
• hold people accountable for missing their commitments and make it visible so everyone knows where the project status is
• succeed as a team, fail as a team – don’t single people out unless it is required due to performance issues, attitude problems, and do that in private

More recently I was asked to help a team that was struggling with delivering software for a new client. This was a startup that was well funded, but the CEO was worried about team performance, so I was called in. Dave, the CEO, had hired experienced developers and an experienced project manager. The team was very small and deeply experienced, so the first red flag to me was that they needed a project manager at all. Dave and I had worked together in the past, and while he saw the value of a product manager, he decided to also play that role to save money. Dave read articles about product management, and took a short webinar on how to be a product owner on an Agile team. He did his best, but he knew something was wrong – they had been working on a 3 month project, and 6 months in, they had nothing to show for it.

When I arrived as a product management consultant, the project manager was on the way out. The programmers had resorted to working from home as much as they could, in spite of having a well appointed, modern work environment that they had designed for themselves. Any meeting of three or more people would devolve into arguments that were unhelpful. Any meeting of two or more people would catch Dave’s attention (he had a nice office with glass walls, and faced outwards) and he would swoop in, eavesdrop, and then start to get involved, no matter the topic. Daily standups were no longer held in the dev area, they had moved to the boardroom with everyone sitting down. This was because every person who spoke up and reported what they were working on, what they had accomplished and if they were having any problems were grilled by Dave. It took far longer than a few minutes. To cope with this,if you didn’t want to be grilled, you didn’t say much. Also, if you didn’t do much work at all and kept a low profile, you flew under the radar and were spared. (Result? Several people were doing little to no real work for fear of reprisal.)

Dave was a type-A personality extrovert, and he was working with mostly introverted technical people. They needed protected time to be productive, and he needed to talk to people to think. Anyone that was sitting quietly that caught his eye would fall victim to a chat. Dave didn’t realize that the programmers needed protected quiet time to be productive. It was even worse when they were pair programming. Dave’s efforts had the opposite effect of his intentions.

This required a major intervention, and I wasn’t sure if it would work, because it meant Dave had to go through some personal growth. I would too, by virtue of working with him and both of us solving this particular problem together. I was willing, Dave was willing, but were we both able?

The first thing I did was create a product roadmap. Dave felt it was an unnecessary expense since the team was small, and they were already behind schedule. Why would I spend the first few days on that? But, he trusted me, so we worked on it together. Once we had that squared away, and the team agreed with the vision, I implemented a simple project management system. We used spreadsheets to create a product backlog and sprint backlogs. We only used the project management software they had been using for bug reports and high level features. We created a status dashboard on a whiteboard, and since the team was now a bit distributed, we re-created it in a spreadsheet that everyone could see.

Dave was banned from standups until he could learn to be an observer, not an active participant. He was also banned from engaging with staff who were working, unless they initiated it, or were in a break room or the lunch room. If they were at their desk, unless it was an emergency, they were to be left alone. If he needed to talk, he had to talk to me first. We also recruited a couple of his peers that he trusted deeply to stop in or call him more frequently so he could talk through ideas and get what he needed.

Next, we prioritized features and tasks, and the programmers made their own commitments for them. They decided a two week sprint was adequate, and signed up for an ambitious set of deliverables to demo at the end of that sprint. I was skeptical because it was so ambitious, but I kept my thoughts to myself. Dave was also skeptical, because he wanted more. Thankfully, he kept that to himself (and me of course.) I also told him to back off for two weeks, and if the deliverables weren’t met at the end of that sprint, then we would be worried. People needed protected time where they actually had a chance of delivering. We empowered them to make their own decisions, and to come to us if they needed help, but they were on their own. I would be visible and available, but no one would hound them anymore.

This was INCREDIBLY hard for Dave. He constantly backslid, and he would pull me into his office or phone me several times a day. I sent him daily status reports using a template for client billing, and he would phone me immediately after I sent them with lots of questions. But after a few days he settled down and decided to trust the process.

I’d love to tell you that at the end of two weeks the team delivered and everyone was happy, but that was not the case. It was a mess. There was nothing tangible that was delivered. Two team members realized they were in over their heads and resigned, and one engineer was put on probation for poor work and was eventually let go. Dave was furious at first, and told me he wanted to fire everyone, but after sleeping on it realized where he had gone wrong. His constant micromanaging had hidden skill gaps, and there were no real methods of accountability. He went from one small problem to another small problem, and people didn’t sign up for anything, didn’t commit to anything, and he had no way of measuring real progress. Micromanaging actually destroys accountability. With the simple, yet visible system we used, problems related to product development became apparent almost immediately. People signed up for their own commitments, and if they failed to meet them, it was visible.

The team was in crisis, and Dave knew they were in serious trouble. If they didn’t meet this commitment, they would have no revenue growth and would likely go under. However, instead of panicking, he rose to the occasion, as did the experienced senior team members. We managed to recruit a couple of expensive, but skilled consultants to help address the skill gaps, and we got it done. The product was gorgeous looking (we had a fantastic visual designer), but it barely worked. However, the client loved the first version, and it was good enough. There was an enormous amount of refactoring that was required, but it got the job done. Revenue trickled in, board members and angel investors were appeased, and the company lived to fight another day. One of the consultants even stayed on to work full time with the team because they enjoyed the work and technology so much.

Eventually the team were able to go back to the process they had been following in the past, and left the spreadsheets behind and mirrored that functionality in their productivity tools. It was harder for Dave to adjust. He went through a lot of painful personal growth, but came out the other side as a much more solid leader. After the fact, he shared with me just how difficult it was, and how he had to resist his initial instinctive reactions. A couple of board members and trusted advisors answered his call for help and really helped him through some tough times outside of the office. It took a long time for him to regain trust in the people, the team as a whole, and the process. I urged him (and still do) to measure outcomes that demonstrate value, (such as working features, products and services) rather than on tasks. That way, the team can excel at doing what they do best, and he can be involved and completely focused on the incredibly difficult job of CEO. (Yes, he did hire a product manager to delegate to, and project management is shared among senior team members.)

Mike was a product manager who was insecure and unable to go through personal growth to become a good manager. Dave was an outcome-obsessed leader, but he still had to go through painful growth. The Mikes of the world have talents outside of leadership, and that is fine. The Daves are usually fantastic leaders, but need good creative product builders. Mike went back to being a creator rather than a leader, and had much better success. Jenn was a unicorn who could switch between technical and leadership roles – they do exist.

There is a lesson here for all of us: all of us will have elements of dysfunction in our leadership approaches and personalities. When under extraordinary stress, these will become much more apparent. When we feel pressure and the team doesn’t seem to be responding the way we’d like, it is incredibly tempting to micromanage. But remember: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND. All of us need to take a cue from Dave from time-to-time and deal with our weaknesses head on, for the good of the team, and most importantly, for our own good.

Note: I first wrote about the micromanager management pattern in this article for Agile Connection.

In part 3, we will look at the erratic driver product manager. In part 1 of this series, we looked at the underminer. In part 2 we looked at the dinosaur product manager.

The erratic driver is a leader who either can’t make up their mind, can’t stick to a plan, or both. This disrupts the work of others, hurts productivity, and threatens schedules and team commitments. Team members may work on items that are subsequently rejected, or they may spend precious time waiting for decisions that aren’t forthcoming instead of producing key work items.

There are usually two types of erratic driver product managers:

1. A visionary who thinks ahead and sometimes struggles to stay in the present, consistently disrupting the team with new ideas
2. A manager who lacks confidence in their own decisions as well as others

The first erratic driver tends to be easier to deal with, but both can do a lot of damage due to their behavior. The first place they do damage to is the product itself. When they change their minds a lot, the vision and value proposition of the product gets muddied and lost.

The second area of damage is to productivity, and scheduling goals. Since they change their minds and second guess the work and commitments teams have agreed to take on, there is a lot of duplicate effort, wasted effort, and plain old waiting around for someone to make up their mind.

On one team I worked on, the head of product had a reputation of approaching software development the way 5 year old children approach soccer (or football depending on your locale.) They start off more or less together, and then things quickly fall apart. Sometimes they chase the ball, sometimes they chase each other, sometimes they move the ball down the field, sometimes they try to score, or defend. Sometimes they even try to score on themselves. Many times, the ball is forgotten by all the players when something interesting and shiny appears to distract them. It’s entertaining to watch, but not very effective at reaching goals.

The head of product oversaw several products and services, and fortunately, each of the product managers that reported to him were shippers. They worked hard to get great products out the door consistently and effectively. Each product manager had a good balance of domain knowledge, market knowledge and technical skills. That meant that the teams they worked with were productive and effective and were able to get things done, but when the product lead changed their mind, they would be undermined and foiled. This company was well funded and had a great pool of talent, but there are always limits on people, resources and logistics. However, depending on the whimsy or stress felt by the head of product, priorities would shift. Needed resources and people would be pulled off of one project and assigned to another. Marketing and sales campaigns would be put on hold, with others suddenly requiring strategy and copy. Progress would start on the new initiatives, stop on others, and productivity would shift to other groups projects. Repeat this on a cycle of 2-5 weeks, and you should be able to predict the outcome.

None of the products or services were ready at the times they needed to be. That meant sales suffered, and the credibility of the company suffered with not only existing customers, but also with potential customers. The company eventually gave up their technical leadership credibility in the market as well. They were surpassed by competitors who were better at managing schedules and were able to honor their public commitments.

A bit of investigation revealed that the head of product lacked confidence in their ability to make decisions, and was easily influenced by powerful stakeholders. In fact, they would misinterpret senior management brainstorming ideas or even misinterpret their moods as directives for the project. That meant that decisions were delayed, overdue, and changed frequently. Not only were the technical teams impacted, but marketing and third party commitments with PR and tradeshow vendors were changed. The products would be late, 3rd parties would charge for work that wasn’t required, and everyone suffered. This problem could have been dealt with if the product manager had trusted their teams and listened to their advice, admonitions and warnings, but they didn’t have confidence in them either.

I worked as a project manager on one of their products, and we were able to create a visible process so that when the head of product changed their mind, everyone knew about it. In the past, information would trickle out to different team members at different times, causing a lot of confusion and needless effort. I also asked them to help me create some mechanisms to deal with their erratic behavior. (I was a bit more diplomatic in how I addressed it than written here.) I then set up frequent meetings with senior members of the team to provide the head of product to discuss concerns, and to shield the team from freakouts. We also created a process on decision making, and asked that any change in direction be driven by real evidence. We also assured the head of product that any success or failure was shared by the team, not one individual, and when required, one of us would step up and take responsibility for a tough decision when the head of product felt paralyzed.

This helped a tremendous amount. Unfortunately, since they were coming from a place of fear rather than fast paced visionary thinking, they did a lot to undo the process, even though they saw the value in it. We were constantly undermined, and our senior team members spent a lot of time trying to keep the team protected from freakouts and churn, reviewing decisions and work products over and over with the head of product, and dealing with other team members who were pulled off track. In spite of some success on our project (our project was the only one that shipped on time and on budget that quarter), the head of product’s track record was so poor across their entire portfolio, they were eventually asked to leave the company.

The erratic driver:

• changes their mind frequently
• overthinks options to solve problems or what to develop next
• delays decisions on tough problems as long as possible
• second guesses and over-rides prior decisions
• interrupts team members, and sometimes the entire team, pulling people off task by having discussions, or making pronouncements about changing direction
• disrupts team alignment with regards to product development
• has trouble differentiating between short term vs. long term goals and ideas
• confuses the team about timelines and priorities either due to indecision, or by getting excited about something new
• is unhappy with developed features
• wants the team to move faster (to keep up with their ideas)

How do you deal with an erratic driver?

• make decisions visible so everyone knows what is going on
• make project management visible so that deviations are spotted quickly
• use a process to manage work to reduce confusion about priorities
• provide realistic costs to changing a feature, or direction – when faced with the potential impact of change to productivity and schedules, that helps determine if the change is needed now, or is ok to do later
• make sure there is a product roadmap prior to signing on to a project
• use roadmaps to manage development priorities and planning to keep things focused and on track
• create a brainstorming roadmap to use with senior team members only for whimsical ideas or long term ideas with a process for promoting these ideas to the formal roadmap(s)
• provide a safe place for brainstorming and letting off steam, instead of randomly interrupting team members
• utilize user experience techniques to help remind us to focus effort towards customers, not by the turmoil in the leader’s mind

On another team, I worked with a visionary erratic driver. (Side note, many, if not most entrepreneurs are erratic drivers at least at some point. Their brains work quickly, they like to entertain a lot of ideas, and they are thinking longer term than where the team is currently at. It’s easy for them to be thinking years in advance, and they get frustrated when labour intensive efforts like software development can’t keep up with them. Learning how to deal with visionary erratic drivers is an important skill for product managers.)

This product manager had a rare gift of being able to identify unaddressed gaps in the market, and quickly come up with technology solutions to match. Once they put their mind to it, they could come up with very polished pitches to stakeholders and get people on board who shared their vision. They could almost effortlessly attract funding and willing team members to work with them. Unfortunately, once the team was settled in and getting productive, they would constantly brainstorm and share ideas for features that would be implemented down the road. They would get excited about these feature ideas, and the team would feel pressure to implement those brainstorm ideas now, instead of when they were intended to be developed. That meant that the evolving product was incoherent, and short-term priorities were often missed.

The product manager also spent a lot of time studying new technology, and would second guess prior technology choices when something new and shiny appeared. We were using JavaScript frameworks, which tend to go in and out of fashion faster than designer jeans. That meant the team was at times bombarded with new framework information, which pulled valuable efforts away from current development. Some team members worked on items agreed to and specified on the roadmap, while others strayed due to confusion and individual direction. As a result, demo days were dreaded because the product manager was always unhappy. “Why did you work on that?” “That isn’t what I wanted at all.” and “I didn’t mean for you to work on that now. were common.

The team was misaligned and frustrated, productivity suffered, and the end result was a product that was disjointed and difficult to use. I sat down with the manager and discussed their behavior and the corresponding team reactions, and asked if we could set up a system to help.

Once I carefully and as non-threateningly as possible went over the manager’s behavior, I suggested some process tweaks. I asked them to work with me on setting up a process for brainstorming whimsical or half baked ideas. The idea was to disrupt the team less, and to have a rule in place to determine whether the team members needed to be interrupted.

To help with team alignment and erratic decisions and work products being developed that weren’t focused, we formalized a product roadmap, with three sections listing efforts and associated priorities:

1. Current development
2. Near-term development
3. Future development

Next, to take technology decision churn out of the picture, we pulled technology out of the product roadmap, aside from high level goals, such as supporting mobile devices and using a modern framework with great user experience. We then tasked the technical team with making the decisions about technology, and helped them create a technology roadmap. The product manager could have input and was consulted, but the technical team were ultimately responsible for picking the right combination of technology to meet product goals.

To make the product manager aware of the cost of changing their mind, we worked with the project management process to make sure work was visible, and effort was accounted for. It was important for them to understand that whenever they change their mind, team members lose productivity and need to refocus before becoming productive again. Also, it was important that they understood the efforts required for new development, and what the trade offs were. If you change now, what are you going to give up? In addition to raw efforts that are required, team members also need to spend some time archiving their current work so it can be picked up later on, researching and getting up to speed on the new work tasks, and then getting productive again.

To help align customer needs with product development, we worked on incorporating field data into the process, so we set up formal weekly meetings with marketing and sales and PR. I helped the UX and graphics design team to come up with a review process for the product manager so they could approve designs prior to implementing them. We also created design documents that outlined style specifications for products such as fonts, colors, logos and other important issues. I then worked with the UX and design team to help them communicate their designs more clearly, and to add their needs and goals to the technical roadmap.

Finally, we set up a formal process for sheltering the team from getting disrupted by new ideas, creativity flashes and self doubt. We started with a weekly meeting among senior team members for brainstorming and sharing half baked ideas. From that, I created a spreadsheet where we would record the ideas the product manager wanted to keep, and we had a promotion rule. Ideas that were really far out were at the bottom of the list. If they were talked about again, they started to move up the list. If they were mentioned frequently enough, I would ask if they should be promoted to long term roadmap commitments. Often, the product manager would say no, but sometimes they would want the idea promoted and added to the near term. Any new changes during development were spelled out with associated effort and cost. That would also help determine if ideas for features or change were serious and needed to be acted on immediately or in the short term. We would review the list periodically, and some ideas from the bottom of the list would be removed.

Visionaries have hunches, and sometimes they need to bypass the process because they have good reason. That meant the product manager also had veto power, since they were ultimately in charge of the product. If they felt very strongly, they could stop work and guide the team in a new direction if they felt strongly enough. At first, they wanted to use this more often if they felt they weren’t getting their way, but once we would pull up the roadmap, discuss current commitments, and associated costs of change, they would back down. Sometimes though, they had a gut feel and felt strongly enough to change and deal with the associated costs. They were almost always right about these changes.

The product manager was uncomfortable with the process at first, but I asked them to respect it for one two week sprint, and see what they thought. After the first sprint demo, they were much happier, but were still concerned about delivering the software when they needed to in 8 weeks time. It wasn’t without hiccups and backsliding and issues. (I would find out about the product manager varying from the process and confront them about it, and we would adjust. Either they would adjust their behavior, or we would tweak the process.) However, we delivered in the time frame that was required, and because of the process, we had a much more focused, usable product that the product manager was happy with. The team met their commitments, and the process was formalized further and later coached and enforced by the product manager instead of me. Surprisingly, the UX and design team were the happiest with the outcomes – they got constructive criticism early, and had far less re-work after sprint demos.

Erratic drivers are incredibly common in visionary roles, and it’s important to learn how to work with them. Visionaries are able to marshal both the required resources and technology together to create new products. They have a rare gift. The downside is that they think quickly and are creative, and when they get excited about new things, they can infect others with that excitement. If it isn’t managed properly, passion and excitement can become distracting and destructive. Many company founders are visionaries, and early stage software startups are full of erratic drivers. While they are most common in new ventures, visionaries with erratic driver tendencies are found in any kind of organization. Good processes and solid communication are important to work on when you encounter the behavior. Some of you who are reading this might have erratic driver tendencies yourselves. If you are a product manager who is an erratic driver, start creating your own process to keep your activities focused on shipping great software, and safeguard against needlessly distracting or holding up work when waffling on decisions. If you ask for help from key team members you trust, they will step up and help keep you honest.

Note: I first wrote about the erratic driver management pattern in this article for Agile Connection.

In part 1 of this series, we looked at the underminer. In part 2 we will look at the dinosaur product manager.

A dinosaur is a product manager who is out of date, and they obstinately refuse to consider anything that is current. They have their model of the world, and they refuse to learn anything new. They might be out of date with any or all of the following: the market, competing products, their customer’s current expectations, pricing, monetization models, marketing and sales approaches, current technology and design trends.

Tyrannosaurus image from Wikipedia.

Of all the product management anti-patterns, the dinosaur is the one that I find to be one of the most painful to witness. As a technical product manager who works with new and sometimes cutting edge technology, I run into the dinosaur quite often. It’s painful to observe because you see all these people working so hard, and the team inertia is moving in a direction, yet one person is getting in the way. It sucks the life out of teams, and it’s also one of the most difficult behaviors to deal with.

Dinosaurs are people who for whatever reason have stopped learning. They have a specific approach and they are frozen there. Often dinosaurs are more experienced people who are fatigued with learning new technology, or they might be jaded after too many campaigns. Software is a tough, demanding business.

I get the learning fatigue. As you have more experience and have learned a lot, it is tiring to learn yet another web framework, a new set of productivity tools and yet another design paradigm. Right now I am learning some new approaches to mobile development, and a whole new templating engine for web applications using responsive design. It isn’t as much fun to learn as when I was new in the industry, and I have to fit that in between engagements and deliverables.

However, I have also met dinosaurs who had very little experience, but they have still chosen an approach and refuse to update their thinking.

Recently, two executives asked me to help them with a difficult problem at their company. They were creating a new product to expand their product line and steal market share from an emerging, lucrative market. Their existing customer base was maturing, and there were strong economic forces at play that they felt threatened current revenue streams. They didn’t want to get caught when an inevitable decline hit the market, so they were looking seriously at other sources of revenue that better fit emerging market conditions. They implemented a “20% time” for technical teams to spend time coming up with product ideas, held facilitated brainstorming workshops, and engaged heavily with their enthusiastic supportive customers and trusted industry contacts.

As usual, the problem they posed to me and the real problem were two different, yet related things. They didn’t say anything about the VP of Product Management, other than mentioning them in passing. In fact, they said the problem was an alignment issue between the experienced people in the company, and a young engineering team. The execs gave me the impression that the engineering team on this project were the problem here – they weren’t respecting the more experienced people in the company. But the execs said they would let me figure out what the problem was. All they wanted was a great minimally viable product they could start introducing to the market.

As I met with more people in the company, alarm bells started to go off. I didn’t meet the VP of Product, and it felt like people wanted to shut them out. Any mention of the VP of Product was met with a silent tension. When I met with the technical team, they seemed depressed and were checked out. They sauntered into the meeting with me, and most of them were late. The product owner was the last to arrive, and while she was pleasant and polite, she spent most of her time with her face buried in their smartphone. The lead engineer on the project took me through an abbreviated walkthrough of their prototype, and aside from some UX and design issues and some unfinished parts here and there, it looked solid. In fact, the fit with the market was obvious, and the technology had a lot of potential. I found it exciting, but the rest of the team were sombre looking and weren’t engaged. I started asking clarifying questions and they slowly started to wake up.

They had stumbled on a very difficult navigation problem, and asked if I had any ideas from my UX experience. I suggested looking at game design, because this sort of problem is well addressed in video games, but often poorly addressed in enterprise applications. After a couple of shocked moments, engagement turned to excitement. We brainstormed, some team members started researching compatible game engines, and looked for examples on the web. At the end of the hour, the team asked if they could extend the meeting further, and most of them were able to stay in the room with me. The frenetic pace of excited brainstorming continued for another 45 minutes, and then we realized we were all tired. The lead engineer wrapped up the meeting, and the product owner took me aside and told me it had been the best meeting they had ever had for that product. In fact, in the two years she had been in the company, it was the best technical meeting she had attended.

Next up was a meeting with the VP of Product. They had been in the industry since the early 1990s, and had seen a lot of past success. You can guess what happened next.

The VP of Product spent the first 15 minutes of the meeting name dropping and telling me all about their accomplishments. When they asked me a question, they interrupted before I could finish answering and began to berate me. This continued on for the remainder of the meeting – any time I spoke I was interrupted and ridiculed. When I changed tack and asked for a demo of their ideas, they showed me a PowerPoint slide deck with an outdated theme, and the product screen examples they had created looked straight out of the 1990s. With a bit of probing I found that they didn’t just treat me with derision and aggression, they were that way with just about everyone. It was obvious that a dinosaur was derailing an important product effort and potential new revenue stream.

I advised the executives of what the problem was, and you guessed it, they already knew. Instead of dealing with the issue, they were trying everything else but having a difficult conversation with the VP. The VP still had a lot to offer the company, but not in product management. They had hoped that a consultant would have some sort of magical solution idea that would get them off the hook, and would somehow get the VP on board.

In two other recent experiences, I have met inexperienced dinosaurs. Both were startup CEOs who had product ideas, and managed to attract friends and family investment to hire technical teams. They didn’t have product managers, and had decided they were going to play that role in their company to save money. They had immediately latched onto the first technology ideas that were presented to them, and refused to learn anything else. Unfortunately, in both cases, they had outsourced development to teams that were inexperienced and placated customers, and made complex, risky development efforts sound simple, quick to implement and inexpensive. Both of them approached me because they had spent a lot of money on solutions that didn’t make it to market.

They were afraid. Yet, in the face of losing their businesses, they refused to listen to contrary advice from people with experience and track records of shipping software. They clung onto their initial ideas and conclusions they had made a year or two ago, and refused to budge. This was likely a controlling dysfunction borne of easy wealth and the arrogance that can come with it. They were intimidated by people who understood technical things, even though they had hired those people precisely because they had technical expertise.

The dinosaur product manager:

• Believes in “one true way” approaches to marketing, sales, products and process. (This tends to coincide with their way.)
• Scoffs at new technology or pricing models
• Scoffs at design trends
• Makes fun of consumers who buy products or services they consider to be fads
• Talks more about “the old days” than being productive in the present
• Dismisses ideas that aren’t their own
• Makes fun of new technology environments
• Equates every new design, marketing or technology paradigm with one from the past
• Blocks efforts to update technology or architecture, even when when it’s needed
• Underestimate the risks, complexities and efforts of their solution ideas
• Reacts strongly to people with more technical knowledge, and especially more recent knowledge and skills than they have. They may be antagonistic, belligerent, use ad hominem attacks, or they may be passive aggressive and simply undermine them.

How do you deal with a dinosaur?

One of the most difficult things when dealing with experienced dinosaurs is that they are often right about a lot of things. They often express their ideas poorly, so it is easy to dismiss everything they say. Sometimes what seems like scoffing and denigrating behavior is simply an attitude problem borne out of harsh experience. The trick is to figure out when they are blustering due to fear, obstinance or unwillingness to change or if they are complaining about a valid issue. This requires patience and trial and error.

• Talk to the person, and ask them what is going on, and point out how their behavior can be damaging and misconstrued if it is well-intended. Ask them to work with you and help the team move towards something successful, even if it means compromising.
• Training and knowledge gaps are common, particularly with more experienced people. See if you can set up training or online materials to help them get confidence in something new and threatening.
• Set up a safe place for ranting and complaining about new models, even if they seem to be consumer or process fads.
• Play to their strengths and experience, and divide labor so that they have input and crucial parts to play in direction, but others are in charge of revenue models, marketing schemes, technology and look & feel.
• Have them do competitor analysis, and have them perform user experience heuristic evaluations and pricing research of competing products.
• Make sure they engage with customers who have differing views from their views and preferences
• Take technology, design and other decisions out of the conversation, and have them provide constructive feedback in a neutral way. Their concerns may be valid, and if so, they will be happy to abstract them and present them differently. If they are not valid, they probably won’t do anything but bluster.
• Let them win at times. A lost battle on a non-core issue is better than losing the war.
• Be consistent and patient. It can take a while for them to win respect of other people with new and different ideas, and to get on board with new ideas and approaches.

If the person is coming from a place of fear, most of the above points won’t really help. In that case it will likely require some repositioning of their work and power. Following a process that uses team-based decisions and approaches can really help in this case. In many of these situations, a hardline approach is necessary, because a team member who obstructs can kill productivity and hijack business initiatives of the entire company.

Ask the champion of the new approach to present their approach to the group.

Next, hear out any criticisms of the approach, because there may be valid points. A dissenting opinion presented constructively is incredibly valuable.

Then make it clear, once the decision has been made, that the decision must be supported by the team, and anyone undermining the position will be asked to leave the team. (Also make it clear that undermining behavior will be monitored and will not be tolerated.) Often people who appear to be on board with the decision will undermine by amplifying problems and use that as evidence to criticize the decision. Peter Block calls this “resistance through compliance” and it is insidious and dangerous in organizations.

Here are two dinosaur examples with different outcomes.

An organization had grown from a two-person startup to a thriving company with close to 100 employees. They had created an MVP, tested it in the market and attracted a lot of initial investment. Trouble was, the market changed drastically and suddenly. The product manager became a dinosaur, slavishly sticking to their initial idea. Their product concept and understanding of the market had worked for over a decade, but they couldn’t get on board with the new market reality. There were also a lot of retirements and younger people moving in to replace their existing customers. That meant that during purchasing decisions, younger people (who use a lot of apps on smartphones and are more fashion conscious) were brought in to provide opinions. A middle aged CTO might have a social media marketing person sitting in meetings analyzing the offering from their perspective. Their expectations were much different, but were taken very seriously.

The dinosaur product manager became more entrenched and combative, and taking any criticism (real or imagined) quite badly and personally. They became more isolated, and the rest of the team were realizing they needed some big changes. The dinosaur also hated any usability issues and was quite scoffing of UX practices. “Our customers don’t need something that is usable…” was often their response.

One Monday morning, the product manager came into work a changed man. We didn’t know it at the time, but the CEO, the CTO and a major investor/advisor had taken him out to dinner that Friday night. They asked if he wanted to continue being obstructionist, or if he wanted to work with everyone else to solve the problem? After all, the company and a lot of investor dollars were at stake, and his behavior wasn’t going to help the team. They had decided early on that the core members of the team would agree unanimously on decisions moving forward. To get unanimity meant that if a person was a lone dissenter, they would be asked to leave. The manager told me later on that the discussion hit him really hard, and he spent the weekend mulling over options.

He moved quickly once he made a decision. He immersed himself in new pricing models, spent hours with potential customers doing field research, and hired a UX expert and visual designer to help them create a new product. The results were dramatic. They turned around a failing product into a big seller, and they sold the company to a larger player in the industry for a tidy sum.

In another situation at a large, established company, a dinosaur product manager was stuck in her ways when it came to marketing and sales. That was one thing, but she also refused to allow the technical team to pay off technical debt through refactoring, and would rarely allow them to update tools and infrastructure. She was also, bafflingly, incredibly stubborn about the look and feel of their e-commerce site. It was six years old and really showing its age. Any UX improvement or change, no matter how small, was met with enormous resistance.

This was flat organization with an open environment, and anyone could suggest ideas for improvements or new revenue streams, and field reports were frequent. No matter what anyone said, she would argue against anything she saw as a threat. She would often literally frighten away younger employees who had good ideas based on observations.

Senior managers tried to work around her, then ordered her to help implement an add-on feature to help increase sales. She appeared to be enthusiastic when they were around, and made all the right noises, but she was resisting through compliance.

She didn’t understand SaaS style pricing models, and her views of pricing, marketing and sales were hopelessly out of date. The projected numbers were staggering, but every meeting she was involved with was a painful fight. A marketing designer described a particularly painful “pixel by pixel” review meeting of pre-release marketing designs that took hours. Everything seemed to be painful, took way too long, and people asked to leave the project in droves.

Since the team was moving one way with executive directives, and that didn’t suit her outdated ideas, she actually hijacked efforts to secretly develop the solution the way she wanted. Part of the team at any given time were also working on her competing ideas. We found out because there was an anonymous tip about this from an abused employee to a politically powerful person. Her revenue model was so outdated and wrong, the legal department got involved and sent out a cease and desist warning internally. She continued in her undermining and obstructionist behavior, so she was let go. After she was gone, the teams moved quickly, and after 9 months of fighting, implemented the new feature with a completely new redesign in 3 months.

Avoid Dinosaur Behavior

It’s easy to fall behind in a massive industry that is constantly changing. It will happen to all of us eventually. The important thing to remember is that no one knows it all, and it’s ok to say: “I don’t know.” Very few people will look down on you for not knowing something, and if they do, they aren’t worth paying attention to anyway. Here are some tips:

• Stay current by reading industry news, a little bit each day
• Talk to your customers and ask them about problems that haven’t been solved yet, and about other applications they like to use
• Study User Experience and keep abreast of developments in that field
• Aim to be a lifelong learner
• Take online training courses. There are a lot of free and inexpensive courses out there that allow you to work at your own pace
• Attend conferences, workshops and local events in your community
• Delegate to people who are more current than you are
• Check your attitude – are you resisting change, or is your discomfort due to a deeper, important issue that needs to be addressed?

Any new revenue generating, marketing, design or technical change will involve problems and stumbling blocks. There will be fear of the unknown, resistance to change, and there should also be healthy dissent. In fact, any decision without some healthy dissent will likely be a poor one. The trick is to not let the dinosaurs hijack decisions or turn teams away from new initiatives just because they stopped learning and don’t want to help anymore.

In part 1 of this series, we will look at the undermining product manager. The underminer is a manager who says one thing to your face, and does the opposite behind your back. Underminers may also sow seeds of doubt about your competence to others on the team.

Disney’s “The Incredibles” image from Wikipedia.

When product management goes well, it has a big impact on the success of a project. Product managers help get alignment between technical teams, business teams, and end users. They can help teams deliver a polished product/service instead of a “bucket of features” that are packaged together at the end of a release. Great product managers can help teams build the right product, at the right time, at the right price.

But poor product management can cause a lot of problems. Instead of having a positive impact, they can detract. When product managers persist with unhealthy behavior, they can derail projects, demoralize team members and destroy productivity.

Recently, a colleague approached me because they were having misgivings about a new product manager that had joined the team. The team saw the value in the role, and had hired their first product manager. After the initial adjustment of adding a new team member, they were expecting some positive outcomes, but instead, technical leadership were very concerned. They asked me if the behavior they were seeing was normal for a product manager. What they described might be normal, but it was certainly dysfunctional. I was reminded of an article I wrote a few years ago on management anti-patterns so I decided to revisit that content but with a product management slant.

An underminer is someone who says one thing to your face, but does something else (often the opposite) when you aren’t around. Underminers might be motivated by their own agenda and wish to circumvent current plans and work items. If they want something else worked on other than the current work items, they will go from person to person until they find someone who will agree with them. People will often quietly work on items that aren’t being accounted for at the request of an undermining product manager, which skews team efforts.

The undermining product manager:

• Doesn’t respect estimates and timelines
• Doesn’t respect team decisions, particularly with regards to product direction, milestones and priorities
• Gossips about team members when they aren’t around
• Second guesses decisions behind other team member’s backs
• Goes from team member to team member until they find the answer they want
• Agrees with you or the group, then does something contrary to the shared decision when they think no one is looking
• Constantly blames other people, other groups (and you when you aren’t around) for any fault, real or imagined
• Seeks out allies to work on items secretly, and to also engage in all of the above behavior

Underminers are destructive because they ruin productivity, create distrust among team members, and weaken the credibility of the people they disagree with.

In a product management role, they are especially destructive because they ruin team alignment and shared goals, which is an important aspect of team success. Sure, once in a while you have to make an unpopular decision or work with some people in private to get things done, but that work still needs to be transparent and working towards shipping the product. In fact, many times a product manager makes an unpopular decision because it helps with goal alignment and ensures the team stays on track. An underminer doesn’t share the goal of shipping software in the manner the team has agreed to do already. The resulting toxicity caused by an underminer also kills individuals’ intrinsic motivation to work on a project, which is a primary driver for our work.

Underminers are motivated in different ways. Sometimes product managers are directed by powerful stakeholders who feel they aren’t getting their way, and that the technical team aren’t listening to them. Instead of dealing with this head on, they prefer to have a plant or someone on the inside who is doing their bidding secretly. In other situations, a product manager may read (or misread) the political tensions in an organization and feels that if they show some initiative and push the team in a different direction, that will lead to their own success and a promotion or similar reward. Still others are in a position that is beyond their expertise, and they are desperately trying to find some control, or deflect their lack of skill by putting focus on others.

Underminers are horribly toxic for teams (and companies) because they are good at marketing themselves to powerful people in the organization, and are quick to take credit when something goes well. Once they have built up enough credibility, they also shift blame onto other team members who can become vulnerable politically through no fault of their own. This means that the people with the most power are the last to see through the undermining behavior. By then, the damage has already been done. They also cost the team a lot of extra money and lost productivity in frustration and a lack of alignment. A project will need to draw on more reserves than initially budgeted due to their behavior, and many won’t survive.

How do you deal with an underminer?

• Make your process and decisions visible to all stakeholders. When something subversive is going on, it should be obvious.
• Utilize project management tools for visibility on individual’s work. Daily standup formats are good for this. If people are working on something other than what they have agreed to work on, it should be visible quickly.
• Ensure team members approach the rest of the team if someone asks them to do something off the record to get their approval.
• Make people accountable for not working on what the team has agreed on. Often a little public Q&A is enough to get people to realize what they are doing is inappropriate. If it persists, deal with it as an HR matter.
• Do not tolerate gossip, blaming or calling people’s work or decisions into question. Foster a culture where people stick up for each other. When undermining starts, it should be obviously different from the norm and discouraged.
• Bring business and other stakeholders into the process so they feel included, and address their concerns in case they feel the need to subvert. When they do, deal with the issue head on and ask to work on a solution other than someone who will cost the team more money and threaten the success of a project.
• When you discover an underminer who is unrepentant, fire them when you have enough cause.

The underminer is so deadly, not only will a team miss their shipping targets and go over budget, the team will lose confidence in each other, and the organization. I’ve seen teams start to falter and people start to spend their time looking for a new job after two weeks of an undermining manager appearing on the scene. They are nasty, and it’s important to screen for this sort of thing when hiring.

It’s also important to examine our own work and habits as product managers on a team. While we may not intend to undermine, we may exhibit these behaviors from time to time. It’s a good idea to have personal retrospectives periodically, and when we catch ourselves exhibiting underminer habits to take immediate action to correct them. If we are under stress or feeling frustrated with the progress of the team, we can easily fall into this sort of behavior. All it does is detract, so we need to police ourselves whenever we are tempted.