AI Adoption & Change Management — Operational Excellence
Difficulty: Advanced. Org Size: Growth
Key Points for AI Adoption & Change Management
- AI adoption is a change management challenge, not a technology challenge. The hardest part is never the model. It is getting people to trust it and change their workflows.
- Start with internal productivity use cases before customer-facing ones. Code review assistance, test generation, and documentation are low-risk wins that build organizational confidence.
- Create an AI Champions program with 2-3 champions per team who experiment first, document workflows, and coach peers. Grassroots adoption sticks better than top-down mandates.
- Address job displacement concerns directly and honestly. Pretending the concern does not exist makes people resist harder.
- Establish a governance framework early, before the first production use case ships. Retrofitting governance onto live AI systems is painful and disruptive.
Common Mistakes with AI Adoption & Change Management
- Top-down mandating AI tools without understanding how teams actually work. A CEO email saying 'everyone must use Copilot' without workflow context creates resentment and checkbox compliance.
- Ignoring the skills gap between engineers who are comfortable with AI tools and those who are not. The gap widens fast without deliberate intervention.
- Treating AI adoption as a one-time rollout instead of a continuous learning process. The tools change every quarter and the organization needs mechanisms to absorb new capabilities.
- Not measuring adoption and impact properly. 'Number of Copilot licenses' tells you nothing about whether the tool is actually helping or just sitting unused.
Related to AI Adoption & Change Management
Incident Management Process, Scaling 10 to 50 Engineers
Conway's Law & Inverse Maneuver — Team Structure
Difficulty: Advanced. Org Size: Growth
Key Points for Conway's Law & Inverse Maneuver
- Conway's Law states that system architecture mirrors the communication structure of the organization that builds it — this is not a suggestion, it is a force of nature
- The Inverse Conway Maneuver deliberately structures teams to produce the desired architecture, using org design as an architectural tool
- Cross-team dependencies in the org chart become cross-service dependencies in the codebase — reduce one to reduce the other
- Splitting a monolith without splitting the team first almost always fails because communication patterns recreate the monolith's coupling
- API boundaries between teams should be treated as contracts — team autonomy requires interface stability
Common Mistakes with Conway's Law & Inverse Maneuver
- Reorganizing teams without changing communication patterns — new boxes on an org chart mean nothing if the same people still have to coordinate on the same code
- Ignoring Conway's Law during architecture planning and being surprised when the system mirrors the org chart instead of the whiteboard diagram
- Applying the Inverse Conway Maneuver too aggressively — splitting into many small teams before the product domain is well-understood creates premature boundaries
- Forgetting that Conway's Law applies to all organizations, not just engineering — product, design, and data teams also shape system architecture through their communication patterns
Related to Conway's Law & Inverse Maneuver
Team Topologies Overview, Scaling 50 to 200 Engineers
Engineering Career Ladders — People & Growth
Difficulty: Advanced. Org Size: Growth
Key Points for Engineering Career Ladders
- IC and management tracks should be parallel in seniority and compensation — a Staff Engineer and an Engineering Manager should be peers, not subordinates
- Each level should have clear, observable expectations across multiple dimensions — technical skill, scope of impact, leadership, and communication
- Calibration across teams prevents title inflation and ensures that 'Senior Engineer' means the same thing in every part of the organization
- Promotion should be based on sustained demonstration of next-level work, not tenure — 'time in level' is an input, not the deciding factor
- Career ladders should be living documents reviewed annually — as the organization evolves, the expectations at each level should evolve with it
Common Mistakes with Engineering Career Ladders
- Creating too many levels too early — a startup with 20 engineers does not need 8 IC levels, and the artificial granularity creates more politics than clarity
- Making management the only path to seniority and compensation growth — this forces great ICs into management roles they do not want and are not suited for
- Defining levels with vague language ('demonstrates technical excellence') instead of observable behaviors ('leads design of systems spanning 3+ services')
- Promoting based on tenure or likability rather than demonstrated impact — this destroys the ladder's credibility and drives high performers to leave
- Not having a calibration process — without cross-team calibration, each manager applies different standards and titles become meaningless
Related to Engineering Career Ladders
Team Topologies Overview, Scaling 10 to 50 Engineers
Incident Management Process — Operational Excellence
Difficulty: Intermediate. Org Size: Growth
Key Points for Incident Management Process
- Severity levels (SEV1-SEV4) create shared vocabulary and determine response urgency — without clear definitions, every incident becomes an emergency or gets ignored
- The Incident Commander role separates coordination from debugging — one person drives the process while engineers focus on technical investigation
- Communication templates (status pages, stakeholder updates, customer notifications) prevent ad-hoc messaging that creates confusion during high-stress situations
- Post-incident reviews focus on systemic improvements, not blame — the goal is to make the system more resilient, not to find a scapegoat
- Regular incident drills and game days build muscle memory so that real incidents are handled with practiced calm instead of panic
Common Mistakes with Incident Management Process
- Skipping post-incident reviews for 'minor' incidents — SEV3 and SEV4 incidents often reveal systemic weaknesses that cause SEV1s later
- Making the on-call engineer also the incident commander — debugging and coordinating are competing cognitive tasks that degrade each other
- Writing post-incident reviews that identify root cause as 'human error' — humans always make mistakes, the system should be designed to tolerate them
- Not practicing incident response — teams that only run the process during real emergencies are slow, confused, and error-prone when it matters most
Related to Incident Management Process
Engineering Career Ladders, Team Topologies Overview
ML & AI Team Structure Patterns — Team Structure
Difficulty: Advanced. Org Size: Growth
Key Points for ML & AI Team Structure Patterns
- Three organizational models exist for ML teams: centralized, embedded, and hybrid. Hybrid scales best once you pass 5 ML engineers because it balances specialization with product proximity.
- Embedded ML engineers without a shared platform spend roughly 70% of their time on infrastructure plumbing instead of modeling work
- ML teams need different hiring profiles than product engineering. A strong ML engineer is not just a software engineer who took a course, and treating them as interchangeable causes attrition.
- The handoff between data science and engineering is the single biggest failure mode in ML organizations. If nobody owns the gap, models die in notebooks.
- Conway's Law applies to ML systems too. If your ML team is siloed from product teams, your models will be siloed from the product experience.
Common Mistakes with ML & AI Team Structure Patterns
- Hiring ML PhDs before building data infrastructure. You cannot do machine learning without reliable, accessible data pipelines, and senior researchers will leave when they spend months waiting for clean data.
- Running the ML team as a service desk that takes requests from product teams without owning outcomes. This creates a sweatshop dynamic where data scientists have no product context and build models nobody ships.
- Expecting unicorn full-stack ML engineers who can do research, write production code, build pipelines, and operate models. These people exist but there are maybe 200 of them and they all work at DeepMind.
- Separating the ML team from on-call responsibilities for their own models. If the team that built the model is not paged when it degrades, model quality rots silently.
Related to ML & AI Team Structure Patterns
Team Topologies Overview, Conway's Law & Inverse Maneuver
Scaling 10 to 50 Engineers — Scaling Organizations
Difficulty: Advanced. Org Size: Startup
Key Points for Scaling 10 to 50 Engineers
- This is the transition from 'everyone knows everything' to 'we need structure' — the first real organizational inflection point
- First engineering managers emerge — typically your strongest tech leads who now split time between people management and technical contribution
- Specialization becomes necessary — generalists start focusing on frontend, backend, infrastructure, or data as the codebase outgrows one person's mental model
- Communication overhead grows quadratically — at 10 people you have 45 possible communication channels, at 50 you have 1,225
- Process must be introduced deliberately — standups, sprint planning, design reviews, and on-call rotations replace informal hallway conversations
Common Mistakes with Scaling 10 to 50 Engineers
- Promoting your best engineer to manager without training or coaching — management is a different skill set, and losing a great IC while gaining a struggling manager is a double loss
- Avoiding process because 'we're still a startup' — the chaos that worked at 10 people becomes dysfunction at 30
- Hiring too fast without onboarding infrastructure — new engineers at a startup without documentation or mentoring take 3-6 months to be productive instead of 3-6 weeks
- Not establishing technical standards early — code style, review requirements, deployment process, and incident response should be written down before you forget the oral tradition
Related to Scaling 10 to 50 Engineers
Team Topologies Overview, Scaling 50 to 200 Engineers
Scaling 50 to 200 Engineers — Scaling Organizations
Difficulty: Expert. Org Size: Growth
Key Points for Scaling 50 to 200 Engineers
- The 'messy middle' — too large for startup informality, too small for enterprise bureaucracy, requiring careful balance between structure and agility
- Organizational layers emerge — directors manage managers, VPs manage directors, and the CEO can no longer maintain context on every technical decision
- Platform teams become essential — without shared infrastructure, every stream-aligned team reinvents deployment, monitoring, and data pipelines
- Technical governance shifts from individual expertise to collective decision-making — architecture review boards, RFCs, and tech radar processes
- Culture preservation requires deliberate effort — the founding culture dilutes as new hires outnumber original team members, necessitating explicit values and rituals
Common Mistakes with Scaling 50 to 200 Engineers
- Adding management layers without reducing the coordination burden — more managers should mean less cross-team coordination, not more meetings
- Building a platform team too large or too early — start with 3-4 engineers solving the most painful shared problems, then grow based on demonstrated demand
- Letting technical standards drift into tribal knowledge — at 200 engineers, if it is not written in an RFC or ADR, it does not exist
- Reorging too frequently — organizational changes take 3-6 months to settle, and constant restructuring destroys team cohesion and trust
Related to Scaling 50 to 200 Engineers
Scaling 10 to 50 Engineers, Conway's Law & Inverse Maneuver
Team Topologies Overview — Team Structure
Difficulty: Intermediate. Org Size: Growth
Key Points for Team Topologies Overview
- Four fundamental team types — stream-aligned, platform, enabling, and complicated-subsystem — each with a distinct purpose and ownership model
- Stream-aligned teams own end-to-end delivery of a business capability, minimizing handoffs and maximizing flow
- Platform teams reduce cognitive load by providing self-service internal products (CI/CD, observability, infrastructure)
- Enabling teams are temporary coaches that accelerate adoption of new practices without creating long-term dependencies
- Complicated-subsystem teams own domains requiring deep specialist knowledge (ML models, video codecs, financial engines) that would overwhelm a stream-aligned team
Common Mistakes with Team Topologies Overview
- Treating team topologies as a one-time reorg instead of a continuously evolving structure that adapts to business and technical changes
- Creating platform teams before stream-aligned teams actually feel pain — premature platform investment wastes effort on problems nobody has yet
- Letting enabling teams become permanent gatekeepers instead of time-boxed coaches that hand off knowledge and dissolve
- Ignoring interaction modes — teams need explicit agreements on whether they collaborate, provide X-as-a-Service, or facilitate
Related to Team Topologies Overview
Conway's Law & Inverse Maneuver, Scaling 10 to 50 Engineers