In September 2019 I published Silly Baboons, Stubborn Elephants: A Product Engineer’s Guide to Working with Platform Engineers. Since then I’ve expanded my thinking on culture gaps inside engineering organizations and how they affect our ability to collaborate across different groups with different motivations and incentives into a talk, presented at Reversim 2021 conference (right before Omicron hit and everything shut down again for COVID).

The talk is in Hebrew, so I’ve included the slides and my speaker notes (with bonus content I didn’t have time for!) translated into English.

Some of this repeats the content from the original post, but there’s a lot of new content and a new perspective on other culture aspects, so it’s definitely worth the read.

Story time! Well before COVID came into our lives, I was sitting with a friend drinking coffee telling her all about how I was frustrated at work. I was working on a super important feature, and the infra groups were giving us a really hard time. Between us, I wasn’t being objective about it – I was complaining. “Do they think we’re idiots?” I asked.

She smiled at me with what I though was empathy until I was done, and then said: “You are idiots”.

She explained to me that from her experience as a manager, infra developers and product developers live in parallel worlds. At some point she called the product development teams “baboons”…

Woah there! If we’re silly baboons… They’re… They’re… Stubborn elephants!

A bit about me: I was born in Israel, but both my parents came from the US, which gave me the incredible privilege of filing tax reports in two countries. Anyway, as I was growing up I couldn’t always tell if I was doing something weird because of my American heritage or because my family was just weird. The awareness of culture gaps was always there in the background.

Fast forward a few years, after my BSc in Computer Science I want on to study an MBA where I majored in organizational behavior (technically it was my minor but I never treated it that way so let’s just go with that).

While studying organizational behavior I studied with professors who were very interested in culture, and surprisingly (or not), considering what the B stands for in MBA, most studies were focused on the wider aspects of culture in a national context, and only then how those lessons can be applied at the organizational level. This fit right in with my personal inclination towards analyzing culture differences, and became one of the ways I analyze things that were going on around me.

So, when my friend told me I was being a silly baboon I said to myself: I guess we all want what’s best for our customers, and everyone is just trying to do their job well, but still… something isn’t working.

Maybe I should look at this conflict from a cultural perspective.

During this talk we’ll cover:

• What is culture and how it works at work.
• Culture gaps – which common differences exist and how we can navigate through them without crashing.
• A few all-purpose practical tools that help us resolve conflicts in our day-to-day work with other groups.

Let’s look at this definition for a second – we’re all individuals, unique snowflakes with our own personality. There is a lot of variance inside groups. But… when we look at certain aspects – we will often compare ourselves to what is acceptable in our culture.

So we can summarize culture as:

But what is considered normal?

Let’s look at an example:

I can say something like: “I’m very punctual. I always arrive within 5 minutes of the invitation time”. This makes a lot of sense in the context of the Israeli culture where no one expects anything to start on time and 10 minutes late is perfectly acceptible.

Someone from another culture may be shocked at this – what do you mean 10 minutes late? That’s rude and inconsiderate.

Someone from a culture where it’s considered normal to be 30 minutes late will be very surprised when they arrive “on time” from their perspective (i.e. 30 minutes late) and the event has already started without them.

This is the idea of a cultural norm – there is some individual variation, but the norm is what we expect. If I arrive 5 minutes late to an event I’m expecting to start 10 minutes late, I will be upset the event started before I got there. But if I come from a culture where on time means on time, if I’m 5 minutes late I will be angry at myself for being late, not at the people running the event.

(In fact, this happened to me when I was 2 minutes late to my son’s recital. Not only did they start exactly on time, he was first! How dare they!).

So we could say that culture is relative and individual behavior varies with respect to their cultural norms.

When we talk about culture in a work setting we have to consider different cultural layers.

The first layer is national culture. This is a deep part of who we are, even if we can’t always see it. It’s our window to the world.

Over that we have a layer of individual variance, because no – we are not all identical just because we happened to be born in the same culture.

Over that we have the organizational culture layer. Such organizations may like to think that their culture “wins” over local culture, but usually that’s not what happens. Usually, the organizational culture is adapted to fit the local culture. Sometimes, if the organizational culture is too mismatched with the local culture – the organization won’t be able to “make it” in that location. More often, the culture and values of the organization are interpreted in a way that the management did not intend. Mostly values are ambiguous and even conflicting – so it just works and no one really notices.

The final layer, which is the subject of this talk: In every organization there are different functional groups like marketing, product and engineering. Each group has different goals, motivations and values. So while we expect some alignment with the organizational goals, it doesn’t always work out exactly as we thought.

