Engineering Culture as a Measurable System: Building Teams That Actually Work

Engineering culture isn't a soft, unmeasurable concept—it's a system with inputs, outputs, and measurable health indicators that directly correlate with product quality and business outcomes. That's the core argument from Gonzalo (Glo) Maldonado, a former Staff Platform Engineer and CTO, who brings a systems-thinking approach to what many leaders treat as an abstract HR concern.

"If you have a lot of tech debt, if your developers are dreading coming to work, it's going to show on your product and it's going to show in your sales," Maldonado explains. "It's so interesting how people don't make that connection always when, for me, it's extremely obvious."

Measuring What Actually Matters: Beyond DORA Metrics

Most engineering leaders default to quantitative metrics like DORA (Deployment Frequency, Lead Time for Changes, Time to Restore Service, Change Failure Rate). While Maldonado acknowledges their importance, he advocates for a more nuanced approach using SPACE metrics and qualitative indicators.

"You need to have some vibe checks," he says, referencing the current trend of "vibe coding" and "vibe checks." "This is one of the reasons DORA metrics... are important, but I mostly try to work more with SPACE metrics. The reason why is you need to build your own metrics. You need to identify how can you see the quality of your work impacting everything."

The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) provides a more holistic view than pure output metrics. But Maldonado takes it further with a simple, powerful qualitative metric borrowed from sales: the Net Promoter Score (NPS).

"I think that's what matters most at work. If your teammates want to recommend their friends, you're doing something great," he says. "People are definitely excited and it touches many areas. It touches from the codebase. If you have a lot of tech debt, no one's going to want to work on that, but it's over in your engineering process."

This team NPS approach reveals what quantitative metrics miss: the human element of engineering work. A team might hit all their DORA targets while quietly burning out, creating a fragile system that collapses when key people leave or when technical debt finally catches up.

The Software Development Lifecycle as Cultural Artifact

One of Maldonado's most practical insights is that your software development lifecycle (SDLC) isn't just a technical process—it's a cultural choice that should vary by organization.

"I don't think it's identical everywhere. I think it must be different on different companies, because for NASA, I want to slow and possibly even somewhat waterfall-ish," he explains. "I do believe in agile and even some modes that I have a whole conversation about post-agile... But what really matters is that you understand that that lifecycle is part of your culture."

This challenges the one-size-fits-all agile dogma that has dominated software engineering for two decades. A startup shipping a mobile app needs a fundamentally different process than a team building medical device software or a space mission control system. The culture should inform the process, not the other way around.

Maldonado suggests that leaders should explicitly design their SDLC as a cultural artifact:

1. Define your risk tolerance: Are you building for 99.999% uptime or rapid iteration?
2. Map your decision-making: Who decides what, and how quickly?
3. Design your feedback loops: How do you incorporate learning from production?
4. Create rituals that reinforce values: Code reviews, retrospectives, architectural decision records

Hiring for Curiosity: The Anthropological Approach

When Maldonado interviews engineers, he doesn't just assess technical skills—he looks for curiosity as the primary cultural fit indicator.

"One of the questions I always ask is, 'Tell me about your hobbies or tell me about something that caught your attention recently.' The important thing is I don't really care about what they do or their interest or the news they hear. I want to hear the curiosity," he says.

This anthropological lens comes from his background in anthropology and sociology. He references Margaret Mead's work and recommends documentaries about Mozilla's formation from Netscape's ashes as case studies in how culture shapes technology.

The key insight: curious engineers naturally see systems. "If people can see things as a system, they tend to be very curious, because systems are fascinating," Maldonado notes. "My whole career has been understanding systems one way or the other."

For hiring managers, he offers practical advice:

• Listen for questions: Candidates who don't ask questions during interviews are a red flag
• Look for pattern recognition: Do they connect disparate ideas?
• Assess learning velocity: How quickly do they absorb new context?
• Value diverse backgrounds: "People are well-rounded. People have interests, they have motivations."

