Okay, You've Convinced Leadership to Invest in Culture—Now What? Practical First Steps

General
1

Alright, we’ve spent several threads talking about why culture matters more than tools, how to measure culture, and why AI amplifies culture gaps.

Let’s say you’ve done the hard work: You’ve convinced leadership that culture investment is critical. You have budget. You have buy-in.

Now what? :sweat_smile:

The Implementation Challenge

Here’s the problem I keep running into:

Culture is fuzzy. Tools have clear implementation paths.

If leadership approves budget for CI/CD tools:

  • Research vendors (3 days)
  • Run POC (2 weeks)
  • Purchase and rollout (1 month)
  • Measure impact (ongoing)

Clear steps. Clear timeline. Clear ownership.

But if leadership approves budget for "improving developer experience culture":

  • Uhhh… where do I start?
  • What’s step 1 vs. step 10?
  • Who owns this?
  • How long does it take?
  • How do I know if it’s working?

I’ve struggled with this. Let me share what’s worked for me, and I’d love to hear what’s worked for you all.

First Steps I Recommend

Step 1: Run a Baseline Survey (Week 1-2)

What: Measure current state before you change anything.

How: Developer satisfaction survey measuring:

  • Psychological safety: "I feel safe to push back, ask questions, admit mistakes" (1-5)
  • Clarity: "I understand team priorities and how my work contributes" (1-5)
  • Feedback loops: "I get timely feedback on my work" (1-5)
  • Cognitive load: "I can focus on my work without constant context switching" (1-5)
  • Collaboration: "I work effectively with other teams" (1-5)

Tools: Google Forms (free), CultureAmp ($5K/year), Officevibe ($3K/year)

Why: You can’t improve what you don’t measure. Baseline survey gives you:

  • Data on WHERE culture gaps are
  • Benchmark to measure progress
  • Credibility with leadership ("We measured this")

Cost: $0-5K depending on tool
Time: 2 weeks

Step 2: Map Decision-Making Processes (Week 3-4)

What: Understand where decisions get stuck.

How: Workshop with eng leadership:

  • List key decision types (architectural, technical, prioritization, hiring, etc.)
  • For each decision type: Who has input? Who decides? Who needs to be informed?
  • Identify bottlenecks: Which decisions take too long? Which escalate unnecessarily?

Output: Decision-making RACI matrix + list of decision-making problems to fix

Example bottleneck: "Product decisions get made without eng input, then eng pushes back, then we re-decide. Adds 2 weeks to every feature."

Cost: $3-5K for facilitator (or free if you run it yourself)
Time: 2 weeks

Step 3: Create Team Charters (Week 5-8)

What: Clarify team ownership, responsibilities, and communication.

How: Each team creates a charter:

  • Mission: Why does this team exist? What business capability do we own?
  • Ownership: What services/systems/domains do we own?
  • Responsibilities: What are we accountable for?
  • Communication: How do other teams work with us? What’s our SLA?
  • Decision authority: What decisions can we make without escalation?

Why: Reduces cognitive load, clarifies ownership, improves cross-team collaboration.

Example: "Payments team owns all payment-related services. Other teams can call our APIs but shouldn’t modify our code. We commit to 24-hour response time for questions."

Cost: Mostly time. Maybe $5K for facilitator.
Time: 1 month (teams work in parallel)

Step 4: Establish Feedback Loops (Week 9-12)

What: Create regular rituals for feedback and improvement.

How: Implement:

  • Sprint retros: Every 2 weeks, teams identify one process improvement
  • 1-1s: Weekly eng manager to engineer check-ins
  • Architectural reviews: Monthly forum for discussing technical decisions
  • Cross-functional syncs: Weekly product-eng-design alignment

Why: Feedback loops are one of the three core DevEx dimensions. Without regular feedback, problems compound.

Cost: Mostly time. Maybe $5K for training managers on running effective retros and 1-1s.
Time: 1 month to establish rituals, ongoing to maintain

Step 5: Measure and Iterate (Month 4+)

What: Re-run the baseline survey, track metrics, adjust.

How:

  • Month 4: Re-run developer satisfaction survey
  • Compare to baseline: What improved? What didn’t?
  • Adjust: Double down on what worked, fix what didn’t

