A Solid Launch Consulting

Successful Leadership Comes From Leaning Into Your Own Style

Leadership

The Dollar Bill

by

A few years ago, I was called in to take over a project that was in trouble: the Project Manager left suddenly and there had been no direct leadership for over a month.

In my first walk around the project area, I noticed a dollar bill thumb-tacked to a wall. I was curious but had other priorities so didn’t comment on this odd sight.

Weeks went by with the typical flurry of ramp-up activity: Who is responsible for each area, what are the requirements, how are we tracking them, where are the gaps, etc. When I stopped to catch my breath, I remembered the dollar bill, so I asked about it.

“Oh, that,” I was told. “The old PM said it was our project bonus.”

WHAT?!

I was horrified.

What the devil was their PM thinking? How did he expect the team to stay motivated with a symbol of negativity in their face day after day?

Apparently, the PM was trying to make a joke.

It was not funny.

The fact is, the team was extremely de-motivated when I got there. They felt unappreciated, stressed, and a bit hopeless in the face of all they needed to do.

I think of that dollar bill not as a self-fulfilling prophecy, but as a perfect representation of how that PM ran the project. His negativity made a difficult project that much worse. He let the team know he thought management saw them all as unimportant and unworthy.

And it took me months to turn things back around.

What that PM failed to understand is that people respond to our attitude and actions more than our words. If we want respect, we need to treat our people with respect. If we want the team to give 100%, we don’t simply tell them; we give 100% ourselves (if not more).

Just because we are in a tough situation doesn’t mean we need to infect the whole project. Difficulties happen all the time: We’re being pressured from the top, or there’s a really tricky issue we haven’t resolved. Maybe we’ve missed a milestone or something’s happened at home that takes us off our stride. While we shouldn’t pretend the world is made of cotton candy, it’s important to find the positive and use that to keep the team motivated.

And there is always something positive, even if we need to hunt for it.

Bottom line, a project team is made up of people. Human beings who are smart, creative, and want to do their best. Our job is to help them get to the goal line. We are here to remove barriers, not to be the barrier!

I took down that dollar bill as soon as I found out why it was there. And I let the team know how I felt about the old PM’s “joke.”

At the time, they may have thought my reaction was a bit over-the-top. But as the project progressed and we gained momentum, the mood improved and it wasn’t such a bad place to be anymore. The project continued to have its challenges, but it wasn’t due to a poor atmosphere.

As for the team’s project bonus? Let’s just say it’s too bad that old PM quit when he did.

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!

Helping a New Team Member Settle In

by

I went into the office for the first time last week. I’ve been working from home since that fateful day in March 2020, when my manager called and said, “Don’t come in this week.”

When a resource joins your team halfway through the project, it’s not possible to “hit the ground running” unless you give them a solid surface first.

Life has been shaken and stirred since the last time I had to commute. And for me it also meant a new client, with new projects and a new office.

I admit, I was a little nervous. Would I find my way there…and around the campus? Where would I sit? Who would I see? What are the expectations for eating at my desk, talking within the group work area, and conference calls? Finally, how long does everyone stay at the end of the day?

So many worries!

Everything turned out fine, of course. But it started me thinking about how a new employee (or contractor) feels when they join your team.

If it’s a brand-new project it’s a bit easier, as you can start with a kick-off. Everyone is starting fresh, and you make your way forward together.

But if your resource is joining in the middle of the project, especially if they don’t know anyone or they’re new to projects in general, it can be more nerve-wracking. Not only are they worried about the logistical pieces (see above!), but they may also wonder if they’ll fit in, how much they’re expected to know already, and whether they’re going to fail miserably!

How can we help our new team members handle the pressure and settle into their role?

  • First, have as much logistical information as possible. This may seem counterintuitive, but helping someone new figure out where the coffee machine is (and how to use it) will give them a sense of control, however small. And from there they can move forward.
  • Next, let them know what to expect during the first few days. Your new person may be wondering if they’re getting a laptop, if they’re supposed to concentrate on taking all the training assigned to them, or if you expect them to start diving into action items right away.
  • If there are a few key people in the organization—maybe an admin who knows how to navigate the operational waters—introduce them! Perhaps go a step farther and ask one of the go-to resources to keep an eye out for your team member. Most people feel good about being asked!
  • Finally, be patient and answer all their questions. Remember that you’ve known Sue in Accounting for years, but someone who just started may not remember if it’s Sue or Susan…or Sam! They’re going to slip up. Be there to help, even if you’re busy.

I consider the first month of ramp-up time for a new resource as having a “puppy license.” This is the time when they’re drinking from the fire hose, their head is spinning, etc. Encourage your new resource to take advantage of this time to ask questions and meet as many people as possible. Because that time is all too short. You’ll need them to start taking control of their own meetings and schedule soon, rather than relying on you to guide them.

One final thought about helping someone transition in. The best way for them to realize they’re not the “new guy” anymore is to connect them with someone even newer. You may not have another new person (bonus if you do), but when your resource becomes the one with the answers, their view of where they fit in the team can shift in a big way.

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.

You’re Not the Only On Who Storms

by

Everyone belongs to a team so everyone goes through the stages of Team Development!

I often write about the stages of team development (Forming, Storming, Norming, & Performing). We should be aware when we go through each stage, and help guide our project teams through them, as well.

But what about people outside our project?

These people may not be on any formal team. Why would team development be relevant to them?

First, everyone is on a team of some sort. Think about it: A Manager has direct reports. An Individual Contributor supplies information to the team. And if you’re a Remote Worker, you may not bump into anyone in the hallway but you’re still part of the group.

