culture

Stop creating Ops teams!

Blog, , Leave a comment

I really thought we had fixed this. I was thinking of retiring Next Gen DevOps because it was out of date having been published 11 years ago. Sadly it isn’t. If your development teams need to beg for favours from your ‘platform team’ in order to get things done then you’ve recreated the nightmare of the Ops team. If the term ‘beg’ offends you then feel free to substitude the term ‘agree priorities’.

In this post I am going to give some helpful advice about how to enable your development teams to get to production without any blockers AND minimise their toil AND ensure your infrastructure is built safely and securely and in compliance with all your companies standards.

The key to enabling the development teams is to free them from things they don’t need to care about in order to ensure the quality, performance, availability and security of their applications. Equally the key to having a platform team that can enable the development teams while also ensuring infrastructure is built securely and compliant with all company standards it where to draw the line. On Amazon this looks something like this:

  • Creating the VPC
  • Creating all the subnets
  • Creating the Internet Gateway
  • Creating the NAT Gateway
  • Mapping the public and the private subnets
  • Creating all security groups
  • Creating Policies
  • Creating CloudWatch Log group
  • Creating secrets using secrets manager
  • Creating Parameter Store
  • Creating Load Balancer
  • Creating Target Groups
  • Creating Listener
  • Creating ECR Repositories
  • Preparing the docker images
  • Creating IAM Roles and Policies
  • Creating ECS cluster
  • Creating ECS task definitions
  • Creating ECS services

The items above the line are global cloud configuration, cost management controls and should be owned by the platform team. The items below the line are application specific configuration and should be owned by each application team.

This split should be agreed and regularly reviewed by the engineering community as a whole. If items below the line are seen to be toil, by the application teams then they need some training to teach them how to reduce that toil for themselves.

As with security we trust but we verify compliance with company standards. These should be tested by running scripts and using AWS Anomaly detection.

One of the key points I make in Next Gen DevOps is how the concept of operations teams went wrong because they had different priorities from the teams building applications and generating revenue. That point is just as valid for Platform teams today as it was for operations teams ten years ago.

If you’re an Engineering Leader and you are considering creating a platform team pay close attention to what their priorties and motivations will be. If they are ostensibly motivated by safety and cost control and your application teams are motivated by revenue and experimentation then you’re going to have problems. You have one team pulling and another pushing. If you want some help thinking through this and aligning the priorities then get in touch or buy the book.

Life at 50!

Blog, , , , Leave a comment

I’m writing this in the days immediately preceding my 50th birthday. It’s common for people to engage in some self-reflection when they hit the decade birthdays. Usually mine revolve around my achievements. Did I achieve enough over the last 10 years? Did I change what I wanted to change? Am I proud of what I’ve done? Have I helped people? What comes next?

I’m writing this post, in part for me, as all blog posts are, but in part for the people younger than me. I want to share something with you that I think would have helped me as I approached 30 and 40.

Systems over goals

A key to my philosophy is systems over goals. Throughout my life I’ve found goals stressful and demotivating. I used to think that was a weakness in my character or a lack of discipline and I spent years beating myself up about that until I decided that they just don’t work for me. So instead if I need to achieve a goal I work backwards from that goal and ask myself what routines, systems, tools, teams, processes, etc. do I need to have in place so that if I work everyday that goal gets achieved as a natural consequence of my routines. That unlocked an enormous joy in achievement for me. So if you’re someone who hates goals consider that approach.

Job titles are less important than achievements

Job titles are less important than what you do. When I was 30 I wanted to be a CTO. I thought of my career as a ladder I needed to climb. I thought that the level of influence I wanted to have required me to achieve the highest position. At the time, in 2004, I saw that CTOs were often from a Telco background, or if they had done software engineering work it was usually in a pre-internet context and they weren’t focusing sufficiently on quality, system design and live service operations. This is why every launch was bad and organisations were optimising too late after they had already lost customers and damaged their reputations. Some things happened, I learned some things about myself and about what’s expected of a CTO and I realised that it wasn’t the right role for me. After a lot of soul searching and thinking I realised that I could achieve my goal of improving quality and systems in a company and across the industry without the need for a CTO title. The important realisation was that I focused on what I wanted to achieve as opposed to focusing on a job title that freed me to use my creativity to figure out how to have that influence that I wanted.

On reflection…

Having provided a little free advice allow me the indulgence of a little public self-reflection. Stop reading here if you’re allergic to cringe. I am really happy with what I achieved in my 40’s. I helped British Gas with their public launch of Hive, I helped the DWP with their DevOps journey, I helped Just Eat improve their reliability. I sold a few thousand copies of Next Gen DevOps (which is more trouble than it’s worth from a tax perspective but I hope I helped at least some of those people on their DevOps journeys). I switched my focus from DevOps to digital transformation and I helped Zoopla build their new tech stack. For the last 2 years I’ve built a team of permanent consultants here at 101 Ways and am mentoring and coaching my team, helping them grow in their careers faster than I did. It’s been a pretty good decade. Also I am thankful everyday for the NHS. Arthritis and diabetes hit me like a hammer during lockdown and thanks to the amazing NHS consultants, doctors and nurses I am pain free and fitter and healthier than I’ve ever been.

Super Doer

Blog Leave a comment

If you’ve just achieved a Head of, Director or VP role then congratulations! You probably earned that role because of your performance in your previous role. The problem now is that you’re being asked to do things you haven’t really done before and probably haven’t even seen done very often.

