Essay on Engineering Culture as a System

from a Systems Thinking (3rd generation) perspective. This is Part 1/3 of the Engineering Culture series. There are Part 2 and Part 3.

The concept of "Engineering culture" refers to the values, beliefs, and practices shaping how engineers work within an organization. It is essential because it can significantly impact the quality and success of the engineering team’s output and the organization’s overall success. © ChatGPT summarization prompt

That was a typical definition of the topic we can find in public sources, so let’s elaborate on the statement above with systems (engineering) thinking which I started to explain in a previous post.

Disclaimer: this article is not aiming to fully cover the “Engineering Culture” topic but only focus on it’s core. There are several aspects of it that we left out of sight this time:

- “Culture of Enginers” as a social aspect of people behavior; this include social distance, power distance index, …
- Known patterns/memes around the topic; like so called “gamedev” culture, “startup” culture, “governmental” culture etc
- Motivation/manipulation aspect of culture; e.g. “working on weekends is the part of our culture!”
-…

When we see any reference to “practices” in relation to an organization (constructor system as a system that creates other systems), we strongly hint that we discuss a subset of lifecycle practices. Org lifecycle is a ”blueprint” of capabilities, and the composition of all org capabilities makes org a true 4D system. This means that “practices”-related aspect of Engineering Culture can be modeled as a subsystem of the whole Organization (or any autonomous part of it, like “engineering organization”), complementing classic org-level models such as Capability Map or Value Stream.

So Engineering Culture handles cross-cutting capabilities applicable to every classic “value stream” capability — we learn, communicate, and make decisions when performing our daily tasks.

This also means that engineering culture is a valid system, as it is realized as the 4D extent of all activities related to corresponding practices (decision-making, communication, learning, etc) performed by engineers as part of their daily work.

A good example of such a practice is the well-known Amazon 6-pager — it is part of Management Culture (area peer to Engineering Culture), and it is a sub-practice of Presentation, which is also part of the top-level Communication practice. It is not that important from a “cultural” perspective, WHAT and WHY you present but HOW. And if we dissect it as a Presentation Practice, we also get both aspects covered:

• what knowledge do you use for it — how to structure the 6-pager, how to use data and metrics in its messages, how to present its objectives etc;
• what technology do you use for it — word template, printer to get a hand-out for discussion participants etc;

Different organizations have different needs, so they have to focus on different “cultural” practices, but I put here my personal top-3 as samples to start from:

1. Ownership/Prioritization. This one is not only about picking tasks or user stories from the backlog but a generalized behavioral practice — e.g. decision-making on priorities in “gray zones”:
   - if you see a problem in an old legacy code, would you try to fix it or focus on the scope of your task?
   - if you can implement a clean, beautiful solution but you will miss a deadline, what would you do?
   - What would you do if you are busy implementing a strategic feature but start seeing unusual behavior in the DevOps sentry log?
   - would you reuse existing code (owned by another team working on a different domain) or copy-paste it to your module?
2. Decision-making. That’s my focus area as an IT Architecture leader. How do engineers make their decisions — do they classify the impact of the decisions? How do they gather context info? How do they understand evaluation criteria and put importance “weight” on them? How do they document it, where do they store it, and how do they use it afterward? How do they look for alternatives? Do they perform competitors' research, or do they use frameworks (like TRIZ/ARIZ, creative, rational, brainstorm, etc)? How do they do decision validation? How do they make team decisions?
3. Communication. What kind of questions would you ask only in person, what kind of questions would you ask in team chat, and what comes to the global org-wide channel? Would it be a raw 1-line observation or a detailed well-written post? Would tone would you use when giving feedback to your manager? teammate? What language would you use in your team chat when you know that everyone in your team has Portuguese as a native language, but communication policy for a global company is “English only”? How do people use funny memes, animated gifs, and custom emojis in work chats? How do they describe the meeting agenda in calendar invites?

At the same time, the “values and beliefs” part of the definition is usually referred to as part of the “Leadership” discipline. This part is usually shared with other “organizations” inside the enterprise (Engineering Organization, Product Organization, Marketing Org, etc).

In brief, what is leadership, and what can we learn from understanding engineering culture as an aspect of leadership?