Here are more. What if you all have the same objectives? That’s a team. Presenting together at a conference? Team. You get the picture. If we need to relate to someone else on a regular basis, it’s a team.

They could also be new. New to the company, their position, or department. Something in the status quo of their work-life has changed and it causes a start back at Forming.

You know the signs in yourself and in your project team. Here’s how they show up in others:

  • Forming: Lots of basic questions. Oriented towards “getting to know you,” what is happening, expectations, what’s typical, etc.
  • Storming: The questions become pokes. More “Why are you doing it that way?” and questioning decisions already made. Re-evaluating, re-vamping, re-doing.
  • Norming: They start asking the “good questions” and know where poking won’t be productive.
  • Performing: You feel comfortable going to them with questions and for their opinion.

So what? Now that we can spot these individuals, we can help them get to Performing with as little Storming as possible.

Here are a few suggestions:

  • Let the questions come. You’ve been in their position. Sometimes you need to ask the question two or three times until it sinks in. And one question leads to another.
  • Keep your cool when the pokes become a bit sharp. It doesn’t mean you need to cave. Think about whether you had the same questions. How did you resolve them?
  • Take the suggestions seriously. Remember, they have a unique perspective. You may have spent countless hours wrestling with an issue and feel you’ve covered every possible outcome, but it’s all brand new to them.
  • Encourage their discovery, however it happens. I was recently in a session with someone who was literally re-doing the work I’d just gone through. But before stopping them and pulling out my own document, I suggested we move forward with their new doc and I’d answer questions as they put the pieces together.

    I had to step back and let them take that journey. But my experience helped them get to the finish line faster. And, as we all know, figuring something out yourself helps it “stick,” and gives someone ownership of the solution.

Helping others move through their own Team Development benefits them, certainly. But it also helps you in three ways.

First, you’ve just racked up a ton of good will! Everyone appreciates help when they’re struggling to understand and get up to speed. That time and effort spent will come back to you!

Next, no matter what type of team you’re both on, that individual was selected for a reason. The faster they ramp up, the more efficient you all can be, and the sooner they will start contributing from their unique perspective.

Finally, if you help focus their questions and pokes on you, the less time they’ll spend slowing down other people who may not be as prepared. Not everyone understands Storming—it can be tough when someone questions your decisions and processes!

So for the next two weeks, pay attention to the signs of Team Development outside of your project. Ask yourself if you can lend a hand in bringing them along faster. And then do it. Watch what happens!

Dumbledore and How to Avoid Mistakes

by

As we grow, our mistakes become “correspondingly huger.”

We’re big Harry Potter fans in the Buttiglieri household. (Our dog is even named “Lumos,” which is the spell for lighting up the end of your wand!)

One of the most impactful quotes from the series comes from Albus Dumbledore, the school’s Headmaster, genius wizard, and complete icon. He says, “I make mistakes like the next man. In fact, being–forgive me–rather cleverer than most men, my mistakes tend to be correspondingly huger.”

It’s not much different for mere “muggles,” either.

When we are just starting in our careers, our mistakes are plentiful…but their effect is typically minimal. They may be embarrassing but only require an apology and a quick fix. (I remember one time I saw a shelving unit in a storeroom with old books sitting on it. I thought, “Great! We need this to house our marketing literature!” and took it. Little did I know the Documentation Manager was using it to store her old materials. Ouch!)

As we gain more responsibility, the mistakes that were simply cringe-worthy start to impact our project: Incorrect data analysis; forgetting to include someone in a critical meeting; sending out the wrong training dates; purchasing a software application that isn’t the right fit; ignoring a risk until it blows up and we need to call an emergency executive meeting. These grow “correspondingly huger.”

We’re professionals, so when something happens on our project we scramble to do what it takes to set things back on track.

But there is another consequence: our reputation suffers.

We spend years working to build trust within our teams and our companies. We’ve built our reputation as someone reliable and knowledgeable.

The loss of reputation can be far worse than the mistake itself.

Of course, it doesn’t take one misstep to bring it all crashing down. But as we string them together, seeds of doubt can start to grow in our stakeholders’ minds.

How do we avoid this?

  • Write it down: If you struggle to remember dates or actions from a meeting, make sure you take good notes and refer to them when you’re using that information in the future.
  • Enlist a second set of eyes: The more important the communication, the more eyes should be on it. (If I take the time to have someone proof-read my Leadership Notes blog, the less I need to worry it will have the wrong subject line ;-).)
  • Trust your gut: If something feels “not right,” don’t ignore it. You may not know what is wrong, but take a step back, maybe take a little time, and then look at the task or issue from another angle. If you still need to move forward despite the “something’s not right” feeling, make sure risk mitigations are firmly in place.
  • Take your time: It’s easy to rush through communication because we have ten other things to do. Or toss some budget numbers out there because “they’re good enough.” The extra time is worth it – ten minutes can save two hours of re-work later.
  • Avoid tough work when your brain is tired: Personally, I struggle to be creative in the late afternoon and evening. I’ve learned to schedule my day so presentation slides and blog posts are drafted before lunch, saving the afternoon for edits or more analytical tasks. Take the time to learn your most efficient pattern. If your project updates are more easily written at 8 a.m., or if you work best after the household is asleep, follow that pattern.

All these suggestions are simple and aren’t new concepts. The question we should ask ourselves is: how often do we follow them?

Do we ever tell ourselves “it will be fine” and send out an important communication…even when our gut is telling us otherwise? Do we ever think “I’ll get to it later” and then forget key information from a meeting?

Recognize that mistakes will happen. Set up your own mitigation practices. And follow them consistently. Your project will run better, your reputation will remain intact, and you’ll have fewer apologies to make.