Minutes of planning save you days of programming. It is shocking how little planning it takes to make a big difference.
We're trying a new thing at work called "Hey what if we defined what done looks like before we jump in the code?". Revolutionary I know 😆
Truth is we've tried planning before and it didn't stick.
Maybe chaos didn't hurt enough yet, maybe we needed to hire enough engineers for people to feel they have time to slow down and think. I certainly feel like I have more time to think than 3 months ago when I wrote about spinning plates.
Either way, after just 1 week of this (and 2 weeks of pre-work by the managers), I'm seeing stress levels are visibly down and everyone's saying they appreciate the structure. People love a clear goal that they understand how to reach.
You don't need much:
- What is the goal? What problem are we solving?
- How are we doing this?
- How will we know it's done?
- What are we not doing as part of this project?
- Who will be happy about this?
Put that in a project brief and add tasks for every step. At Tia we used to do this on the story level because projects measured in quarters. At Plasmidsaurus we're trying it on the project level because projects take weeks and initiatives take quarters.
🤷♂️ words. It's all the same.
You shouldn't write that plan in a vacuum. Everyone who's going to work on the project should be in the room and contribute. Let juniors speak first.
Manager or PM defines the goal, team jointly defines the execution plan. Always ask to get over the water, not build a bridge. Write things down. It forces you to be clear.
You have to define what's not in the project. Write it down in bold if you have to. Never make a project called "Make X better", "Updates to Y", or "Blah v2". Those accumulate scope forever and won't let you move on.
Make a new project for all the great ideas you're getting. Put it on the backlog.
And make sure you understand who it's for. Helps you get feedback and follow up to make sure it worked. Deliver incrementally. One pain point at a time.
Cheers,
~Swizec
PS: I think super experienced engineers do this intuitively. For others, adding a little structure helps.
Continue reading about Small projects, clear scope
Semantically similar articles hand-picked by GPT-4
- The swarm doc
- How to take ownership and make progress without explicit direction
- How *do* you break down a large project?
- How to lead a project
- Coordinating at the end is too late
Scaling Fast book free preview
Enter your email to receive a sample chapter of Scaling Fast: Software Engineering Through the Hockeystick and learn how to navigate hypergrowth without burning out your team.
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
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
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
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️