Going into a Cave

How many times have you heard a developer say this?

This problem is really complex, I’m going into a cave for the next few days to work on it.

So they go away for a few days and when they come out – BOOM – problem solved, new features built, product ideas are pouring out the ceiling.

Two days in a Cave – no distractions, minimal interruptions, no communications – yielded – progress, delivery, initiative.

We can’t always work out of our cave (wherever that is) but it’s refreshing to know that we all have that place where we yield the most incredible work possible.

If you haven’t found yours, find it, don’t flaunt it (no social media) and kick it into Overdrive.

PS – It’s not solely for code problems either.

What is Inititiave?

Initiative is our first step towards leadership.

It’s leading the Army of One on all the missions where only we can go (and perhaps only where we want to go).

It’s the 10 seconds it takes to step forward and put up our hands to volunteer for something new.

Before you lead others, you need to lead yourself.

Want your team to start commenting their code?

Start commenting your code.

Want your team to come to meetings having read last week’s action items?

Start reading last week’s action items.

Becoming a Leader starts with you and the ability to lead yourself, when you’re down and out, wanting to give up, ready to throw in the towel.

If you can lead yourself through that, you can lead a team through anything.

Leaving Uncompilable code before leaving

I can’t leave code that won’t build at my desk overnight.

Perhaps it’s because I won’t remember what is wrong with it in the morning.

Perhaps it’s a worry that my machine will reboot overnight and it will then be even more of a mess.

Maybe it’s wanting to have that last sense of “Build Succeeded” to scroll past my screen so I always that small measure of daily accomplishment.

Whatever it is, the same holds true for your customers.

Don’t leave them dangling on that last minute support issue.

Don’t give them wishy/washy information.

Don’t push out that status call one more day.

Change “Build Succeeded” to “Customer Succeeded” and get those same feelings.

Ignoring the Date

One of the hardest parts in leading a software release is being late.

You tried your best, you rallied the team, you put in the extra effort, but it simply wasn’t enough – for whatever reason, you’re shipping late.

Okay, that’s done, that’s known, you know it, everyone on the team knows it, maybe even your dog knows it.

Now it’s time to keep repeating.

Not because you are trying to be rude or dismissive but because they need to understand that the release is shipping on a different date and inform their stakeholders (so the process can continue).

The worst thing when a project is late is when no one wants to hear why it’s late and no one wants to take action to fix it from not being late.

What happens, is the team starts to Ignore the Date, their productivity drops, they feel less motivated or passionate for what they are doing because the perceived response is “no one cares”.

Take off the blinders, accept the project is late and do something about it, if not for you, then for your team.

 

When the Team Comes Together

They are unstoppable.

A force of nature.

The combining of all lions into Voltron.

Yes, they are that good.

And you know when it happens, you know the moments I’m talking about, I don’t need to say more than that.

So how you do make it so the Team Comes Together Every, Single, Time.

Now that’s a problem worth solving.