Building Effective Engineering Culture

Essential elements for a happy and high performing engineering team

In this post, I want to talk about my views on engineering aspects of culture and what I believe are some key elements for building a high performing environment that engineers want to work in. The bulk of this post was adapted from material originally published on the Coalition, Inc. blog here. Feel free to head over to that version if you want the full pitch on joining the Coalition team and experiencing this culture for yourself!

I’ll keep this version more generic and hopefully something thought provoking to current and future engineering leaders. I have had the privilege of building and scaling some truly great organizations in my career. While each of those journeys was unique, the areas highlighted below are the ones that transcended when I sat down to recently to describe what I planned to build with the team at Coalition.

Human centric culture

First, I believe in a human centric culture. News flash! Engineers are humans and good software is as much an art form as it is a science. Sure, we engineers may be nerdy and particular and a bit whiny at times (guilty!), but we’re human too. Any culture that treats engineers as code producing robots that can be relentlessly pushed isn’t going to last for long. Not only that, part of being human centric is striving for a diverse organization that is inclusive.

To create a human centric culture, leaders need to be genuine, honest, candid, and transparent. They need to connect with the team on a personal level and show empathy for life events outside of work. Needless to say, this aspect of culture is more important than ever in this time of global pandemic, isolation, and widespread civil unrest, just to name a few of our unique challenges in recent past.

‘Work hard, have fun, make history’

Next is to follow a motto that I unabashedly stole from Amazon: ‘Work Hard, Have Fun, Make History!’ For me, this speaks to a type of balance. Engineering organizations virtually always have hard problems to solve and hard problems take hard work. Hard work has to be balanced, though, with fun — fun at work (one of Coalition’s engineering leaders shared some ideas in his post on remote work here) and fun in people’s personal lives.

Whereas working hard and having fun are something we can do right away, making history is different. That one takes time, often playing out over several years. This is why I think it’s so important for leaders to strike a balance between hard work and having fun. Done right, this builds a team and culture that sustains for the long term and enables ‘Making History!’

Make and meet commitments

Third, engineering organizations need to do what they say they’re going to do. They exist to build ‘stuff’ (products, features, bug fixes, etc.). Aside from exceptionally rare circumstances, someone is going to care when they are able to deliver that stuff. Whether it’s your customers, a board of directors, or executive leadership, a great engineering organization should be able to make and meet commitments, most of the time.

That ‘most of the time’ qualification is important. Building software is inherently uncertain and the variance to expectations across different efforts will be high. If you make one hundred percent of your commitments, you are ‘sandbagging.’ On the other hand, if you rarely make a commitment, you erode the trust of your customers and stakeholders over time.

Effective organizations strive for that ‘goldilocks’ zone. Try to be aggressive enough to know that our team is working hard to deliver customer value. But not so aggressive that the organization loses trust in the engineering organization.

Set high standards

Fourth, effective engineering organizations have relentlessly high standards. The adage that comes to mind is, “If it’s worth doing, it’s worth doing right.” This is especially true as it relates to software quality, but in reality it must transcend across every aspect of the organization. Those of us engineers that have been around a little while have almost certainly experienced what happens to a piece of software when it wasn’t built with the right standards or cared for along the way.

At the end of the day, pretty much every engineer I know wants to build new stuff. When the underlying software is difficult to work with, impossible to test, and constantly breaks in production, life gets miserable pretty fast. An important aspect of achieving high standards is adopting a ‘shift left’ mindset. This means:

• Investing to make sound architecture and design decisions up front
• Building tests before and while coding to know that the software is always working
• Crafting a comprehensive observability strategy so that we operate on software with ease and ‘boring’ on-call shifts

Raising the bar

Finally, any effective organization (engineering or not!) must raise their own bar. The reality is that the bar is always moving. Competitors are moving it. Customers are moving it. Even our own products and software are moving it as we scale to more users, geographies, etc. If an organization isn’t raising the bar then it falls behind.

I have always conceptualized this tenet as the slope of a line representing aggregate organizational capability over time. Great organizations achieve a higher slope of that line than the not so great ones. That higher slope is achieved by avoiding complacency and status quo. Continuously seek out ways to innovate more in every aspect. Take time to celebrate successes and improvements, but then ask ‘Ok, what’s next!?’.

What’s Next

Admittedly, I suspect I haven’t covered anything that is earth shattering or contentious in the above. Where I have found that things get tricky is in the ‘how’. For example, It’s easy to say that we are going to make and meet commitments, but actually doing it can be awfully hard. Not only that, the ‘how’ has to evolve dramatically with scale. Making and meeting commitments with a 10-person team is wildly different than for a 100-person team. In future posts, I will introduce some of the mechanisms I have found to be particularly effective in helping with the ‘how’ question.