Reshaping culture - Prioritizing transparency and open communication in an engineering organization

Culture

Culture can be a complex and subjective topic. After all, a company culture is hard to even define. When you ask folks around your company what the culture is like, they’ll always come up with different perspectives and different points of view or examples of how they see it — sometimes, those definitions even contradict each other.

With that in mind, I think it’s important to start a blog post like this with a definition.

According to Edgar H. Schein in his book Organizational Culture and Leadership, culture can be defined as “a pattern of basic assumptions that a group has invented, discovered, or developed in learning to cope with its problems of external adaptation and internal integration.” Meanwhile, in his book Understanding Organizations, Charles Handy notes that culture can be thought of as “the way we do things around here.”

As for me, I like to think of it as “what people do or how they act when no one else is looking.”

This post aims to shed light on the importance of having a transparent and open engineering culture in our organization, but I also try to offer practical tips on how you can actually foster a cultural shift within your own engineering teams. So, let’s dive in and explore why it matters and how you can make it happen!

Why is culture important?

As engineering leaders, we hold a pivotal role in shaping the trajectory of our organizations. We understand that culture isn’t just a buzzword — it’s a powerful driver of change and a catalyst for fostering initiatives. A strong and purposeful culture sets the stage for success and empowers our teams to go above and beyond.

First and foremost, culture acts as a compass, guiding our teams toward the shared vision and values we hold dear. By prioritizing transparency and open communication, we create an environment where trust thrives. This foundation of trust fosters collaboration, breaking down barriers between teams and departments. It encourages everyone to contribute their ideas, insights, and expertise, leading to breakthrough innovations and fresh perspectives.

Culture also plays a pivotal role in driving change. When we champion a culture that embraces adaptability and continuous improvement, we enable our teams to be agile and responsive in the face of evolving demands. By fostering a growth mindset and encouraging experimentation, we empower our engineers to challenge the status quo, explore new technologies, and drive transformative change within the organization.

Transparency and open communication in engineering

A transparent and open engineering organization is one where information is freely shared across all levels of the organization. Leaders communicate openly with their teams, sharing the reasoning behind decisions and plans for the future. Teams are encouraged to provide feedback and ask questions, with leaders actively seeking out and listening to their ideas and concerns.

In this type of organization, a strong culture of trust and respect permeates every interaction, empowering individuals to freely voice their thoughts and perspectives while fostering an environment of open dialogue and constructive debate. In turn, this culture encourages the active challenge of ideas. These dynamics are evident across various organizational touchpoints — from the collaborative atmosphere of team standups, to the inclusive and engaging nature of all-hands meetings — exemplifying a culture that values transparent communication and collective growth.

To foster such conduct and align with the organization’s values, several important engineering ceremonies are in place.

Blameless postmortems

A blameless postmortem is a practice adopted in engineering organizations to encourage a culture of learning and improvement following incidents or outages, where the main focus is on understanding the underlying causes and system vulnerabilities rather than assigning blame to individuals.

Blameless postmortems are conducted every two weeks, inviting not just the engineering teams but the entire Product and Engineering (P&E) division.

For me, one of the most important qualities of a blameless postmortem is that it fosters trust and collaboration: When individuals feel that their contributions and perspectives are valued, they’re more likely to actively participate and provide meaningful insights. In this environment, teams actively collaborate across departments, fostering a shared sense of responsibility and cultivating stronger relationships among team members. As a result, there’s a heightened commitment to following up on postmortem learnings, with a collective effort to prioritize their implementation and enhance the reliability of our systems.

Standardized incident management processes

Standardizing the way we handle incidents and outages ensures that every team knows how to effectively detect, respond to, and resolve incidents.

We also place a lot of emphasis on communication. Ensuring there are clear expectations on how to communicate about an incident and keeping the entire organization up to date on the status is a big part of the process.

We encourage engineers to participate in on-call rotations early after joining the company, as it’s a great way to build skills and understand the core of our systems. As with our postmortems, we apply blameless practices in the way incidents are run to encourage a culture of learning throughout the process.

Open tech radar

A tech radar is a visual tool or framework used by engineering organizations to track and communicate their recommended technologies, tools, and practices. Our tech radar provides a common reference point for engineers, teams, and stakeholders, ensuring both alignment and a shared understanding of the organization’s direction. It serves as a visual representation of the organization’s technology landscape, fostering communication and transparency about preferred technologies and practices.

Additionally, the idea of the tech radar is to promote open communication and collaboration by providing a platform for discussions around technology choices. It encourages engineers to share their experiences, insights, and recommendations, in turn promoting a culture of knowledge sharing and active participation. This transparency leads to informed decision-making and enables teams to learn from one another.

Tech radar meetings are normally held biannually, with invitations extended to engineering leaders and senior team members across different specialties.

RFCs

An RFC — a Request for Comments — is a widely recognized format used for proposing and discussing standards, protocols, procedures, project ideas, and technical approaches. RFCs promote an open and transparent process for discussing and refining technical proposals. They encourage team members to contribute their ideas, share their expertise, and participate in the development of a project.

RFCs are disseminated throughout the entire organization, allowing for comments, questions, and additional insights from any member.

