Culture and Values
In a previous post, I discussed the importance of company culture. At that time I wanted to discuss the broader area of company-wide culture. Today, I want to shift the focus back to the specifics of engineering culture.
Engineering culture refers to the shared values, beliefs, and attitudes that guide how an engineering organization functions. It influences not just what people do, but also how and why they do it.
Ideally, your engineering culture should align with the overall values of the company. But, particularly at small companies, the values may not already be “stress-tested” to ensure they truly reflect the organization’s needs and aspirations. Regardless of whether your company’s values are well-defined or not, as an engineering leader, it’s your responsibility to cultivate a productive culture within your teams.
Unhelpful Values
Company values can significantly contribute to a positive culture when they are designed to support employees. However, some values—though well-intentioned—can inadvertently promote negative behaviors, such as excessive competition, individualism, or morally questionable practices. For example, values like “Win at All Costs,” “Just Do It,” “Customer First and Last,” or “Always Move Forward” and similar slogans may sound motivating, but they can encourage unhealthy dynamics.
The risk with these values is that they can prioritize personal ambition over collective team success, especially when rewards are tied solely to individual achievements. This can undermine collaboration and harmony, which are essential for a thriving engineering culture.
If you have to deal with unintended negative drivers, you’ll need to put in extra effort to counteract them and nurture a more positive, collaborative environment. However, if the company is intentionally fostering these types of behaviors through its values and practices, you have bigger problems…
Engineering Culture
Engineering culture should align with the broader company culture while placing a particular focus on the processes, practices, and attitudes that the teams use to build their products.
As a specific example let’s consider software testing. Every engineering team has an approach to testing their work, even if that method is to skip testing altogether. Elements of the culture surrounding testing include (but are not limited to) concerns such as these:
- Do engineers naturally test their code, or is it something they are required to do?
- Is test automation a common practice?
- Do engineers recognize and value the importance of testing?
- Do they track and measure testing efforts, such as code coverage?
- Is there collaboration with QA teams on testing strategies?
- Do senior engineers actively mentor juniors in testing best practices?
- When issues are identified, do engineers update their tests?
The specifics of testing may vary in complexity, depending on the team and context, but a strong culture will have a deeper understanding of why certain testing practices are in place, along with a more thoughtful approach to their execution.
This principle extends across the entire software development life cycle (SDLC). While the actual activities may differ, the depth of thought and intentionality behind those activities reflects the overall quality of the engineering culture.
This also applies to how team members interact with each other, the rest of the company, and customers. Ultimately, the quality of a culture is evident in its results.
Cultural Signals
Building a strong engineering culture requires gathering concrete feedback and insights from your teams. However, many team members may not have experienced a high-performing engineering culture before and might struggle to articulate what they want or need. As a leader, it’s important to be attuned to the more subtle signals of team morale, maturity, and effectiveness. Here are some key indicators to help you assess how well your team is performing and where it might need guidance or support:
- Adherence to Best Practices: Do engineers consistently follow best practices on their own, without external pressure? Are they self-motivated to maintain high standards in their work?
- Open Communication: Do team members regularly discuss their challenges with one another? A culture of open communication often signals that people feel safe sharing difficulties and seeking solutions together.
- Understanding and Value of Processes: Do engineers see value in the processes they follow, and do they understand why those processes are in place? Strong teams typically appreciate the reasoning behind their methods and adopt them willingly.
- Continuous Improvement: Are engineers actively suggesting improvements to the codebase, development practices, and team workflows? A culture of continuous improvement reflects a team that is engaged and forward-thinking.
- Reliability and Accountability: Do team members consistently deliver on commitments and timelines? Reliability is a key sign of a healthy and well-managed team.
- Holistic Problem-Solving: Do team members consider broader technical aspects like technical debt, deployment pipelines, QA challenges, security, observability, and scalability in their work? Healthy teams approach development with a focus on both functional and non-functional requirements.
- Growth Mindset: Are engineers actively seeking to improve their technical and professional skills? Teams that embrace a growth mindset are more likely to innovate and adapt effectively to new challenges.
- Mentorship and Knowledge Sharing: Do senior engineers mentor and support junior team members in a positive and constructive way? A strong culture often includes mutual support, where experienced engineers share their knowledge and help others grow.
- Asking for Help: Do team members know when to ask for help, or do they hesitate to reach out when needed? Teams with good communication and psychological safety will ask for assistance when facing challenges.
- Consideration of Non-Functional Attributes: Do engineers factor in non-functional requirements such as scalability, security, usability, and reliability when making decisions about solutions? A focus on non-functional attributes demonstrates a thoughtful and comprehensive approach to software engineering.
This list is by no means exhaustive, but it provides a solid foundation for assessing the current state of your team’s culture. By observing these signals, you can gauge where your team is and where you’d like to guide them in terms of cultural growth and maturity.
Once you have a clear understanding of the team’s strengths and areas for improvement, you can prioritize the changes and initiatives that will have the greatest impact. Much like prioritizing product features based on customer needs, you’ll want to focus on changes that will move the needle the most. Some areas for improvement will be immediately obvious, while others will require you to be attentive to the subtler signals in order to guide your decisions effectively.
The Role of Your Development Methodology
A well-defined software development methodology—whether Agile, Waterfall, or another formalized approach—can play an important role in shaping and supporting your engineering culture. When properly implemented and respected, these methodologies provide structure and consistency that help teams work effectively and efficiently. However, if misused or implemented poorly, they can become a burden, stifling creativity, demotivating teams, and undermining the very culture you’re trying to build.
Development methodologies are not inherently good or bad—they can be highly beneficial when applied thoughtfully and adapted to suit the needs of the team. On the other hand, when they are treated as rigid, one-size-fits-all solutions or are adopted without considering the team’s context, they can quickly become a source of frustration. This is why it’s crucial to approach these methodologies with flexibility and an open mind.
Helpful and Unhelpful Practices
Agile, for instance, is often seen as a panacea for modern software development, and when used properly, it can greatly enhance the engineering culture. Practices like daily standups, iterative development, and continuous feedback loops can help teams stay aligned, quickly identify and resolve issues, and maintain a fast pace of progress. In particular, retrospectives allow teams to reflect on their work and continuously improve, fostering a culture of growth and adaptation. Pair programming and test-driven development (TDD) can encourage collaboration and ensure high-quality code, while sprints with clear goals can keep everyone focused and motivated.
However, Agile can also hurt the culture if it is applied in a way that feels more like a set of frustrating dictates than a useful framework. For example, strict adherence to overly prescriptive practices (e.g., numerous long meetings, or endless rituals that don’t add value) can lead to burnout and resentment. When teams are forced to follow the methodology without considering the specific needs of their project or organization, it can feel like a waste of time. In some cases, Agile can become a box to check rather than a meaningful way to work, with no real flexibility or room for adaptation.
Some engineers have expressed frustration with Agile because of its potential to devolve into bureaucracy—where it becomes more about adhering to the process than solving problems. A well-intended Agile process, if poorly implemented, can become counterproductive.
Tailor Processes to Fit Your Team and Challenges
The key takeaway is that software development methodologies should not be adopted mindlessly or as if they were a religion. The practices that work well for one team or organization might not work for another, and processes should evolve as the team grows or as the nature of the challenges changes. For example, a small team might thrive with a lightweight Agile process, while a larger, more complex team might need a more structured approach to keep everything coordinated.
It’s also important to evaluate your processes periodically and adjust them as needed. As your team faces new challenges or scales, you may need to experiment with different methodologies or adapt certain practices to maintain effectiveness. This flexibility ensures that the process remains helpful and that it continues to support the culture rather than hinder it.
My Experience with Different Methodologies
Agile has certainly worked well for me in many situations. However, I’ve also had success with Waterfall in environments where a more structured, sequential approach was needed to support limited access to hardware. The right development methodology is one that aligns with the team’s goals, size, and challenges. The goal should always be to use processes that improve the culture, not ones that hamper it.
To Be Continued…
I continually find that what I am writing or researching takes more time (and page space) than I would like for a single post. So like most of my recent articles, I will extend this post into two sections. Stay tuned, I will polish up and post the remaining sections soon.