How to Build an Engineering Culture

Photo by Joe Robertson

Engineering culture is a topic I am passionate about, mainly because I have personally witnessed its transformative effects on engineering groups throughout my career. When I say I’ve witnessed transformative effects, I’ve seen it go both ways, and have arguably learned more from the negative culture movements than the positive ones.

What type of organization are you in?

I recently read this paper “A typology of organizational cultures” and tend to agree with its three proposed categories, distinctions made based on the preoccupation of each:

1. Pathological: Personal power, needs and glory
2. Bureaucratic: Rules, positions and departmental turf
3. Generative: The mission itself

If you have worked at more than one tech company in your career, you have probably witnessed these characteristics in play. You might work in a company where you see one group operating pathologically, and another bureaucratically. It is less likely (but possible) to have one group operating generatively whereas other groups do not. The paper goes on to extol the benefits of the generative approach and its positive effects on groups.

I start with this distinction for one main reason — your approach to building, changing or improving your engineering culture will depend on which type is the predominant one in use.

What is ‘culture’, anyway?

The OED definition for culture includes this:

The customs, arts, social institutions, and achievements of a particular group

How does that apply to engineering organizations? In a number of ways.

Social aka team values

• How do team members treat each other?
• Do team members celebrate each other? Birthdays, project wins, etc
• Are team members friendly to one another? Brutally honest? Mean, vindictive?
• When team members aren’t actively coding or in a meeting, what do they do in the office?

Technical

• How are decisions made? Does the team make compromises, and if so, how/when?
• Where do new ideas come from?
• How are code reviews conducted? Pair programming?
• What are the technical standards of the group?

Why is culture important?

There are a number of ways in which culture helps a company.

First off, if the mission statement of the company is the interface for a company’s operations, the culture is the implementing class. Culture will be a calling card that will help in attracting talented people, growing them and retaining them to do excellent work.

Culture creates a unique working environment when done right, as it is implementing the mission in a way the people you have can support it. Before you go off and decide to do axe throwing or jedi training, you will need to determine if those ideas are consistent with the team’s culture. If not, the team will surely reject the ideas as ‘uncool’.

Standards are well kept in good cultures, thus allowing leaders to spend their time strategically. Instead of spending time corralling teams and exhorting them to do the right work the right way (which can quickly spiral into micro-management), a good culture frees leaders to make the company better in ways the leaders are uniquely qualified to do so. Win, win.

What is our culture?

After determining what category organization you have, here are some things to contemplate about your existing culture (assuming you have one already):

• Who works here, IOW what is your D&I (Diversity & Inclusion) story?
• Is the culture documented? Or more tribal and unspoken?
• Is it known and supported to/by the chief executive and inner circle?
• Does senior leadership believe culture is important? Do they desire a culture change? If so, why? What do they think they will get out of it?
• Do you have a culture/team fit step in evaluating new engineering candidates in the interview process? If so, how do you describe your culture as an interviewer?
• Who in the company is ‘culturally aware’ and can help you navigate the team when making culture changes?
• Was the culture architected/purpose-built? Or organic and ever changing based on the latest hires?

The answers to the above will give you a good baseline to help you in determining how to strategize culture. You CAN influence culture in positive ways if the senior leadership isn’t bought in… if you can sell them on it. Culture is really hard to implement uphill, if the senior team doesn’t believe in the culture change they may inadvertently (or purposefully) undermine your efforts.

It is a hard requirement for you to find your ‘canary in the coal mine’ to help advise you on culture additions. If you can find someone in the org who cares about culture like you do, and is willing to be honest with you, your culture effort will benefit greatly from it.

A great way to introduce new culture is to document what you are proposing. There are a number of ways to start this — whichever one you choose, make sure you have input from the team and that you define the metrics that will be positively impacted by the culture change (and if you can’t define those metrics, are you sure you need to make a change at all?) Retention rates, employee satisfaction surveys, success in recruiting/hiring are good ways to measure the effects of this.

Do you need to make a culture change?

Now that you have read this far, you might have deduced that you don’t have a culture problem in your group. If so, fantastic! GOTO END. :-)

OK, if you are still here, you have decided that you do need to make a change. You have thought about the culture that exists, the landscape, senior leadership and their appetite for change and the current state of the team. Now let’s take a look at some specific things you might consider in improving your team’s culture.

Inspiration

Photo by skeeze

