Thanks to the Process

I’ve worked on a lot of releases that have come down the wire.  Not always a great trend, but in what I do, it can happen.  However, the best part when it happens, is when you have a team with you, you’re all in it together, it’s late, you’re trying to close the last bug, run the last test, give it one more shot.  I’ve been in these situations as the jr developer, the tech lead, the manager and more and each time you know you’re going to make it through because you have a great team beside you.  And it’s at that moment that it hits you…

The only way we’re going to ship is with everyone who is a part of this team.

And everyone is accepting of that which is great.  The next day, you ship, everyone is happy, possibly some big pats on the back, “you broke the rules and fought through, congrats”, “you pushed the envelope and never gave up”.

Everyone is thanking each other, but no one is thanking the development process that got you there?

For all the different methodologies out there, I have never seen a piece of software that shipped where someone said – “Well, thanks to the process, we were a success and shipped on time” – never have and I doubt I ever will.  It’s always about the people (and sometimes about the rules they broke to get it done while persevering to make it a success).

So if the process isn’t the first person that you thank after shipping a project, why make it so complex?  If it is really that invisible member of the team that just hums along while you are working and knows when to back down when things are going south, why make it ever present in your daily life?

And maybe that’s the point, maybe it shouldn’t be so in your face, but just there, in the background, ready to help or ready to get out of the way, flexible yet structured, simple but powerful?

But just remember, for all the effort that you put into the that process, at the end of the day it’s going to come down to the people on your team and how they rise to the occasion to ship your latest project.

Insulate the Failure

I know this is one of those topics out there that people might go – “oh great another blog about letting people fail and everyone being happy and unicorns and rainbows and let’s hold hands and save the world, etc, etc, etc…”.  And to some extent it might be, to some extend it might not.

One of, if not the hardest part about managing/leading a team is giving your team the opportunity to fail because at some point, the little voice in the back of your end starts connecting the dots and going “Red Alert!  Red Alert!  We’re going to crash”.  And where does that voice come from?  It comes from the impression of how that failure will later be imprinted on you.  We see it in any sport that requires a goalie where parents steadfastly refuse to have their kids play in nets because if they fail (i.e., let in goals) people will look to them and their kids for having lost the game even though this could not be farther from the truth.  It could of been a myriad of things – sun in the eyes, got pushed in the crease, bad line changes, bad pass, no defense, etc, etc – that the goalie had zero control over.

When you see something like that happen on the ice, as a parent are you going to jump the boards and get in front and block the puck/ring from going in?  Essentially pushing your kid out of the way?  Probably not.  Yes YOU stopped the puck and made the save, but YOU also robbed that kid of the opportunity to learn how to fall down and get up quickly, learn to recover and pivot when something goes wrong and adjust their game so next time they can be better prepared for what comes at them.

Now all they’ve learned is how to step aside.

So – back to delivering software – as a leader/manager your goal is to insulate the failure, how can you give people the opportunity to learn and fail without utterly wrecking themselves and the project?  Focus on the small win, coach from the sidelines, offer guidance and experience.  When receiving estimates for work, if you know they are way off, add in the slush that you think should be there to get the job done.  Are they working with a new API and language they have never seen?  Probably not going to be done in a day (even based on a – Can do 100%, 16 hour, give it all I’ve got attitude day) .  So go to your stakeholders and tell them 5 days, if it needs to be done in 2, gather more resources to help them out.  The best time to learn can be in the moment when they start to unravel all that they have to do but they never thought was there before.  If they need it lead them through it, but don’t do it, otherwise you’re just 2 steps away from putting on the goalie pads.

The BEST, BEST, BEST part about letting someone fail through the course of implementing a new feature is when you sit down with them afterwards and look back at what was to be done and what was delivered and they realize where they fell off, but where they had to fail to make it better by the end.  The Aha moment if you will.  They will not only appreciate the confidence you showed in them to not only let them handle it on their own but also the trust and independence in letting them get there and coming out better for it.

And the beauty is – they will keep getting better over time – continually, guaranteed.

Living Documents are a Cop Out

I hate this phrase – “It’s a living document, it will never be completed, it will live on and on, we will be in the ground and yet this document will continue to live on”.  Okay the last bit might have been exaggerated a bit, but you get the gist of where I’m going with this.

Can someone show me a document that is dead?

Probably not, because we don’t exactly label documents as dead because that would mean that someone took a significant amount of time to write something, we deemed it useless and than pushed it aside into the garbage can.  It’s a topic for another day, but once people have invested x amount of time into something, they don’t want to see it thrown out.

But the term “the living document” is a cop out because here is what it translates to – I’ve done a pretty good job, I’ve got a pretty idea there is more to do and I don’t want to be the one to do anymore on it.  That’s it, think of all those times you’ve heard that phrased used, guaranteed its when you have asked someone if they are finished writing it.  And they are, they are finished, they don’t want to do anymore, they want to move on with their lives, they don’t want to hear about how you need more in it.  They are done.  At this point, the phrase the living document came to life so as to compensate for any missed information (hey it’s living of course I missed stuff) and to hand off to someone (here take the document, feed it some words, its alive).

Those kinds of living documents are ones that don’t really live on, because of the information that might be missing and the time and quality that went into it – it’s not complete, its not great, its going to be skimmed over.  But the gal that says – “here’s the doc, it’s done” – yeah those are the good docs, those are the ones that live on because people read them and see what level of effort you put into them and they want to make it better and build on it and increase it’s shelf life for all.

So those documents, the ones that aren’t pronounced as living, become the real living documents, because they weren’t labelled, they were complete and everyone knew before reading that this would be something worth carrying on.