I recently got to experience the exquisite joy and excruciating pain of helping to build a new software team for a large, well-established company. We had the mandate to do things differently and to help other teams modernize. While a lot of things went very well, I think the most helpful, or at least entertaining, things I can write about are what didn’t go well and why. So, at taking the risk of being a prescriptive hypocrite, here’s a list of what I think you should not do.
1. Do not muddle the message.
It’s about Agile! It’s about Lean Startup! It’s about DevOps! It’s about a green-field project! It’s about The Cloud! It’s about Open Source! It’s about automation! It’s about whatever personal pet perspective you care about. Yes, when your mandate is to innovate, you’re going to work with different tools and techniques, but If you’re known as “that cloud team” or “that agile team” you’ve lost control of your own identity. You should be about innovation, experimentation, and letting go of the way things have always been done. Everything else is just implementation details.
2. Do not change the experiment halfway through.
A few months into the project, a new executive informed us of the new reality. “You guys have been operating all on your own. That ends now.” Looking back on it now, that was the moment when all value in the experiment was lost. We started working with the existing processes (which nearly everyone agreed were terrible).
Between the radical process change and the lack of clear messaging, any person could take any result and use that to validate their own existing opinions. If the project were a huge success, it was because of technology X. If it were a failure, that was obviously because of process Y.
I don’t expect a lot of scientific rigor, but seriously….
3. Do not keep things a secret.
I fear that I’m being a little unkind to the anonymous executive in the point above. He was reacting to the fact that we were completely opaque. Apparently (I didn’t know this at the time) other groups in other offices were either not informed that we existed or specifically told to not interact with us. A more sustainable approach would have been to have full transparency, along with broad autonomy, from day one. Other groups should know what’s going on, and even to give advice and suggestions, but not to swoop in and micro-manage.
4. Do not piss all over other people.
One of the first things that our team did was to look at an existing project underway from an existing team and to throw it away entirely. From a purely technological perspective, that may have been a good decision, but it was, if I may speak plainly, a total dick move. That, coupled with our opacity, created the perception that we were a bunch of elitists. I always wanted to be elite, but not elitist. We never wanted to be a group of better technologists. Just technologists with a different mandate and a different toolkit.
The boastful and tone deaf claims of “look at this team getting done in six months what that other team spent several years on” didn’t help matters. If anyone on that other team reads this. You have my sincere apologies.
5. Don’t conflate being an “innovator” with being an “agent of change”.
If your organization is large enough that an innovation lab makes sense, you’ll also need change agents who can evangelize and support changes. These are different things. Your change agents can point at what the innovation lab is doing, which will help work around the developer blind spot, but being a change agent requires more patience and political savvy than being an innovator.
Change agents are there to dismantle the dysfunctional engine, innovators are there to create fuel for new engines.