Ongoing metrics:

  • Quarterly developer satisfaction survey
  • Velocity and quality metrics (to show business impact)
  • Retention and attrition (to show talent impact)

Cost: Ongoing
Time: Quarterly check-ins

A Concrete Example from My EdTech Company

Let me share what we actually did:

Month 1: Baseline survey. Identified:

  • Low scores on "clarity of priorities" (2.8/5)
  • Low scores on "decision-making speed" (2.5/5)
  • Medium scores on psychological safety (3.4/5)

Month 2: Decision-making workshop. Created RACI matrix:

  • Product owns "what" and "why"
  • Engineering owns "how" and "when"
  • Weekly alignment meeting to resolve conflicts

Month 3: Team charters. Each team clarified ownership. Reduced cross-team dependencies by 40%.

Month 4: Established feedback loops:

  • Sprint retros (every 2 weeks)
  • Weekly product-eng sync
  • Monthly architectural review

Month 5: Re-survey. Results:

  • Clarity of priorities: 4.2/5 (was 2.8)
  • Decision-making speed: 4.0/5 (was 2.5)
  • Psychological safety: 3.8/5 (was 3.4)

Business impact:

  • Velocity improved 35%
  • Engineer retention improved (0 attrition in 6 months)
  • Product-eng conflict way down

Total cost: ~$30K (surveys, facilitators, manager training)
Total time: 5 months
ROI: Massive (35% velocity improvement alone justifies the cost)

The Key: Leadership Must Model the Culture Changes

Here’s the hardest part:

Culture changes only stick if leadership models them.

If you create a decision-making RACI but leadership still makes arbitrary decisions, it won’t work.

If you establish psychological safety but managers punish people for pushing back, it won’t work.

If you create feedback loops but no one acts on feedback, it won’t work.

Culture flows from the top. Leadership must:

  • Use the new decision-making frameworks
  • Model psychological safety
  • Participate in feedback loops
  • Hold people accountable to new norms

This is why culture change is hard. It requires behavior change from leadership, not just new processes.

My Questions for You

1. What’s worked for you?
What first steps have you taken to improve DevEx culture? What worked? What didn’t?

2. How long did it take?
My experience: 3-6 months to see meaningful impact. Is that typical?

3. How did you maintain momentum?
Culture changes can regress if you don’t maintain them. How do you keep the improvements from sliding back?

4. What’s the biggest obstacle?
For me, it’s getting leadership to model the changes. What’s been hardest for you?

Let’s figure out the practical implementation side of this. Because culture investment only works if you actually DO it. :flexed_biceps:

2

Keisha, this is SO practical. Thank you for the step-by-step breakdown. Let me share what I did at my financial services company.

My Implementation Approach: Team Topologies Workshop

When I got buy-in to invest in culture, I started with organizational structure. Because I’''d learned: Structure changes ARE culture changes.

Month 1: Team Topologies Workshop

What: Brought in a consultant to run a 2-day workshop on Team Topologies framework.

Who: All eng leadership + senior ICs (about 25 people)

Outcome:

  • Mapped our current team structure
  • Identified problems: Too many dependencies, unclear ownership, cognitive overload
  • Designed new structure: Stream-aligned teams, platform team, enabling teams

Cost: 5K (consultant + 2 days of everyone’''s time)

Month 2-3: Restructure Teams

What: Reorganized teams based on workshop output.

How:

  • Stream-aligned teams: Each team owns a clear business capability (Payments, Identity, Lending, etc.)
  • Platform team: Builds internal tools to reduce cognitive load for stream teams
  • Enabling teams: Security and compliance teams help stream teams adopt best practices

Key principle: Minimize dependencies between teams. Each stream team can ship independently.

Challenges:

  • Some people had to change teams (uncomfortable but necessary)
  • Had to clarify ownership boundaries (“Who owns this service now?”)
  • Some managers lost headcount (politically tricky)

Cost: Mostly time and political capital. Maybe K for org design consulting.

Month 4: Clarify Decision Authority

What: Documented decision-making authority for each team.

How: Created a matrix:

  • Team-level decisions: Technical implementation, testing approach, deployment schedule (no escalation needed)
  • Cross-team decisions: APIs, data contracts, shared infrastructure (requires architectural review)
  • Leadership decisions: Hiring, budget, strategic direction

