When one team (e.g., engineering) adopts agile methods while interdependent teams (e.g., finance) do not, it creates system-wide dysfunction. This "arrhythmia" highlights the need for a holistic view of transformation, ensuring all parts of the organization can keep pace.
Software companies struggle to build their own chips because their agile, sprint-based culture clashes with hardware development's demands. Chip design requires a "measure twice, cut once" mentality, as mistakes cost months and millions. This cultural mismatch is a primary reason for failure, even with immense resources.
If a company creates a siloed "innovation team," it's a sign the main product organization is stuck in "business as usual" maintenance. Innovation should be a mindset embedded across all teams, not an isolated function delegated to a select few.
Many leaders view GTM systems as technological (e.g., Salesforce). Instead, think of it as a living ecosystem where changes in one part (e.g., sales) create cascading impacts on others (e.g., CS). This biological framing centers people and processes, not just tools, recognizing that the system is constantly evolving.
Product leaders often try to implement agile best practices within their team, but fail because the surrounding organization still operates on a project-based model. The rest of the company treats the product team like a feature factory, handing over requests and demanding deadlines, creating immense internal friction.
Instead of over-analyzing and philosophizing about process improvements, simply force the team to increase its cadence and ship faster. This discomfort forces quicker, more natural problem-solving, causing many underlying inefficiencies to self-correct without needing a formal change initiative.
Contrary to the popular bottoms-up startup ethos, a top-down approach is crucial for speed in a large organization. It prevents fragmentation that arises from hundreds of teams pursuing separate initiatives, aligning everyone towards unified missions for faster, more coherent progress.
Forcing innovations to "scale" via top-down mandates often fails by robbing local teams of ownership. A better approach is to let good ideas "spread." If a solution is truly valuable, other teams will naturally adopt it. This pull-based model ensures change sticks and evolves.
Instead of large, multi-year software rollouts, organizations should break down business objectives (e.g., shifting revenue to digital) into functional needs. This enables a modular, agile approach where technology solves specific problems for individual teams, delivering benefits in weeks, not years.
While intended to improve efficiency, the rise of Agile ceremonies and specialized roles like Product Managers has created layers of abstraction. This often "hides" engineers from direct customer interaction, reducing their understanding of the "why" behind their work.
To gauge if an engineering team can move faster, listen for specific 'smells.' Constant complaints about broken builds, flaky tests, overly long processes for provisioning environments, and high friction when switching projects are clear signals of significant, addressable bottlenecks.