Our understanding of leadership is that it is a discipline of realizing Roles and their role-based behavior by Actors. E.g. with leadership, we can put me as an Actor (Ivan Padabed, 43y.o., capable of playing football and doing systems architecture) into the Role of Systems Architect (role in Project X, accountable and responsible for architecture design, requires systems architecture competence). Even if I am not always happy with writing architecture design docs, I can usually “lead” myself appropriately, so my arch docs are ready in time.

There are three basic types of leadership I can think of:

1. Self-leadership: the discipline of you realizing yourself in the desired Role. It might not be necessary a professional role — I am often able to realize the role of a father or role of a football player with formidable success.
2. Personal leadership: an Actor explicitly assigned (or performing in shadow mode) to the role of leader. Most of the “leadership trainings” aim to this area of making an Actor a well-performing Leader role. Success can be measured by how other Actors perceive one’s performance as a Leader. In other words, you are a good leader if others play their roles well under your leadership.
3. Team leadership: distributed, shared, multi-actor, peer-to-peer implementation of the Leader role. We can see this kind of leadership in well-knit teams, where everyone knows their part of the play. This one is nearest to the engineering culture aspect but one level down. Note that for smaller organizations like startups, the Team leadership is fully equal to Engineering Culture, and moreover — while growing, the Engineering culture will be evolving from this first team.

To sum it up, we have decomposed Engineering Culture into a set of cross-cutting practices (capabilities) that compose a whole organization and a way we realize those capabilities in our employees via leadership (“values and beliefs”).

Evolutionary aspect of Engineering Culture development can help us to explain why it is unique in different organizations even if their “values and beliefs” sound very similar. That’s due to the many combinations of included practices and their maturity levels, that we can put in quasi-homeostasis on all org levels — individual, team, “team of teams” and whole org level. And contradictions between levels here can drive further evolution: as example, team-level culture can allow behavior which is not acceptable on “team of teams” level so team-level culture likely evolve to a more suitable variation. Same with top-down culture-governing policies — the can be easily sabotageв or ignored on local levels if they are too far from currently working practices.

Any other insights that we can get from this model? With it, we have the opportunity to perform the following actions in a conscious way:

1. Assess the current state of engineering culture in our organization by gathering corresponding capabilities and measuring their maturity and variations (the heatmap model can work well here).
2. Trace the origins and predict the direction of change of our Engineering Culture in its current state. As we know, it evolves bottom-up: from self-leadership of hired employees through personal leadership of key leaders on different levels in different positions to team leadership of established teams.
3. Engineer a target state of the Engineering Culture by specifying desired maturity levels of corresponded sub-practices; find relevant references in peer companies with similar context.
   Keep in mind that the “continuous everything” principle works here, so better to avoid pre-defined maturity levels similar to CMMI but specify target measurements to define a desired “maturity level” instead.
4. Plan the development of Engineering Culture by discovering appropriate leadership drivers: “values and beliefs,” key practice champions, target metrics, and success criteria, and hire a bearer of the relevant culture from reference companies.
5. Execute Engineering Culture development plan by adjusting a hiring approach to get employees with a good-fit self-leadership, put champions with aligned personal leadership into power to influence others, highlight teams with the right team leadership, and coach teams with insufficient maturity.
   Also essential to provide the suitable technology to support a desired maturity level of target practices: decision-making sheets, communication tools like chatbots or Karma engines, actionable retrospective backlogs, etc.

As systems engineers, we definitely can “engineer” engineering culture in our organizations to their potential. However, as with any other system, things can go wrong; there are some common mistakes:

• Over-engineering: pursue a high-maturity “cultural” practice just because “other companies doing that” can take significant effort but give you little value (e.g. management push to keep regular internal “engineering meetups” without the demand to share knowledge rarely works well) — “fit for purpose” principle is essential.
• No feedback loop: regular sync up on measurable metrics like ENPS, artifacts count, reactions count, etc can help you to adjust investments for the best outcome.
• Lack of focus: trying to improve Engineering Culture as a “black box” is usually a vast and unmanageable goal, discouraging by its ambiguity and uncertainty.
• Incompatible configuration of “value stream” practices and “engineering culture” practices. In other words, if you try to use org design to build world-class engineering processes, e.g “engineers need to update arch/tech documentation after product increment as part of the DoD (definition of done)” — but at the same time, your engineering culture at its current state might neither have document writing practice mature enough nor a right tooling for it. So don’t be surprised when your DoD will be rarely completed without rigor micromanagement.

I hope you enjoyed this brief essay; feel free to share your thoughts and feedback with me :)