Leaving a job can be difficult. I recently left my position (for a number of reasons), and though I am satisfied with my decision to do so, I will sorely miss my teammates and the mission-focused work that we did together. I will be cheering them on as they continue to empower people to become financially literate and stable.

While it is fresh on my mind, I wanted to document what I feel went well in my transition and what I feel could have gone better.

I did not burn any bridges.

All too often, people become consumed by their grievances--both real and imagined--and seek to redress them as they make their exit. Many people will allow themselves to become disgruntled (or perhaps that led them to leave in the first place), and then act out of character in spiteful or reckless ways. They may air out their team's dirty laundry by gossiping or bad-mouthing their teammates during the exit process. They may complain about the organization or its leadership. They may disrupt and negatively influence their teammates who are choosing to stay with the employer.

All of these patterns of behavior are childish, counterproductive, and unfortunately all too common. What does one hope to accomplish by engaging in them? What solution is there to be had when the ultimate solution (leaving) has already been effected?

There were issues that I had with the organization which led to my departure, but ultimately, I chose to cite the least inflammatory issue as my reason for leaving. I refrained from bringing up any grievances that I might have felt because doing so would not have achieved anything other than perhaps alienating myself from the organization or hurting my teammates' feelings. At the end of the day, I no longer felt good about working there anymore, and so leaving was the solution.

I tied up all my loose ends, and did my best to help make the transition smooth.

My departure was fairly sudden--even to myself and my family. One day, I realized that this position was no longer the right place for me to be, so I set myself to the task of finding a new source of employment. Two days later, I had accepted an offer as a Ruby developer with another company and put in my notice.

On the same day that I gave notice, we found a configuration issue with our billing service that required code changes to multiple apps and serverless functions. Additionally, we had just implemented a new bundled product experience that required UX tweaks that had implications for several of our organization's platform service integrations. Furthermore, we decided that standing up a new app to unify our existing apps was the best way forward, given architectural and UX considerations.

Oh, and the contractor who would be replacing me was going on vacation and would only have a single day to transition with me.

Luckily, I cultivated relationships with several of our platform services teams over the years, and was able to lean on them for assistance in knocking out a lot of the work that needed to be done. Also, I was able to pull in members of my development team so that they would get some much needed exposure. Ideally, I would have been able to transfer the knowledge of the various platform service integrations that I had with them sooner, but our operational tempo was simply too high for us to effectively cross-train. In hindsight, I think that I should have raised a flag on how siloed/specialized we were becoming; I'll certainly watch out for this in future teams.

The contractor and I had also worked together before, and we were able to make significant progress in roughly 4 hours worth of meetings that we were able to squeeze in (and record for posterity!) He had some familiarity with our codebase from previous work, and much of the architectural design decisions were documented in ADRs, so it was fairly simple to get him up to speed.

I timed my exit in such a way that it caused the least amount of disruption to the team as possible.

I mentioned that we had just made a decision to unify our product offerings into a single bundle (which requires a significant development effort to accomplish), so at first glance, it may appear as if I left right when my team needed me most. Although I can understand why someone might think that, the opposite is true: my team would have been in a much worse position had I stayed until after we had discovered, decomposed, and assigned the work items. At that point, I would have committed to taking on a significant amount of work, which would have left them scrambling to complete the work that I was no longer doing. Deadlines would need to be revised and the effort itself might have needed to be scaled back. By leaving in the infancy of the project, I gave my teammates the ability to adequately plan for and estimate the effort upfront.

I did not adequately prepare my team for my departure.

This stings a little to admit, but honestly, I should have done a better job in laying the groundwork for my eventual departure from the team. I hinted at some things that I could have done better above--let me lay it all out: I did a poor job of cross-training the other developers on my team; I allowed us to become specialized to the point that too much knowledge was siloed. Although I did document our architectural decisions, I could have done a better job of documenting how our apps integrated with our platform services as well as other 3rd party services. I did not make time to knock out the operational work that would have reduced the cognitive overhead associated with learning our codebase. There are so many tickets that I have sitting in the backlog which would have improved the codebase, but we never seemed to have time to pull them. I did not give my leadership a heads-up on how I was feeling in the lead up to my decision to leave. This was largely due to my fear in how that would have been perceived. Ultimately, I should have summoned the emotional courage to have the tough conversations earlier, which would have given them time to proactively plan for it.

Leaving a position is hard, but I am satisfied with how I went about leaving this position. I am confident that I am leaving the organization and the code better than how I had found it, but there are some considerations that I want to keep in mind as I move into my next role.

The big thing that I am going to have to ask myself in the future is this: "Am I working in such a way that I am empowering my teammates to succeed in my absence?" I encourage you to ask the same of yourself.