Why: Reduced decision latency by 75%. Teams can move fast without waiting for approval.

Cost: Minimal (mostly documentation)

Month 5: Implement Decision Logs

What: Started tracking decision velocity.

How:

  • Created a Notion database for “decisions needed”
  • Each decision gets logged with: What’''s the decision? Who decides? When was it decided?
  • Tracked time from “decision needed” to “decision made”

Why: Visibility into decision bottlenecks. We could see where decisions got stuck and fix those processes.

Cost: Free (just Notion)

Results After 6 Months

Velocity: 40% improvement (teams shipping faster because dependencies reduced)

Cognitive load: Dramatically down (engineers own clear domains, less context switching)

Decision velocity: Average decision time went from 8.5 days to 2.1 days

Incidents: Down 30% (clear ownership means faster resolution and better prevention)

Engineer satisfaction: Up significantly (people feel empowered)

Total cost: ~0K (consultant, facilitation, org design support)

ROI: Massive. 40% velocity improvement alone pays for the investment 10x over.

Key Learning: Structure Changes Enable Culture Changes

Keisha, you focus on surveys and decision-making workshops. I focused on organizational structure.

Both work. But here’''s what I learned:

Changing structure FORCES culture changes.

Example:

  • Old structure: Unclear ownership → culture of finger-pointing and escalation
  • New structure: Clear ownership → culture of accountability and autonomy

You can’''t have a culture of autonomy if the structure requires 5 layers of approval. Structure and culture are deeply intertwined.

My Answers to Your Questions

1. What worked?

  • Team Topologies framework (gave us a mental model)
  • Clear ownership (reduced ambiguity and conflict)
  • Decision authority matrix (empowered teams)

2. How long did it take?

  • 6 months to see major impact. Similar to your timeline.

3. How did you maintain momentum?

  • Quarterly retros on org structure (“Is this still working?”)
  • Kept tracking decision velocity (visibility prevents regression)
  • Leadership reinforced the new norms consistently

4. Biggest obstacle?

  • Political resistance. Some managers didn’‘‘t want to lose headcount. Some ICs didn’’'t want to change teams. Had to push through that discomfort.

My Recommendation: Start with Structure

Keisha, your approach is great. Mine is complementary.

I’''d recommend: Start with structure, THEN invest in feedback loops and surveys.

Why? Because structure changes create immediate impact. Then you can refine with surveys and feedback.

But both matter. Structure without feedback loops gets stale. Feedback loops without clear structure just surface problems you can’''t fix.

3

Keisha, Luis—both of your approaches are excellent. Let me add the C-level perspective on implementation.

C-Level Culture Change: It Starts at the Top

Here’''s the uncomfortable truth:

Culture change fails if it doesn’''t start with executive alignment.

I’''ve seen too many well-intentioned culture initiatives die because:

  • Engineering invests in DevEx culture
  • Product doesn’''t change their behavior
  • Sales keeps making promises eng can’''t deliver
  • Finance cuts headcount mid-culture transformation

Culture is a system. You can’''t fix one part without alignment across the whole leadership team.

My Implementation Approach

Month 1: Executive Alignment

What: Got the entire exec team (CEO, CTO, CPO, CFO, Head of Sales) aligned on engineering culture principles.

How: 2-day offsite where we:

  • Defined engineering principles (quality, autonomy, collaboration, learning)
  • Discussed what each executive needed to CHANGE to support these principles
  • Created accountability: How do we measure if we’''re living these principles?

Why: If the CEO is saying “ship faster” while the CTO is saying “invest in quality,” culture change won’''t work.

Key outcome: Everyone agreed:

  • Product won’''t commit to timelines without eng input
  • Sales won’‘‘t promise features that aren’’'t on the roadmap
  • Finance won’''t cut eng headcount during transformation
  • Engineering will deliver predictably

Cost: 0K for facilitator

Month 2-3: Define and Cascade Engineering Principles

What: Turned our executive alignment into engineering principles that the whole org can understand.

Our principles:

  1. Quality over speed: We ship predictably, not frantically
  2. Autonomy with alignment: Teams have authority within clear boundaries
  3. Collaboration is non-negotiable: We work cross-functionally from day one
  4. Learn and grow: We invest in developing people
  5. Data-driven decisions: We measure and iterate

