Software is a game of late night deployments and early morning patches to fix a “new feature” before it becomes a big problem. It’s not bad, sometimes it’s lots of fun, the camaraderie built over some take-out while everyone is grinding on the last release trying to fix the last of the team’s bugs or it’s that bright and early design session to lay out the plan for the day and make it happen – not just talk about it… but make it happen… really, really make it happen.
Those are the best moments that I remember, when you are working with your fellow team members to meet a goal or a deadline – it doesn’t get much better than that.
There is a lot of literature and media that always surround the success of a project that it always comes down to one person. This guy/gal made the difference, they were the saving grace, they were the hero – time to step aside everyone because we have a new hero in town. But it’s never the true, honest case – because while buddy cranked out that last piece of code, the rest of his team were making sure the other projects of the team didn’t fall off the radar and QA put in some extra OT to make sure that the fix actually did what it was designed to do (and didn’t create some wacky new feature in the process). Are they no less than everyone else on the team? It’s the team that has to come together to make your projects a success and yes, some times you need a hero to jump in and save the day, but a hero shouldn’t be one person, it should be a team.
The problem we fall into too often, is a person steps up and becomes the Hero in a release or fix and we keep propping them up as the hero, not recognizing that what we really need is to create a whole team of heroes that are interchangeable and contribute in exactly the same way.