Have you ever looked up a recipe on the internet? Most of the websites with recipes have this two-thousand word “It was summer in Tuscany when I first learned this recipe from my nana” preamble in front of it. There is a lot of scrolling down involved in order to find the three things you need from the store, and the temperature you need to set the oven to. It has given me this irrational fear that all of my leadership coaching stories here are the same—a bunch of random storytelling followed by three things you need to buy at the grocery store. I am pretty sure that is not true, but the struggle is real.
Good leaders need to be able to predict the future. This is an important skill to develop. Since it is March, and you probably put your bonus in the bank last week, next week, or “hopefully real soon now” if you bank at SVB, I am going to give you some late breaking advice on an engineering leader super power.
Here are some magic words to use in your job interview: “I am going to tell you about the software projects I have shipped on time and under budget.” If you do not have any of those handy, it is time to start figuring them out.
If you are at work this week and one of your team starts asking questions about this, congratulations! You have found a fellow reader of my blog on your team.
In all seriousness, shipping software on time is very important. It is also very rare. One of my peers a decade ago loved to repeat a saying from a game developer he worked with: “I love deadlines, and the loud whooshing noise we make when we blow right past them.” Hardly a statement that inspires confidence, but the statement drips with truthiness.
An important skill to learn and master is being able to communicate deadline changes. The secret is: The earlier the better. If you find yourself being asked from time to time about incremental milestones, or “can I get an ETA?”, you should not feel alarmed. Most of the time these questions are designed to look for yellow flags that something is going to be late. This is because for some reason, people have this really bad habit of trying to hide things when they are about to be late. I generally believe that it is due to a scarcity mindset, and it is an important thing to deprogram if you have this tendency.
I get it, everyone wants to be the hero and ship stuff on time. What a beautiful thought. Even the best engineers have projects that run late. I always tell people that building software is like planning a subdivision. You figure out where the roads should be created, what are the lot sizes, and where the various utilities need to go. Sometimes when you are planning out a subdivision you might not know that there is a massive granite chunk right where you wanted to put the sewer lines, or that there is some other kind of physical impediment to construction that did not show up in the surveys.
In order to readjust the work, budgeting, and timing of everything, it is best to find these things out early. It is better to reroute the sewer drainage plans for a subdivision before you have built half of the houses.
This is one of the many reasons why you break down your tasks into small chunks and estimate them.
If you have broken down your big project into twenty pieces, and the first three of them start to slip and run late, the odds are you are likely going to be late overall. Many people like to believe they can power through and put in some extra time to get the project completed. This is a bad pattern to apply because it is habit forming. It is far better to communicate the delays early, and make some deadline course corrections where possible. Sometimes it is not possible. I jokingly tell people that one of my favorite user stories that never makes it onto the planning board is “As a software developer, I wish to move Christmas by one week.” Certainly once or twice a year you might find a deadline that is immutable like that, and you need to coordinate with leadership on the things that you can do together to get the project done on time.
Some deadlines do have some flexibility and can be moved. Those are easier to do earlier in the project. You are more likely to have happy leadership when you ask to move the deadline one week during the first month of a project than if you ask to move it by a week the day before it is due.
There is a small problem here that you might find you need to ask to move the deadline again. This is where things get really challenging. You might get a second opportunity to move a deadline, but it is also a really bad habit to get into.
The solution is to improve your software estimation skills, and to be able to have some amount of prescience about how late a project is going to be once you have established it is going to be late.
If you are a month into a four-month project and you are a week behind, you can either ask for a week extension or extrapolate that you might land a month late. There is some uncertainty there. It might be worth averaging out those two numbers, and giving leadership a heads up that you are at risk of being two and a half weeks late.
You will notice that some patterns emerge as you develop the habit of predicting your deadline changes. More than half of them will get delayed on the same kind of work. As you become familiar with the recurring hiccups, you can use that information to recalculate future estimates.
You will also notice that you will need to ask for deadline changes less and less. This means you are now better at predicting the future, and should add that to things you brag about when you are trying to get a shiny job at NewCo.
There it is. That’s the post. Alexa, send tweet. This post is brought to you by the letter “H”, and the Amazon-affiliate-linked Mueller wrist brace, for those of you experiencing repetitive stress injuries from your work: Mueller wrist brace! Be safe out there, and have fun practicing your prediction skills at work tomorrow!
