Communications of the ACM
Evolution Through Revolution: Getting Your Team to Embrace Change
Some years ago, I joined a Java programming team as an architect. When signing up for the gig, my boss gushed over how talented the development team was, and that while the architecture could be improved, it was still a good foundation. No problem, right? After all, they hired me to drive change and if the team was as talented as promised, cleaning up the architecture wouldn’t be an issue.
It took only a few weeks for me to realize that the reality on the ground was far different. For one, most of the 30 programmers on staff were quite junior. While some of them had drive and gumption, many would have struggled to explain the difference between a static method and an object method.
Oh, and the promised "good" architecture? Nothing more than an amalgamation of .java files compiled by different people at different points in time. There was little rhyme or reason to the "architecture."
Neither of the above problems were necessarily critical. If the junior programmers were talented and driven, they’d pick up the skills. And so what if the architecture was a mess? So long as there was a willingness to change, that could be addressed as well. It might take awhile, but patience and effort would pay off.
"Willingness to change", it’d turn out, was the critical issue. Most of the developers on staff had already learned a particular approach and relied on a specific set of tools. Many of the tools the developers had fallen in love with were widely hated by true OOP programmers, including Spring, MyBatis, Singletons, as well as getters and setters.
I faced a serious challenge: I needed to shake things up on the development team, but I was an outsider and newcomer. I had little political capital, no pre-established relationships, and while I had my boss’s support, I didn’t have the mandate to institute radical change, especially not overnight.
If I had simply banned Spring, I may as well have put my contract through a paper shredder. Termination would have been a matter of "when", not "if." Instead, I instituted a sort of guerilla campaign, building up resources and striking when the conditions favored me.
My long-term goal was to get the entire team to evolve and to embrace change (meaning: better practices). In the short run, that meant building my own "minority team", and crucially, one that would support my vision for change.
"Revolution", however, was a threat to most of the programmers, and especially the ones with the most experience and seniority. I didn’t blame them. Evolution was a threat to their careers. If I were in their shoes, I might have been tempted to resist change myself.
Still, something had to change. The question was how to build my minority team that would champion change.
The first step was to reach out to the younger programmers, and I don’t mean in terms of age but career-wise. Newer employees are often less resistant to change and more open to revolution. I picked the best, and by this, I mean those most eager and willing to learn.
After some conversations, I narrowed my team down to seven programmers. It became immediately obvious that they hadn’t been properly mentored and had no growth strategy. That might seem concerning, but for me, it was a benefit. I’d get to start with a clean slate.
Now, what to do with that clean slate? First, I became their unofficial mentor. I started by reviewing their code and providing critical feedback. That feedback was supported by knowledge, specifically blog posts and books to build my case and to increase their own knowledge.
Next, I organized weekly lectures. These were open to all of the developers, not just my team. Yet unsurprisingly, my team attended every lecture while others drifted in and out or didn’t bother showing up at all.
Finally, I refactored some code and had my team review my pull requests. These small but challenging tasks gave my team some meat to chew on, topics to debate, and ideas to hash out. This helped build unity and within a few months, there was genuine cohesion within my team.
My minority team was no longer satisfied with the architecture. Most importantly, they didn’t sit by silently but instead challenged the status quo. This did create tension but also provided the foundation for evolution.
There’s no sugar coating it, my efforts created a divide among the developers. But that’s how evolution through revolution works.
Over time, other programmers drifted into our orbit and got with the program. Genuine discussions about fixing issues emerged. Things were heading in the right direction. Test coverage increased and objects were becoming immutable, among other things. I didn’t eradicate Spring but I did loosen its stranglehold.
I left the team in less than a year, under my own volition. For me, greener pastures laid elsewhere. Still, I planted the seed for evolution.
You can accomplish all of the above, and with time, more. But you have to start today. Don’t wait until you get the "title" to push for change, start now even if you’re a junior developer. If anything, it’ll help you secure the right job titles later on down the road. And even if you are a junior developer, you can still be a mentor.
What you need is the drive, vision, and commitment to fight for change.
Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.
No entries found