I always find the most interesting aspect of "we changed from X to Y" to be about why change is happening, how it is managed, etc. Context is everything, but the process described by the OP sounds like standard, top-down decision making. The OP certainly gets to it by the end of the article.
I've gone through this process (tech stack shift), both as a recipient-of-change as well as a catalyst-agent-of-change. Remarking on the email that the OP's CTO sent to everyone, these statements stick out:
"...A technology choice will be made appropriately for the needs as we see them..."
"...no hard decision has been made about our future languages or technologies..."
"...Less C#/.Net, more Scala/Java/Open Source..."
The CTO likely has very good intentions, but this is an implied technical decision that's already been made. He references "we" in the email to imply group participation in decision-making, but it is very much a you-are-with-us-or-you-are-against-us definition. To wit, those who didn't buy in were shown the door.
Having been the guy in that chair, this is not an easy thing to do. Being handcuffed by prior technology decisions is not only difficult, it's often untenable. Usually, the people hired into those leadership roles often have to resolve the decision making issues that got the company to that point. That said, here's what I've learned in terms of how to go about these types of long-term changes:
- As the CTO, take full responsibility for introducing change. This is not taking credit, but instead being the owner of the decision and ensuring it succeeds. Support the team, and encourage them to openly question the decision, so that those questions can be addressed. The CTO's email above makes a change decision requisite, but it's up to everyone else to make it work. To anyone who's worked in a potentially charged environment, that's a typical setup for scapegoating. As the lead dog, don't put your team in that position. If your decision comes off as playing-the-executive card, you have failed.
- As a team member, embrace change but make it completely objective. Be open to change, but only as it helps to reach a goal. Evaluate technologies after using them, comparing them, and finding what's good and what's not-so-good. Make your personal productivity the least-influential point of analysis. If you can't find a way to assess something honestly because of your preference for operation, you're doing yourself a disservice. Be productively critical of technical decisions -- your own, and others.
The Technical Strategy email was sent out about midway through our adoption of Scala. I didn't explain the dynamics of our larger development department much in my post, but at that time we were essentially two teams in two different physical locations. The location I was at had already seen success with a few projects in Scala (BeetleJuice and the beginning of our API). Our CTO thought it was time to set a clear direction for the future of development department after an analysis of our current situation and discussion with members of the wider team.
Nobody was shown with the door. I'll admit there was some resentment, but nothing a well adjusted developer couldn't get over.
As I mentioned at the end of the post, one thing I would do differently in the future is make a stronger effort around consensus building about the decision. However, the Scala change started off as something small and organically grew into a legitimate alternative to the Microsoft stack. Going into our first project (BeetleJuice) we didn't anticipate the impact it would ultimately have on the organization.
Cool, thank you for the context (which is everything in these situations.) And apologies if I implied things that weren't the case; just my reading/interpretation of the post.
My primary criticism of the CTO's email was that it didn't seem direct, which I've found is the most important aspect when communicating in that role. With all the intentions of being inclusive and providing avenues for flexibility, I've found the interpretations are most often viewed as ambiguous. The higher up the chain, clarity becomes so much more important. Live and learn, in my case.
In terms of consensus building, I had to do the same thing. For me, we accomplished that through objectivity -- we were constantly evaluating. We asked team members who liked technology A to provide brown-bag sessions on technology B. We had "skin-the-cat" sessions, where we would have a team of two or three implement a somewhat basic solution in three different ways (you know, nine ways to skin a cat....). It took some doing, but essentially what we did was enable developers who might not be so flexible to considering alternative technologies to get comfortable with those by spending time using them and providing an opportunity for them to say "this sucks" or "this is awesome". The team, as it was constructed, really responded well to this. Not only did they feel involved, but they were also tacitly preparing themselves to accommodate a shift, no matter which way it went. I was really surprised at how well the team became empowered; it was not something I was expecting to see.
Your CTO definitely had a tricky process and conversion to balance. I empathize, it's so easy to do a mediocre job with things that one wouldn't expect to matter quite so much.
I've gone through this process (tech stack shift), both as a recipient-of-change as well as a catalyst-agent-of-change. Remarking on the email that the OP's CTO sent to everyone, these statements stick out:
The CTO likely has very good intentions, but this is an implied technical decision that's already been made. He references "we" in the email to imply group participation in decision-making, but it is very much a you-are-with-us-or-you-are-against-us definition. To wit, those who didn't buy in were shown the door.Having been the guy in that chair, this is not an easy thing to do. Being handcuffed by prior technology decisions is not only difficult, it's often untenable. Usually, the people hired into those leadership roles often have to resolve the decision making issues that got the company to that point. That said, here's what I've learned in terms of how to go about these types of long-term changes:
- As the CTO, take full responsibility for introducing change. This is not taking credit, but instead being the owner of the decision and ensuring it succeeds. Support the team, and encourage them to openly question the decision, so that those questions can be addressed. The CTO's email above makes a change decision requisite, but it's up to everyone else to make it work. To anyone who's worked in a potentially charged environment, that's a typical setup for scapegoating. As the lead dog, don't put your team in that position. If your decision comes off as playing-the-executive card, you have failed.
- As a team member, embrace change but make it completely objective. Be open to change, but only as it helps to reach a goal. Evaluate technologies after using them, comparing them, and finding what's good and what's not-so-good. Make your personal productivity the least-influential point of analysis. If you can't find a way to assess something honestly because of your preference for operation, you're doing yourself a disservice. Be productively critical of technical decisions -- your own, and others.