Planning and delivering projects is dead simple.
As long as you know what you are doing and what you are trying to achieve.
Here’s the expanded recipe for avoiding the most common f-ups in business planning, management, and development + how to finally break free from the vicious circle of doom that traps so many teams.
Avoid the Classic Pitfalls as a Team
Iron Out the Details
- Start with the higher business - Validate their business vision and expectations from an engineering perspective.
- Drill down through all the layers of business until you’ve covered every relevant stakeholder.
- Involve designers early, but validate designs with your leads first - this saves you from setting unrealistic expectations that cannot be delivered in reality.
Build Trust-Based Relationships
Working with technical managers over the years taught me one thing: Trust makes the machine run smoothly.
The best managers don’t demand hour-by-hour estimates. They trust the team to pick a workload they feel comfortable with, knowing that delivery speaks louder than tracking spreadsheets.
This process isn’t rocket science it’s simple:
- When delivery slows, they question the process and blockers first, not the devs.
- When the process is sound but some issues persist, only then evaluate individual performance when it's clear there is "a slacker on-board".
When you work out this kind of trust:
- Morale rise, and teams work towards shared goals.
- Stress drops because the team isn’t burdened by micromanagement.
- Everyone feels accountable for their work without fear of arbitrary deadlines.
Building Trust with Management as a Developer
Building trust doesn’t happen overnight, but it’s not complicated. You need to show them you’re reliable, transparent, and care about the project as much as they do. Here’s how to do it:
Communicate Early and Often. Don’t wait for problems to blow up. Tell management about risks, blockers, and delays as soon as you spot them. They’ll appreciate the honesty.
Back Up Your Decisions - If you say, “We need two more weeks,” explain why. Show the trade-offs: “We can cut corners and meet the deadline, but it’ll hurt quality and require rework later.” Lay it out clearly so they see you’re thinking long-term.
Deliver What You Promise. Nothing builds trust faster than delivering on your word. Start small - hit those early milestones, even if they’re minor. Consistency matters.
Don’t Sugarcoat Reality. If something sucks, say it. Sugarcoating bad news to avoid conflict only leads to bigger problems later. Management needs to trust that when you say “It’s fine,” it really is.
Show Them You Care About the Big Picture - Management doesn’t just want to hear about your code. Show them you understand how your work impacts the product, the customer, and the business goals. This proves you’re not just a dev -you’re a partner in success.
Make Them Look Good. Let’s be real - Managers love to report good news. When your team crushes a milestone, make sure they know. Let them take credit. Your reputation grows when they know you’ve got their back.
Preventing the Circle of Doom as a Manager
If you’ve been in IT long enough, you know the sad truth: Unrealistic expectations kill projects.
It starts small but spirals out of control:
- Unrealistic expectations are set.
- Stress climbs, efficiency drops.
- Sloppy code gets written.
- Bugs pile up, rework increases.
- Deadlines are missed, and management panics.
- The pressure lands back on developers.
- Repeat until everyone hates their life.
This circle of doom never ends unless you:
- Stop overpromising to higher business.
- Stop treating estimates as deadlines.
When you fix this, you break the loop, freeing your team to deliver quality software without soul-crushing stress. And if delivery slows, you’ll know exactly where the problem is.
Days vs. Story Points: Picking the Right Tool
After ironing out your process, it’s time to plan your project. This is where you choose between Story Points and Days. The wrong choice here can set off the entire circle of doom - or save you from it.
Use Story Points When...
- You’re in an Agile environment that values consistent delivery over tight deadlines.
- The business understands that Story Points measure effort and complexity, not time.
- There is general understanding that team’s velocity is predictable after a few sprints, and no one is secretly converting points to hours.
But keep in mind:
- Story Points fail when misunderstood. If the business keeps asking, “How many days is 20 SP?” then you’re already doomed. Just do hours/days.
Use Days When...
- Deadlines are the main focus, and business wants hard time based estimates.
- Stakeholders don’t care about Agile concepts and need straightforward timelines.
But beware:
- Days can lead to overpromising. Always include a buffer to account for complexity.
The Golden Rule - Work Delivered is the Only Measurement
After 10+ years of working with clients, one thing stands out for me:
- Work delivered is the only thing that matters.
Forget logged hours or Jira tickets. Focus on whether the team is delivering features that move the project forward.
If delivery slows:
- Question the process and blockers first.
- Only after fixing those you can clearly verify if there is a problem with some underperforming teammates.
This approach ensures you’re managing the team as a system, not as a group of interchangeable parts. Most delays are process problems—not people problems.
Note:
Most of the time tho, it's rarely a developer problem - in most cases things slow down and get chaotic due to bad business decisions and chaotic management.
Lessons for Business and Management
- Stop treating estimates as promises set in stone. When you frame estimates as flexible, you leave room for the team to adapt to complexity.
- Learn from developers/leads - Trust the team to deliver without micromanagement. When devs feel trusted, they’re more productive, and morale stays high.
- Make process improvement a habit - Fix the system before pointing fingers. Even when a developer struggles, it’s often a symptom of broader issues.
Let's sum it up!
Estimations suck in general if treated as deadlines. Teams can be very efficient without artificial estimations that don't make any sense. But if you absolutely need to chose 👇
- Story Points work for Agile teams focused on continuous delivery, but only when the business understands the concept.
- Days work for deadline-driven projects where time tracking is critical. Use them with a buffer to avoid stress and overpromising.
- Trust and process trump micromanagement every time.
Build a culture where work delivered is the only metric that matters!
Hopefully, you’ll now spot these common mistakes a mile away - and have the all the tools needed to avoid them.
Remember: trust your team, question your process, and break the circle of doom.
Profit stress-free. 💰
