I tend to take short contracts — 3 to 6 months. That means even on day one, I am already planning for my upcoming departure.
This is a good thing! The positive effect I can have on a project is extremely limited if I am just writing code by myself. Writing code, designing features, and other direct interventions are necessary, because the work cannot get done without them. But they are arithmetic improvements — each commit I make or wireframe I produce pushes the project forward one step, and then stops. I am very aware that if I only do that kind of work, then my six months of contributions will be buried and forgotten very quickly.
There are other kinds of interventions, though, that are less direct but result in ongoing, geometric improvement:
- If I make a common development task easier, that helps now and also again and again in the future.
- If I teach a junior developer how to do something they didn’t know, I am contributing to the immediate feature they’re working on, but also features they’ll work on for the rest of their career.
- If I improve the way a team assesses which features to implement — by changing user interview tactics, or increasing the accuracy of estimation, or giving the product owner a new perspective — that can avoid huge swaths of unnecessary work.
- If I make an introduction and help bring a valuable new team member on board, they can continue to contribute long after I’m gone
- If that new team member not only builds good software but also contributes in these geometric ways, that’s an immense dynamo of ongoing change kickstarted by a single introduction.
All of these contributions will continue to yield benefits long after I have moved on to other projects.
Every project, no matter what kind, requires direct labor — it’s still important to put in the raw work. Beyond that, though, spending some thought and effort on these higher-order contributions can let me feel satisfyingly productive even on a sick day, or long after I’ve completed a contract.