How to build a generative engineering culture

A generative engineering culture is one where nothing seems to fall through the cracks, “we should” gets prioritized and becomes reality, and original ideas and value come primarily from engineers, rather than management. A culture like this is an engine for building capacity, quality, innovation, and sophistication.

Generative cultures are the goal and the envy of most industry-aware tech teams. Companies like Netflix and Valve boast about their cultural philosophy and its generative effects. Popular books, like Accelerate, show quantitatively that generative cultures yield high performing teams. Yet with all this information and many tech orgs striving to build this type of culture, few companies actually achieve success, and those that do tend to see the culture crumble as they grow.

What is a generative culture?

The term generative culture was coined by sociologist Ron Westrum in 1988 while researching complex technological systems and the organizations that produce and maintain them. Westrum identified a topology of organizational cultures ranging from pathological, to bureaucratic, to generative. Below is a table that shows the characteristics Westrum found were associated with the three different culture types.

This is more of a spectrum than a classification because most companies don’t strictly conform to one column of characteristics. In fact, many companies I’ve worked for were large enough to have individual teams that leaned toward different cultures, while the overall company tried to steer toward a specific culture model with varying effectiveness.

If you read enough management books you start to see this topology reflected in different frameworks, but called things like empowered culture or a team of teams. I use Westrum’s term, generative culture, because it describes the outcome and not necessarily the process, techniques, and frameworks that you use to get there — such a culture comparatively generates more original value from more people on a regular basis. This term has also been adopted by the folks behind The DevOps Report and Accelerate.

Why’s it so difficult to achieve and maintain?

The short answer is: knowing the principles, characteristics, and benefits of generative culture is not enough.

It takes:

Management buy-in, from the top down.
Structures and policies that create alignment, reserve time for engineers, and facilitate cross team collaboration.
Coaching and skill building for those who are being empowered.
Consistent managerial reinforcement across the organization.

I’ve seen, and unfortunately been part of, too many teams that focus solely on empowerment and structure and not on the alignment, coaching, or skill building. These teams usually wind up with some form of empowered chaos — engineers tackling the wrong problems or tackling them with ineffective or incomplete solutions.

Even though there are many books that talk about the benefits of a generative culture, there are few that give guidance on how to transition your team to one. Below, I aim to give some practical and opinionated tactics and techniques that have helped me and my engineering teams make that transition.

Buy-in from the top down

In order to create fully supported structures and policies that create alignment and space for engineers to be empowered you need vocal and public buy-in from management. At a startup, that means from the CEO and your product partners. At a larger company, your department head might suffice.

Unfortunately, it’s not always as simple as them waving a magic wand and saying they are bought in. Sometimes it takes them facing their own rules driven behaviors and policies and rethinking them so they don’t unintentionally hinder your efforts. From there you’ll need individual product managers and engineering managers to buy in to the concept and support the engineers on a daily basis as they tackle problems and build skills.

I’ve been fortunate at Policygenius. Our CEO, Jennifer Fitzgerald, and CPO, Francois de Lame, bought in on this concept before I started and were already implementing structures and policies to help with this culture in other parts of the company. However, I haven’t always had the same consistency of support throughout my career, so if this is a big change for your team, I suggest starting here.

Structures and policies

20% time: It’s important you create room for engineers to work on problems aside from their day to day sprint work. This gives people space to build skills, collaborate, and actually complete work on opportunities they identify. This is where you’ll need buy in and support from your product managers and your tech leads so they actually make sure individual engineers think about 20% time every sprint. To paraphrase Marty Cagan’s way of describing this policy to product managers: Give engineers 20% of their time to work on whatever they want and they won’t ask you to rewrite your entire system.

Engineering OKRs: Policygenius already had one of the best OKR implementations I’d seen when I started. It began at the top, with Jennifer setting goals for the whole company, and ended with every department and product team having their own OKRs that contribute to those high level goals — every department except engineering. While product OKRs should also be owned by engineers, it’s also important engineering has it’s own objectives to create alignment on most important goals for the department or team. They help create alignment on things such as tech debt, architecture, tools, process, etc. From there, engineers can find opportunities to contribute to those goals. I won’t go into too much detail here since that would take several more articles, but I will say that if you are completely unfamiliar with OKRs then you should pick up a copy of Measure What Matters. Whatever your implementation is, try to make sure that these objectives are created as a group with input from as many engineers as possible.

Cross team working groups: Finding opportunities, formulating a plan of attack, and organizing the right people to execute on a solution are all hard problems, especially for engineers who may have never done this before. The goal is to have groups start to eventually self organize, but that may be over a year away if you’re just starting to build this type of culture. Managers can help jump start this process by organizing these groups for the team and charging them with a problem to go after using their 20% time. We kicked off this transformation with Charter Guilds (I detailed out that process here) and have since diversified to include general working groups and engineering initiatives.

Status and reinforcement: In order to ensure success you need checkpoints to give feedback about everything ranging from the planning process, the proposed solution and its scope, the plan of attack, and progress as it’s happening. We use a mixture of design reviews, sprint reviews (where each cross team working group also presents), RFCs, OKR statuses (since most of the problems they are solving level into engineering OKRs), and 1:1s. The key is to have group leaders check in often and to ask about their confidence level in order to find when they may need additional help.

6 core skills required to be empowered

