Learn modern project management strategies, release planning, QA integration, and team scaling. Insights for engineering leaders and project managers.
It is 9:30. The team is gathered. Each person in turn answers the three questions: 'What did I do yesterday, what am I doing today, what are my blockers.' Fifteen minutes later, everyone goes back to their screen without anything having changed. This daily accomplished nothing.
There is an admired archetype in the tech industry: the brilliant, solitary developer who produces more code than ten ordinary developers. This archetype influences hiring decisions, justifies unequal compensation packages, and creates dysfunctional team cultures. It is also largely a myth.
Your organization has implemented SAFe. You now have ARTs, PI Plannings, System Demos, and Inspect & Adapt workshops. Your organization is also slower, more meeting-heavy, and more frustrating for engineers than before. This is not a bug in your SAFe implementation. It is often a feature.
Estimation is often a shared fiction: developers give numbers they know are imprecise, management treats them as commitments, and when estimates are exceeded, everyone is surprised to be surprised. #NoEstimates says: let's stop the fiction. The question is: what do we replace it with?
The production database went down on Friday at 6pm. The post-mortem was held on Monday. In the write-up: five process improvement points, three technical remediation actions, and a discreet mention that 'the incident was caused by human error during migration.' That sentence is the opposite of a blameless post-mortem.
If your team spends more time debating monorepo vs polyrepo than writing code, that is a sign the debate is framed wrong. Both approaches work. The real question is: which structure fits your organization and your delivery cycle?
Your codebase has 47 active feature flags. Five are documented. Three are tied to features shipped nine months ago and no one thought to remove them. Two conflict with each other: enabling both at the same time produces undefined behavior. You have just discovered why feature flags are not free.
The team spent three weeks modeling the bounded contexts, aggregates, and domain events of their content management application. The application does CRUD on five tables. That is the sign that DDD is being used as an end in itself, not as a tool.
"We need a technical debt sprint." This phrase is spoken in hundreds of teams every quarter. What happens next: two weeks of refactoring without clear direction, whose value is impossible to communicate to management, and which doesn't fundamentally change the most painful problems.
How many days does a new developer spend trying to get the project running locally before they can actually contribute? In most teams, the answer is somewhere between two and ten days. The onboarding documentation exists - it's just wrong.
