Five Things I Did to Change a Team’s Culture

Culture – Be Specific!

People often talk about culture being the barrier to adoption of DevOps, but they are rarely specific about this.

This was succinctly put by Charity Majors here:

What to Do?

Here I discuss a few things I did to try and change a culture a few years ago in a demoralised and dysfunctional centralised IT team that I managed following the sudden departure of the IT Director.

Whether it worked or not I don’t know – you’d have to ask the team (and I was poached a couple of months after I started), but I felt a big difference pretty quickly.

1) Get on the Floor

The first thing I did was spend two weeks doing triage of incoming requests. This had a few useful effects.

I saw one of the two main pipelines of work into the team

The IT team was working on 1) Requests received via tickets and 2) Out-of-band requests from management (“Can you just implement a new video conferencing system? Thanks.”)

Getting a handle on 1) was the shortest path to get savings fast, so I started there. Number 2) was going to be a tougher nut to crack (mostly finding ways to say ‘no’ without getting fired). Improving 1) would help with 2).

I discovered the triage process was broken

The triage process was not serving its purpose. It had been given to a weaker member of staff because no-one else wanted to do it, and he was not adding any value by thinking about what was being presented to him.

I put some controls into the process from above and moved the duty around the team.

The ticket count dropped by 75%

I cut the open tickets by 75% in a week by deduplicating and applying simple call queue techniques to the backlog. Dropping that number didn’t drop the work by 75% (probably more like 30-40%), but it improved morale and focus significantly. I also implemented some of the techniques talked about here to reduce running costs.

I was seen as someone who wanted to get involved

While I had to be careful not to get into the weeds, by getting my hands dirty my credibility with the team grew.

More importantly, I could start to challenge them when I didn’t buy what they were saying. They had become used to pulling out certain excuses for failure. This wasn’t because there were not good reasons, but because they had felt ignored for so long they had stopped trying to engage openly. That culture needed to change, and being able to argue from within was critical to achieving that.

2) Move People to Other Teams

One of the things I’m absolutely certain of is that a critical feature of effective complex organisations is that they make people do all the jobs.

Only when people have seen things from all angles can they make real and effective adaptations to changing circumstances or effect real change within a complex organisation.

There’s an incredibly powerful talk here by John Allspaw where he discusses how the Navy does this to help solve the challenges aircraft carriers face:

‘So you want to understand an aircraft carrier. Imagine a busy day, and you shrink San Francisco airport to one short runway, one ramp, and one gate. Make planes take off and land at the same time at half the present time interval, rock the runway from side to side, and require that everyone that leaves returns that same day. Make sure the equipment is so close to the edge of the envelope that it’s fragile, then turn off the radar to avoid detection, impose strict controls on radios, fuel the aircraft in place with their engines running, have enemies in the air and scatter live bombs and rockets around. Now wet the whole thing down with salt water and oil and man it with 20 year olds, half of whom have never seen a plane close up. Oh, and by the way: try not to kill anyone.

(See 19 minutes in for this part of the talk.)

I made the IT staff go and sit with the developers for a couple of weeks as soon as I could. The resistance I got to this idea, even among the keen ones, was deeply surprising to me. There was a profound tendency to put others on a pedestal and fear humiliation by going outside their comfort zone.

The results, however, were immediate. Relations between teams improved dramatically, and areas of tension that had been bubbling for years got resolved as IT staff had seen things ‘from the other side’, which changed their view of why blockers should be removed, and – equally important – how they could be removed by more creative means that the ‘other side’ could not see. Once staff saw the drivers of frustration, they could implement solutions for the problem itself, and not necessarily what was being asked for.

3) Remove Bad Influences

People don’t like to talk about this, but one of the most effective ways to change culture is to fire people.

There’s a probably apocryphal story about an Orson Welles trick, where he would get a stooge to show up to work on the first day on a shoot, do something Welles didn’t want, and Welles would fire him.

The message to the crew would be unambiguous: my way, or the highway.

That’s obviously an extreme example, but I’ve seen the powerful effects of removing people who are obstructing change. That doesn’t mean you don’t follow due process, or give people clear warnings, or help them to mend their ways, but nothing sends a message of ‘I disapprove of this bad behaviour’ better than dealing with it firmly.

And check point 6 on this deck about Jeff Bezos’ mandate to change the way Amazon worked:

Anyone who doesn’t do this will be fired.

One of the first questions I generally ask myself when considering the latest attempt from on high to bring cultural change to my group is: what changes here that gets me fired?

4) Take Responsibility for Hiring

As with firing, who comes into the team is vital. I was shocked to discover that it was not considered standard to have the overall manager personally vet new hires.

While I didn’t know my Active Directory from my LDAP, I did know the difference between a bright young thing and an irritating know-all, so I took responsibility for any new hires. I deferred to my colleagues on knowledge calls, but that was not often a deciding factor either way. Far more important was how useful they would make themselves.

5) Take Responsibility for Training

There’s a great quote from Andy Grove, founder of Intel about training:

Training is the manager’s job. Training is the highest leverage activity a manager can do to increase the output of an organization. If a manager spends 12 hours preparing training for 10 team members that increases their output by 1% on average, the result is 200 hours of increased output from the 10 employees (each works about 2000 hours a year). Don’t leave training to outsiders, do it yourself.

And training isn’t just about being in a room and explaining things to people – it’s about getting in the field and showing people how to respond to problems, how to think about things, and where they need to go next. The point is: take ownership of it.

I personally trained people in things like Git and Docker and basic programming whenever I got the chance to. This can demystify these skills and empower your staff to go further. It also sends a message about what’s important – if the boss spends time on triage, training and hiring, then they must be important.