Finding the right problem
Early on at Slack, I wanted to make a bigger impact. My manager pointed me toward Cypress testing as a way to catch bugs earlier in development. That thread of exploration eventually grew into a full reliability initiative.
If you don't have a clear lead like that, start by asking yourself a few questions:
- What is the team doing well?
- Where is the team struggling?
- What am I good at?
- What do I want to learn?
The first question is rarely where you should spend your energy. Instead, look for the overlap between the team's pain points, your existing strengths, and what you're motivated to pick up. Run your idea past a manager or a peer to sanity-check that it's worth pursuing.
In my case, the team wanted to find bugs before customers did. I had zero automation testing experience, but learning Cypress genuinely interested me, so the fit was clear. Once I identified that intersection, I started spending extra time studying Cypress and its existing usage.
Making the case to stakeholders
Every initiative has a cost, whether that's pulling people off other work or simply the opportunity cost of choosing one direction over another. Your job is to make it easy for stakeholders to justify that cost upward. This isn't a fight against them; it's a collaboration.
Start by gathering data that explains what you want to do and why it beats the alternatives. Bring other engineers into the conversation early—a critical mass of interested people often makes the value obvious.
Change takes time, and you'll likely have to push through a slow stretch before things gain momentum.
During my initiative, I used a public Slack channel to broadcast findings about Cypress and log small wins. I'd tag stakeholders whenever I made an improvement or found data showing how Cypress could have prevented an incident we hit. Over time, that started organic discussion in the channel.
Documenting the process publicly felt counterintuitive—it exposes your missteps. But that transparency humanizes the work and gives stakeholders a full picture of where things stand. A public forum lets people truly understand what you're building, and it eventually becomes the place where the initiative gets driven forward.
Scaling beyond yourself
An initiative can't stay a solo project if it's going to have lasting business value. Growth can happen organically or deliberately, and you need both.
Organic growth comes from awareness: talking with other engineers, demoing to your team, sharing the work openly. In my case, engineers started posting to the channel I'd created because they associated it with Cypress—it became their entry point.
Intentional growth is equally important. Once you have stakeholder support, you can nudge priorities, suggest roadmap items, or simply ask other engineers what would get them involved. Every conversation keeps the idea in people's minds.
I remember a review meeting for a production issue where we collectively realized a Cypress test could've prevented it. An engineer who'd been quietly following the channel volunteered to write that test. That mix of organic interest and deliberate cultivation is how the initiative began to scale.
Metrics are the part people forget. Stakeholders won't stay on board just because you're excited.
If your pitch was “fewer bugs,” show the bug count trend. If it was “better engagement,” show that trend. Whether you believe it's working or not, demonstrating quantifiable value is non-negotiable if the initiative is going to survive.
Handing it over
Eventually an initiative outgrows its founder. It becomes part of team culture, a standard process, and it stops being “yours.” Releasing control can be difficult, but the ownership shift is a sign of success.
At that point, reflect on what comes next. Can you improve the initiative further or expand who benefits from it? Is it time to start working on something else? I'm still heavily involved with Cypress, but I've recently started steering time toward TypeScript, which touches reliability while giving me a fresh set of problems to solve.
There's no formula for launching an initiative, but the core is consistent: find a genuine need, document your work openly, involve others, prove value with data—and then let it go.
