Crisis management has always fascinated me. At least from the perspective of the watcher, I think it’s analogous to the train wreck or car accident you know is about to happen, but can do nothing to stop. Despite tons of research, thousands of articles and hundreds of classes, we still seem to have learned nothing. If a crisis hits the level of being called a crisis, it’s already too late. At this point, an issue has escalated to such a state that it warrants crisis management and involvement at all levels of organization.
Too often that “involvement” includes only a narrow definition of “all levels.” Look only as far as recent news stories and you find that more often than not, the people managing the crisis have very myopic views of inclusion and leave off a fairly large contingency of stakeholders. One wonders what the insular group has to gain from excluding those most unlike themselves. Unfortunately that includes the most vulnerable. Kim Crayton (@KimCrayton1 on Twitter) speaks often on the how the “lack of inclusion is a crisis/risk management issue”. She also authored “prioritize the most vulnerable” and “intention without strategy is chaos” as part of her Profit without Oppression guiding principles. It would seem to be that we could all take a lesson from her book on how we approach our next “crisis.”
In my observations, we see those in crisis doubling down on this foundational error by making decisions in isolation and ultimately not including those who will be most impacted (or often most knowledgeable). If we as decision makers and participants would take a step back to think through our true intentions and made sure to bring the most affected to the table, we might ultimately be more successful in avoiding the crisis in lieu of the management.
My team spans timezones and continents and first languages and areas of expertise. We manage ongoing customers and new project implementations. In the pre-pandemic days, we crossed oceans and land masses to learn and laugh and share together.
For most of us, the pandemic hasn’t been easy. We’ve been uprooted from routine, separated from our family and friends, or maybe, quarantined too close to them. My team has stood strong through the changing dynamic and I’ve learned a lot from them. My team
Thrives on challenges – As our customers were responding to the pandemic and pushing us for solutions, my team got engaged and excited to deliver on those solutions. They truly looked to the uncertainty as opportunity and delivered on it.
Supports each other – as life continued, we together celebrated successes and life events and showed compassion to schedule changes or adjusted to uncertainty. They showed flexibility and compassion with each other and sometimes with themselves.
Craves the connection – not surprising given the general closeness of the team, but the remote work left us all craving our connections to each other. Zoom fatigue and increased workloads and life interruptions makes it hard to prioritize those virtual meetings, but 1:1 check-ins were much appreciated.
Needs to smell the flowers more (and nurture the roots) – sometimes we get so caught up in the issues of the day, we forget to focus on how far we’ve come or what else we need to do to cultivate our roots to make our ecosystem stronger.
Needs more bees – Just like nature, we need an army of bees to bounce around between the team members, and expertise and cross pollinate the knowledge. As an organization, we have a fairly strong set of documentation but still have challenges with its maintenance and ensuring it’s consumed and recalled when it’s needed.
Clearly, I have spring on my mind given the flower and bees analogies. I’ve been very lucky to have the team that I’ve had during this most challenging of times. We did a see a bit of turnover, but we were also able to bring on some new talent that invigorated the team dynamic, despite the remote onboarding and continued work. We continue to get challenged by what is going on in the world, but I know that we’ll be able to pull together to deliver the best we can.
I’ve often found myself in roles at the intersection of sales, professional services and support (and as an extension, product, although not directly relevant to today’s post.) Throughout my career, my selling style has really evolved into the valued partner, solution expert who can help customers or prospects leverage whatever product/service I’ve been associated with to solve their problems. I’ve noticed recently that it’s much less about the product or service, and much more about aligning to the dream.
It used to be that I would leverage our core values to demonstrate how we can fill the gaps in each organization. As a general matter, this helped establish myself as an expert, but it didn’t resonate as well with my audiences because they would latch on to one or two smaller points rather than grasp the big picture. My next shift had me emphasizing truly meeting customers where there are to solve very specific problems and using that as a basis for a broader conversation of what solving those problems will enable them to do and how it will help them solve much broader goals. I think there is still another evolution in the language of value and being able to leverage your content, your demo, your expertise to enable your audience to truly connect your words and images with their dreams (realized or unrealized).
As I mull through this problem, I started some research and came across The Secret to Selling SaaS – Value vs. Product blog post that references this phenomenon as ‘crossing the chasm’ and states “a customer can go 57% of the way through the buyer’s journey, but still not understand what you’re selling.” And this is very much describes what I’ve been feeling like recently.
An extension of this problem is that the disconnected conversation often results into a directional shift focused more on price and feature/functionality versus really aligning to the audiences goals and vision. Ultimately these opportunities are smaller and less valuable to the customer.
I think my biggest take away so far is that I shouldn’t second guess my methodology and thought process around the importance of having discovery calls and understanding the problem we’re trying to solve before jumping right into to demos and technical discussions. Without it, you can lose your grip on the opportunity and can’t possible promote the right value proposition if you don’t fully understand the audience or their goals.
I read this Harvard Business Review article “Why WFH Isn’t Necessarily Good for Women” a while ago and I was struck a little bit by my own experiences working from home for the last 10 years. About 5 years ago, I interviewed with someone who told me that project managers couldn’t be effective in their jobs without being present in the office everyday. Needless to say, I wasn’t the right fit for that job, and my interviewer now runs a fully remote company. The pandemic has definitely pushed companies past their comfort zone, being forced to embrace a fully remote environment at a minimum, a fully engaged and remote culture as the ideal.
I attribute some of my success working from home to a fundamental understanding that you are at a disadvantage and need to ensure you really communicate, even over-communicate to some extent. As a manager, this means that I leave my lines of communication open and meet my team members where-ever they need to be. As an employee and project manager, this means I am constantly sharing information and establishing a baseline for my communication, so that when I need to escalate or talk through something, I get treated with the urgency I need.
My current team is primarily compiled with the majority located in one geographic area, a smaller group in another and multiple team members, including myself remote to either location. The primary location was the base of operations for our key customers, with an open door policy that encouraged them to stop by. There were definitely missed conversations and opportunities, that remote team members needed to overcome. But there were also some downsides to the office community, we have identified since work from home has been implemented.
The sense of community provided quite a bit of distraction – In anonymous surveys of team members, and analysis of the numbers, all accounts show that the entire team is more productive. They feel more productive and the numbers show dramatic increases in productivity since the start of the pandemic. Even the most extroverted have taken note and are refocusing their energy to impact their goals, and driving growth for the team.
Boundaries are key– Everyone’s family and home situation is unique, and it’s imperative that each person set boundaries, and the rest of the team abides them. Further, it’s imperative that you communicate these rules to your stakeholders as well. We all need the flexibility to work through a shared workspace, or kids in remote school, or loved ones who got sick miles away. Having an open door policy to discuss each person’s needs allows them to share as much or as little as they feel comfortable, but allows you to provide individual support.
Don’t assume, ask – We did a few anonymous surveys of the team to figure out where we were succeeding and where we needed to improve. We also had did skip level 1:1 meetings across the entire team. This allowed team members to be heard, and for us to continue to figure out how best to support.
There are still some downsides that we need to navigate: including a sense of loneliness, a shift towards too much work in the work/life equation, and figuring out how to retain those connections with customers and our team members as we bring new ones on, or as we navigate how to open the office and balance everyone’s new found enjoyment in working remote with needing to have some presence in the office as a haven for our customers.
I think we all know that “toxicity” is bad, but when you are in the middle of a toxic situation it’s difficult to think beyond the immediate moment. It’s very much like sitting through days of rain, or hours of a hurricane without power. You know there is sunshine and rainbows somewhere beyond it, but it changes nothing about the current situation.
These types of situations happen in implementation projects as well. I don’t want to spend any time on the sources of toxicity, but more importantly, what happens after you are able to successfully remove it. Below are 3 key positive outcomes that can arise.
The entire tone of the project changes
Once you have been able to remove the toxicity, the tone of the entire project can change. It doesn’t happen overnight. You usually need to spend a bit of time retooling the project plan, realigning resources and level setting expectations. The project team can grow closer together for going through the shared trauma of the experience.
Toxicity encourages bad behavior. It makes team members less likely to speak up, share ideas and innovate. Why would/should you bother if those ideas will just get shut down. Once the toxic environment has been cleared, those previously silenced lines of communication are re-opened and those creative ideas start flowing again. Team members find and implement innovation and process efficiency. The biggest challenge here is ensuring that the questions raised are done so in a constructive way. You don’t want to risk putting these opportunities at risk because people are reacting to where you came from as a project team rather than seeing it for the positive impact.
It can be truly refreshing to see the lines of communication open after the shared experience. As the project manager, it can be incredibly frustrating to find out all the things that hadn’t been communicated previously. Take a moment to acknowledge your frustration, but then let it go. This speaks more to the situation than you it does for you as a project leader. Everyone was feeling the negative impact and people didn’t feel comfortable sharing. The power that the toxicity had over the project is very legitimate. Be understanding and positive – the other team members now feel comfortable sharing with you. This will make the remainder of the project much more successful.
Toxicity sucks just as much in project management as it does anywhere else. The goal as the project manager is to diagnose it early and do what you can to minimize it, or even better remove it. Once you do that, plan a conscious project reset – schedule, team members, expectations, etc.
The standard process for selling software to customers involves sales driving the sales process then handing over to services for implementation and ongoing support. Sales people are incentivized to sell more, but services is ultimately responsible for delivering. Even in scenarios where services is involved in some portions of the sales process, more often than not the contract that is ultimately signed contains an element of surprise for services.
“This is because a rigid separation of sales and service motions is a way to guarantee (even exacerbate) a disconnect between supplier and consumer objectives. This is something TSIA has been documenting for some time. The traditional CapEx tech sales model is a “make, sell, ship” concept that is, quite frankly, more or less completely focused on the need of the supplier to sell boxes, software, speeds and feeds, etc., and almost not concerned at all with the customers’ use of the solution or their business value in adopting it. The role of Services in that model is to implement what’s sold by Sales, offer some training on how to use it, and fix it when it breaks. But because the customer, in this model, pays up front for the solution, now owns it, and is more or less required to keep renewing the insurance policy (maintenance contract) on the solution, the supplier is whole whether the customer is getting value or not.”
This blog post goes on to challenge us that this issue becomes exacerbated in our new reality, where everything is a software as a service. In this age, customers are expecting faster implementations and subsequently, faster time to derived value. Any disconnect between sales and services results in delays and negative impact to the customer.
What causes these disconnects? And how do we solve them?
Sales training – There are several parts of the sales training process to be considered. First, there is the basics of solution selling and understanding customer problems. Second, there is a fundamental understanding of what the software solution can do. Ideally, there is also someone in the sales process who understands where the lines of delineation exist between what is not possible and what is possible but requires custom implementations. Lastly, it’s also important that the sales team is taught how to sell your particular products in the most effective way to ease the onboarding and ongoing support (or at a minimum set expectations with the customer on more complex implementations).
Lack of Services voice – Often times, services is engaged in the sales process in very limited ways. It might just be to draft the statement of work based on the little bit of information provided by sales. Hopefully, services also has a place in reviewing the contract as is it evolves to ensure it aligns to costs, and services. Services should also make sure their voice is heard in sales training/enablement processes. Is the services organization promoting the value their customers are deriving? Has the services organization developed the sales tools required to get the information necessary to properly scope projects; or to educate the sales teams? If not, the services team isn’t doing themselves any favors.
Changing market landscape – we hear it constantly that the pace of business is changing so rapidly, and companies need to adjust to the changing winds of the customers. Services is typically engaging with end users, while sales is engaged at higher levels in organizations. It’s a very real possibility that the market has changed, and that information hasn’t been communicated to services.
The biggest step to be taken to re-align sales and services is better communication. As a sales organization, it’s imperative to keep services up to date on the changing market landscape as well as the customer conversations that occur that impact services (and most of them do). As a services organization, it’s imperative to have a discussion with sales as soon as you see the disconnects. While you may not be able to do anything for this specific contract, you might be able to prevent the same issues with the next one. The lines of communication and respect need to stay open.
I have had the opportunity to work with good and bad product managers, as well as fill that role myself. There are a few key traits that differentiate between the good and the bad, at least when it comes to web, data or technology products. Below are my top 5.
In depth understanding of the product
I find the best product managers truly do understand their product, and where customers are getting value. These are the ones you can rely on to give you an honest assessment of whether the product can be used to solve a problem today, as well as having a strong enough understanding of what it does, to make a determination of whether it can or should do something in the future. The weaker product managers don’t have a strong foundation on where customers derive their value, and therefore can’t help you truly assess what it can do today, versus what it could do tomorrow. This latter group typically will rely on product developers to fill in the details, or the customer facing personnel to provide the use cases.
A solid sense of direction
Another key difference between good product managers and weaker ones is whether they have a sense of direction for the product. Simple things like having a roadmap, or being able to quickly assess whether a new feature request aligns to the strategic direction of the product differentiate the two groups. Customers want to know what you are bringing to the table in terms of new features and functionality. They also want to know that they are being heard, even if those feature requests don’t align to the product direction. Being able to explain the current position, the near-term future direction and respond as to why this request doesn’t fit, is critical to having a solid product ecosystem.
Willingness to meet with customers
Great product managers are interested in how the customers use the system, regardless of how it’s been designed to be used. Further, great product managers want to engage with customers to continue to evolve with the business problem the product has been designed to solve. Those conversations can sometimes be contentious or frustrating, but they are an absolute necessity to continue to be relevant.
Ability to follow through
It is not enough to meet with customers that one time. These days, it is also not enough to gather your information and go off to develop the product in a silo. Customers want and need to be engaged. It’s critical that product managers follow up and follow through. This is almost more important when the decision does not align to the customer request. Customers want to understand why and how – there could be a very good reason that the request can not be fulfilled. The core business problem the customer raised is still a fundamental issue (to the customer). Is your product going to solve it? or do they need to look at alternatives?
Communication is key
At the end of the day, communications is key. This is an underlying theme to the previously mentioned traits, but it’s important to call out separately. Once the new features and functionality has been released, it is critical for the product manager to be able to articulate the feature/functionality, explain our understanding of the problem it addresses, clearly articulate how this feature/functionality fits into the product suite from a contract/pricing perspective and finally solicit feedback as to whether we delivered.
At the end of the day, the best product managers have been a pleasure to work with. They really own the products they manage, and have a very strong understanding of why and how customers use them. They are the starting point for all conversations around the art of the possible, and are always willing to have a conversation to get a new idea, or work with a customer on a problem. They are organized at the tactical level, and open minded at the strategic level.
I had been working on a very large migration project for about a year when we started preparing for the cutover day (AKA “launch”). As far as projects go, this was fairly typical. We started at an even steady pace, but as time went on we found ourselves putting in more work across the board to mark off all those little things that come up.
We had our punch list of prioritized issues, and work feverishly working through them. We were also aggressively determining/negotiating the true show-stopper nature of each of them. After a couple of close calls where it was unclear whether we would need to push the date, our launch kicked off. Every person involved with the launch had quite a bit of pent of nerves, excitement, energy, etc. Of course Murphy struck and we had to tackle those real-time, last minute issues. After several long days and very specific collaboration across teams, we were able to ultimately deliver.
While I was extremely happy to be live in the new system, this monumental effort (or what had seemed like it a year ago, or even 3 months ago) had no real impact. We did it! But now it was time to move on. The customer had been our customer for many years, and so we were not getting the benefit of working with a new customer. Nor were we getting to do anything new with an existing customer. It was business as usual. It was time to start thinking about all that work we had pushed off, while also helping the customer prep for their next operational weekly cycle.
Once the adrenaline faded, I looked around and thought about how far we had come. But there really wasn’t any fanfare. I’ve come to realize that this is a good thing. The project team had set out to accomplish something and we did. And it worked. And now it’s time to refocus and help the customer realize all those benefits they had hoped to get by the migration.
A couple of weeks ago, I had an epiphany about the role I was playing with the customers I support. For much of my time, I work on large implementation projects, but I spend a lot of the rest of the time working with customers in the role of Customer Success Manager (CSM). The goal of Customer success is help customers derive the most value out of the product, and ultimately helping them meet their business goals. As a Customer Success Manager, this can mean many things. I engage with both corporate and specific business teams, guiding them on the solution and helping them with their individual goals.
It was while I was having one of these weekly discussions that I realized my role had shifted. I was no longer just a project manager or CSM. I was contributing to their business strategy in a consultant role. A consultant is defined as “a person who provides expert advice professionally.” In this particular case, I was leveraging years of experience working with this particular product, in this particular industry. I wasn’t having a tactical conversation about next steps, or how to use the system. I wasn’t discussing the next corporate initiatives. I was sharing my business expertise to help them to determine how they could improve their overall success over the lifetime of this project, ultimately increasing their sales. I was providing value versus just assisting them in getting value out of our products.
In retrospect it seemed like such a silly moment for me. I came into my role with no prior experience in the industry or even directly the technology. My first 3 projects were highly technical and highly industry specific. I jumped in and asked many questions along the way. Almost seven years later, I’ve completed quite a few implementations and special projects, working with about a dozen large customers in the industry. I’m no longer feeling my way, along with my customer. It’s in under these circumstances, that I stand back and put my consultant hat on.
I have often been asked to step into projects where the industry or software are unfamiliar to me. More times than not, the project team has been hesitant at first. A common sentiment towards project managers of many technical resources I’ve encountered is disdain. After a while, the team gets used to working with me and figures out how I can help. In many cases, I’ve changed the opinions of project managers for these technical resources. But why is that? What is it about my approach to managing data and software implementation projects that enables me to step into any project at almost any stage and help deliver results?
Willingness to learn – I am willing to learn. I know when to shut up & listen, take notes and ask later. I try to read the materials I’m provided, and if relevant, find external sources. I follow up with questions and try to make connections but acknowledging that I could have missed something.
General understanding of technology – I have a fairly good understanding of software development, database, data, workflow, process methodologies that gives me a foundation of understanding.
Resources – I’ve been lucky enough to have worked or socialized with a number of very smart people across a broad range of disciplines. I’m able to engage with my network on an as needed basis.
Know what you don’t know – It is imperative that I admit when I don’t know something. I need to engage with the right people at the right time, but yet recognize the dynamics of the situation and adapt accordingly.
I don’t think you do need to be a system expert to successfully manage an implementation project. I think you can develop enough of what you need to know to get involved to the extent you can. You’ll obviously need to adjust your level of engagement, and rely on your project team for the software expertise. You also need to know enough about the project and system to call bullshit when you need to.