The Importance of Organization’s Culture Is Truism! Should I Really Care as Staff+ Engineer?
Every organization has a culture. It may be a designed one or an emerged one, but it's always there. And it's inseparably linked with the organization's performance. What is often challenging for staff+ engineers (and can be a significant boost for those aiming at such roles) is understanding the importance of organizational culture in their role. Even more - using culture as a tool.
Importance of Culture
Why is culture so important for staff+ engineers? To answer that we first need to define this esoteric term. Culture can be defined in many ways - depending on the perspective. The statement I like to define culture with (which gives the right lenses for staff+ engineers) is this: "Culture is the way an organization accepts and processes information". Why do I believe this to be the right perspective? Because communication (creating and distributing information) is at the heart of how staff+ engineers operate. Regardless if you are an architect, solver, tech lead, or "right hand" your responsibilities will include setting technical direction, providing engineering perspective, mentorship, or sponsorship. Regardless if your scope is a specific horizontal slice or your perspective is global as a member of an "Office of the CTO" you will be looking for buy-in and operate with limited authority. That means that the way an organization accepts and processes information (and your ability to understand, use, and influence it) will determine your success.
Understanding Organization's Culture
The easiest way to understand something is to model it. So, can we model culture? You probably already know that the answer is yes. The problem is not the lack of models, but quite a significant number of those. That said, I'm going to focus on one which has been created from the perspective we are looking for - the perspective of information flow. I'm talking about Westrum's Organizational Model. It defines three types of organizations.
Great, we have a model. But how can we map a specific organization to this model? Going with gut feeling might be dangerous - the names in the table or quite subjective and your "idea" may be misleading. Luckily, the DevOps Research and Assessment (DORA) program has developed a set of questions that can be used to survey an organization:
On my team, information is actively sought.
Messengers are not punished when they deliver news of failures or other bad news.
On my team, responsibilities are shared.
On my team, cross-functional collaboration is encouraged and rewarded.
On my team, failures are treated primarily as opportunities to improve the system.
On my team, new ideas are welcomed.
The possible answers to those questions should range from 1 (Strongly Disagree) to 7 (Strongly Agree). The scores average will give you your Westrum culture metric, that will put your organization somewhere on the spectrum. This will be your starting position for the next steps.
Staff+ Engineers vs Culture
What should you do with the understanding of your organization's culture? If it's a generative one does it mean that your life will be easy? If it's a pathological one should you run?
Knowing what you can expect from your organization is empowering. In case of pathological or bureaucratic culture, you can foresee the roadblocks ahead and attempt to mitigate them in advance. In the case of generative culture, you should feel a responsibility not to abuse (and in the outcome deteriorate) it. This brings us to an important question, how (as a staff+ engineer) you can influence the culture? To answer this question we should explore one more culture model - the Edgar Schein’s Model.
Edgar Schein’s Model defines culture as a composition of assumptions coming from three different layers.
Out of those three layers, two are natural areas of operations for staff+ engineers - it’s where they can and should influence the organization's culture.
The first layer is values. This is where, as staff+ engineer, you will be impacting your organization through your interactions with others. Those interactions will often include mentorship, coaching, creating space for others, or networking with peers. You will also lead by example when it comes to exhibiting responsibility, breaking the silos, propagating cooperation, and ensuring blameless inquiries. Last but not least, what you choose to work on will also impact the perceived values (after all staff+ engineers are expected to work on things that matter).
The second layer is artifacts. Artifacts in an organization contain visions, creeds, procedures, and rituals. This is often the most tangible part of culture and staff+ engineers have a direct impact on it. Codifying standards and behaviors is what staff+ engineers are expected to do. You will be driving the organization's culture directly when defining branching strategy, post-mortem process, or engineering standards. You will be driving the organization’s culture indirectly when writing engineering strategy or defining technical quality program. It’s important to remember that and use that power properly.
Failure Is Always a Possibility
Can you fail at influencing the organization's culture? Yes, and in more than one way. You may fail at driving a positive change to the culture and as a result, fail to achieve your goals. You can also influence the culture in the wrong direction and negatively impact the entire organization. Always keep that in mind.