Why Engineering Culture Is Everything: Building Teams That Actually Work

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Glo Maldonado. Glo, welcome. Thanks for taking the time to talk to us today.

Introductions [00:31]

Gonzalo (Glo) Maldonado: Hi, Glo Maldonado, also known as Gonzalo Maldonado. That's my official name, if you may. Yes, so happy to be here. A little bit about myself. In my previous life, I was staff platform engineering. I focused a lot of development engineering and everything that basically was the sociotechnical aspect of our technical work. I recently was working as a CTO and co-founder of a startup, and nowadays I'm just doing advisory roles and a little bit of consulting while trying to think about the next big thing. Yes, so happy to be talking with you, Shane.

Shane Hastie: Cool. That's a bit about your background. We were chatting earlier on about what we want to talk about today, and you made a wonderful point that, given that this is the Engineering Culture Podcast, culture is what matters most. Obviously, as the lead for engineering culture, I agree. But why? What are the many factors that make culture so important in our organizations today?

Why culture is everything in engineering [01:35]

Gonzalo (Glo) Maldonado: Yes. Like I was mentioning, I have 15-plus years of experience in the industry specific here in the Bay Area. If you see from my background, I had five years that I work in Latin America, Mexican specific. One of the things that always catches my attention is how important is that the people understand the why. Especially us engineers, we really need to understand why are we doing something. It's not just because we want to make sure that things matter, but also because the solutions that we build really depend on us getting enough context. Talking about the culture, I think that, in my opinion, all great engineers are curious and they're detail-oriented and they care about how their systems are going to impact people.

When I say that it's everything, it's because it tends to be. If you want to see on one side of the spectrum, the business side and sales side, you are trying to impress a customer, you're trying to make a customer happy, make sure that the product that you're giving them actually solves the problem. But then from the engineering side, 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. It's so interesting how people don't make that connection always when, for me, it's extremely obvious.

Shane Hastie: What does a good engineering culture show up like? What does it feel like? What does it look like?

What good engineering culture looks like [03:08]

Gonzalo (Glo) Maldonado: One of the conversations I always have with my engineers whenever they get to the senior levels is that you need to understand that there's two ways of measure things. You can measure things quantitatively, you can put numbers into things and just try to hit those numbers, or you can do it by quality. This is all relevant right now when we're vibe coding and doing vibe checks and everything. This is definitely what we're doing with our engineering teams. You need to have some vibe checks. This is one of the reasons DORA metrics, those engineering quality metrics... I think they're 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.

One of the changes recently in the sales world is the net promoter score. I know some people like it, some don't, but the reason I like it is because it's a simple question. It's like, "How likely are you to recommend this product to someone else?" I think that's what matters the most at work. If your teammates want to recommend their friends, you're doing something great. 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. The software development life cycle, 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.

I do believe in agile and even some modes that I have a whole conversation about post-agile that I don't know if we have time to delve into that today. But what really matters is that you understand that that lifecycle is part of your culture. Even if it's a very technical thing, at the end of the day, you're trying to make people happy, your customers, and your own people happy, your internal customers, your employees. You're trying to make them happy. So yes, culture matters a lot.

Shane Hastie: Measure the qualitative things, think about your product lifecycle is a part of the way we do things here. What else? If I'm the reasonably new technologist leader, recently promoted into a position of leadership, maybe for my first time or I'm thinking about the staff engineer versus the people leader journey, what are the things that I should be considering and how do I make that choice?

Making culture choices as a technical leader [05:53]

Gonzalo (Glo) Maldonado: One of my favourite books on entrepreneurship, but I think this is applied to anyone that works in technology, it is called Who You Are Is What You Do by Ben Horowitz, Andreessen Horowitz fame. It is true, the way that you choose how to do your actions, we forget that we're social animals. We engineers, we're still social animals, we still deal with social technical issues mostly. This is really important, because the ritual that you have like, "Oh, I'm going to have this process over another process or lack of process". That's also a process. Basically, not making the choice like, "Oh, we're going to be fit for all". That is a decision. I love that phrase, "If you don't plan, you're planning to fail". That is true.

The culture is something that is a fact and it's also something intrinsic with human beings. We're people, we have a background. We were raised in one part of the world versus another. We have the way that we talk and things that we care about. All those things influence your team indirectly and directly. It's really important, you as a leader, to be aware that as an engineer, I use a lot of metaphors from monitoring and observability. We always talk about known knowns, known unknowns, and unknown unknowns. Those are really important to understand on a systems level, period, because your social technical system is also a system.

The people that you work with, the way you work, your organization, it's a system. And if you're not aware of what are the metrics you need to track, what are the things that are threats to it, the good old strengths, weaknesses, opportunities, and threats. Yes, they apply to the individual, but they apply to your team and your whole organization. If you're not aware of all this simple metrics and... Yes, again, they're qualitative, they're not quantitative. You're at risk. Those unknown unknowns are going to catch up with you, so you should be trying to have some systems that is something that you didn't expect. I don't know.

