Planning For My Departure

I have experienced the departure of many colleagues at Mxi, and each time it has been emotional and stressful. Now it is my turn to leave. I wanted to minimize that same gut-punch to my friends and team. So, like Tom Sawyer, I was able to attend my own funeral. The weirdest part was that I played the role of meeting coordinator, in discussing the aftermath of my departure.

The Agenda

As with any retrospective or post-mortem, it is important to have a skeleton of the meeting, to set expectations for attendees. Here was our plan:

  • What does Jonathan do on the team?
  • Which skills or roles will the team need to support?
  • If the team is to hire a new member, what depicts this ideal candidate?
  • What other stressors are caused by Jonathan's departure, and how can we decrease them?

Judgement Day

After some levity about the awkwardness of this meeting, the first activity began. Each team member wrote down the things they believe I had been doing on the team. I was to not participate in this ideation, forcing everyone else to reflect on my visible and invisible roles.

Team Work

Once all the sticky-notes were posted on the wall, the team time-boxed 5 minutes to organize, categorize, and remove duplicates.

Ideation

I was then asked to look over the ideas and comment if I saw anything missing. I did not, but was surprised by many of the items listed by my friends. Their perceptions were deeper than mine; they listed hats I had not realized were on my head.

L33t Skillz

Our next goal was to pick which skills were most important to the team. We discussed what criteria made a skill "important" to us: was it skills we were going to lose, skills we wanted greater redundancy, or highly valued skills the team wants new members to encompass?

Discussions

Once that was defined, we moved to dot-voting: 5 each. We immediately removed any skill with less than three dots, so that we could focus on the top priorities.

Skills

The top skills are:

  • Eye for software architecture
  • Researching and experimentation
  • Enjoys software development (SOLID, DRY, etc)
  • Positive morale
  • Introduces new practices to the team

We iterated on the Morale item as it was vague and difficult to identify in a new hire. We replaced it with Personality focusing on good communicating & teaching and passionate about software craftsmanship

Skills Refined

We discussed if there are people we already knew that might make good additions to the team.

"If you don't try you have already failed"

Stressors

We made a list of any other stresses caused by my leaving. Mostly, they relate to ownership and tribal knowledge, which are problems the team has been trying to aleviate. Each individual in the team is a special unicorn without redundancy protection.

Stressors

Conclusion

Armed with these lists, in the open and known to all, it is easier for the team to tackle the problems and to not feel alone during the transition. This team is composed of a great people, and I know they can achieve lofty goals. I hope that this session (as odd as it was for me) helps the team overcome the chaos I have introduced with my departure.

Satir Change Model

I would recommend having special meetings whenever faced with a disruptive change to the team dynamic, as a means of coping, communicating, and finding ways back to stability.