Company culture. Extremely important, impossible to define.
Impossible to define doesn’t mean impossible to understand. A surface-level understanding of culture is available via Glassdoor and company onboarding documents. However, a deep understanding of culture is only available via experience.
This article focuses on a set of values often associated with software engineering culture. Instead of the discussing the values themselves, I discuss the activities which measure them.
Software Engineering Culture — A Basic Understanding
Culture Via Definitions
I will defer the definitions to the Internet:
Company culture can be defined as a set of shared values, goals, attitudes and practices that characterize an organization.
www.builtin.com
This culture consists of shared beliefs and values established by leaders and then communicated and reinforced through various methods, ultimately shaping employee perceptions, behaviors and understanding.
www.shrm.org
Culture Via Questions
- Do you enjoy your job?
- Who do you look up to at work?
- How do your colleagues respond to difficult situations?
- What actions are rewarded? What actions are punished?
Culture Via Characteristics
- Heavily dependent on people
- Extremely difficult to change, yet constantly changing
- Influenced by parent cultures, but locally unique
- Experienced differently by different people
Culture Via Values (Software Engineering Specific-ish)
- Freedom — How To Work
- Freedom — Solution Choice
- Collaboration
- Personal Growth
- Operational Excellence
- Transparency
- Feedback
- Developer Happiness
How Is This Useful?
A long list of cliché bullet points is not useful; I’m sure “Operational Excellence” and “Personal Growth” are stamped inside every company’s culture handbook.
At any given software organization, infinite tasks are being concurrently executed by a perpetually understaffed employee thread pool. Code is being written, architecture is being reviewed, retrospectives are being run, interviews are being held, compensation is being planned. A unique culture is reflected and measured in each and every one of these processes.
In this article, I present three standard-issue software engineering activities that can be used as metrics for software engineering culture. Improving these activities is not for the sake of the activity, but for the sake of your company’s culture.
3 Interesting Software Engineering Culture Metrics
#1 — Adoption Of Frameworks & Tools
Values Measured: Feedback / Collaboration
Measurement Example: What ratio of teams have adopted the shared {rate limiting, caching, background job, migration, etc.} framework versus rolling their own solution?
Every software company has a set of teams that are designated as “Platform” teams. These teams are tasked with developing high-leverage software with the goal of accelerating experience-focused teams.
Despite their best intentions, platform developers still struggle to get other teams to adopt their technologies—even when that other team sits down the hallway. Why would they want to use your software over building their own solution or paying a little extra money on AWS features?
The level of adoption of internal platform features measures two (probably more) important cultural values.
The first value is feedback. In order to get a potential customer to adopt your software, you need to talk to the customer. In this case, the customer is your colleague. Do you understand their requirements? Is your software actually solving their problems? Have you met them yet?
A common risk is for platform teams to create a set of “standards” based on their personal perceptions of another team’s requirements. This happens more often than you might expect; it’s in a developer’s nature to build frameworks that bias towards their own problems. As a platform developer, never assume that you fully understand another developer’s problem without engaging him or her. Continuously gathering feedback is critical to develop this understanding and to build trust with your colleagues. This begets adoption.
The second value is collaboration. The adoption of a framework is driven by framework creators. There is a stark difference between these two strategies:
- Hey, our team just developed a new set of security penetration testing tools. Here’s the documentation, please try it out and let us know how it goes.
- Hey, our team just developed a new set of security penetration testing tools. Does your team have some time to walk us through your product so we can figure out how these tools might help you?
Both strategies have the same goal—adopt the penetration testing tools. Strategy #1 is more scalable, but it’s the wrong move for early adoption. I argue that Strategy #2 is the more effective route for platform developers to foster sustainable, long-term adoption of their software.
Strategy #2 reflects collaboration and empathy. Strategy #1 reflects throwing things over walls. If you’re willing to sacrifice your time and work alongside your colleagues, it won’t be long before every developer at the company has a new feature request for you. Once Strategy #2 is repeated successfully enough times, auxiliary actions—word of mouth, self-service assets, bug support—will be icing on the cake.
If a software organizations notices that a platform team keeps producing software that no one opts to use, it may reflect a lack of value in feedback and collaboration.
#2 — Effectiveness Of Retrospectives
Values Measured: Operational Excellence / Freedom — How To Work
Measurement Example: In a company survey, ask developers to rate the effectiveness of last quarter’s retrospectives from 1-5.
Look around any software organization and you will find retrospectives surrounding sprints, incidents, and projects. No matter the context, all retrospectives share a similar purpose—deeply understand a situation, cordially discuss areas for improvement, and grow as an organization. Running effective retrospectives is a clear metric for operational excellence.
Retrospectives also measure a more nuanced software engineering cultural value—freedom. Specifically, the freedom to choose how to work.
Retrospectives, alongside other software ceremonies, represent process. Every organization wants their process to be as effective as possible.
Ironically, effective process comes out of no process. Effective process is not built out of process, but is built out of values, or culture. Let’s take incident retrospectives as an example—how would you introduce this process to your organization?
- We have decided to implement incident retrospectives because Amazon does incident retrospectives. From now on, every incident must be followed by a retrospective that follows this template.
- We value operational excellence. We make mistakes and learn from them. After an incident is resolved, every team is responsible for implementing a retrospective process so we can collectively improve our operations.
Again, both strategies have the same goal, but may produce drastically different results. Strategy #1 runs the risk of mandating process for the sake of process. This is useless if the culture is not ready for it; it’s impossible to copy Amazon’s ceremonies if your company inherently has different values than them.
Furthermore, process before culture inadvertently stifles the ability for developers to choose how they work. Not every team will be enthusiastic about copying Amazon’s incident response. This doesn’t mean that they are neglecting operational excellence; they might just want to create their own solution.
Strategy #2 reflects freedom. Freedom is the preferred operating mode for software developers. Our goal is operational excellence and we want to be empowered to create a unique solution to reach this goal. For incident retrospectives, perhaps teams want to use a custom template, introduce a “minimum viable retrospective”, or execute their follow-ups asynchronously. If Strategy #2 is repeated enough times, it inevitably turns into a natural process for the organization and the end goal is reached.
This idea is not unique to engineering. Consider how consulting firms engage with their enterprise clients. No one appreciates a consultant barging into an organization and changing up how everything works. Seasoned consultants know that sustainable change does not come from mandating change, but from changing the client’s culture. If a consultant can shift a company’s values, they will inevitably shift that company’s processes, and hopefully that company’s success.
As a developer, examine the various processes that you participate in. Which ones are not effective? Perhaps process has been introduced before the culture is ready for it. If you had the freedom to change the process, while achieving the same goal, what would you do?
#3 — Effectiveness of RFCs (Or Any Other Approval Process)
Values Measured: Collaboration / Freedom — Solution Choice
Measurement Example: RFC creation count. RFC average approval time. Frequency of negative sentiment towards software approval processes.
Another pervasive process found in software organizations is the journey for consensus. Examples include gaining signatures on an RFC document, winning a majority vote from a technical committee, or arriving at an important architecture decision.
Frustration surrounding approval processes may signal that engineers value technology preference over collaboration. These two attitudes are very different:
- No, that’s not going to work.
- No, that’s not going to work, but let me help you solve your problem.
To belabor one more time—different strategies, different results, different culture.
Honorable Mentions
Every single software engineering activity measures culture. I’ve only touched upon three, but there are many, many more.
Engagement During All-Hands Meetings
Values Measured: Feedback / Transparency
If leadership is opaque and feedback falls on deaf ears, no developer will bother asking questions during meetings.
Diversity Of Team Ceremonies
Values Measured: Freedom — How To Work
Not every team has to follow the two-week agile sprint cadence to a tee.
Frequency of Performance Recalibrations
Values Measured: Transparency / Personal Growth
Recalibrating an engineer and delaying a promotion can be tough for both the developer and their manager. However, this is a healthy process that shows that management is transparent with each other and takes personal growth seriously.
Average Time To Merge Code
Values Measured: Operation Excellence / Collaboration
Average time to merge is an important health metric that is difficult to trace back to a specific engineering value; a thousand factors contribute to slow code reviews.
Regarding operation excellence—developers should be trained to write well-tested code and be able to present it clearly to their colleagues.
Regarding collaboration—developers have the responsibility to inform their stakeholders of upcoming changes. If you open up a code review in another team’s repository and their reaction is, “Where is this requirement even coming from?”—don’t expect your code to be merged any time soon.
Deployment Health
Values Measured: Developer Happiness
Developer happiness is directly correlated to healthy, predictable, and frequent deployments.
How Often The Career Ladder Changes
Values Measured: Feedback / Personal Growth
Leaderships doesn’t change engineering level descriptions for the sake of changing copy. When leadership fine-tunes the career ladder, it signals that they are listening and putting in an effort to support the growth of the engineers.
Conclusion
As an organization, don’t spend too much time attempting to describe your culture. It is already understood and reflected through process. Spend that energy paying attention to the processes that break down and be wary of introducing process for the sake of process.
As an individual, pay attention to your personal strategy of work. There’s a difference between “No, that’s not going to work” and “No, that’s not going to work—let me help you.” Your strategy affects your actions, which affects the company’s processes, which changes culture.