How we cascaded:

  • Town halls: I presented the principles to all engineers
  • Skip-levels: I met with ICs to hear their feedback
  • Manager training: Trained all eng managers on reinforcing these principles
  • Documentation: Wrote up principles in internal wiki

Cost: ~5K for manager training

Month 4-6: Implement Culture Champions

What: Identified “culture champions” in each team to model and reinforce new behaviors.

Who: Senior ICs who already embodied the culture we wanted. Not managers—we wanted peer influence.

What they do:

  • Model behaviors (e.g., psychological safety, collaboration, quality)
  • Call out violations (e.g., “That meeting didn’''t have eng representation”)
  • Coach peers (e.g., help junior engineers navigate decision-making)
  • Provide feedback to leadership (monthly skip-levels with me)

Why it works: Culture change is peer-to-peer, not top-down. Champions create social proof.

Cost: Minimal (recognition and small bonuses for champions)

Month 7-9: Invest in Engineering Manager Training

What: Trained all eng managers on creating culture.

Topics:

  • How to run effective 1-1s
  • How to create psychological safety
  • How to facilitate retros
  • How to give feedback
  • How to resolve conflict
  • How to develop people

Why: Managers are the culture carriers. If they don’‘‘t know how to create psychological safety, it won’’'t happen.

Cost: 0K for external training program

Month 10-12: Measure and Adjust

What: Quarterly measurement and adjustment.

Metrics:

  • Developer satisfaction survey (Keisha’''s approach)
  • SPACE metrics (satisfaction, performance, activity, communication, efficiency)
  • Retention and attrition
  • Delivery predictability

Adjustments:

  • If satisfaction is low in a team, investigate and intervene
  • If delivery predictability is low, look at decision-making or dependencies
  • If attrition spikes, understand why and address root causes

Cost: 0K/year for measurement tools

Results After 12 Months

Developer satisfaction: Up 40% (from 3.2/5 to 4.5/5)

Delivery predictability: Teams hit 80% of commitments (was 45%)

Retention: Attrition dropped from 25% to 8%

Quality: Incidents down 35%

Talent pipeline: eNPS up, referrals up, easier to recruit

Total cost: ~00K (facilitators, training, measurement tools)

ROI: Retention improvement alone saved 00K+ in replacement costs. Delivery predictability unlocked M+ in revenue from on-time launches.

Key Learnings

1. Culture flows from the top

If executives don’‘‘t model the culture, it won’’'t stick. I had to:

  • Model psychological safety (admit when I’''m wrong)
  • Model collaboration (involve eng in product decisions)
  • Model learning (share what I’''m learning)

2. Managers are culture carriers

Invest heavily in manager training. They’''re the ones creating psychological safety, running 1-1s, facilitating retros.

3. Culture champions amplify change

Peer influence is more powerful than top-down mandates. Champions create social proof.

4. Measurement creates accountability

Quarterly surveys make culture visible. Leadership can’''t ignore low satisfaction scores.

My Answers to Your Questions

1. What worked?

  • Executive alignment (critical foundation)
  • Engineering principles (clear north star)
  • Culture champions (peer influence)
  • Manager training (culture carriers)

2. How long did it take?

  • 9-12 months to see major transformation. Longer than Luis or Keisha, but we’''re a bigger org (200 engineers).

3. How to maintain momentum?

  • Quarterly measurement (keeps it visible)
  • Culture champions (ongoing reinforcement)
  • Leadership modeling (I still do skip-levels and town halls)

4. Biggest obstacle?

  • Getting exec alignment. Some execs didn’''t want to change their behavior. Had to have hard conversations.

My Recommendation: Start at the Top

Keisha starts with surveys. Luis starts with structure. Both great.

I’''d add: Start with executive alignment.

If the exec team isn’‘‘t aligned, culture initiatives will fail. Get alignment first, THEN implement Keisha’’‘s surveys and Luis’''s structure changes.

4

Keisha, Luis, Michelle—I love all these approaches. Let me add the smaller-scale version for those of us who don’''t have CTO-level authority. :sweat_smile:

Small-Scale Culture Improvements: Design Team Edition

