Learn modern project management strategies, release planning, QA integration, and team scaling. Insights for engineering leaders and project managers.
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.
How many times have you had a 1-on-1 where your manager opened Jira to review your current tickets? That meeting could have been an email, or a glance at the Kanban board. A 1-on-1 that looks like a status report is a wasted 1-on-1.
Your team has a Notion page with next quarter's plan. It was written last week. Three people added comments. Two reacted with an emoji. The plan hasn't changed. No decision has been made. That's async without guardrails: lots of activity, little resolution.
