Part 3: Deploy and adapt
STEP 1
Communicate the launch, including context and details
All of your hard work has been leading up to this moment. It’s time to tell everyone that the decisions have been made, the changes are imminent, or the key project deliverables are ready.
But before you go big and broad, do consider whether a "soft launch," preview, pilot, or rolling release is possible.
For all projects
Whether you announce a full launch or something more preliminary, use consistent messaging in all communications. Make ample use of the documentation in your common fact base. Outline the steps you’ve taken to be inclusive and transparent. Highlight the who, what, when, and how of your decisions. Share information as freely and openly as you can. Point impacted audiences to the support process you’ve created, where they can voice concerns or ask additional questions.
Additional notes
Standard complexity
This is another opportunity to acknowledge how feedback shaped your decisions. Share the top 2-3 ways feedback improved the initiative or helped the project team avoid mistakes. Define and describe what success looks like and publish relevant metrics. Share your timeline or criteria for revisiting controversial elements (or re-evaluating, if possible).
Less complex
No further work is needed.
More complex
This is another opportunity to acknowledge how feedback shaped your decisions. Share the top 2-3 ways feedback improved the initiative or helped the project team avoid mistakes. Define and describe what success looks like, and publish relevant metrics. Share your timeline or criteria for revisiting controversial elements (or re-evaluating, if possible).
Communicate details about the initiative and its alignment with Red Hat’s strategy, mission, culture, and values. This is especially important for unpopular or large-scale initiatives.
Reiterate relevant business requirements and constraints, such as legal, reporting, or confidentiality issues.
STEP 2
Launch, beginning with a preview, pilot, or rolling release if possible
Using a soft launch approach takes the pressure of perfection off of everyone and cultivates a “release early, release often” iterative mindset.
Remember that your decisions, projects, and changes will contribute to the Red Hat associate experience, for better or for worse.
For all projects
Demonstrate accountability for the outcomes of your initiative. Share your metrics and indicators, to the extent possible, and take action where needed. Diagnose problems that emerge during or after implementation. Identify and provide for any ongoing support needs from a technical or training perspective. Make any needed adjustments, while also keeping in mind that you can’t please everyone. A little discomfort, frustration, or complaining is a natural part of change adaptation.
Additional notes
Standard complexity
Administer an associate experience survey or interview to a random selection of stakeholders. This helps identify areas where the process or outcome may not have yielded the desired associate experience and provides insight for future initiatives.
Less complex
No further action needed.
More complex
Administer an associate experience survey to all impacted audiences. This helps identify areas where the process or outcome may not have yielded the desired associate experience and provides insight for future initiatives.
STEP 3
Ensure your support process is live and responsive
Whether you’ve devised a large cross-functional hypercare team with a help ticketing system or you have assembled a small group of stakeholders to answer questions, it is important that your support process is available as soon as you launch.
For all projects
Check all systems and channels to confirm they are receiving incoming requests. If in doubt, send test messages. Make sure those who are assigned to monitor a system or channel are fulfilling their duties.
Additional notes
Standard complexity
Check in with everyone who is monitoring support systems and channels at least twice on launch day and daily during the following weeks. Monitor the volume of incoming requests, as well as any unresolved issues, and use this information to guide your actions and decisions.
Less complex
No further work needed if everything is going according to your plans. If not, see the "standard" or "more complex" options for further guidance.
More complex
Check in with everyone who is monitoring support systems and channels at least twice on launch day and daily during the following weeks. Monitor the volume of incoming requests, as well as any unresolved issues, and use this information to guide your actions and decisions. Decide if you need to recruit additional support staff.
STEP 4
Launch additional training and enablement
Depending on the experiences and support needs during the launch, you may need to enhance or add more training and enablement resources.
Think ahead, too, of people who join Red Hat next month or next year. How might you need to adapt or enhance the training and enablement materials for that future audience?
For all projects
Much of your early training and enablement resources may be focused on helping Red Hatters transition from a familiar environment to a new, unfamiliar one. As you move forward from your initial launch, think about what additional or new training or enablement might be required for short-term and long-term success. Add these needs into your Training Plan and Sustainability Plan worksheets.
Additional notes
Standard complexity
Reconnect with teams like Red Hat University or other training and enablement support partners to plan, prioritize, and scope any remaining work.
Less complex
Set a reminder to check in with current users and new hires several months from now to determine what else might be needed for long-term success.
More complex
Reconnect with teams like Red Hat University or other training and enablement support partners to plan, prioritize, and scope any remaining work. Ask your launch support team for input on what to prioritize.
Step 5
Identify and address resistance
Not everyone will make the effort to reach out proactively with their questions or concerns about an initiative, choosing instead to just silently resist. For your initiative to be successful in the long term, resistance in all its forms—silent or vocal—must be identified and addressed.
This step offers guidance for uncovering barriers and areas of resistance after your initiative has launched.
Feeling surprised and frustrated? Feedback is a key part to a successful launch and a sustainable project. Be prepared to be met with push back.
For all projects
Stay engaged with those who resist or reject the initiative. Acknowledge their concerns. Seek to understand their use case and whether anything can be done to help them. Remember that an unhappy stakeholder does not necessarily mean you’ve made the wrong decision for Red Hat as a whole. Make adjustments where needed. But also remember that change is hard; often, people simply need support to navigate it.
Additional notes
Standard complexity
Make personal contact with stakeholders most impacted by these concerns or who might silently resist the changes. Listen with empathy. Pay close attention to areas where unanticipated consequences might result in critical failures, even if it is for a small group.
Less complex
Make personal contact with stakeholders most impacted by these concerns or who might silently resist the changes. Listen with empathy. See how things are going for them.
More complex
Make personal contact with anyone who is showing signs of resistance or make yourself available for town halls and similar events. Listen with empathy. Reiterate key messages and information from your common fact base, where helpful. Pay close attention to areas where unanticipated consequences might result in critical failures, even if it is for a small group.
What is the “associate experience”?
At Red Hat, we call our employees and colleagues our “associates,” and we care about the experiences they have as Red Hatters.
If you are familiar with the concept of a “user experience” or an “employment experience,” that’s what we are concerned with. What is the daily experience of working at Red Hat like, for our colleagues? How does each of us, as Red Hatters, contribute to that experience? What can we do to create a positive associate experience?
Think of how often you are asked questions such as, “How was your experience with us today?” or “How was everything today?” when you are a retail customer or restaurant goer. Our goal, when making decisions and changes, or leading projects, should be to consider, design for, and care about our colleagues’ experiences, in much that same way.
Why did I bother asking for feedback?
It can be frustrating or demoralizing when your fellow Red Hatters seem unwilling to adopt a change or accept a decision. You might even wonder why you bothered to ask for anyone’s input or share information, instead of just moving forward with your preferred option. We’ve all been there.
First, remember that for every loud and upset voice, there are likely many more Red Hatters who are quietly appreciative of having the opportunity to give input. It may feel as though you are under attack, but there is a good chance that someone is simply expressing their dislike or disagreement. Try to approach them with curiosity, seeking to understand their perspective, before seeking to be understood. Often, this will lead to improved mutual understanding.
Second, remember that you can’t please everyone. That’s not the purpose of this process. When you behave in a transparent, inclusive, adaptive manner—when you’re willing to discuss, debate, and decide—you get better outcomes. You contribute to Red Hat’s unique culture, which we all value. You help sustain high levels of passion and engagement among Red Hatters, and that’s the “secret sauce” that makes our company successful.
In short, you make Red Hat, Red Hat.
