Release engineering isn’t just about building slick tools. Sure, it’s satisfying to finish constructing some elaborate build monitor and find that it works perfectly – that is, right up until none of the developers use it. You go back and look over it, and it doesn’t seem to have any bugs that would prevent it from working, so why is it just sitting there? As it turns out, there’s a fairly big social component to release engineering as well that friends in the IT/administration field can probably commiserate with – you actually have to convince your coworkers to use the tools and associated workflows you painstakingly assembled.

Now, let’s be realistic here: some workflows are never, ever going to change. Some developers are too used to a certain way of doing something; any deviation from that standard will appear unbearably complex to them, even if it actually simplifies things in the long run.

Other workflows are easy to change. These are the pain points, the things that everyone has hated or wanted to be different from the start, and it was just a matter of when you got around to creating a better option. If all of your target problems are like this, you’re lucky – sure, the assembly might be tricky, but once it’s done, it’s really done.

Most things, however, fall somewhere between those two endpoints. There are tradeoffs involved, or there are marginal (or even significant) gains involved with moving to a new process, but most people are “okay” with how things are currently, too – or they don’t really have an idea of how much better things could be. These are the trickiest workflows to change, because without some external influence, there’s no real impetus for a developer to embrace the new way of doing things – or even read your emails describing said new ways of doing them, let alone trying out new tools.

How do you convince people to see the light in these circumstances? One idea in this regard is to treat it kind of like launching a new consumer product. Find the early adopters, the coworkers who are always willing to try out the latest and greatest things, and go the extra mile for them. If they have feedback, address it in a timely manner. Consider adding a few of the small “wow, this is cool, but it’d be even neater if I could just…” features they might mention. If one of them discovers a bug, address it ASAP and then let them know about it personally. Show them you really care about making a great tool, and they’ll pick up on that – and pass the enthusiasm along to other members of their team, which saves you from having to sell it to each of them individually.

What other good strategies for encouraging adoption of new tools and workflows have people run into?


About this entry