Last week our question of the week was “how do you convince your teammates to use XState?”

One of our most frequent requests for the documentation is more advice on how to convince others to use XState. Many people read an article, watch a talk or participate in a workshop about XState and are sold on using XState themselves. But when it comes to getting their team on board, they often need more.

Thanks to all the wonderful folks who answered our question posted to Twitter and in our #office-hours Discord channel, we’ve got some fantastic suggestions.

Present using the Visualizer

Many people immediately understand the benefits of statecharts as they’re familiar with diagrams using “boxes and arrows.” The Visualizer gives you an instant, recognisable overview of your application logic, which is often enough to get them on board.

Give examples using their own work

Nick Hehr takes it step-by-step, utilizing the Visualizer.

And Farzad successfully convinced his team. We discussed his success in our office hours last week.

Give them side-by-side examples

Amy Pellegrini recommended many complementary approaches, starting with comparing XState to other types of state management.

This might be an intensive approach, but it’s the ultimate way to show the benefits of XState.

Show existing projects that are using XState

We’re all more convinced by a technology when we know it’s already being used by projects or organisations whose work we admire. Amy Pellegrini suggests taking advantage of that:

Dictate the use as team lead

A few people are fortunate enough to be leading their teams, and of course adoption is much easier when you can just tell your team to use XState from the top.

Cédric:

I have said: "We will use XState" 😂

Become the expert so you can answer their questions and help them progress

But not everyone can be the boss. Amy Pellegrini recommends becoming the XState subject matter expert, so you’re better prepared to support the rest of your team.

And Josh Ferrell suggests collaborating with your product team, showing them how to model with the Visualizer, enabling them to do the modeling themselves in the future.

Tell them that the Stately team is fast and responsive

Knowing a technology is under frequent development, and the developers are likely to respond to your feedback, is important to most of us when we’re embedding a new tool into a key part of our workflow. Cédric on our Discord uses this as a way to convince his team to work with XState.

Xstate team improve the project really quickly, office hours give a good idea of the roadmap and features, when something is propose there are a real discussion and project improvement from only “an idea” on discord

Thanks Cédric!

Promoting the collaboration benefits

At Stately, we’re excited about the potential for collaboration with our Visualizer and Editor. We want to shrink the space between planning, design and development, helping the whole team work together on their application logic. Cédric agrees with those benefits.

The Viz is a real support to share business logic between product and tech team, this could be add[ed] into a specifications and of course with the futur[e] way to create machine by a simple drag and drop this offer[s] the possibility for the product team to create themselves a real machine useful [for] the tech team

Timing it right with a good use case for the team

On our Discord, Jan has a carefully planned approach:

I received the task to build some pretty complicated UI components, and I opted to build them with simple state machines, implemented as good ol' switch-based reducers. Since we're using Redux, this approach didn't alienate my team entirely, and so the seed had been planted.

Fast-forward a bit, and we're currently rewriting some of the core of our application as a state machine (or something of a Frankenstein statechart), after receiving new requirements would make it completely unmaintainable if we had continued in the same tracks. We're still doing it with switch (with nested states, even!), which isn't optimal, but it's way better than where we came from.

For now it does the job, but my plan is to note any pains which could easily be solved with XState, and propose a rewrite if/when the time is right. I figure it will be a much easier sell if my team is already somewhat familiar with the concepts of state machines, and we have a really good use-case on our hands.

Finding the right timing for your team is key for introducing any new technology.

Make them less intimidated by the terminology

And sometimes a team is rightfully cautious of trying a technology that comes across as new. It’s all about how you frame it…

😂

In the future we hope to provide more documentation and advice to help you convince your team to use XState. If you have any suggestions or requests, please let us know on our Discord. We want to make our tools work for you.