Learn How to Create a Startup Engineering Culture

This is the first in a planned series of posts about building a healthy startup engineering culture. This post is focused on evaluating the existing culture and offers advice on the one cultural change you should prioritize to have an immediate and positive impact. In subsequent posts, I’ll dive deeper in each of these areas to suggest tactics for shifting the culture in ways that support a growing and ever-changing team.‍

As an engineer or engineering leader who is considering or has recently joined a growing startup, how do you positively influence the engineering culture of your team? To start, it’s important for you to be able to observe and evaluate the interactions between individuals (how the team treats each other) and to understand the team’s processes (how the team does things).

You may find a team is supportive and psychologically safe but is constantly burdened with fire drills, inefficient processes, and poor tooling. You might also discover a team with solid tooling, lots of automation, and good operational practices, that at the same time is focused on individual success and achievements over team accomplishments. So, how do you approach evaluating the current culture of the team, and how should you influence moving forward?

How Does the Team Treat Each Other?

The first thing you’ll want to do is understand how people interact. Beyond the obvious red flags of aggressive or unsupportive communication–or a lack of communication at all–you’ll have to dig deeper to evaluate how individuals on a team treat each other.

One area that provides a good signal is the team’s culture around code reviews.

• Does the team perform code reviews at all? 
• Do they treat them as a box-checking exercise or embrace them as an opportunity to share knowledge, learn, and grow? 
• Are the comments in code reviews written in a supportive way? 
• Do they focus on major design issues or nitpick minor details that could be enforced by linters or other tooling? 
  

All of these questions can provide insights into how supportive the team is of each other, and whether or not the team embraces continuous learning and improvement.

Another key area to focus on is what happens when things go wrong. 

• Is the team comfortable raising a red flag when a project is running behind schedule? 
• Do individuals raise concerns when product requirements or technical designs are unclear, or when they have alternative ideas for how to implement a feature? 
• When operational incidents arise, does the team rally to mitigate the customer impact or deflect and point fingers? 
• If the team has a post-incident review process, is it blameless, focusing on understanding root causes and identifying ways to improve? 

These are all indicators of whether the team feels like transparency is valued and feels safe bringing their own thoughts and ideas to the table.

How Does the Team Do Things?

Equally important to how you treat people is how you do things. While this may involve process, it’s really a matter of determining whether the processes in place support the goals of the team and the company. 

Perhaps most important in an early-stage startup environment is how your team strikes the right balance between being scrappy and pragmatic with building for future scale. There isn’t a right or wrong answer here, and most solutions will fall on a continuum between quick-and-dirty and robust and forward-looking, but it’s critical that your team isn’t approaching these problems from entirely opposite ends of the spectrum. 

Gaining alignment here doesn’t have to be difficult, but it does require openingly discussing the topic. 

• What are our core competencies? 
• What things do we have to get right? For example you can take shortcuts with security, but I wouldn’t advise it. 
• What is “good enough”? Does this solution give us enough runway to learn more about our product and the customer’s needs, while getting us to that next inflection point in scale? 

Be comfortable with the fact that you’ll need to revisit your assumptions, while also making efforts to avoid decisions that might be extremely expensive to unwind in the future.

As a small but growing team, I’ve made it a goal to strive for culture over process. Process is often introduced as a means of solving problems. However, if the team has the right culture, many of these problems simply don’t occur in the first place. And if they do, the team is able to make pragmatic decisions about how to overcome them without heavy-handed or top-down solutions.

What’s the single most important technical investment a startup can make?

If you can only focus on one thing, I recommend getting your team to a place where they can do frequent, automated, zero-downtime deployments. This has a high return-on-investment both for the product and customer, but also for the culture of the engineering team itself. 

Scheduled downtime should be considered an anti-pattern and avoided wherever possible. For modern SaaS applications, your customers expect around the clock availability. As you cater to an increasingly global user base, there is no “good time” to take the system down for maintenance. It’s always someone’s working hours somewhere in the world.

Beyond the customer benefits of frequent, automated, zero-downtime deployments, there are many ways in which this benefits engineering culture. Shipping without downtime allows you to deploy during working hours and avoids weekend or evening releases. As fun as it might sound to order pizzas and have a Zoom party for a Saturday night deployment, believe me it gets old fast. 

Frequent deployments also take much of the risk and uncertainty out of the event, as the incremental changes in each release tend to be small. If something goes wrong it is generally easier to identify the source of the problem and rollback the deployment if needed. Along with the use of feature flags, this effectively decouples the deployment event from releasing new features to customers, avoiding the need to synchronize deployments with marketing and other customer-related activities.