The open nature of RFCs allows for constructive discussions, alternative viewpoints, and peer review, leading to better-informed decisions and improved standards.

ADRs

ADRs, or Architecture Decision Records, are used in software development and engineering to capture and document architectural decisions made throughout a project’s lifecycle. ADRs provide a structured way to record the context, considerations, and consequences of architectural choices, enabling teams to understand the reasoning behind decisions and their impact on the system.

One of the main intents is to facilitate communication and collaboration among team members and stakeholders by providing a shared understanding of architectural choices. ADRs serve as a reference point for discussions, enabling teams to revisit and review decisions as a project progresses.

They also help new team members or future maintainers of the system understand the reasoning behind architectural decisions and avoid reevaluating the same choices.

Reshaping culture in practice

So, how do you reshape the culture of an engineering organization? For example, how would you go about introducing one of the practices described above in your own organization? And how would you know if you were successful? After all, according to my simple definition of culture (what people do or how they act when no one else is looking), even after you leave an organization, people will continue to behave in a certain way.

So, let’s take the standardized incident management process described above as an example. We’ll start with a few key points that I believe will help:

Define and communicate the desired culture — Clearly articulate the values, behaviors, and norms you want to foster within the organization. Communicate this vision consistently to all members of the organization. Forget about the DRY principle here; in this case, repetition is key to ensure that everyone understands the desired outcome.

For the incident management process, this means putting together clear documentation about the behaviors and processes that are important to follow. Take the time to present these ideas to different teams, gather feedback, and refine the documentation. Encourage other leaders and engineers to join you in the process to ensure that the desired culture is embraced throughout the organization. Lead by example — Step 1 will fall short if you don’t take the time to demonstrate the qualities and behaviors you want to see. You should embody and model the desired cultural attributes, consistently demonstrating the behaviors you expect from others. There’s no other way. In the incident management process, this means demoing the change you want to see. Join as many incidents and on-call rotations as possible, and take the lead when you can. After the incident, follow up and ask for feedback from others about their thoughts on the process, and include that feedback in Step 1. Foster open communication — Create channels and platforms that facilitate open and transparent communication within the organization. Encourage feedback, suggestions, and ideas from employees at all levels.

Recognize and celebrate cultural champions — Acknowledge and celebrate individuals and teams who embody the desired cultural attributes. Highlight their contributions and recognize them as role models for others to emulate. In the incident management example, this would mean stepping back from leading the management of incidents, and instead supporting, guiding, and encouraging others to take the lead. Call out individuals and teams who demonstrate good examples for others to follow. Evaluate and adjust — Regularly assess the progress of culture change efforts. Collect feedback, measure outcomes, and make adjustments as needed. For the incident management process, evaluate if incidents are resolved faster and more effectively if communication is handled more promptly, and if engineers are finding the process enjoyable and learning from it. Make sure to conduct these evaluations periodically throughout the year. At Zenjob, we track both incident response times and the number of incidents in different priorities (P0, P1, P2) to make sure these numbers are trending as expected.

So, what can I expect?

If the blog post has sparked some ideas and you want to try something similar, keep in mind that the way it’s written may give the impression that everything has been super straightforward and easy for us. It might seem like you just need to follow a few of these ideas above and voilà, easy peasy, change done.

The reality is that reshaping or introducing a new culture in your organization is difficult, and it’s probably one of the hardest things I’ve encountered on my engineering leadership journey.

It has taken us several iterations and a lot of back-and-forth feedback to ensure that things are working as expected. And we’re not completely there yet.

For example, when I tried to introduce a better standard process for conducting postmortems, I encountered a lot of pushback. The brave engineers who had initially volunteered to present in front of the entire P&E organization about how they “failed” had a hard time going through the process and sharing their learnings while answering difficult questions from others. Then, after the meeting, I received messages expressing discomfort about how the meeting played out.

Time passed, and after a few more iterations of the meeting, things seemed to improve, and people became more accustomed to presenting in the postmortem meetings.

However, I noticed that engineers began overpreparing for the meetings. Some spent hours or even days analyzing every detail to ensure they wouldn’t be caught off guard by any questions and could share as much information as possible. As a result, this defeated the purpose of the initial postmortem meeting, as much of the information and learnings had already been discussed outside of it by a smaller group.

Personally, I’ve found that the best thing I can do to facilitate a cultural change is to devote as much time as possible to defining and communicating it. I set aside time to write down my ideas and ask for early feedback from peers.

Once a proposal is introduced and everyone seems on board with the idea, it’s important to unlock as much of my time as possible to demonstrate the desired behavior. Leading by example can take hours per day, depending on the topic.

That time should also be invested in following up with others and providing candid feedback, enforcing the desired contributions or behaviors during one-on-one conversations or any other chance that you have.

Remember that you cannot change everything overnight. It requires a sustained effort, commitment, and patience over the long term. Therefore, don’t be too hard on yourself if you don’t see immediate results.

However, this is also one of the most interesting and rewarding processes to come with the role. So, embrace the challenge, stay committed, and be patient. With sustained effort, you can shape a culture that fosters growth, creativity, and — hopefully — success.