At the organizational level, and even more so at the functional group level, we will see less individual variance. This is due to self selection – if someone feels their personal values or way of working is mismatched with the group or organization, they can easily move to another group or organization. It’s not the same as uprooting yourself from a place you’ve lived your whole life and moving to another country.

The positive side of the self selection effect is that people who work closely together can be well aligned and work smoothly together. But when they need to collaborate with another group of individuals who are aligned on a different way of working – there can be trouble.

Let’s take a look at some common culture gaps:

On Monday, the product development team ask the infra team for support. The product team needs to release their very important and absolutely essential feature within a few weeks, but the infra team is not available to help at the moment. Actually, they weren’t planning to support this requirement, it’s not in their roadmap and they don’t have the resources. But the product development team needs it… Now!

(This scale that will be going with us for the rest of the talk is a relative scale loosely based on the cultural scale from The Culture Map by Erin Meyer. There is no “absolute” metric, it’s just a tool to visualize which cultural gaps are significant and which are less significant)

Conflict source

Product developers usually work in short cycles. Days, weeks, maybe in a really big corp – a quarter. If you don’t deliver fast, you’ll miss the market.

On the other end of the spectrum we have infrastructure teams. Infrastructure projects are long, they get planned thoroughly and it may take years to complete.

This cultural dimension is not about how “fast” engineers write code or how long the sprint is – the speed refers to how long it takes to deliver a feature to its users and say “it’s done”.

Which is better? Working “fast” or working “slow”? The answer is – neither. Or both. Depends who’s answering.

“Fast” is good for product developers who need to deliver value to their customers and get continuous feedback as quickly as possible.

“Slow” is good for infrastructure teams who need to take their time and consider the long term effects of their decisions on the entire organization.

*Conflict resolution*

Product development teams: Don’t show up with requests at the moment you need support. Bring the infra teams in early on. A simple heads-up will enable them to allocate the appropriate resources, or at least – not be caught by complete surprise when you appear out of nowhere asking for things.

Another option is to suggest someone from the product development team will do the necessary work with guidance from the infra team. This way the product development team can get what they need sooner without the infra team having to put a lot of time and effort into it.

Infrastructure teams: Integrate ongoing support for your internal customers with your regular work process. You can’t make long term projects and internal plans your sole focus. Product development teams need support now.

Looking at this conflict from an organizational level – the infrastructure teams should be incentivized to give good service to other teams. We sometimes forget that’s what those teams are actually there for. If they give good service it will help everyone work together better and increase the overall engineering velocity. When product development teams don’t get the support they need – they’ll start using bubble gum and thumbtacks to hack their way into a working solution – and that never ends well.

On Tuesday the designer asks engineering to add a tooltip to an interface, it’s a small change. The engineer says: I’m sorry, we can’t. If they had more time and energy they’d say: Well, there’s really no such thing as “can’t” in software, there’s only “how long will it take”, but what you asked will take a long time so let’s not. But they’re tired and decide to cut out all that explanation and just say “can’t”.

Now the designer is upset because clearly this engineer doesn’t care one bit about customer experiences. And the engineer is frustrated because the designer is insisting on insignificant details and doesn’t understand what “real” work is.

Conflict source

When designers start working they’re almost literally starting from a blank slate. They don’t have to worry too much about what was there before. This is not to say they don’t take into account design systems, common paradigms or what they think engineering can implement in a reasonable time frame, but their design is not strictly limited by these considerations. The can (and do) decide what’s best for the new design and go with that.

On the other end of the spectrum we have engineers who are carrying a load of technical debt. I’m not going to discuss if tech debt is a good thing or how to manage it, I’m just acknowledging that it exists. And not only does it exist, it adds constraints and dependencies from the existing code and features which can severely limit our ability to do stuff.

So when the designer shows up with a pretty blank slate and has to work with someone carrying a pile of tech debt, things that may seem simple as adding a tooltip can get ugly quickly.

*Conflict resolution*

Engineering: Don’t stop and “can’t”. Explain where the existing system limits your options and makes it hard to do what design asked for. Don’t assume they know and don’t care. If you explain your side with good will – design will cooperate.

Try offering other options: Where are the pain points? Maybe you can make a small change in the design that will eliminate the problem? Maybe you can offer a solution that will give us 80% of the value at 20% of the cost?

Design: Wherever you can stay within the current best practices – please do. If things have been done before it will be easier to do them again. You don’t need to reinvent the wheel for every feature.

