A Solid Launch Consulting

Successful Leadership Comes From Leaning Into Your Own Style

team communication

Include Your Whole Value Chain from the Start

by

We need to gather input from the teams down the length of the entire value chain.

As an IT/IS project manager, I am often involved in the selection of business software. The RFP is a key component of any large purchase, as it allows us to compare several systems against a set of common requirements, including business, technical, cost, and support.

But it doesn’t go far enough.

It’s easy to focus on marketing, finance, and the end user requirements. But what about infrastructure, manufacturing, or field technicians? How about quality control or customer service? We need to gather input from the teams down the length of the entire value chain.

I’ve been in situations where two systems look great: functionality, front end, and cost all are where we need them to be. Vendors, of course, talk a good game. Their RFP responses look similar. On the surface they’re both shiny new sportscars with all the latest gadgets.

But then the technical folks get in there and check under the hood. They find one still has an engine circa 1980! There’s no way this will work in your organization. You don’t have the resources to maintain the servers or update the desktop-based application. And it makes no sense to revert your users to 32-bit!

Good thing you included the tech folks before you signed the contract.

But not all projects involve software.

Years ago, our company was struggling because our manufacturing costs were consistently high. A review of our new product development process revealed that the problem wasn’t our product, and it wasn’t the skill of our manufacturing team. It was the NPD process itself.

R&D would design a product, test it in their small, flexible lab, and hand it over as a defined product. They weren’t aware of the constraints of large-scale manufacturing. No one asked them how long it would take to change over a line.

Manufacturing was not involved in the process until the very end. They had no input! The result was a product that worked as designed but could have been made at half the cost if only someone had checked with them first.

In the software example, it is wise to plan for a technical deep dive with the vendor finalists. We don’t want to bring them in too early, before we’ve finished analysis on other areas. But adding this tech review as a normal part of our software selection process can eliminate years of headaches for end users, IT, and you!

For product development, we want to make sure all areas of the value chain are involved in the NPD process. That doesn’t mean Support has equal say in the design as R&D, of course, but reviewing early and keeping them in the loop can keep you from launching a product that’s unsupportable.

All projects rely on communication through the whole value chain, at each phase of a project. Pull in the experts when it makes sense and plan to make adjustments. Reach out to teams you don’t traditionally include. And be prepared for a better outcome!

Three Truths About Praise

by

There are three truths of workplace praise. And all have their roots in communication style and human behavior.

The topic of workplace feedback is wide and deep. Maybe I will write a book about it someday, but to keep this article a reasonable length, I’m going to focus exclusively on praise.

There are three truths about praise:

  • Not many people take the direct path and say, “Good job.”
  • Most people are oblivious.
  • Not everyone likes to be praised.

Let’s look at each of these in more detail.

The Indirect Path

I was working with a client a while back who felt disconcerted because his manager never said, “Thank you.” He thought he was doing a good job at work, but never received direct positive feedback. When we took a closer look at the situation, the proof his manager valued him was right there all along.

Here are some clues that your manager is pleased with the job you’re doing:

  • You’re invited to meetings. Most people are so busy they think of another meeting as a punishment. But consider: Who else is at the meeting? Is it a topic that expands your current role? Will being involved create opportunities down the road or make your current job a bit easier? Most often, the invitation is a gesture of growing trust or belief in your abilities.
  • You’re called upon to present…again. Like attending more meetings, many people don’t enjoy presenting. But if you did a bad job the first time, your manager would hesitate to put you in front of an audience a second time. It’s actually a compliment to be asked to lead a meeting and share your knowledge.
  • Your manager stops attending your meetings or no longer wants to be copied on every communication. This isn’t a sign that they don’t care, but that they trust the work you’re doing. Just remember they expect you to keep them updated on the project’s progress, and to let them know if you need them to help resolve an issue.

Most People are Oblivious

Yes, it’s true. 😉

What seems like a monumental task to you, something you’re exceptionally proud of, your manager may never even mention. They’re not trying to ignore your good work. They just have a myriad of other things to do. (Hey, if they had time to do your work as well as their own, you wouldn’t have a job.)

A long time ago I had a friend who worked for a big supply company. He used to go in on the weekends when no one was around to inventory the warehouse, straighten the shelves, and basically do a ton of things that kept the place working efficiently during the week.