The responsibility and skill required to be empowered to solve a problem independently is often overlooked or underestimated. Nothing contributes more to a culture of empowered chaos than empowering people who are not yet ready to take on the challenge. The good news is, these skills are not a prerequisite — they can be taught and learned along the way. In fact, that may be the only good way to actually learn them. What that means for management is they need to stay vigilant with empowered engineers who are still being trained and grab every opportunity possible to coach them through the challenges they’re facing, without taking over the problem themselves.

Here are brief descriptions of six skills I have coached engineers to build that are necessary for them to be able to add original value.

Time management and planning: Kicking off with this one because it’s probably the most important and is often an underdeveloped skill for engineers who work in agile environments. I love agile, but unchecked it can lead to a ticket taker mentality where engineers don’t think about what they want to accomplish and how to use their time to maximize success . Instead, they simply take tickets one after another off the top of the queue. I often find myself reinforcing that it’s every engineer’s job to manage their calendar. I want to get to a place where every engineer plans out their days and weeks to make sure they have reserved the time to spend that 20%.
Opportunity identification: Every problem is an opportunity — an opportunity to fix something, make the team better and stronger, to own something, and to build skills. Identifying that is harder than it sounds. When you’ve been trained with a ticket taker mentality, where your product managers and engineering managers are the ones who decide what you work on, every problem looks like something you need to raise up for someone else to solve. Unfortunately, most of your managers are already swamped, so they often seem uninterested or don’t understand the importance, which leads to the perception that things are constantly falling through the cracks. (If there ever was a time for a sad face emoji it would be here.) This perception will change broadly as engineers see other engineers become empowered and successful in solving these types of problems. Again, it takes vigilance in management to find ways to delegate these problems when they are raised up rather than taking them on themselves or ignoring them.
Peer organization: In order to solve most problems with any sort of robustness or quality, it takes a few people to band together in a cross team group. That requires good organization, collaboration, and internal delegation. Most cross team groups that we’ve stood up at Policygenius have elected or appointed a chairperson. This person will need to build most of these skills in order to facilitate the daily and weekly activities of the group. This role is not unlike a tech lead or scrum master of a typical scrum team. The one factor that makes it more difficult is that you need to organize a group who typically will think of their 20% work as secondary, which means that person usually needs to lean in more to make sure progress is made.
Stakeholder communication: Many engineers (including myself earlier in my career) have a bad habit of jumping from problem to solution within seconds. In order to create a successful solution, it’s important to coach engineers to socialize their understanding of the problem, their proposed solution, and garner feedback at every step of the process. No one on the team should be surprised by what the solution is by the time they start building it. Our chairpeople have gotten into the habit of setting up structured brainstorms, sending out RFCs, utilizing design workshops (with our entire team optionally invited), and advertising their initiatives in sprint reviews.
Scoping: I’ve had teams I had high confidence in because of their problem identification and broad solution buy-in, ultimately tell me they did not share my sense of confidence. When digging in, I discovered it was because they didn’t have a good sense of when the project would ever end. Working on something part time and not having an end date in sight is extremely demotivating. Learning to scope a solution and draw a line in the sand as to what phase one looks like can be instrumental in keeping a cross team group motivated. My rule of thumb is that nothing should take more than four months, including the planning and socialization phase. That end date allows engineers flexibility to disband for a time, or even permanently. It also allows people to explore other priorities or reorganize with different membership. All of these are healthy options for a dynamic team.
Learning and application: As stated earlier, you don’t need to be confident empowered people have all the above skills before starting the transition toward generative culture. In fact, I’ve had people chair cross-team groups who didn’t feel confident in any of those five skills. But, if you do empower someone to lead an initiative, you need to set them up to succeed, which means helping them work to develop these skills with consistency. As you see chairpeople learn and apply these skills you can start to give more room and trust. Helping them recognize when they have made progress on these skills can be a powerful tool to help reinforce that improvement and to help them start learning and applying these skills on their own. Once someone has made progress on all these skills, you will have an engineer who can continue to lead cross-team groups, generate original value, and even start to teach others how to master these skills — it creates an exponential effect.

The exponential effect & maintenance

I’ve been refining and using these techniques for the majority of my career in technical leadership. I’ve heard others describe the job of manager as being a force multiplier. I view creating a generative engineering culture as an extension of that role — multiplying force not just for who can take on pre-prescribed problems and solutions, but for how many people can identify and solve problems independent of management. In such a culture, nothing falls through the cracks.

At Policygenius, I am lucky to work with a team that is extremely mission driven and is motivated to acquire these skills so they can continue to increase their impact on the overall strategy. Over the past year, I’ve seen people build their skills and start to teach each other techniques they learned along the way. Time management techniques have started to flourish (am I too old to say the’ve gone viral?) and I’ve seen chairpeople start to lean on each other for advice about how to organize groups and coach each other. I’ve also seen engineers starting to identify problems — like bad production alerting or crapy documentation — and realize they not only should solve those problems for their teams, but should socialize them and try to come up with solutions that can apply to all teams in our department.

The one word that sums up how to maintain such a culture as your grow is vigilance. Never stop coaching, never stop delegating and empowering, and push people to pay their newly learned skills forward.

David Kaplan is the head of engineering at Policygenius, the nation’s leading online insurance marketplace. David has been an engineering leader for over a decade, as a VP of engineering at Yodle (acquired by Web.com), a senior manager at Bloomberg L.P. and the co-founder of Helioscene, a SaaS startup in the video production space.

You can read more insights from the Policygenius team on their engineering blog.

Editor’s Note: David joined us on The Changelog for a deep discussion on generative engineering cultures. If you enjoyed this article, you’ll love the accompanying podcast!