On Wednesday morning one of the engineers comes into the office and says “good morning” to the security guy who immediately responds: “no”.

(Insert laugh)

This is something you hear often from people working with legal and security. The block everything. And that can be quite annoying when you’re trying to do stuff.

Feature teams may be trying to do some quick and dirty experiment and legal and security are interfering with their plans just because they didn’t pay enough attention to legal and security restrictions.

Legal just keep insisting on these draconian measures like a long legal agreement with an “I agree” checkbox at the very end, or forcing the feature teams to consider what information they’re retaining, how they’re storing it and for how long (the horror!). I’m being sarcastic, of course, but these things can really delay development and the whole thing is unpleasant for both parties.

Conflict source

Some groups in the organization have more flexibility in the way they work and in their ability to change direction or decisions. Others – not so much.

The role of legal and security is to protect the organization. They have to make sure that all these pesky engineers won’t cause a security breach, hurt the users’ privacy or expose the company to a law suit. So to those of us who are trying to get things done, they really give off that stubborn elephant vibe. On their end, they may feel that the feature teams are being reckless, not really caring about the dangers they’re exposing the company to.

Let’s pause for a bit and try to remember that everyone is just doing their job. Legal and security are there to protect the company and the users. Feature teams are there to deliver value to their users as fast as they can and (hopefully) make money for the company. Both of these functions are essential for the organization, so we must reach a balance between the optimal amount of protection and development velocity.

Conflict resolution

Engineering: Do yourself a favor, get legal and security into the development process early. Talk to them often. It’s best if you can get a single point of contact for an entire project. When they have the appropriate context and intimate knowledge of what the team is working on – you won’t have to explain everything from scratch every time you talk to them. This helps them make faster decisions.

Best case scenario – they’ll be able to point the feature teams in the right direction before they get locked in to problematic solutions that will be hard to change. Even better case scenario – they’ll be emotionally involved in the project and feel that it’s “theirs”, pushing towards creative and flexible solutions on their own to make things successful.

Legal and security: Don’t say “no”, you always have to come up with an alternative solution. Process-wise – make sure that it’s clear to everyone that you have to be involved from the get-go and not brought in just before release. If you get organizational buy-in, your involvement may be seen as necessary and even welcome.

[Bonus content ahead! This part was not in the talk, which is why it’s structured a bit differently. For continuity let’s say all of this happened on Thursday]

I’m just a simple software engineer, I don’t get machine learning or how these people live with themselves. I give the computer instructions, and it does what I told it to do. Admittedly, it not always what I meant it to do, but it always does what the code says.

With machine learning it just doesn’t work that way. I mean, imagine a result coming back with a confidence score! What do you mean you’re not 100% sure? It’s never 100%. Sometimes things change when you re-run the exact same code. How can stuff like this be verified? [Cries in traditional software engineering]

Conflict source:

Look, there are a lot of open ended problems out there, but a lot of what we do as product managers and engineers is reduce that uncertainty and ambiguity and agree on how the product will behave.

In machine learning uncertainty and ambiguity are built in. That’s what they expect. Models are inherently unpredictable and the ability to determine if something has changed because something in the real world has changed or the model has a bug is limited.

This makes it very hard for us to work together without going off the deep learning edge.

*Conflict resolution*

ML engineers: Please help software engineers “get” that ML is not magic, explain confidence scores and how they’re calculated. Give us a peek into your mysterious world, maybe a “Machine Learning 101” course. I’m sure we have the ability to learn this stuff, but it doesn’t mean we already know it.

Software engineers: Breath. Meditate. Do whatever you need to survive the pain of uncertainty. Working with ML is surprising and inconsistent. It is what it is.

[/End bonus content]

On Friday engineering informs product that for the next two months all the software engineers will be working on switching from React to vue.js. Product is not happy with this idea.

You know how some engineers are, they love technology. The want the most stable, fastest, newest tech stuff out there. And that’s totally fine! Technology is part of an engineers job and it’s OK to get excited about new toys.

But then product comes to rain on the party, they don’t understand why the newest trendy tech is the most important thing in the world and why it’s worth delaying development for two months. They don’t see the value in switching to a different tech stacks – if it ain’t broke, don’t fix it!

Conflict source

It’s not that engineers don’t care about customers. I mean, some of them don’t – but even if they care deeply, a big part of what drives them is technology for technology’s sake, otherwise we would all still be programming in COBOL.

The problem is that engineers don’t communicate the value of technology to the product, so product is under the impression that engineering just likes doing whatever’s fun and trendy, with little regard to delivering value to customers, which is what’s really important.

