It’s obvious when the magic dies.
Great bands are always magical at first. That first release* is always so full of energy, life and collaboration. Inevitably, things go downhill the band starts mailing it in to collect a paycheck. Ever watch a documentary on your favorite band? Next time you do, watch for the moment where the magic dies. First, the band mates talk about how much they like playing music together and how much they care for one another. Soon, they start to talk about the things that come between them and their music. Managers. Fame. Drugs. Money. When these things walk through the front door, the magic slips out the back. The magic is what makes you successful in the first place.
Working on a large software development team is just like being in a band. You have the lead singer in front, soaking up all the credit. The unseen members in the back on bass and drums, laying down the groove. And behind the scenes, sound engineers and managers make the whole process run smoothly. What kind of music are you making? Are you phoning it in? Collecting a paycheck? Putting out crap? It could be your collaboration.
You win as a team and you lose as a team. I don’t care how many Jimi Hendrix’s you have on guitar. If the sound is muddy and the drummer sucks, no one is going to buy it. You need a great team to make a great product. Most product cycles looks like this:
Requirements -> Engineering -> Quality Assurance -> Deploy -> Maintain
Each arrow is a hand off. Want to make better software? You need to collaborate better on those hand offs. Want to collaborate better? You need to CARE about the all the steps in the chain. Not just your step. It’s your job to make everyone else’s job easier. Stop trying to cover your backside and think about who is catching the crap you throw over the fence*.
If you are writing code, make sure it passes the test cases before handing it off to QA. Spent a few hours tweaking something to get it right? Add some comments for the person who is maintaining it. Don’t just let your app blow up when it goes to production, try and give DevOps as much warning as possible.
Writing requirements? Make them concise and actionable. Think about the behavior for error cases and document it. Add success criteria so that the team will know when it is good enough to go to production.
Email me when Clyde Jones publishes or recommends stories