- Get the support you need first.
- Make stakeholders engaged by adding value.
- Promote it within the team.
- Learn to let go (pass the ownership, support oncoming leadership initiatives)
- Keep growing it.
Before starting this task, get the backing you need from your manager and peers. I can't emphasize this enough. Support from your boss comes packed with credibility, authority, valuable feedback, and it will force you to collect your thoughts and think about the problem concisely. If you can't communicate your ideas out loud in a clear and meaningful way, they are probably not worth pursuing at the moment.
The main three reasons I like to talk with my manager before going the extra mile are:
- Making sure my thoughts are in line with the greater vision and plans.
- Making sure to get approval before doing any major work.
- Getting practical advice from someone who genuinely wants the process to improve.
Get out of the idea generation and research as soon as possible.
My strategy for nailing this step consists of:
- Defining the key players - people I need to make this work.
- Including them early, getting the feedback, and making them a part of the solution.
- Doing the job for them by solving an existing problem or a part of it.
I look for quick victories that will add the most value (when stacked together) in the long run. It has to be something people (including myself) care about or something that's bothering them. Then I put extra time into building a working solution. A working solution is not a finished version, but it is robust enough to be used right away and recognized for its potential.
I realized that some people could take it offensively if I take the liberty of solving a problem. Most people will appreciate it, as long as it makes their jobs easier and adds value. That's one more reason to make alliances with your boss and key stakeholders early in the process.
Here are some ideas on making critical stakeholders (people whose work will be affected by the change) interested by adding value?
- Choose a tool that will solve the problem. You can build your solution from scratch if you have time and skills, but more often than not, choosing the right tool is a better option.
- Start and do the work but leave room to grow. Remember, starting something is the hardest part of any activity, so it is very likely no one on your team will begin solving accumulated problems. You have to start, but also, you need to leave some skin in the game, so when people join, they can leave their mark on the project.
- Make your solutions so great that it's hard to refuse them, and their potential is obvious.
Once key stakeholders are excited and contributing, it's time to use our marketing skills and promote our solution to the general audience. These are product managers, developers, product owners, and others whose workflow won't need to change.
Promotion is an essential step in making our new way official and getting more people on board. Once we have a critical mass of people on board (that recognize the value), even the minor contributions will ensure the project keeps growing and getting better.
More contributors indicate we can step back, which leads us to our next move - letting it go.
Here is where the teamwork should kick in and swipe your ego away. Are you a team player? Can you walk away from the project or a workflow you started and set the groundwork? If you care about your team's success, you will have no problem letting your colleagues take ownership. If you are not, you should be because there is no personal success without the team. The same applies to the process.
Here are two ideas that can make this inner conflict manageable:
- Empathy - put yourself in other people's shoes. Most people want to help, contribute, and show their value.
- Create a new mental model based on opportunities. Mental models are like templates for thoughts that shape them according to the situation. Here are some that can help: a.When [Nikki and John] contribute to [this], I will be able to start [that]. b. The next problem I can work on now is [building a weather app]. c. Because [Sue] is contributing, I have time to learn [C#].
When I say "learn to let go," I don't mean "walk away." Keep growing it as described in the next section.
Whenever we stop evolving, the opposite takes place. The same happens with processes, workflows, and work rules. They get out of date, out of use, and eventually, they die.
To prevent this from happening, I like to keep track of all the process improvements I've started and worked on (that do not have a manager who keeps track). To prevent the "Too many cooks in the kitchen" problem, I take a step back to make room for someone else to step in and lead. Taking a break is also necessary from a testing perspective. I need to change my mindset from someone who owns to someone who is using to discriminate against what works and what does not. If a process is helpful and makes us better, we will follow it. If it's not, we will discard or change it.
I like to follow this flow to keep a system alive and well:
"Stepping out > Using and observing > Stepping back in > Fixing and improving > Stepping back out > Repeat"
Considering this system improvement initiative came from within, and there is no external business owner that is tracking results, there is a big possibility that our process will get stale after a while. Since I'm expecting that to happen, I'm ready to jump back in when it happens.
Keep growing. Keep improving.