I’m sure you can guess what happened: his boss never noticed, and if he did, he didn’t say a word.

Don’t expect anyone to be focused on what you’re doing. Most managers expect you to do a good job—you were hired to do it, so just being competent won’t merit praise. There are no participation awards.

I gave my friend this advice and it is still relevant: either don’t do the extra work, or let your manager know the relevant outcome.

There was no reason for my friend to go in on his own time to clean the warehouse. He could do it, or assign someone to do it, during the workweek. If he wanted to show his initiative, he could have told his boss about a significant finding during his time the past weekend. Remember, fishing for compliments is unprofessional and will backfire. Better to focus on the outcome. And again, if there’s no benefit to the project or company, don’t do it.

If you have an “oblivious” manager, simply let them know a particular event or effort went well. Here are some tips to receive a positive reaction:

  • Keep your delivery in your normal communication style. You want your manager to focus on the event, not be distracted by your altered style.
  • Don’t tell them about every little thing; the big efforts won’t stand out.
  • Be consistent in your communication so sharing good news won’t come during a special meeting.

Not Everyone Likes to Be Praised

This may shock some people, while others will raise their hand and say, “Oh, yeah, right here!”

For those who can’t imagine anyone who doesn’t enjoy a good pat on the back (or bouquet of flowers), take a moment to think about your teams. You have many personalities and styles to manage every day. Your communication methods vary to make sure you reach everyone.

So if Brenda doesn’t speak during a meeting, or if Lonnie blathers on about everything he did last weekend, you will likely find they will receive praise very differently, too.

And there are more of these folks on our teams than we know. They usually just grin and bear it.

A few years ago, I worked with an amazing team lead. She was the lynchpin to success in her area. I wanted to let her know how much I appreciated her. But she told me that she hates (yes, hates) to be called out, even if it’s praise. And she didn’t just mean in the obvious, public way. Her name attached to a team thank-you email caused her discomfort.

For team members like this, balloons aren’t going to be well received. Here are some low-key ways that, if they accept anything, may work:

  • Reply to all their email / DMs. That’s it. Just do them the courtesy of acknowledging their communication.
  • Use their data. They want to contribute and to know they’re doing a good job. When you actually use their work product, they’ll feel valued.
  • Do something for the whole team, but not together. A team gathering is probably not going to fly. But something non-personal will be more appreciated, like letting people know that next Friday you want everyone to take off at noontime (if within your power).

At the end of the day, the most important part of praise is paying attention to the communication style of the person on the other end of the line. When you’re seeking validation, you may want direct feedback but receive indirect signs of trust. On the other hand, you may feel uncomfortable with a public shout-out, but your manager loves to hand out awards.

And when showing appreciation to a team member, the best outcome happens when you focus on their most receptive communication style, not your own.

There Really Is Such a Thing as Over-Communication

by

Information Overload!
If we’re not careful, we can overwhelm our people with information!

There once was a fantastic manager whose performance critique from their boss consisted of only one word: brevity.

No, that manager wasn’t me. But it is a true story and certainly wouldn’t be a surprise to find on my annual review.

We all understand how critical it is to communicate with our stakeholders. We want our team to feel important and included, and to have all the information so they are empowered to make good decisions. Our sponsors and other executives should have the critical information at the right time. And our end users and extended team? Let them know what’s happening so they’re “with us” all the way.

But sometimes it’s hard to know when we’re going overboard.

Do any of these sound familiar?

  • A five-minute update can regularly take twenty-five.
  • A meeting that “shouldn’t take too long” goes the entire hour…plus a few minutes.
  • There are five main slides stuffed with content in your presentation…and fourteen back-up slides.
  • You put everything they need to know in your email…and get the most basic questions in response.

I am guilty of all of these. And I can name a dozen colleagues who do it, too.

So really, if we’re making sure we’re giving people all the information; how could there be any harm in it?

