By Rob Cleghorn, Chief of Engineering, ClearPoint

We’ve been lucky to get involved with many enterprise DevOps transformations across different sized businesses and industries over the last few years. One of the biggest challenges we find is culture. The world’s best Continuous Delivery (CD) pipeline delivering the latest in software engineering solutions (from check-in, building, testing, and deploying through to production in minutes) will be a waste of time if the culture of the team and its surrounding support structures aren’t aligned.

Management and C-Suite need to reimagine their roles. Once you realise that you work for the teams, not the other way round, the better.  In order to get a high performing software engineering team, we need a mindset of putting the team up on a pedestal. As Managers, Architecture, Security, Administration, we do everything we can to help the team go “faster and safer”.  You’re the unblockers, enablers and supporters, all working hard to help the team drive and iterate your digital products. All working towards the same outcome of delighting your customers.

We can split team culture into two broad categories of changes that need to happen:
1) inside the team and
2) outside the team.

Both are equally important.

Culture Changes Inside the Team

  1. Encourage the team to own their work through to customers.  Getting features from ideas to customers is a team responsibility. With solid engineering, test automation, infrastructure as code and monitoring tools, we need to cover all bases.  We build solutions that are robust, so we’re not being called up in the middle of the night to fix something. We have a clear understanding of our customers, their needs and the features we build, deploy and run for them.
  2. Yes it’s your job, JDI. Yes, there are boring jobs in every team and everyone needs to take this on the chin and work through them.  Anyone with an “it’s not my job” attitude fundamentally doesn’t belong in a high performing software team. Respect for team members means rolling up your sleeves and getting on with it.
  3. Make an effort to understand each other’s areas.  There are typically three areas of code being committed into the repository – infrastructure code, software application code and test automation code. Everyone in the team needs to get across the various areas of the codebase and understand and review each other’s work. Challenge, get things explained, understand and start committing to things outside your area.  Building empathy for the other team members helps guide our solutions to be holistically healthy. It’s great to see developers helping to refactor test or infrastructure code and build helper classes etc to help their teammates.
  4. Challenge each other. Positive open debate is healthy. Keep it on track, make sure you try to understand the other person’s view and realise you don’t always have to win, but you do have to get onboard. Jeff Besos famously summed this up with the term “disagree and commit”. Keep it healthy and respectful, egos are not welcome here.
  5. Mistakes are learnings, don’t hide them – share and evolve from them. Innovating with speed is a learning concept and things will fail, so make sure that as a team, we learn from these mistakes without blame. Focus on the future and how the team can move on and make sure we don’t let it happen again. Remember failure doesn’t necessarily mean we need to slow down – just that we need to evolve, as Charles Darwin realised, evolution is built on this very concept.
  6. A problem shared is a problem halved. Transparency with the team is crucial for building team trust. With trust comes accountability.  If you’re feeling like you’re not getting through a task quickly enough, it’s a moment in time when you need to share more, communicate more and as a team, you need to help more.  If the team is not shipping quality software, the team fails. Reach out for help and help those who need it without judging. If you’re way behind, don’t make it worse by not telling anyone.

 

Culture Changes Outside the Team

  1. Architecture, you’re in or out – One of the bigger changes with DevOps practices is the role of architecture.  In large enterprises, architecture can be complex, inconsistent and not designed for rapid change. There is a wide range of reasons for this which we won’t go into now.  However, the vision for future architecture should be clear and focused on being decoupled, and easy to change through automation. The Architect’s role is widespread and guiding teams to align to this future vision is a key part of the role.  Jump in too far however and you’ll quickly risk removing the one thing from the team we are trying so hard to build – accountability. How often have we seen developers talking about their solution in a detached way? eg. “I had to use this framework and it’s crap”Let the team decide the details and challenge them to align to the principles. If you want to get more involved with the details, then you’re in, you’re working with the team and you are committing code together. Anything in between is operating in the danger zone. Most architects aren’t accountable for delivery (though they’ll swear black and blue they are), so this is when we see maximum conflict. Architects have their perfect view of the world; the team, however, is working in the real world, with things like budgets and deadlines, things that some Architects often don’t need to consider. Remember your role is to help put the team up on a pedestal – you work for the team. Talk to the team and ask them how you can help and what level of detail they need – get in or stay out.
  1. Let the practitioners choose the tools – Noone knows better than practitioners what tools they need.  In construction, you wouldn’t get an architect walking around a construction site and telling the builders what tools they must be using, even if the architect was a builder once themselves or still builds things every now and then. This is the case in most industries, we usually see excuses like “well we’ve bought all these licences” or “we want consistency in tools across the enterprise”We’re seeing more and more that the tooling doesn’t matter, it’s the outcomes that do.  Focus on holding the team accountable for the ‘what’, and let them worry about the ‘how’. This approach is becoming widespread in leading software companies like Netflix, Google and Spotify. Tooling standards bubble up, they are not enforced top down.  Recently I was watching surfers in a reasonable swell off Maui, Hawaii, catching some awesome rides and the range of surfboards was crazy. I was watching them for a while but I couldn’t see any pattern between the board they were riding and the best rides. They all seemed to know their boards well and how to get the most out of each wave on them.
  1. Make sure Security is a team practice – Security is very important.  Teams need to understand and bake security into their design, code and infrastructure – this is fundamental in building quality software. If you’re a security specialist and you’re finding things that you’re not happy with, then it’s you who’s accountable for this state. It’s very slow and expensive finding security issues late in the cycle. Security needs to be coached and embedded in the team’s disciplines and automation practices. As a security expert, you need to do this, as well as support and grow the capability in the teams so you don’t end up being the one who kills the throughput. Shift it left and you’ll sleep better at night.
  1. Change Management process needs to evolve – Change management has its place. Remember it changes with DevOps and needs to be continually challenged. When impact is low and recovery is quick, we can mitigate risk in new ways.  Reed Hastings from Netflix recognised this nearly a decade ago and said “Good process helps talented people get more done, bad process tries to prevent easily recoverable mistakes. Rule Creep or bad process tends to creep in (preventing errors just sounds good). At Netflix we try to get rid of rules when we can, to reinforce the point.”

When was the last time your management/support staff around the team had a retrospective on how you can better support your software teams? Remember it’s a moving landscape and a culture that works well for one company may not work for others.  Keep trying new things, and whether you’re inside the team or outside supporting, don’t stop evolving.

Rob Cleghorn, Chief of Engineering at ClearPoint, has a passion for digital transformation, DevOps and Continuous Delivery, creating high performing teams and all things related to building awesome digital experiences. If you need help with your DevOps teams or Continuous Delivery initiatives, get in touch with us now.