Getting your team to embrace brand-new technology

Recently two Khan Academy devs dropped into our team chat and said they were gonna use React to write a new feature. They even hinted that we may want to adopt it product-wide.

“The library is only a week old. It’s a brand new way of thinking about things. We’re the first to use it outside of Facebook. Heck, even the React devs were surprised to hear we’re using this in production!!!”

Great. And so my stodgy old brain entered Phase 1.

Here’s a sneak peek for you, brave proposer of new tech, inside the heads of your teammates.

The 8 phases your teammates’ brains go through when you propose a scary tech switch:

  1. Someone in chat is talking about some new thing called “React.” It’s probably used for mapreduces or something. I’m hungry, gonna grab dinner.

  2. N/M LOL, the library they’re interested in is client-side magic that’s only a week old and would represent an entirely new way of writing our app. Plus it’s the weekend. Nothing wrong w/ a little imagination and wishful thinking.
  3. WTF, these people are serious. Don’t we have bigger problems to solve? Do we really need to inherit all the issues that come w/ a whole brand new set of client-side coding patterns right now? Time to demand some well-thought-out answers.
  4. BUT but but. I get that you love the library and it’s cool and it actually does make a difference for us and our users. But what about our i18n code? But what about our server-side templates? But what about our entire existing codebase? But what about our onboarding process? But have you thought about other alternatives? But why now?
  5. Hmm. I see value here. Lots of devs are affected by this, though — do they know about it? Who’s owning this transition? What’s the plan for old code? Is there a rule of thumb for new code?
  6. I see the big picture and how the transition might work. Good luck, you’re now directly responsible.
  7. I sure am glad I thought of this whole React thing. I am so, so brilliant.

Now you know what you’re up against.

Your job is to create a wormhole that transports a developer’s brain from Phase 1 to Phase 8 and then shove everyone on your team through it. Here’s how.

  • Know that your proposal is scary, but not because it’s new tech. It’s scary because of uncertainty about all your old code and habits. So you can’t bring somebody to Phase 8 just by selling them on benefits of the new tech. You have to sell how well you’ve prepared a transition for your team.

  • Schedule a plan to help others understand, share your proposal, listen to concerns, and then communicate a decision.
  • For every word you spend talking about the tech, spend two talking about your transition plans. Trying out the tech on one live feature before you want to suggest it for everybody? Say that. Tell the team exactly when you’ll either remove the experimental tech or talk more about team-wide adoption.
  • When doubters pile on, tell them exactly when you’ve scheduled time to discuss more. You’re trying to be brilliant and experiment — not the time to be burdened by early doubters. Sidestep them. “You’re absolutely right, there are a million problems. I’m working on a blog post right now to help others understand React, and I already scheduled a tech talk next Friday for us to go over all concerns before any big decision is made.”
  • Stomp down every conceivable objection before others even get a chance to raise their hand. By the time you want to propose a team-wide change you’ll have been thinking about this longer than anyone. Show your team that. Mention every objection upfront. Mention the alternatives you’ve considered. Honestly acknowledge pain points. Don’t wait for others to do it for you.

You’ll be seen as the clear owner of this decision. Nobody will want to waste their time agonizing over objections because you’ve already done that for them and provided answers.

Exactly how it should be.

Imagine you drop into your team’s chat one day…

…and you write this:

There’s a new JS library out called React. It’s promising but a bit scary. I’m playing with it for my new feature to try to learn more, and I think it’s possible we’ll want to use it everywhere in the future. Before making a team-wide decision like that, I scheduled a tech talk on Friday for us to discuss. I’m writing up a blog post before then that’ll teach others about the library and why I chose it. Read it, then bring all your concerns on Friday. I’ll have a plan for transitioning old code if we want to move forward, and if we decide this isn’t right for us I’ll undo my experiment.

…well. That’s a wormhole capable of transporting even your stodgiest, oldest teammates’ brains straight to “Phase 8: I thought of this and I am so brilliant.”

That reminds me: look’it our smooth math content editor

All the math formatting in this very serious example makes it hard to preview the content as it is being edited.

Our renderer, post-React, is on the left. A typical math editor’s preview is on the right. Ben Alpert and Joel Burget can tell you more about how they’re using React to make this so buttery. It’s absolutely brilliant. I’m just glad I thought of it.

Thanks go to Ben Alpert for draft-reading and to Fleetwood for bandana-wearing.


Leave a Reply

Your email address will not be published. Required fields are marked *