To answer that, let’s look again at the above cases:

  • If you say an update will take five minutes, not only is your audience expecting five minutes, they may have re-scheduled if they knew it was going to take longer. But they’re trapped in the middle of the conversation and need to see it through.
  • The same goes for a meeting. It’s hard to leave a meeting in the middle of a conversation. And if they do leave, they take with them a sense of frustration and unfinished business. And if you tell everyone the meeting will run short, they will be expecting some of their time back, even if it’s just five minutes to grab a water before their next meeting begins.
  • A jam-packed slide deck is deadly. Each slide should contain useful information, but ask yourself: do you want your team to spend time reading a slide or listening to you? And what is in those fourteen backup slides? If your audience needs the data, should it be in the main presentation?
  • Most emails don’t need a ton of background to evoke the intended response. It’s easy to miss the main point of a long, involved email.

Our teams (core, executive, extended) trust us to be respectful of their time and to deliver what we promise. In each of the above cases, we are wasting someone else’s time. More than that, we’re setting expectations and then not living up to them. But combine both—and do it repeatedly—then we’re starting to erode their trust.

How Do We Tell We’re Over-Communicating?

The result of over-communicating can be subtle. You’ll notice people start declining your meetings or aren’t available when you ping them for a quick update. They may stop reading your emails and instead send you a DM asking about the exact the subject you emailed them yesterday.

Let’s take a final look at our cases. A bit of review is usually all you need to dial it back to where it needs to be:

  • Take a few extra minutes to craft a more succinct message in email—or preparing for that five-minute update.
  • Unless there’s a very good reason for a meeting to run over, cut it off and make sure you do a better job estimating the time needed for each topic.
  • Check your slides for the 3-5 bullet rule. More information than that and your audience can’t absorb the information. Be critical in your review: does your overall point get lost because there’s so much context?
  • Read your email before you send it. If it requires a lot of explanation, maybe a phone call or meeting would be better—that way they can ask for additional information if they need it.

The focus on communicating the right amount of information helps you and your team get the job done. And it builds that foundation of trust so when you do find a meeting running over, they know it won’t become a pattern.

The Problem with Helicopter Leadership

by

Do they really need the rescue?

I was listening to a podcast about children and anxiety. The host (a psychologist) said oftentimes parents tell their kids “Just do your best. If you are struggling with something, we’ll find someone to help you get better.”

She went on to say this is actually conflicting instruction. It tells the kids that sometimes their best won’t measure up and someone needs to swoop in to make sure they do better.

She gave the example of her nephew. He’s in the 4th grade. He was assigned an oral book presentation for class via Zoom.

His mom had two options:

  1. Option 1: Ask him about the book, set a schedule for first draft, final draft, and practice times in front of mom, make sure he goes to bed on time the night before and eat a good breakfast the day of the presentation. Afterwards, grill him on the details, how he could improve for next time, etc.
  2. Option 2: Be aware of the assignment. Ask how he’s feeling and if he needs anything. Listen if he wants to share – but don’t interrupt. Then, after the report, ask how it went and how he felt about it. Don’t worry about anything else – he’s only in 4th grade!

Option 1 sets up the child for anxiety and stress. Option 2 gives him a sense of accomplishment and encourages independence.

When Mom takes over in Option 1, it also teaches the child that he’s not good enough and someone else needs to be in charge. This is also known as “learned helplessness.”

My question for you today is this: when it comes to project leadership, what messages are you sending your team?

Are you listening, guiding, and letting your team learn so they’re more independent?

Or are you micro-managing – attending every sub-group meeting and telling them exactly what they should do so they don’t make a mistake?

We want our project to run smoothly and our team to succeed.

But it can be difficult to let go of the need for everything to be perfect. The truth is, our people won’t feel a sense of accomplishment, and they won’t be able to work without your guidance if they never do anything on their own.

How can we learn to let go?

When considering what to let your team work on without you, ask yourself these two fundamental questions:

  1. Is your team ready for this next level of independence?
  2. Is the risk low enough that failure won’t tank your project?

If the answer to these questions is “yes”, then let go of the reins.

If you have a good relationship with your team, they’ll ask you when they need help.

Be ready when their output isn’t perfect. Then be ready when the next item they take on is better!

Before you know it, your project team will be independent, strong, and successful.

And you can feel proud to have helped them get there.

Is It Sabotage?

by

I was talking with a friend the other day. He is working on a renovation project. The team gathered requirements, reviewed options, had a lively discussion (or three), made decisions and then sent the final plans to the architect.

If you’re a PM you know what’s coming…

Yup, 2 days later, one of the team members sent an email to everyone: “I don’t think this is going to work. Here’s what we should do instead…”

