views:

148

answers:

4

With all the news of layoffs, developers may ask themselves, "I feel like I personally contribute a lot to this company, but I'd like to make sure it does as well as possible when I move on to greener pastures".

In my last job, I had setup, maintained, and shared a number of useful tools for myself, like automated builds and source code browsers, and lead the team in releasing our product reliably on a schedule. Then I left, and every other developer on my team quit within a few months, and I'm pretty sure those things don't happen any more. I know I can't write a book "How to be a developer with several years of experience at this company", but what should a conscientious developer do to make sure the culture they built continues? Should we do the opposite for job security?

They say every McDonalds is run exactly the way Ray Kroc wants it to even though he has been dead for many years. Is this even possible or desirable with software?

+1  A: 

Some of my key thoughts:

  • On one hand, company culture is a function of who the employees are at a given time
  • On the other hand, codified standards can establish some of the better practices. If automated builds are working for you, write that up as This Is How We Do Development Work Here.
  • New employees may have other new ideas that will enhance the productivity of the group, given whatever projects or people are at a place at a given time
  • In software particularly, things will change. New systems - bug trackers, testing tools, etc. - will come into play. The How We Do Development Work doc should evolve over time
  • Protect the future starting today: Hire only smart, conscientious people who will also hire smart people, all of whom would gladly follow useful processes.
David
+5  A: 

It's not your responsibility.

If you've managed to build up a positive culture (and starting it and keeping it going to start with is the really hard part, particularly if you faced opposition) and the company can't or won't keep the momentum up when you've gone, that's their fault, not yours. It may well be the fault of incompetent managers - or it may be the devs themselves who can't get their act together without strong leadership.

Having said that, you may find that just keeping in touch with some of the developers and nudging them to suggest improvements (or "let's do X which worked when Daniel was here") could be helpful. But don't worry about it too much - let go :)

Jon Skeet
How does Jon Skeet do it!
joeforker
A: 

As someone who has inherited a number of situations like this, simply ensuring that all source and documentation is in a repository before you leave makes a massive difference.

nzpcmad
+2  A: 

That's a really tough question. You have to be aware that the only person's behaviour you can control is your own. If you set a good example for team members while you are part of the company it can only rub off on them in a positive light.

When it is time for you to leave just be as transparent as when you worked there. Make sure where ever possible that you dot the i's and cross the t's. If you forsee a possible future problem try to make them aware of it but not as a prophecy of doom.

Simon MacDonald