Like tomorrow, your favourite programming language disappears. That happens. I've seen that happen in this 15 years of industry that suddenly you cannot hire any more objective C developers. That is probably happening right now. Those are the sort of things you need to think about like, "Okay, if that happens, how can I make a culture that either people will quickly learn Swift and we have a culture of constant learning?" Those are things that really impact, well, everything. Your business, your engineering team, your culture.

Shane Hastie: How do I influence culture?

How to influence engineering culture [08:33]

Gonzalo (Glo) Maldonado: That is one of the most interesting questions you can ask. My favourite subject in high school was anthropology and I've always been curious about sociology. I still read Margaret Mead books and stuff like that. Anthropology is definitely something that I have seen so useful and so appliable on my professional life. If you don't like reading books like that, there are excellent documentaries about Mozilla and especially what happened when they disbanded from Netscape. That is a fascinating story. I don't remember the name of the documentary on top of my head, but I recommend people looking up for that.

There's amazing work and essays by Jamie Zawinski and others that worse is better. Basically, the idea behind worse is better and the technical terms is that if you try to build a completely clean and perfect architecture from day one, you're going to waste a lot of time. What is better is to go and start building something that it's a prototype, it is not defined, it is barely understood, and then slowly you turn into something useful. It's interesting.

If you see the story of both languages, TypeScript and JavaScript, they started very experimental, very free for all, and then slowly they became something different, but it was based on the usage of people. For me, it's fascinating. One of my favourite things about JavaScript is that it's prototype-based. However, 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 OP better.

Yes, that is just culture and there is no other explanations. How you influence that culture, there are so many ways. You can do essays, like I mentioned, Jamie Zawinski, watch the documentary to also see conversations happening, people building things. It's also really interesting how building things influence your culture. In so many ways, and this goes back into anthropology principles, technology and art, they're byproducts of the culture. You have a culture, they are going to tend to go and build art to express their feelings, and then technology to get stuff done, to extract resources, process resources, and stuff like that. The interesting thing is I think they're one and the same.

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. People, when they see these creatures, they're like, "Oh, I need to build one. I used to have one on my desk and I should pull it out". But that shows that the technology and the art is influenced by call it trends, call it fashion, call it whatever you want to call it. These are all cultural things. It's really interesting to see that we forget that lesson all the time.

One example that I give all the time to engineers is do you know why we chose TCP/IP? Because Cisco had really good marketing. Yes, the marketing influences the culture like books, media. I don't know about you, but in 15 years of experience, I always run into a service called Samwise because Samwise was a character from Lord of the Rings. And of course we engineers, we love Lord of the Rings. 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?" And when they later tell me, "Oh, I read Lord of the Rings or watched the movies and I love them". I'm like, "Exactly. That is great". That is the sort of thing that we need to do as engineers. I think that curiosity is the best way to influence culture.

Shane Hastie: If I'm a manager tasked with employing someone, how do I know that they have that curiosity?

Identifying curious engineers during hiring [12:56]

Gonzalo (Glo) Maldonado: Well, that's a brilliant question. There are many ways, and I'm going to give the advice for both sides, both for the manager and for the interviewee. On the manager side, you need to remember that people are well-rounded. People have interests, they have motivations. Again, going to psychology and anthropology for a second, there's a Maslow hierarchy of needs. You need to understand that people are here and they're reaching to you because they do need to feed their family, but then there's the other steps, and those really inform you how the culture is.

It's important to be aware that your culture is different than others. One of the things that I love about anthropology is this concept that there is no culture that is superior to others. There's no culture that's better than the others. All cultures are. They have their own identity and they just are. When you know that as a manager, that's where you start getting intentionality. You start saying like, "Hey, does this person have a culture of nature that is curious naturally?" 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.

Or the other way I go around is I tell them the story and people who are curious tend to chip in like, "Shane, I think you're doing a great job of being curious. You're asking me like, 'Hey, how do you check curiosity?'" That is curiosity and that is something you can filter. For me, for employers, I feel like you need to do the job of giving them opportunity to be curious. If they don't ask you any questions, usually for me that's a red flag when I'm interviewing someone. On the flip side, I think don't be shy. I tell everyone, "You're unique. You were born and original. Take advantage of that, because us managers, we hire individuals for a collective and we want to see the best in you".

Shane Hastie: Leaning a little bit into that intentionality and touching on intersectionality, how do we encourage that diversity in teams?

Encouraging diversity and intersectionality in teams [15:15]

Gonzalo (Glo) Maldonado: I think that we can see it on many sides in leadership. On one side, we can see it as a process and the other side as a culture. When you're talking as a process, basically if you create on your... There's a software development lifecycle, and if you build into that spaces for review, spaces for bringing that diversity of thought, that is great. For example, when you're about to work in a new feature, if you can say like, "Hey, can we meet all of us, product managers, salespeople, and engineers, put in the same room and talk about this feature?" That is amazing and that is allowing diversity of thought to come in.