Pick a few companies whose cultures inspire you, and keep track of them. Nowadays you can learn a lot by following a company’s news and developments, and it can help to validate the worth of culture changes. Good company cultures are generally not quiet (ex/ Netflix’s culture is renowned, and easily viewable here); you will likely find it easy to keep tabs on them.

1:1s, skip 1:1s, coaching, mentoring

These are four different things, but are related in that they are all personal mechanisms that result in greater engineer growth. 1:1s (one on ones) are the bare minimum, a psychologically safe and recurring meeting to maintain a good communication channel between manager and engineer.

Skip 1:1s are less common, but can be an effective tool to help when the 1:1 communication is missing things of importance or if there is some personal issue limiting effectiveness of the 1:1. It is also a way for a manager’s manager to determine how effective a manager is, leading to coaching opportunities.

Coaching can be done with any pair in your organization, it is not constrained to a manager / engineer conversation. In fact, if you are an engineer you really should seek out a coach who is not your manager — you already have the 1:1 for that conversation. Coaching is great for ‘teaching someone how to fish’, describing tools and methods for a person to better deal with difficult / growth situations.

Photo by Startup Stock Photos

Mentoring to me is similar to coaching; the distinction in my brain between the two is akin to HTTP 1.2 vs. HTTP 2. Coaching is the older, HTTP 1.2 way of communicating client to server, and the protocol observes closing of connection in between requests, much like coaching sessions are insulated and you can have one meaningful coaching session with one person and the next with another.

On the other hand, mentoring is more of a persistent connection between mentor and mentee, and there is a growth path observed in the relationship. Both are very similar, both are great. In many places I’ve seen both happening, so you don’t have to choose one or the other.

360° Reviews

Traditional yearly employee evaluations yield some benefits, for sure — namely, it allows for the employee to know how their performance has been judged by their manager. In good cultures, the result of a yearly evaluation should not be a surprise to the employee — it should be a yearly distillation of the ongoing conversation between manager and employee.

Where 360° reviews differ from the traditional yearly review is in perspective. 360° reviews tell the employee how their work is viewed by the larger organization. Inputs include that of the person’s manager, but also include co-workers, managers and engineers of other groups. It paints a richer, more comprehensive picture of a person’s performance and culturally, adds the advantage of allowing for more voices in the organization.

360° reviews are a pretty big effort but they do pay off. If you can’t invest in the full 360, there is still a lot of value in the traditional yearly reviews and the time you spend on that will pay off culturally. It is very important for your engineers to know where they stand and have documentation on their path forward.

Career ladder / lattice

If you do not have engineer career progression documented, I believe you should. The expectations for each role (software engineer, senior software engineer, staff software engineer, etc) should be clearly listed and accessible from a well known location. It should NOT be a mystery as to how to achieve a promotion at the company, and the standards should be universally applicable at the company. It does your culture harm if someone can be promoted by achieving less in a different group — it can breed envy, which you definitely do not want.

Photo by geralt

In recent years, the conversation around career advancement has grown from the career ‘ladder’, the one-size-fits-all list of steps from the entry level to the most distinguished engineer role; to the dual-track ladder, where you have senior engineering roles depicted as equal in level to management role; to the idea of a career ‘lattice’, which replaces the bundle of achievements (which must all be met to achieve a promotion) with the same set of achievements, unbundled. The lattice helps plot out personal career paths that may deviate in the order in which the steps are achieved, and can unlock a more equitable path to promotion that doesn’t force everyone to achieve the same things the same ways to move into new roles.

I really love what Camille Fournier has done to advance thinking about the Manager’s Path and career ladders in general. Take a look at her writings, you won’t regret it. A career lattice may be a big undertaking right away; start off by making sure you have a well known career ladder with dual tracks for engineers and managers, take feedback from your team on it, and you will be well on the way to success even if you don’t end up with a lattice.

Open Source

I do not believe an engineering group has to contribute to open source. I do think, however, that open sourcing good and useful code, provided your team has the bandwidth to respond to questions / suggested additions to the project from outside interest, has the potential to improve the reputation of your tech team outside of your company. This is a good thing. Just MAKE SURE it is good code you are open sourcing, as this tactic can easily backfire and create an impression that your tech team doesn’t ‘get it’.

If you are committed to open source but aren’t sure your code is ‘good enough’ to be open sourced, I would suggest starting off by contributing fixes to an existing open source project your team already uses. This is a good way to be a good citizen, without overextending your team, an especially useful approach if your team is small and/or junior.

Innovation

