Several weeks ago I had the opportunity to participate on a CTO panel at Cross Campus in downtown Los Angeles discussing how to build great engineering and developer culture. It was an honor to be on stage with four other accomplished CTO/CIOs including Mike Dunn 
of Ver, Braxton Woodham of Fandango, Bret Ulrich of Awesomeness TV and Scott Sibelius of Versus Gaming Network. We touched on a lot of great questions, but only scratched the surface on most of them, and in this post I’d like to expand on some those topics.
Question: What defines good engineering culture?
Generally speaking the foundation of a good engineering culture, and good organizational culture is one that at the very least addresses employees’ Maslow’s hierarchy of needs. Maslow’s hierarchy is broken down into five motivational needs: Physiological, Safety, Belonging, Esteem, and Self-actualization. Relating this to your employees, to support their physical needs, employees want to be paid adequately; as part of their psychological needs, they want to feel secure in their job; and to support their needs for self-actualization, they want to have autonomy and ownership of their work product, to name a few examples.
Assuming you have addressed the basic needs of your employees, how do you then, layer a set of values to create appropriate cultural norms on your team? For the teams and organizations that I build, I do this by hiring for, and nurturing the values represented in the D–O–T–E–A–M–S evaluation process. I coined DOTEAMS as a mnemonic to help me conceptualize the values that are important to me and my teams, to use when evaluating people for value fit. It embodies the following:
Diversity of thought and opinion
Ownership of Product
Transparent Communication and Decision Making
Experimentation, Failure, & Learning
Abundance Mindset for your team and customer
Mastery of your domain
Speed of delivery
This mnemonic helps me focus on all of the important values when looking at candidates, as opposed to just using skill as the sole evaluation criteria. As hiring managers, when we are interviewing, we often tend to focus too much on Mastery as the determination of a candidate’s qualifications; this can be either the mastery of a specific language, or skill. Too little do we focus on evaluating how a candidate will contribute to the whole value system that we are trying to build, and bring into our teams. We spend hours on whiteboard problems and technical challenges, and yet, almost no time on the whole set of organization needs in regards to building great culture. If we focus less on mastery as the sole determining factor of someone’s team worthiness, and instead filter people through a much more holistic value-based heuristic, then we will be far more successful in nurturing the specific culture that we set out to have in our organizations. Ergo DOTEAMS.
When we filter for mastery during the hiring process, the first place we usually turn to is a potential employee’s Github account. The beauty of hiring engineers in this day and age, is that you can also use Github to get a pretty good idea of how a candidate embodies many of the other potential values. For Ownership, for example, you can look at whether they have a long running side project with a history of improvement; for Experimentation and learning, you may see a graveyard of projects written in a variety of languages. The Abundance Mindset is in many respects demonstrated by participating in and contributing to OSS.
I won’t talk about all of my DOTEAMS values as some of them are, or at least should already be universally accepted as givens of a good culture. There are a few of them that I think warrant additional discussion including Diversity of thought, Experimentation, learning and failure, as well as the Abundance Mindset. I’ll touch on those next.
Diversity of thought and opinion
There was little disagreement on the panel about the need for diversity on teams as a driver of innovation. In my opinion, it has to be one the first values that should be considered as a driver of strong culture.
When discussing our desire to create diverse teams, an audience member posed an excellent question about why we hire for diversity based on “superficial” characteristics such as race, religion, sex, etc. They asked why instead we do not hire people that we think will meet the goal of diverse thought, and ideas, and how we would filter for those qualities.
Unfortunately, we don’t have very good ways of determining diversity of thought, but superficial qualities are in my opinion some of the most accurate leading indicators of diversity of thought; shaped through that person’s life experience, one which is going to be inherently different than those of white middle-aged bearded technology panelists.
Experimentation, Failure, & Learning
One of my core values is that the best learning comes from constant experimentation and failure. This is a process that is self-reinforcing, where the more that you fail, the more that you learn and can improve upon your failures.
Unfortunately, failure is something that people are not generally taught to be good at, and don’t accept, especially many people in management. I would venture to say that in most organizations, failure is severely discouraged, often resulting in dismissal. In this kind of environment, innovation cannot flourish, and instead gets replaced by a culture of mediocrity that infects the business like a virus.
The alternative is that failure is celebrated as part of the process of learning and development. I did this well at YP, and Spotify documents it well, integrating failure into their process and celebrating it. It starts with failure being treated as a safe activity. In order to make it safe, your people and technology architecture should make it possible to fail safely, which means that your product architecture, as well as your organization architecture, are built up of decoupled systems and self-sufficient teams that share common goals. With such an architecture, technology and organization-wise alike, the failure of any one system becomes non-fatal, quickly recoverable, and safe. This promotes experimentation, learning, and ultimately innovation.
Abundance Mindset for your team and customers
Steve Covey coined this term, and it is crucial to good engineering culture in my organizations. In short, the Abundance Mindset describes a mode of operations where we all win when we help each other. This is in contrast to the zero-sum game of a Scarcity Mindset where if I win, then someone loses. When it comes to teams, this pays real dividends in creating an organization that supports all of the other values. A team with an Abundance Mindset helps each other, pairs, coaches, teaches, and lifts the entire organization.
The Abundance Mindset also pays big dividends with your customers. While it’s de-rigueur to say that you have a “customer centric culture”, the Abundance Mindset puts it into action. When we have an Abundance Mindset, our mission is to feel responsible for our customer’s success, as without them, we don’t have a business. When they are successful, then so are we.
Question: How do you build a culture from scratch?
When building an organization from scratch, you certainly don’t have the “burden” of existing norms and habits to overcome, and you can just get down to the business of creating the first version of what you think that culture will be. I came up with another useful acronym, the P–R–O framework for this — that is, People, Rituals, and Organization structure.
People: Hire for values not culture fit
To build a culture, it’s imperative that you first have a good grasp of the values that you want your culture to embody. For me that’s reflected in DOTEAMS; for you, it could be something completely different. You can’t skip this step, however, as organizations and culture start with people, and so to create it, you will need to hire people who you think will be the ambassadors of these values.
In this video from his Techsylvania talk (around the 10:00 mark) https://www.youtube.com/watch?v=yniDni6QfWk Rohan Chandran, one of my previous co-workers from YP, talks about how hiring for culture fit is the opposite of hiring for values, especially with respect to diversity.
To paraphrase him on why you shouldn’t hire people just like you, when you hire for culture fit, you will likely get clones of yourself that will rarely disagree with you, and you will probably enjoy every moment of creating a failed enterprise.
Conversely, when you hire for values, especially when they are those such as in DOTEAMS, then you are more likely to surround yourself with people with diverse opinions, who will make transparent decisions, who will move fast, fail fast, learn from their mistakes, keep you in check, and help you move your business forward. This is likely to create a good amount of healthy conflict, as you may often disagree, and there may be times when your relationship will be strained, but this is also the desired end result to help prevent the kind of group-think that is fatal to a business. It is the melting pot of ideas, opinions, and experiences that enables you to innovate, respond to business risks, and build great products.
Rituals: Process to support your values
Rituals are the tactical processes that you put in place to support your values. For me these are mechanisms like automation tools (test, deployment, marketing, etc) to help with Speed of delivery of your product. Code Reviews, Retrospectives, and Pair Programming support Transparent communication, Experimentation and Learning, and the Abundance mindset values. I am also a big proponent of the Build Measure Learn feedback loop as a ritual used not only in product development, but also when applied to the improvement of culture as well.
At ProductionBeast, for example, we use all of the above, with extensive automated test suites, combined with Continuous Integration and Continuous Deployment to be able to ship features to production with very little drama at the push of a button. We are comfortable with failure, and use it to feed it back into learning and improvement.
Organization structure
Much has been said of the ideal organization structure, with Spotify and Netflix being the canonical examples these days. Martin Abbott and Michael Fisher also go into a great deal of detailed analysis of creating scalable agile teams in their book, “The Art of Scalability.” The book generalizes that the ideal organization structure can be accomplished through the organization of self-sufficient product teams. Braxton on the panel put it best, describing their engineering organization structure as a systems diagram of product teams instead of a functional organization chart. This certainly works well for startups that are already self-sufficient product teams, and scales well provided your architecture is made up of isolated independent products, as your organization structure will be shaped by this.
Question: How do you address culture problems when inheriting an organization?
Another question posed was in relation to turn-around work of inheriting an organization with a poor culture — that is, when you can’t hire your way into a DOTEAMS team. The way to address is, is to realize that culture is not a static concept, but an extraordinarily fluid one. It is never good enough, or complete, and will evolve over time. So whether in a brand new organization, or in one you inherited, you should use the same improvement minded rituals to regularly experiment, identify and learn from what is and is not working, so as to improve.
∑
There were a good many other questions posed during the panel, and by the audience that I haven’t touched on. Get in touch with me here and let’s keep the conversation going. There is also a lot of good reading on the subject including the aforementioned “The Art of Scalability”, Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds, and Netflix Culture: Freedom and Responsibility
Finally, a big thank you to Joe Devon and Caroline Rose for putting the panel together, and being stalwarts of the SoCal technology community.
Startup Therapy 