In the short term there may be a tradeoff between worrying about technology and delivering value to customers, but in the long run it may converge. All engineering has to do is prove it. Show the powers that be how many dollars that tech is worth.

Conflict resolution

Engineering: Time is money. Easier recruiting and greater retention is money. Future development velocity is money. But you have to do the ROI calculation, you can’t just hand wave your decision because “it’s cool”.

Product: Sometimes you have to invest in the long term at the expense of the short term. You can find appropriate compromises. Maybe put a limited number of people or time on whatever engineering wants to do, or let them do a proof of concept. Something that won’t stop all feature delivery while engineering is checking out some cool new tech.

These cultural gaps or conflicts are not all the possibilities, they’re just some examples I’ve seen personally and wanted to deep dive into. This slide contains a few other cultural gaps you may consider, but the point is that identifying cultural gaps is another tool in our toolbox to analyze problems in group interaction and help us solve the deeper conflict, instead of the symptoms we see at the surface.

We’ve reviewed a few culture gaps, now let’s get down to business with some practical tools to resolve any conflict:

When something isn’t going well with another team or person, ask yourself if this is a personal issue or a cultural issue? If it’s a personal issue speaking with this person’s manager may help. But if it’s a cultural problem – escalation to a manager won’t help at all, because they’ll have the same point of view on the issue! This won’t get you anywhere.

Once you’ve identified a cultural gap, you should try being explicit about it. You can try saying something like: It seems like you’re approaching this issue with A, but we’re approaching it with B. Can we work together to bridge this gap?

It’s good to remember that just like you see them as behaving nonsensically, they see you as behaving nonsensically. If you share your point of view and how you perceive their way of looking at things – even if you’re wrong – it shows empathy and respect. It also gives them the opportunity to see things from your side, opening up their own point view, which is already a big step in the right direction.

Be nice. Respect them personally, respect their time.

Other teams are not sitting around idly waiting for you to give them work to do, they have quite enough to do on their own. If you need help, at least do them the courtesy of giving them a heads-up and some detail on what you’re planning to do so they can adjust their plans accordingly.

Even when there are conflicts – not only do you need to assume good intentions, you also need to assume competence (we kind of miss that part sometimes). You’re not silly baboons and they aren’t stubborn elephants, you work at the same company on the same end goal. Your immediate interests may clash, but it’s worth it to try and see the bigger picture here.

This is a nice little trick I’ve picked up over the years: If you need to collaborate with someone, one of the ways to get their cooperation is to frame it as a request for help. Asking for help is nothing to be ashamed of, right? It’s essential for being effective at work. But framing the request that way makes the recipient feel needed, it makes them want to cooperate and be generous with their time. They feel important and appreciated, and they’ll want to continue feeling that way.

This is the the most powerful tool we have in our toolbox. Almost every conflict can be resolved by first building a personal connection. And to build that connection – we have to communicate. I know, after all this time at home with COVID we’ve forgotten what little we know about personal communication, but in spite of the cliché, communication is the only thing that works in almost every situation.

When you have solid relationships and a wider personal view of the people you work with, you might come to realize they’re not that bad, even if you don’t see things exactly the same way. With some mutual trust you’ll be open to different ways of working and thinking.

Don’t be too scared or lazy to communicate personally and directly. If you can meet in person – great. If you can’t? Hop on a video conference. Can’t VC? Try chat. It’s much more personal and pleasant than emails. And if you’re chatting – use emoji and gifs. I don’t have any hard data to back this up but I’m sure it helps creating that personal connection.

Stay away from JIRA and other task management systems. These systems are important for managing and tracking projects, but there is nothing that kills trust faster than transferring tickets between groups and having long discussions in the comment section. First discuss and make decisions together, then update JIRA.

Summary:

“Culture is whatever is considered normal”

Culture gaps can create conflicts that are hard to identify and resolve because they are below the surface.

What should you do?

1. Identify the culture gap(s) – is the problem related to one (or more) of the culture gaps we discussed? Maybe it’s not a culture gap at all or there’s another culture gap we need to identify?
2. Analyze the culture gaps we’ve found and identify which one is causing the current conflict
3. Resolve the conflict with one of our practical tools: Raise awareness, be explicit, be nice, ask for help and building relationships.

Thanks Karen Cohen for calling me a baboon, without her this talk would never have existed. And thanks dear reader for making it this far! I hope you enjoyed it. And despite the slide, if you don’t know Hebrew I suggest following my English account instead at @_rinaarts_.