There are countless posts and books and opinions about innovation in engineering organizations. Innovation is not free, and your organization’s type (remember from the beginning, pathological vs. bureaucratic vs. generative?) figures pretty heavily in how innovation can work at your company.

Internal hackathons are a common, proven method for generating new ideas for your company. Whether or not those ideas are good, and if you are prepared to consider putting those ideas into the product that generates your company’s revenue, is not as clear and are two important questions to answer.

Photo by genesis_3g

Here’s a good post with some thoughtful questions to ponder if you are considering hosting a hackathon. Ultimately I think hackathons are generally a good thing, but it is very important that you determine what they are for, and what the company will commit to doing with the ideas from the event.

If you are considering hosting a hackathon but aren’t sure, you can start out by having one of your teams join someone else’s event. That is a good way to determine what kind of output you might expect from a team in an internal one. If you want to associate your brand with innovation but don’t want to host a hackathon, totally understandable, look into being a sponsor and/or offer to host someone else’s hackathon (if you have the space to host, that is).

Knowledge Sharing

Healthy engineering cultures have at least one proven way of sharing knowledge internally amongst the engineering group. There are a lot of different ways to do this:

• Wiki/Knowledge DB: Having an internal wiki of relevant tech information is pretty common. This creates value iff those posting to the wiki keep it organized. I would suggest you have one or more curators to help with organization, as wikis can become wastelands of inaccurate, dated information pretty quickly without organization/oversight.
• Tech/lightning talks, brown bag lunches: Effective way of communicating engineering knowledge, the distinctions between each type are related to how formal and how long presentations are. Recommendation: record them, even if they are informal, and keep them around as part of the knowledge DB. Side benefit: it improves engineer presentation skills!
• External training: Nowadays if your engineers want to learn something technical, the best way to do it is a combination of JIT training (see my previous post, ‘A Case for Learning & Development’) and practice. However, if they want to learn more effective communication skills, how to be more persuasive in presentations, meeting mastery, etc, an external training firm can help. Note: this is not free.
• Meetups: If you are in a city with a lot of tech companies, you will generally also be in a city with a lot of tech-focused meetup groups on meetup.com. This is also an effective way of learning new material, by attending a meetup. Side benefits: improve your brand’s tech reputation if your engineers are seen attending meetups; good career opportunity if you can have one of your engineers speak at a meetup; you can offer to host someone else’s meetup and that has similar brand benefits as well.

Blameless post-mortems

A hallmark of a generative culture, blameless post-mortems are a cultural construct where a cross functional team meets after a customer impacting issue has happened to find the root cause, develop and review an action plan to prevent the issue from recurring. In pathological and bureaucratic cultures, this may be harder to pull off. If you are having these at your organization, good for you! If you aren’t, I would highly recommend having this.

Team Outings

Team bonding can definitely improve cohesion and team performance. Please DO NOT THINK that team outings = engineering culture. Team outings are great; an occasional lunch, coffee break, fun activity, corporate sports league, happy hour — all of these are reasonable things that can help the team. Volunteering, through an organization like NY Cares, is a great way to have bonding and fulfill peoples’ need to help others in need.

However, make sure the team wants the outing and pay attention to your team members while at the event — there is a thin line between a fun outing everyone enjoys, vs. “forced fun” with your team outside of work.

How do I Know if the Culture Change is Working?

Keep your ear to the ground. You should already have the metrics in mind that you will use to objectively calculate the efficacy of your culture change. Employee surveys can help, observe hallway conversations discreetly to determine the ‘team mood’. If the culture is improving, you will likely feel the office is more purposeful; conversations become more crisp, and less outright moping should follow.

Listen to your cultural advisors — some culture constructs won’t work, so pay attention to that and ditch what doesn’t work. Even the things that do work will need tuning over time; sometimes a very successful event series works great for a few years and then runs out of steam. That’s fine too.

Conclusion

In order to create/change an engineering culture, you have to actually mean it. People will sense phoniness or ulterior motives behind cultural events and if you are found guilty, your event will quickly become a ghost town.

No matter how great the event is, you are the cultural lightning rod and if you don’t really care, it will fizzle. Therefore, only lead the cultural events that interest you. Find someone else to lead the other events… and if you can’t find someone passionate about an event, then the event shouldn’t happen until you can.

Never forget: It’s about the people, stupid! They are the focus of the culture, and they will need to see the benefits clearly of the cultural change before they will choose to participate in it. The good news is that I KNOW YOU CAN DO IT. So, what are you waiting for? We’re all counting on you. Good luck!

END