Predicting project timelines is a waste of time
The engineering world has been trying to figure out project timelines for a long time. There’s been a number of systems, methodologies and approaches that many have tried, yet there doesn’t seem to be a clear answer to what works best.
In a founder group I belong to, someone asked for recommendations for a Scrum/Agile coach to help their team setup better workflows - that simple ask sparked the highest volume of comments and engagement that group had ever seen.
It was such a controversial topic that no one could agree on.
The conversation evolved from recommending the right coach, to opinions on Agile & Scrum, different tooling to help keep teams on track and various methodologies that people had tried.
Did the group come to a definitive answer on what worked best? No.
Were there some common patterns? Certainly.
In fact, a lot of what people had in common in approach, we had been adopting all along at Compose.
Here’s my take on the matter 👇
The core problem is engineering timelines and delivery - how do you accurately plan, predict and deliver project milestones?
💡 Our approach at Compose is a somewhat unconventional one, we solve the problem by getting rid of it. 💡
Instead of trying to slap a timeline on every project, task and line of code, we like to use the “Race Car Method” (patent pending).
The race car method has two components:
- The gas pedal: Ensuring your engineers are delivering product value at the highest sustainable rate possible.
- The steering wheel: Ensuring your product roadmap is continuously thought through and updated based on user feedback.
That’s it. There are now two simple metrics that you can control far more effectively than you can predict timelines for any one project or task.
If you get the gas pedal right, your team can go anywhere, fast. And if you nail the steering wheel, your team can now go to exactly the right place, fast. And that’s what project management in software engineering is all about.
Does it matter exactly when a certain project will finish if you know that you’re taking the shortest path there (effective steering) as fast as possible (pedal to the mettle)?
At the end of the day, Engineering momentum > Accurate timelines.
Enjoying this post? Read more from Compose here 👇
Building a New Input Box: Switching to Tiptap
A Lesson in Implementing Product Analytics
So we’ve discussed the two core components of the Race Car Method. Now, we’ll dig into how to nail your steering - F1 style, and how to keep your foot on the gas without causing any engine failure (team burnout).
Nail your steering
Here are a number of operating principles that will help you ensure you’re on the right path
👥 User feedback - your compass
Feedback from users is the ultimate guide and the key to effective steering.
The first step is to ensure your user feedback cycles are robust.
Can you push something to your users easily? No → Figure out CI/CD.
Can you track the success of that newly launched feature? → Figure out analytics.
And can you get your users thoughts on it? → Figure out qualitative feedback.
If the answer isn’t yes to all of those, then that’s the place to start.
💻 Bullet-proof analytics
You need 20/20 vision on what’s happening in your product (in a compliant manner of course).
20/20 here means that you have wide vision, you can see all stages of your funnel (acquisition, activation, retention), not necessarily deep vision (every single detail of every single interaction in your product).
In most cases, you should just use June.so in combination with Segment - here’s why.
🎯 Weekly objective setting
You should do this once a week. This will dictate which projects and tasks you need to focus on and more importantly which you should not.
Set one company wide goal that’s measureable.
The inputs to this exercise should be:
- User feedback
- Product analytics
- Gut feel
🔄 Better work tracking
Use Linear for tracking engineering work. Yes, you could use one of the million other tools, Linear is the simplest and No, you don’t need that one niche feature that platform X has.
#️⃣ Public comms > private comms
Make sure your team always communicates in public channels, especially when it comes to any project work. Especially important with remote work! Keeps everyone aligned on the right direction
Pedal to the mettle
❤️🔥 Scope is sacred - The 1-Day, 1-Week, 1-Month Method
Something can be done in a day, a week, a month or as much time as you're willing to spend on it.
Break down your projects into the 1 day, 1 week & 1 month versions and assess which encapsulates the right scope for the problem at hand.
Once scope is locked in, you should not expand it and try to stick to the timeline.
And yes, (almost) everything has a 1-day version.
⬅️ Shifting to the left
Whenever you can trim scope and align earlier, you should. This is true across all work.
If you can think of a simpler problem to solve, better.
If you can design a simpler flow, better.
If you can build a simpler feature, better.
The sooner in the pipe you nip things, the better.
🧑⚖️ RAPIDs
In the interest of speed, decisions should be deferred to one person rather than a committee. Opinions and feedback will be heard but committing to a direction will be undertaken by the decision maker.
Once it's decision time, you commit and execute.
🛠️ Execution > Ideas > ego
An idea can come from anyone and can be adopted - no one will get brownie points if their idea is the one that makes it.
Executing the idea well is far more important than coming up with the idea and pushing for it.
A mediocre idea, executed well is far better than a great idea, executed in a mediocre fashion.
With the Race Car Method & the operating principles at hand, you should be able to conquer any project no matter how small or large.
Don't stress about predicting the timeline - just get your steering angle right and peddle to the mettle.
