Creating a Simple yet Effective Engineering Culture

As builders and owners, we want to build companies that serve our customers and partners in the best way possible. Technology is central to that ambition, and to develop innovative technologies, we need to build the best engineering teams and culture that we can. These engineers must be set up for success or they will not support the organization’s mission, or even worse, serve to derail it.

The best time to build an engineering culture is from the start, as retrofitting culture is not always so smooth, but the next-best time to start to build an engineering culture is now.

This article provides some ideas on how to effectively and efficiently build that culture, prioritizing what really matters.

Installation: constructing the right team

The foundation of any sustainable engineering culture is to hire excellent hands-on engineers. The “Medici Effect” argues that innovation happens when a diverse group of people from different cultures and disciplines come together to solve problems.

To build an engineering culture, start by hiring serious engineers, including plenty from outside your industry. Exposure to a variety of state-of-the-art thinking from different sectors, like e-commerce, travel, finance, etc, will bring new ideas on how tech can be built.

A-player engineers want to work with A-player engineers. This affects hiring, but there are untapped opportunities in developing outsourcing & partnering strategies.

Administrators are essential to structuring an organization’s success but left unchecked, they can overwhelm the hierarchy. The ratio of builder to administrator to manager must be tracked and monitored. In extreme examples, administrators may outnumber builders. This clearly does not make sense. By tracking this ratio and reporting it, senior executives can better understand the workings of the team - and identify potential imbalances early on.

When it seems technology is stagnating, a common response is to create an ‘innovation team’. This is almost always a mistake, as it pushes the responsibility (or restricts the opportunity) of innovation to a small group of people, plus introduces an implicit fundamental error: sometimes innovative research is not what is needed - teams simply need to keep up with the state of the art. Adopting the state of the art in the middle is more important than driving innovation on the edge.

Configuration: setting the team up for success

So what does a successful engineering team setup look like? Here are three attributes that are core to any engineering culture:

1. Technology and Business are recognized as a partnership.

Technology is not simply a service function. Ownership of tech outcomes also sits with the business, through product managers and aligned processes. Technology teams supporting a particular function, such as sales or operations, should be fully integrated. Having mutual empathy and some functional understanding of one another leads to faster time-to-market, more streamlined processes, and ultimately better outcomes for the company.

2. Teams support a transition from project management to product management.

Project management is important for some activities, but this transactional approach to a platform can lead to under-investment. Each platform or capability requires a product manager (ideally not an engineer, as they bring along their biases) who is responsible for driving a clear user-focused roadmap to which everyone aligns. This is not merely functional prioritization – the product manager must understand both the business and technology limitations and potential of the product, and act accordingly.

Traditional team hierarchies are based on outdated methods of information dissemination, such as paper-based memos or ‘confidential’ emails. Modern communication methods call for modern team hierarchies: two-pizza, agile product teams. We cannot forget Conway’s Law and its implication on the products our teams build.

3. Effective team processes stem from effective feedback loops.

Retrospectives allow the team to regularly check ways of working to see what is constructive and what isn’t. “Open” discussions don’t always get the best results, some engineers or cultures don’t speak up. Instead, create shared documents and have a silent meeting where everyone is encouraged to write down their thoughts. The same reluctant engineer is much more likely to explain their thinking after it has been written down and shared.

Deployment: getting sh*t done

As described in Turn the Ship Around!, decisions around what is and isn’t a good idea should be driven downwards into the organization. Engineers thrive on emancipation.

Of course, this needs to be balanced with relevant regulation, but not doing something solely because other institutions are unwilling to accept the risk should not be an excuse. 

The truth is, fast fish eat slow fish.

The velocity of decision-making is key to success, and sometimes making a reversible bad decision is better than making no decision at all.

Understanding which decisions are reversible and which are not is a skill that must be developed within the team. This has been well articulated within the culture at Amazon.

Builders do not need to be taught how to be agile and innovative, they need to be allowed. No one becomes an engineer because they want to build boring, inefficient solutions. No one chooses to avoid modern architectural approaches and frameworks. They may, however, be forced to. Leaders must ensure builders have the freedom to choose their approach.

A common false economy is to try to save money on computer equipment. To build an engineering-first culture, we must acknowledge that the tools builders use are essential to their success. If a piece of office equipment can influence or undermine an engineer’s productivity and motivation, then it is well worth the investment. Trust your builders to make good choices for their tools. A $10/month piece of development software or $2000 computer is insignificant compared to the cost of a builder’s productivity.

Adding processes and checklists is easy; removing them is not. While all companies obviously want to comply with relevant legislation and best practice, a process that exists for the sake of 'process' must be hunted down and eliminated to ensure engineers can focus on building, not red tape.

Be guided by “guardrails, not speed-bumps;” the idea that as long as we stay within established rails, we can go as fast as we like - as opposed to speedbumps (formal approvals) that aim to keep us safe, but constantly slow us down.

The Takeaway: get out of the way

To build a great engineering culture that drives innovation and first-class output, you must engage the best engineers from the region, and give them the tools they want, the freedom to make decisions, and the space to get on with it.

Don’t make it any more complicated than that!