I’‘‘m not a CTO or eng director. I’’‘m a design lead with a team of 6 designers. I can’''t restructure the whole company. But I CAN improve culture within my team.

Here’''s what I did:

Month 1: Design Critique Guidelines

Problem: Our design critique sessions were awkward and unproductive. People were either too nice (“looks great!”) or too harsh (“this is bad”).

Solution: Created design critique guidelines:

  • Focus on the work, not the person: “This button feels small” not “You made it too small”
  • Ask questions first: “What were you trying to achieve here?” before offering criticism
  • Offer alternatives: “What if we tried…” instead of just “This doesn’''t work”
  • Celebrate what works: Point out good decisions, not just problems

How: 1-hour workshop to introduce guidelines, then practiced them in our weekly critique sessions.

Cost: Free (just my time)

Result: Design critique became productive. People felt safe to share work-in-progress. Quality improved because we caught issues earlier.

Month 2: Decision-Making Framework for Design Choices

Problem: Designers and PMs would argue endlessly about design decisions. No clear framework for who decides.

Solution: Created decision-making framework:

  • Designer decides: Visual design, interaction patterns, accessibility
  • PM decides: Scope, priority, business requirements
  • Collaborate: User experience flow, feature design
  • Escalate: Anything that impacts brand or legal

How: Documented in Notion, reviewed with PM partners, reinforced in practice.

Cost: Free

Result: Design-PM conflict dropped dramatically. Decisions happened faster.

Month 3: Design Office Hours

Problem: Engineers would implement designs wrong, then designers would find out later and be frustrated.

Solution: Weekly “design office hours”:

  • 1 hour/week, open drop-in
  • Engineers can bring questions about design implementation
  • Designers provide real-time guidance
  • Cross-functional collaboration ritual

Cost: 1 hour/week of my time

Result: Design-to-dev handoff errors dropped 60%. Engineers felt supported. Designers felt respected.

Month 4: Measure and Iterate

What: Ran a mini-survey of designers and cross-functional partners.

Questions:

  • “Design critique is productive and helpful” (1-5)
  • “I understand how design decisions get made” (1-5)
  • “I work effectively with design team” (1-5) [asked to eng and PM partners]

Results:

  • Design critique: 4.3/5 (was probably 2.5 before)
  • Decision clarity: 4.1/5 (was probably 2.8 before)
  • Cross-functional collaboration: 4.0/5 (was probably 3.0 before)

Total cost: /Users/tianpan/projects/discourse_docker/simulator-v2/complete_devex_simulation.sh (all just process and time)

Total time: 4 months

Impact: Happier designers, better collaboration, higher-quality work

Key Learning: You Don’''t Need Big Authority to Improve Culture

Michelle talks about executive alignment and engineering principles. That’‘‘s great if you’’'re a CTO.

But if you’''re an IC or a team lead, you CAN still improve culture:

  • Start with your team
  • Fix one friction point at a time
  • Model the culture you want
  • Create rituals that reinforce good behavior

Small changes compound over time.

My Question: How Do You Scale Culture Practices as Teams Grow?

Here’''s my current challenge:

Our design team was 6 people when I implemented these changes. Now we’''re 15 people.

Challenges:

  • Design critique doesn’''t scale (too many people, too long)
  • Office hours are getting crowded
  • New designers don’''t know our culture norms

Questions:

  • How do you scale culture practices without losing the intimacy that made them work?
  • How do you onboard new people into an established culture?
  • How do you maintain culture quality as you grow fast?

Keisha, Luis, Michelle—you’''re at bigger orgs. How do you handle this?

5

Keisha, this is such a valuable thread. Let me add the product-eng alignment perspective.

Product-Eng Alignment: The Missing Piece

Everyone’‘‘s talking about engineering culture. But I’’'ve learned:

DevEx problems are often product-eng misalignment problems.

Example:

  • Engineers complain about unclear requirements → That’''s a product problem
  • Engineers complain about constantly changing priorities → That’''s a product problem
  • Engineers complain about being treated as “order-takers” → That’''s a product problem

You can improve eng culture all you want, but if product is still throwing chaos at engineering, DevEx will suffer.

My Implementation Approach: Product-Eng Rituals

Here’''s what I did at my company:

