The Key Success Factors

Figure out how Promyze can succeed (and fail) in your context.
Before deploying in your organization, we consider that 3 requirements should be met for Promyze to succeed.
If all of them are met, then we bet Promyze will be smoothly accepted and integrated. Ready to get started?
If not all of them are met, no worries: you can still start your journey with Promyze, but keep in mind the points where you could improve and the risks of not addressing them.
If none of them are met: if you're here, it means you're at the beginning of raising a new culture in your context, and that's great! You can contact us to tell us more about your context, and we'll assess together what's the best strategy to start your experience with Promyze.

1. A culture of sharing standards

Your organization must have a global culture that emphasizes and supports sharing best practices and coding standards. This culture targets breaking knowledge silos and thus encourages any initiative that fuels knowledge sharing. In terms of culture, you might be in one of these 2 scenarios.
  1. 1.
    You have a solid culture and use tools to structure and organize your coding standards, such as Wikis. Still, you want to ease how these standards are shared, discussed, and validated while closely integrated into the developers' environment. Promyze will take you to the next level.
  2. 2.
    Your culture is still emerging, and you currently have no best practices or tools to structure them. Promyze will help to grow and sustain this culture.
Engineers must be convinced this helps to improve the source code quality, remove latencies during code reviews, and boosts the onboarding process.
Bad smell: Contexts where people don't see the value of sharing best practices with others. Promyze won't deliver much value there.
Good smell: whatever its technical level or maturity, contexts where engineers enjoy learning from others and sharing knowledge are likely to make the most of Promyze.

2. Clear motivations for sharing practices

Why should you define new best coding practices tailored for your organization and its teams/domains/projects? Because you have a clear vision of what value to expect from that, including, for instance:
  • Preventing bugs from happening again;
  • Improving your lead time for changes by reducing latencies during code reviews;
  • Keeping the source code consistent and easier to maintain;
  • Speeding the onboarding process.
Assessing your motivations to share your coding standard and communicating them internally will help people to understand your vision and ensure we're all aligned in this quest.
In some contexts, such as teams practicing mob programming every day, usage of Promyze is less relevant, even it makes sense to record practices explicitly in addition to oral transmission. In this case, Promyze would make sense for sharing these practices with others teams in the organizations.
Bad smell: Contexts where people don't know why Promyze is here and what value we expect from it.
Good smell: Engineers onboard on Promyze with a clear vision of what are the company's motivations for using the tool.

3. An involvement of tech leaders

Whatever the size of your company, Promyze will most often gather workspaces with a moderate number of people (< 20). And for each space, a small group of engineers will have a key role in the animation of the workshops. This will typically be assigned to a Tech Lead as one mission is to promote best practices in their teams. They should inspire others and use Promyze as support to accomplish this work.
Someone must take the lead on continuously improving coding standards for each context in your organization. If they are under pressure, have no time for doing code reviews, and don't contribute, this will probably negatively impacts their team, who will also stop contributing. To assist the Tech Leaders, external help such as technical coaches can have a great impact.
A best practice can be is to write down a table in your Wiki to give visibility on that, such as:
Space name
Tech leaders
Space "Back-end"
Sofia & Paul
Space "Front-end"
Ben & Lucy
Bad smell: No one in the team is assigned to lead workshops in Promyze, resulting in the absence of contributions from the team.
Good smell: A Tech Lead (or several) is responsible for ensuring Promyze will be part of the team's life.

More resources