I'm investigating a pattern I've seen across 15 years in aerospace, startups, and AWS: projects fail because of alignment breakdowns, not skill gaps.
The team is talented. The tools work. But somewhere between the decision and the execution, the signal degrades. Information exists but doesn't reach the person who can act. Context gets lost between handoffs. Small misalignments compound until the deadline arrives and everyone discovers they built different things.
In aerospace, we called this cascade failure. In software, we call it Tuesday.
I want to understand this better — not from books, but from practitioners. What does alignment actually look like in practice? Where does it break? What do teams do about it, and does it work?
I'm talking to 25 engineering leaders — managers, directors, TPMs, CTOs — about alignment breakdowns they've experienced firsthand. Structured conversations, not surveys. One core question:
"Tell me about the last time a project failed because of misalignment, not incompetence."
I'm also building an Alignment Diagnostic — a short assessment that helps teams see where their coordination is working and where it's theater.
I've been on both sides of this problem. At Airbus and in aerospace research, alignment wasn't optional — a small misalignment could cascade into losing a spacecraft. At AWS, I led an 18-month platform migration and caught a critical gap six weeks before launch that would've torpedoed deployment. At startups, I watched the same dysfunction play out faster and louder.
I wrote a manifesto about what I've learned — Guidance System for Software Teams — built around three pillars: clear context, active communication, and shared culture. The research is how I pressure-test those ideas against other people's experience.
If you've managed or led engineering teams and this resonates, I'd love to talk. It's a 30-minute conversation — not a sales pitch, not a coaching session. Just a practitioner comparing notes with another practitioner.