UGH!

I felt so bad for my friend. And I could complete empathize!

It happens all the time on a project, unfortunately.

But why do certain people always seem to sabotage a project? And what can we do to prevent it?

The “why” is pretty easy: we’re human. And being human means we’re subject to frailty and influence…and we don’t always do what we should, even if we know better.

Here are some common reasons for the late entries:

  • Shyness. Some people don’t like to speak up. They work up the courage to speak but it’s well after the deadline
  • Introversion. As opposed to shyness, these folks may not speak up in a meeting, but need some time to reflect. And they may feel more comfortable writing or meeting 1:1 to discuss
  • Power. Let’s face it. Some people – consciously or unconsciously – feel the need to step in and take over. They may believe they have the better answers and it’s “my way or the highway”
  • Temperament. This one feels like Power, but it’s more about how they communicate. I know plenty of folks who honestly don’t realize they’re disrupting the very thing they’re trying to accomplish – they think they’re helping by bringing up additional suggestions or solutions, regardless of who they’re stepping on or how much re-work they’re causing

Having these late additions go unchecked can disrupt the project and the good will of the rest of the team. People may even leave the team completely – they refuse to work with the “disrupter”.

And as the Project Manager, if you don’t rein in the late entries your reputation takes a hit, too.

Each case is unique, but given the four common reasons above, there are a few pretty simple ways to minimize the occurrence, or at least the disruption:

  • Set up a short meeting with the known disruptor pre-decision meeting. Ask their thoughts and if there are any risks they see. Make sure to bring up these risks during the meeting so they’re addressed
  • Set up a meeting with the disruptor post-decision meeting. Ask for feedback again – you can play on the “did we cover it all” angle
  • Hedge your bets by giving the decision a “draft”. Give the final decision a buffer period for “new information”. I use this one with requirements. Sometimes we’ll schedule a “soft freeze”, knowing things will come up right after we freeze the requirements – even without a “saboteur” on the team!
  • Simply don’t allow it. Politely but firmly tell them it can’t be changed without \approval from the executive team. This one is tough to do unless you’ve planned for it. I always set up a change control process early in the project: process, documentation, decision-making. And make sure everyone is aware of this process throughout the project

Identifying project risks is important, no matter when they are raised. Our goal is always to bring the project forward, with everyone on board. Seeking to understand why a team member gives you a late entry helps lead you to the most appropriate response.

Does That Mean…Yes? Or No?

by

The other day my husband Steve asked if I was ready to go for a walk. I replied, “And the dog’s more than ready!”

He said “that’s not what I asked. Are you ready?”

This tends to happen to us. He’ll ask a question. I’ll read into it and give a reply that assumes the answer.

But if he doesn’t hear the actual answer, he can’t interpret what I’ve said. And that is frustrating for both of us.

If I’d simply added 1 word, if I’d answered “Yes! And the dog’s more than ready!” he would have understood and been able to receive the further information. Instead, I assumed he understood that my “and” covered the answer.

We all know what happens when we “ass-u-me”.

As I have a tendency to do this at home, I need to be extra careful to avoid “assuming and extrapolating” at work, too.

Communication with our stakeholders should be concise, as we all have full plates already. In an effort to be brief, to not waste our reader’s time, we naturally make assumptions in our emails, documentation, reports, etc. However, being too concise increases the chance of misinterpretation.

Here are three key methods to keep your communication clear:

  • Answer the question first. If you’re replying to an email or writing a summary report, there was an initial question or intent you’re responding to. First answer the question, and only then add relevant information
  • Use formatting techniques. Specifically, use bullet points to group together information. But here’s the key: use a header topic to explain the information. (For example, these bullet points are under a header topic that says the grouping is all about clear communication.)
  • Re-read your document for assumptions. Do you remember your elementary school teacher telling you to write like you’re explaining to “someone who has never heard of the topic”? That remains good advice! Especially in our distracted world, our team members don’t always pay attention to the details. This is a good way to orient them to the subject before you give them important information

Clear communication takes effort. It’s a balance between data and human nature. If we are going to respond to a question, we must answer it in a way that the person asking can understand and absorb. No assumptions.

Am I ready to walk the dog? Yes. Is he excited, too? Absolutely! Time to get his leash…