On the other side, I'm talking more about the culture.

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, the five whys. Usually when you ask five whys, you get to the real root of the questions.

Let's suppose your system going down, you can be going completely on the technical aspect, not on the social aspect yet. "Why did the website went down?" "Oh, it was a DNS issue". "Okay, what kind of DNS issue?" "Oh, it was this partitioning scheme", or something like that. I'm not a network expert. "Why that happened?" "Oh, because a vendor changed the way the syntax is doing". "Oh, why we didn't catch that?" "Oh, because we didn't see the documentation". So the error was the documentation. Great. That is the technical side of this problem, but what was the social side of this problem?

Let's do five whys. It's the same thing like, "Oh, why did our engineers didn't catch this?" "Oh, because only this certain team talks about that and deals with our networking". "Why do we have so few people looking at their networking?" "Because it requires certain expertise and being known about this syntax". "Who was looking into this when this change happened?" "Oh, actually no one. It turned out to be the vendor just made the change and they didn't notify our network admin that was happening. While they were in vacation, this change happened". "In the future, can we make sure that there's someone else, the rotation on call ready for that?" "Yes".

As you can see, both sides will yield better results. If you only focus on the technical side, you're missing the opportunity of like, "Hey, we want to build a culture that is resilient". Just like you build resilient systems, you need to be... Again, cultures, teams, people, we're systems. Literally, our bodies are systems. There's a digestive tract system, there's a neurological system, muscular system. Everything's a system if you ask me. My very technical answer about curiosity, how you know someone is curious is people that see systems. If people can see things as a system, they tend to be very curious, because systems are fascinating. My whole career has been understanding systems one way or the other.

Shane Hastie: Another thing I know you're passionate about is what can we as software engineers learn from the other engineering professions?

Learning from other engineering disciplines [18:36]

Gonzalo (Glo) Maldonado: Excellent question. 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. You can literally look back and be like, "Yes, the Romans were doing civil engineering. They were not computing yet".

Arguably, we had some historians, there were some things that resembled computers and the Incas did have computers. But for all intents and purposes, we can just say like, "Hey, the Romans definitely had civil engineers". We didn't get engineers until the '60s, '70s when we actually got electrical machines doing this work.

There's a reason why many industries have certifications and have codes of ethics. For me, the work that IEEE and the ACM are doing, both are professional organization. One is for electrical engineers, the other one is for software people, the Association of Computing Machinery. They do essential work, because we need to understand that our systems are a reflection of our culture. I was talking about anthropology earlier. Your culture really influence what you build. Technology is not built in a silo. The way you think, the way you work, and the people that you hire, they influence directly what you're going to be building.

What we can learn from other industries is their lessons. Again, we are now on yet another industrial revolution. This time it's more of a knowledge revolution. 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? 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. Eventually those things influenced directly the civil engineering practices and the codes of ethics.

They were like, "Hey, if you get a brick off this company, you know it's not going to fail". It matters. It has certain specifications. It has certain guarantees. Again, it's culture. Another book I really love is Sapiens by Yuval Noah Harari. I hope I pronounced that right. It's amazing how companies are cultures and cultures are a company, and they become this abstract things that is bigger than the individuals. Our professions, civil engineering, you can see the influence of so many people on how we think. Electrical engineer by training and the Maxwell equations during the profession.

Maxwell and Maxwell thinking influenced everything from our telecommunications to our digital signal processing. It's all from these ideas and honestly values that Maxwell inflicted on us. It's really interesting, because there's this actress that I also admire a lot back in the golden age of cinema of Hollywood, Hedy Lamarr. 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. It's interesting, because I think we need to go beyond just thinking about the engineering practices, but this brilliant actress invented what now is benefiting us. She did it because she was curious and she was talking with Navy experts and asking them questions. For me, I think we can learn a lot from the engineering practices, especially the old ones.

Go talk with a chemical engineer, go talk about their standards, how you make sure that there's this diamond shape with four rectangles that have different colours. They have a meaning, they have a really important meaning. And if you don't understand that code, you're going to get into a lot of trouble in the lab. I wish we had that for basically everything. From ID to our models, I wish we had codes like that and, well, we should invent them.

Shane Hastie: A lot of interesting stuff here. If people want to continue the conversation, where can they find you?

Gonzalo (Glo) Maldonado:I go by E-L-G, the number zero, N-Z, on most social media, so you can find me either way.

Shane Hastie: Thank you so much for taking the time to talk to us today.

Gonzalo (Glo) Maldonado: Thanks so much, Shane. Thank you for your curiosity. I think you're a great engineer, even if you don't know it yet.

Mentioned:

• Book: What You Do is Who You Are by Ben Horowitz
• Margaret Mead Anthropology Theories
• Worse is Better
• Artist Theo Jansen
• Book: Sapiens by Yuval Noah Harari
• Maxwell Equations
• Hedy Lamarr CDMA
• Gonzalo (Glo) Maldonado on LinkedIn