In my last blog, I emphasized how a compelling reason to change is a fundamental precondition for starting a project to product journey. In this blog, I take that a step further and discuss three key characteristics that your organization should create as they take their first steps.
Start small
It’s critical to generate early wins and gain momentum as you begin your project to product journey. In every organization we find pockets of resistance focused on maintaining the status quo. A compelling reason to change will go a long way in motivating people to move from their current state. I strongly recommend going deep with a small part of the organization (instead of going wide and spreading the initiative too thin early on). I’ve also found it incredibly impactful to spend more time with fewer people. This will generate enduring engagement, enthusiasm and energy from those involved.
Finding time to talk one on one and allowing people space to voice their concerns will foster mutual understanding and trust, two essential components for change. If you’re taking on too large an area early on, you simply won’t have time for these critical conversations. If you start big you may initially find that it feels like you’re moving fast but typically that momentum isn’t sustained and things begin to regress. At that point you’re in an even worse position because parts of the organization will say “we tried it and it didn’t work”, which can tear a hole in the sail. At these early stages, it’s best to focus on quality over quantity to demonstrate what’s possible. Never underestimate the power of the old adage of “seeing is believing.”
Build leadership engagement for the project to product journey
Business and technology leaders will often be the first to feel a compelling reason to change. This will provide the necessary spark and critical investment required to reach a preferred future state, but their participation can’t stop there. At Tasktop, we’ve long known that an organization’s culture flows from the top, a pattern that we repeatedly see with our customers’ project to product evolution. It’s important for leadership to regularly assess metrics that simply and effectively illustrate how the software delivery work is meeting business outcomes. Visualizing and measuring how work flows across product value streams aligned to business results helps them to do this.
The Flow Metrics dashboard enables them to baseline the current state of their value streams and pinpoint where investment is needed to remove friction impeding flow. By clearly defining the business outcomes their product teams are delivering on, leadership can reiterate “the why” to reinforce the mission for cross-organization alignment and focus. Not only can they better comprehend the team and cross-team challenges, but they can also celebrate those key wins along the way. “The platform product team cut feature delivery time by 25% this quarter!” By staying involved and able to “talk tech” in a language everyone understands, leadership can ensure the investment generates the greatest return possible.
Empower teams to own their journey
As you select the first small slice of the organization to initiate your journey, I strongly recommend selecting an area that can independently produce value. If you select an area so small that they can’t bring value to production, you’ll find the wins that are generated are so small they go unnoticed. Choosing a team that only owns the last mile of the development journey, for example moving code into production, will invariably quickly run into upstream bottlenecks limiting their ability to work on the most important blockers. Instead, choose a thin slice of the organization that can define, build and deploy value to production. In this way, you’ll get quick exposure into the primary bottlenecks and be able to influence improvements in the areas that matter most.
Additionally, it’s essential these teams are empowered to directly make changes. Requiring all improvement ideas to be vetted and approved by management will stifle creativity and response time, slowing these early improvements that are so essential to momentum of the project to product journey. These teams should have control over how they develop solutions to the challenges they encounter. Allowing teams to dream and implement alternative ways of working will enable them to own not only the change but the results as well. I’ve found this creates a more motivated and energized workforce that can rapidly improve in ways that matter most to the business (outcomes like time-to-market or product quality).
