Develop Your Culture Like Software

This post was originally published on this site


Recently, I tried out a new talk at La Victoria Lab’s innovation festival in Lima where I covered an experiment we have been engaging in, somewhat by chance, at The New York Times: working on our culture like it was software. I’m not sure how the talk went over, but personally, I think we are onto something good and novel at The Times.

Nick Rockwell/The New York Times

The story I told at the FEST was about how my team and I have gone about trying to impact the tech culture at The New York Times. It should be obvious to my readers why we want to work on the culture: we want to be better — better environment, better capability, better talent, better decisions and better results. Focusing on the team is the leverage point for all of those things, and culture is the leverage point on the team. As I put it in my talk, the benevolent laziness of the software engineer led us straight to culture.

Our goals are fairly typical: we want a culture that is open and transparent, objective, risk-taking and ambitious; one that values talent, values inclusion and so on. But our goals is not what this post is about.

So how do you go about changing culture? It’s notoriously difficult, but so is changing complex software systems and we know a lot about how to do that. But we didn’t think of that at first. We didn’t know how to start, so we just picked something that our technology team had asked for: a clearer engineering ladder with a technical track. (There are many reasons why this is a critical plank in the tech platform, but I won’t go into it right now.)

To start, we made an artifact — we (made up and) wrote a description of our technical career track, cribbing — laziness — from Camille Fournier’s work at Rent the Runway. We worked in a Google Doc in “suggesting” mode and added lots of comments. In my weekly direct report meeting, we talked through the contributions, accepting or rejecting changes that had been made in the week before; sometimes we reverted to an earlier version.

Eventually we thought it was pretty good, but we needed more feedback. So we set up a group called the Sounding Board, made up of 30 or so people, intended to be representative across the technology team, and who we thought would provide good perspectives. We asked the Sounding Board to do the same thing we had been doing in our weekly meeting — revise as a group until they thought it was ready. As a side benefit, they were particularly good at pointing out all the things we needed to document next to ensure the technical career tracks make sense, giving particular focus to our promotion process, internal transfers and hiring.

In the process, we made a little bit of our implicit culture explicit. It turns out that when you do this people get anxious, because writing stuff down makes you pretty exposed. I guess that’s why it doesn’t happen often. But the key is habituating your team to talking about these things and to make change; and to the idea that we can make mistakes with culture and process, just as we do with software, and it doesn’t have to be the end of the world.

Next we needed to test our newly written career ladder out, so we sent it to the whole technology team and said, “We are going to start doing this. What do you think?” We didn’t get too much feedback, unsurprisingly. So we surveyed the team using Google Forms and got a decent signal back. As we implemented the ladder, we continued to iterate and improve it, getting more feedback and figuring out what worked and what didn’t.

Then we turned to the adjacent topics: our hiring process, promotions and internal transfers. We went through the same steps with our hiring process, then moved on to the next topic, and so on.

We’ve spent the last year or so doing this and have produced at least 50 documents, each materializing a little piece of our culture, including processes and artifacts like career ladders, hiring, transfers, promotions and training, but also a beliefs and values statement, a code of conduct and meeting guidelines. We’ve produced charters for each team that cover the team’s mission and values, their current goals and who to contact. Each artifact is just a little piece, but taken together, this has had the effect of making the intangible tangible and letting us work collaboratively, iteratively and transparently on our culture.

And this is the central insight — culture is a bit like code. Software systems are hard to see, complex and have emergent effects, just like culture. Using the techniques that we have evolved to change software — creating artifacts, version control, iteration, code review, instrumentation and beta release — can work to change culture too.

This idea, this metaphor, is now directly inspiring our next steps. We’re launching a tracker for “management bugs” to report management responsibilities that are broken. We are going to open source our culture docs, first internally, for revision by all with a pull request like system, and, soon, publicly. And, I’m trying to think of how we could do blue/green deployments… haven’t cracked that yet.

So what are the takeaways? If you want to try this, what should you do? Here’s a start:

  1. Materialize your culture into artifacts. Start with anything. Then, keep going.
  2. Use a collaborative editor, with version control, like Google docs.
  3. Organize your concentric circles of review — in our case, my directs, the Sounding Board, the whole team. Introducing things in this way helps ensure that as you reach a larger group, more eyes have been on the thing, and more people are already up to speed and can explain it.
  4. Don’t skip the surveying. The hardest part is understanding the effect of what you are producing. In reality, it takes months or even years to know for sure, but you can learn a lot by asking.
  5. This might be an uncomfortable process, but that’s OK. Many companies feel safer letting culture remain implicit. As long as you are authentic and mindful, and use language carefully and deliberately, it will probably be OK. Design a good review process and trust it. It’s worth it!

We’ll keep you posted on this experiment. If you have any thoughts or suggestions, or questions, please reach out to me here, on Twitter, via LinkedIn, etc.

This story is published in The Startup, where 266,300+ people come together to read Medium’s leading stories on entrepreneurship.

Subscribe to receive our top stories here.


Develop Your Culture Like Software was originally published in Times Open on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