Week 1: Weekly Alignment Sessions

What: 60-minute product-eng alignment meeting every Monday.

Agenda:

  • Product shares upcoming priorities for next 2-4 weeks
  • Eng gives technical feedback and feasibility input
  • We resolve conflicts and ambiguity together
  • Decisions get documented

Why: Prevents “surprise” work and scope changes mid-sprint.

Cost: 60 minutes/week of leadership time

Result: “Surprise scope” dropped 70%. Engineers feel heard. Product gets better technical input.

Week 2: Decision-Making RACI

What: Documented who decides what.

Framework:

  • Product owns: What we build, why we build it, success metrics
  • Engineering owns: How we build it, when we can deliver, technical architecture
  • Collaborate: Scope negotiation, timeline trade-offs, feature design

Example:

  • Product wants feature X by date Y
  • Eng says: “We can deliver by date Y if we cut scope to A and B. Or we can deliver full scope by date Z.”
  • Product decides: Priority or scope
  • Eng decides: How to implement

Cost: Free (just documentation)

Result: Product-eng conflict down dramatically. Clearer decision-making.

Month 2: Reduced Context Switching

What: Limited engineers to max 2 projects at a time.

Why: Product was assigning engineers to 4-5 projects simultaneously. Cognitive load was crushing people.

How:

  • Worked with eng leadership to set boundaries
  • Product had to prioritize (can’''t have engineers on everything)
  • Engineers got focused time on fewer projects

Cost: Free (just prioritization discipline)

Result: Velocity actually INCREASED because engineers could focus. Quality improved. Engineers happier.

Month 3: Embedded Collaboration

What: Product and eng collaborate from day one of feature development.

Old way: Product writes PRD → Throws over wall to eng → Eng pushes back → Re-negotiate

New way: Product and eng collaborate on PRD together → Eng has input early → Fewer surprises

How: Product invites eng to early product discussions. Eng invites product to sprint planning.

Cost: More time upfront, less rework later

Result: Features ship faster end-to-end because we avoid the back-and-forth.

Month 4: Measure and Iterate

Metrics I track:

  • Feature delivery predictability: How often do we hit our commitments?
  • Scope change rate: How often does scope change mid-sprint?
  • Product-eng satisfaction: “I work effectively with product/eng” (survey question)

Before changes:

  • Delivery predictability: 40%
  • Scope change: 60% of sprints had mid-sprint changes
  • Product-eng satisfaction: 2.9/5

After changes:

  • Delivery predictability: 75%
  • Scope change: 20% of sprints
  • Product-eng satisfaction: 4.2/5

Total cost: /Users/tianpan/projects/discourse_docker/simulator-v2/complete_devex_simulation.sh (just process changes)

Total time: 4 months

Impact: Faster shipping, happier engineers, better product-eng relationship

Key Learning: Consistent Rituals > One-Time Workshops

Michelle talks about 2-day offsites and workshops. Those are valuable.

But here’‘‘s what I’’'ve learned:

Consistent weekly rituals matter more than one-time workshops.

Example:

  • One-time alignment workshop: Creates clarity for 2 weeks, then regresses
  • Weekly alignment ritual: Maintains clarity over time

Culture is built through repetition, not events.

My Answers to Keisha’''s Questions

1. What worked?

  • Weekly product-eng alignment (prevents chaos)
  • Decision-making RACI (reduces conflict)
  • Focus time policies (reduces cognitive load)
  • Embedded collaboration (improves quality)

2. How long did it take?

  • 3-4 months to see major impact. Similar to others.

3. How to maintain momentum?

  • Weekly rituals keep it alive
  • Quarterly retros to adjust
  • Measurement keeps us honest

4. Biggest obstacle?

  • Getting product leadership to accept boundaries. PMs wanted engineers on every project. Had to say no and prioritize.

My Recommendation: Fix Product-Eng Alignment FIRST

Keisha starts with surveys. Luis starts with structure. Michelle starts with exec alignment.

I’''d add: Fix product-eng alignment first.

Because if product is still creating chaos, no amount of eng culture improvement will help.

Start with weekly alignment. Add decision-making clarity. Reduce context switching.

Then invest in the deeper culture work Keisha, Luis, and Michelle describe.