On devops and team structure

So I ranted previously on flagrant abuses of the term devops. To summarize, devops is not a team name or a job description and it would be really great if everyone would stop using it as such. To me, it should be a term used to describe a culture or a mindset. It's harder to describe that than it is to just slap the devops label on one of your teams and call it a day. I just found this blog post by Major Hayden that defines devops as a mindset where everyone is responsible for the success of the customer experience. Ok, maybe that wasn't so hard to describe after all, but let's dig into that a little.

First, we have the customer experience. Ultimately, that's what your company or product is supposed to be about, right? (If you're only in it for the money and not because you care at all about the product or service you're helping to create, I really have nothing to say to you.) We shouldn't be so focused on our own salaries or personal glory or shareholder profits that we forget that what we're really trying to do is solve a problem for our customers. The problem a lot of people have with the so-called 'rockstar developer' is the focus on the rockstar part first and the developer part second. You aren't actually a rockstar. You're a developer, and you're supposed to be developing something that is ultimately for your customers.

Secondly, we have the idea that everyone is responsible. I've seen too many times situations where responsibility ends as soon as your part of the work is 'done': designers stop being responsible as soon as they hand their designs over to developers, developers stop being responsible as soon as the code goes from their dev environments into production. So a feature exists but it's so unstable it crashes and needs to be restarted dozens of times a day? Eh, ops problem now.

No. It's everyone's problem, because everyone is a part of the same company, and supposedly all working towards the same goal (the customer experience, remember?). This is not to say that all the devs should be doing ops and all the ops people should also be developers and everyone should be a designer or anything like that, because everyone has different skills and strengths and individual responsibilities, but what everyone has is a shared responsibility to the customer and the company.

In addition to responsibility, contributions can also be shared across team lines. As it turns out, people can actually have good ideas for areas that aren't their primary area of expertise or responsibility. Assuming that your company is hiring smart, talented people instead of just finding bodies to sit in chairs for so many hours a day, ideas for how to improve the customer experience could come from places where they might not be expected. Someone on the operations team might see customer-facing software crashes due to a bug that wasn't caught in development or QA. A customer support person might see customer confusion that could be remedied with a design change. We should be asking what can we learn from each other, and how can we use that to improve the customer experience even more.

At my current job, we're moving towards more vertical project teams (as opposed to 'horizontal' front-end, back-end, mobile, operations, etc). Teams with design, development, and even marketing and ops input are focused on a particular project or customer-facing feature, making it a lot easier to share responsibility (and a lot harder to say 'fuck it, it's someone else's problem'). Before, it wasn't always clear where responsibility ended, or who was responsible for getting something across the finish line, especially when iterating back and forth (such as between design and dev) meant that a feature went back and forth between different teams. With a feature-focused team, the responsibility becomes clearer, communication happens more readily, and there's far fewer cases of people getting distracted by other work.

It's taken some getting used to, as any organizational change does, but so far it's been an improvement, both making our customers happier (project focus instead of web versus mobile app focus means features get delivered sooner on both  platforms at once) and in making processes better for employees. More responsibility being shared means less things getting thrown over any walls, and that's pretty great.

So stop saying devops, and start focusing on working together to make things better for your customers.