An individual contributor is surrounded by people doing a similar job that they can look to for guidance. A new manager has seen management up close for at least a couple of years. In addition to that managers will usually receive some form of guidance from human resources to help them manage their team. In contrast a new leader may not have seen leadership before. In most departments there is usually only one head of, director or VP and Individual contributors and managers never see them work together. There is very little training available for leaders. There are coaches but they aren’t always made available to new leaders.

Being a successful leader requires a different set of skills and approaches than being a successful individual contributor or manager. Being the best engineer, delivery manager or product manager in your department is not going to make you a successful leader. If you find yourself telling your people to give you what you need to let you write that document, or code or create the plan then you have fallen into the trap of the Super-doer.

In your 1:1’s, your boss may be telling you that they don’t want you to do the job they want you to lead your department. You probably think that the best way to do that is to protect your team from all the pressure you’re experiencing. You’re probably working late and sometimes on weekends in order to get the job done. If this is you then I’m afraid  you are a super-doer, not a leader.

The best description of the role of a leader I ever heard was: To create an environment where the teams can be successful. That is a great test to determine if you are leading or doing. If you are explaining what good looks like, encouraging your people to try and achieve it and you are praising good behaviours, you are creating an environment where people can be successful. If you are frustrated that your people aren’t doing as good a job as you would and you’re taking the work off them and doing it yourself then you’re doing it yourself, you’re not leading.

I know the work is very important. I know the future success of the organisation depends on it being just right. That just means you need to do as good a job as you can of explaining what is needed and ensuring your people have time to do the work, that they have the support they need and that you can work it through with them and guide and, if absolutely necessary re-write the executive summary ;).

When you lead teams well there is a joyous virtuous circle. Not only is the work done well, but you get to help your people grow and experience their excitement as they learn and contribute. All the praise and the glory you heap on your team comes back to you and you get to do that for every team in your department. It’s an incredible feeling. When you are failing to lead your teams well you will feel the burden of all of theIR work, as though it’s all on you so you try and do it and there aren’t enough hours in the day. Your team will seem sullen and frustrated and they may even seem to be working against you.

If you feel like you are failing as a leader then congratulations you’re in good company. Every new leader with an ounce of self-awareness feels that way. The question is will you try and learn how to do it better?

DevOps: What comes first the culture or the collaboration?

Blog, Leave a comment

Much has been written on the subject of corporate culture, more has been added since the advent of DevOps. Luminaries such as Patrick Debois, Gene Kim and Jez Humble all talk about DevOps and Culture on a regular basis. Every organisation I’ve worked in has been obsessed by it’s culture. After 20 years in small startups and global enterprises I’ve come to the conclusion that culture isn’t something that can be controlled, measured or managed directly.  This gives me a great excuse to paraphrase one of my heroes the late great Sir Terry Pratchett: “THEN TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF CULTURE…”

Culture is created as a by-product when we work and play together, the nature of our culture is determined by our purpose and habits. A group that is encouraged to learn from failure and improve as a result will be curious and innovative. A group that only looks inwards for help and is discouraged from interacting with other groups will become defensive and narrow-minded. Groups have a tendency to reach out to other groups when they can speak the same language and have the same goals. Groups tend to become defensive when they perceive they have different or opposing goals to the groups around them, they take on a besieged mentality when they don’t even share terms of reference with the groups around them.

If you want to change a group’s culture you need to change how they work together, how they work with others and the habits they share. If you want a culture of innovation you should expose people to foreign ideas and concepts by creating the opportunity for groups with different skills and perspectives to work together on proposals that will become new projects. If you want a collaborative culture you should create the projects that require people with different skills and perspectives to collaborate.

As far as I can tell, there are currently two successful DevOps models. The directly collaborative cross-functional team model that encourages groups to work together to deliver services and the Service/API model that encourages groups to have rapid, predictable interactions by presenting APIs to each other. If we want collaboration we must break down the silos and allow engineers with different expertise and perspectives to work together. Consider a monitoring/feedback project where software, operations and test engineers work together to delivery better quality tests and monitoring. If we want groups to communicate with each other’s services via API calls we need to ensure all groups have the resources necessary to create good quality API’s. That includes Network, Operations and Test functions as well as focusing on the APIs between services and between clients and services.

The choices we make about how our teams work each day, the things we encourage them to do in the morning (whether we encourage them to check out the quality of the service or just look at their teams project progress) how we encourage them to behave when they make a mistake all contribute to the culture we create. We choose our culture when we decide how our teams work together and what we ask them to focus on and the opportunities we present them to learn, grow and receive recognition. In my experience DevOps happens when the opportunity exists to collaborate.

DevOps accelerates the rate at which the opportunities to collaborate present themselves. When I joined Playfish the Operations team existed as a service provider to the game and platform teams. Operations then built a few tools and shared the code with the games and platform teams and that created a few opportunities for operations and software engineers to work together. As those collaborations yielded more and more interesting and valuable results the level of collaboration increased as did the quality of the service that was provided. This then made more software engineers curious about operations and that yielded more opportunities for collaboration and learning until we had some teams that were almost entirely self-reliant for their regular day-to-day activities that made more space for greater levels of collaboration and so on and so on…

I write a lot more about how to build and foster collaboration in IT organisations in my book Next Gen DevOps: Creating The DevOps Organisation. Available on Amazon now.

*Image credit: Yoel on Morguefile