A fellow reader wrote in with this question:
This feels very simplified. If the 6 steps were all that's necessary, why aren't more teams doing this. Additionally, 18 months can be an eternity in software. Any ideas why it took that amount of time and if can be shortened?
It was a comment on How we made the best burndown chart you've ever seen and unfortunately they didn't leave an email. Might never see this answer.
But it could help you, so here we go.
This is the best burndown chart I've seen. It shows our team getting stories done exactly on time and finishing all work a day early.
I use it as an example in Senior Mindset workshops to talk about theory of constraints, bias to action, and The Mythical Man-Month lesson everyone forgets 👉 Delays happen one sneeze at a time.
In How we made the best burndown chart you've ever seen, I outlined 6 factors that made this happen:
- A real deadline
- Small stories
- Work in sequence
- Bias to action
- Don't be a blocker
- Break the process
I stand by these. You need a deadline otherwise work expands to fill the time available. Fake deadlines don't work.
Small stories are easier to track and help you build momentum, working on every story as a team keeps work in progress low and makes them go faster.
The rest is cleaning up those little time sucks that sneak into all our days. The 5min break that oopsies into 15min between one task and another. The 3 hour back-and-forth on a pull request that could be a 5min "Ah let me just do it for you" commit.
Because it's culturally hard. Even weird.
Every time we hire a new engineer they say 2 things:
- Wow I've never seen a team move this fast
- I don't like this
When we first started working as a team instead of a group of soloists, every story felt like a million gerbils running through my brain. You had a thought, an idea, an approach you wanted to take and immediately the gerbils would trample all over. Move things around, change the code, grab a piece of your brain and connect it to a new piece that felt wrong.
It was jarring, confusing, distinctly uncomfortable, and way better.
We moved faster. We got more done. We kept everyone in the loop. Shared more ideas. Found more edge cases. Created fewer bugs. And heard more opinions.
Think of the stereotypical engineer on the internet. The reply guy. The well-achually dude. The brilliant nerd sitting in their ivory tower of perfection that nobody else can touch.
This is my code. You, peasant, touch your own code.
They don't last long in a team like ours. Hell, they wouldn't even make it through the interviews.
Changing a culture takes time.
Humans are messy. You can't say "Okay we'll do things this new way" and suddenly it's all better.
Progress looks like this:
Your progress oscillates around the ideal. High variation at first, then closer and closer until one day, you get it right almost every time.
This is known as regression to the mean.
Exceptionally good performance? Your next try is likely to be worse.
Exceptionally bad performance? Your next try is likely to be better.
Independent of external feedback! The effect is so powerful it fools expert coaches and managers.
In the late 60s, Kahneman was a consultant for the Israeli Air Force. He lectured instructor pilots on the latest research that showed that reward was far more effective than punishment at improving performance. Instructor pilots were not buying any of it.
They told Kahneman, when student pilots have a bad flight we yell and scream at them, and the next day they tend to do better. But when they have a good flight we'll praise them like you suggest, and they tend to do worse.
It was then that Kahneman realized how natural variation in performance, and its natural regression to the mean, were fooling the flight instructors into believing it was their yelling and screaming that improved the student pilots' performance.
You have to focus on your average performance my friend. The easiest way is to consistently do more of what's working.
And that takes time.
PS: yes our very next sprint was worse. We got cocky and took on too much
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Leave your email and get the Senior Mindset series - a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.
Get a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.
it describes my days in a way I have not read before.
This was a very enlightening article about being a senior engineer.
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️