Building Resilient Teams Through Blameless Culture

Maldonado advocates for blameless post-mortems not just as a technical practice but as a cultural foundation. He uses the five whys methodology to demonstrate how technical and social systems intertwine.

"One of the things that I love, and this is very popular on the SRE circles, is a blameless culture, a culture that is like, 'Hey, we don't care who broke what. We really don't care. We care why it broke.' This is one of the most important engineering principles that I think apply both in the culture side and on the technical side."

He walks through a DNS failure example:

1. Technical root cause: Vendor changed syntax without notification
2. Process gap: No monitoring caught the change
3. Organizational gap: Only one team understood the networking stack
4. Cultural gap: No rotation or knowledge sharing for critical systems
5. Systemic solution: Implement on-call rotation and vendor notification protocols

The key is that blameless culture isn't about avoiding accountability—it's about understanding that systems fail, and the goal is to make the system more resilient, not to punish individuals.

Lessons from Civil Engineering: Professional Standards and Ethics

Maldonado draws powerful parallels between software engineering and mature engineering disciplines like civil engineering, which has existed for millennia.

"My dad, he was a civil engineer, which civil engineering is one of the oldest professions that we have in the engineering realm. It was a stark contrast with my engineering, which is software engineer. We're brand new, we're a couple decades old, we haven't achieved 100 years like civil engineer has."

He references the history of the Freemasons, who originally emerged as a guild to ensure construction techniques met standards. "When the brick was invented, what did people do in order to make sure that bricks matter? That's a fascinating and very curious story about the Freemasons. People forget the Freemasons were a culture about making sure that these constructions techniques, even more than the technologies, the techniques, were up to standards."

This historical perspective reveals what software engineering lacks: standardized codes of ethics and professional certifications that ensure quality. While organizations like IEEE and ACM provide frameworks, they haven't achieved the same cultural weight as civil engineering's professional standards.

Maldonado suggests software engineering should learn from this:

1. Create clearer professional standards: What does "professional software engineering" mean?
2. Develop ethical frameworks: How do we handle AI, privacy, and security decisions?
3. Build knowledge preservation systems: How do we ensure lessons aren't lost when technologies change?
4. Establish mentorship traditions: Civil engineering has centuries of apprenticeship; software engineering needs similar structures

The Intersection of Technology, Art, and Culture

Maldonado makes a profound connection between technology, art, and culture, using artist Theo Jansen's wind-powered "Strandbeests" as an example.

"One of my heroes, Theo Jansen, he makes this weird PVC sculptures that are a feat of engineering and a feat of art and they're the same thing. He's showing that, with his art, the real value of these creatures is they influence culture."

This perspective reframes software development: we're not just writing code, we're creating cultural artifacts that shape how people think and work. The choice between TypeScript and JavaScript, for example, isn't just technical—it's cultural.

"TypeScript, it feels very object-oriented. The reason why they chose that is, again, the culture, because it's still very rare to see people who are less experts and care about functional programming and stuff like that. They tend to understand OOP better. Yes, that is just culture and there is no other explanations."

Even our naming conventions reveal culture. Maldonado mentions encountering services named "Samwise" (from Lord of the Rings) for security and authentication systems.

"It's always about security and authentication and that is culture. It's a double-edged sword. You want to make sure that what you're building can be understood by someone who hasn't read Lord of the Rings. At the same time, it's good that you have engineers that have that curiosity like, 'Why is the team Samwise?'

Practical Framework for Cultural Leadership

For technical leaders looking to intentionally shape their team's culture, Maldonado offers a systems-thinking approach:

1. Map Your Cultural System

• Known knowns: What cultural values are explicit and documented?
• Known unknowns: What cultural aspects are you aware you don't measure?
• Unknown unknowns: What cultural risks are you blind to?

2. Design Cultural Rituals

