I listened to episode #10 of The Law of Raspberry Jam about coaching past resistance, and thought I’d share a little anecdote on the subject.
I was coaching a team who were constantly stressed out with upkeep of old stuff – both old production code and development tools.
My opinion was that the team should try to minimize the amount of tool administration we had to do ourselves by switching to GitLab, which was under the central IT department’s maintenance.
This would mean we could ditch a number of Jenkins installations by using GitLab CI. We could dump the totally out of control Kanban board in Trello and use GitLab Issues. We presided over a vast system flora. I spent many hours every week keeping Trello in order. The rest of the team didn’t want to touch it because they didn’t understand the structure. Branching would also be easier, as merging was a constant pain with SVN, and getting commit references to issues as an added bonus.
We discussed it during several team meetings but the senior members were not keen. They did not think a move would be worth the hassle.
Why were they “resisting”? Because they were stressed out! They were not open to change because of the workload they were under – plus some organisational issues that I won’t get into here.
Working alone during the days between Christmas and New Year, I made a test migration from SVN to GitLab just to see how painful it would be. It was a breeze. It was really easy. So I wrote a tutorial on how to do it and decided we were moving.
On returning from holidays the team migrated almost all the systems within a couple of weeks. One of the guys quickly wrote a CI worker so it would be easy to ditch Jenkins.
But there was still a lot of resentment about the switch and things got a bit sour at times. It took a long time for the team as a whole to accept the move.
So, did I do the right thing? Yes and no.
- The stress level was reduced once the team got used to the new tools and we could ditch most the old stuff.
- When moved from Trello to GitLab Issues the structure was improved so much that the team could manage it without my input.
- Because of the resentment, as a coach I was crippled for months. I couldn’t suggest any further changes until this move was accepted. For the team it was a big thing.
- For me, on a personal level, it was very stressful. This had been my decision and I had to take a lot of gibes every time there was a perceived “problem” with GitLab. I had to be be humble about this and help out, even though the solutions to most problems were only one Google away.
So, in hindsight, was it worth it?
Yes, I actually think it was. Things turned out for the better.
But! And this is a big but.
As a coach, I shouldn’t have taken the responsibility for fixing this problem. In that sense, I did both myself and the team a disfavour. However, in the end, it led to the team being less stressed out and more autonomous because I didn’t have to take responsibility for the Kanban board.
If you make this kind of decision you need to be aware of the consequences.
I got lucky. The change was eventually accepted, but it could potentially have cost me the trust of the team.
So it was a gamble and I am not 100% sure I would do it again.