Thanks for engaging so much with the story. I agree with a lot of the points you make here.
I can’t go into very much detail about the process that culminated in Rick’s departure without piercing the anonymity of the story. Despite the fact that this happened years ago, and that the company we worked with at the time is linked nowhere in the post or on my profile, I don’t want to risk it.
I wish I could provide further detail about the overtures made by management to try and talk Rick back, the various bad behaviors that persisted and escalated through these overtures, or the ways we tried to provide him a soft landing.
There’s one cardinal take-away which obtains to both developers and managers reading these stories. If what you’re doing isn’t working, doing it harder and faster isn’t going to fix it.
If you’re a developer and you’re working in these conditions, you need to open a frank dialogue with management or start looking for better work.
If you’re a manager and you’re laying the fate of the entire project on one developer, you’d better start looking for other work, too, because the project is going to fail. Or the developer is going to leave and the project is going to fail.
I would have liked to have saved Rick. Unfortunately for Rick, the combination of his bad work habits and burnout pushed him into a place from which he couldn’t return. He became a toxic element and we had to part ways.
As for me, well, firing people doesn’t make me happy. But creating the conditions under which a whole team can grow and thrive does. Sometimes that means going through a really painful process first.
We did learn a lot from this experience as an organization, as well. Some of that knowledge resulted in my other posts about documentation and the development/release process. We also restructured, changed a lot of other management processes.
I wrote a breakdown of the most important changes in a follow-up post.