• Code review as cultural practice: Not just for catching bugs, but for knowledge transfer and standard-setting
• Retrospectives as learning loops: Focus on systemic improvements, not individual blame
• Architecture decision records: Document the "why" behind technical choices
• On-call rotations: Distribute knowledge and prevent hero culture

3. Measure Cultural Health

• Team NPS: "Would you recommend working here to a friend?"
• Psychological safety: Can people admit mistakes without fear?
• Learning velocity: How quickly does the team adapt to new technologies?
• Cross-functional collaboration: How often do engineers talk to product, sales, and customers?

4. Learn from Other Disciplines

• Civil engineering: Professional standards, codes of ethics
• Chemical engineering: Safety protocols, hazard communication
• Electrical engineering: Maxwell's equations as foundational principles
• Anthropology: Understanding culture as a system of shared meanings

The Future: Software Engineering as a Mature Profession

Maldonado sees software engineering at a crossroads. We're in a "knowledge revolution," similar to how civil engineering transformed with the invention of the brick or electrical engineering with Maxwell's equations.

"We can learn from civil engineering like, okay, when the brick was invented, that was a revolution. When the brick was invented, what did people do in order to make sure that bricks matter?"

He references Hedy Lamarr's invention of frequency-hopping spread spectrum (the basis for CDMA and modern wireless communication) as an example of how cultural curiosity drives technological innovation.

"She thought, 'Hey, you know how in a piano you have multiple notes? Can we use that for the communications, for the radar? Can we use that for things?' That's how our cell phone works today. It's called CDMA and it's called modulation and it's basically saying, 'Yes, you can use different codes to send data'. That was a huge revolution."

The lesson: our cultural values—curiosity, collaboration, ethical standards—directly shape what we build and how we build it.

Actionable Takeaways for Engineering Leaders

1. Start measuring team NPS: Add one question to your retrospectives: "On a scale of 0-10, how likely are you to recommend this team to a friend? Why?"

2. Audit your SDLC: Is it designed for your specific risk profile and business model, or are you following someone else's template?

3. Hire for curiosity: In your next interview, ask about recent learning or hobbies and listen for the "why" behind their interest.

4. Implement blameless post-mortems: Focus on systemic fixes, not individual blame. Use the five whys to uncover both technical and social root causes.

5. Study other engineering disciplines: Talk to civil, chemical, or electrical engineers about their professional standards and ethical frameworks.

6. Design cultural rituals intentionally: Every meeting, review, and process should reinforce your desired cultural values.

7. Map your cultural system: Use the known-knowns framework to identify blind spots in your team's culture.

Conclusion: Culture as a Technical Practice

Engineering culture isn't separate from technical work—it's the foundation that makes technical excellence possible. As Maldonado demonstrates, culture can be measured, designed, and improved using the same systematic thinking we apply to software architecture.

The most successful engineering organizations don't treat culture as an HR initiative. They treat it as a core technical practice, with metrics, rituals, and continuous improvement. They understand that the code they ship is a reflection of the culture they've built, and that investing in culture is investing in product quality, team resilience, and long-term business success.

For leaders ready to move beyond vague "culture talk," the path is clear: measure what matters, design intentional rituals, learn from mature disciplines, and always, always prioritize curiosity.

---

Listen to the full conversation: Engineering Culture Is Everything: Building Teams That Actually Work

Learn more about QCon London 2026: March 16-19, 2026

Connect with Gonzalo (Glo) Maldonado: LinkedIn

Related resources:

• SPACE framework for developer productivity
• Google's DORA research
• Blameless post-mortems in SRE
• Margaret Mead's cultural anthropology
• Theo Jansen's Strandbeests

Books mentioned:

• What You Do Is Who You Are by Ben Horowitz
• Sapiens: A Brief History of Humankind by Yuval Noah Harari

Documentaries and essays:

• Mozilla documentary
• Jamie Zawinski's essays
• Worse is Better explained