Yes Chef! How to Build a DevOps Team

Let me put that another way - it's never a good idea to put a project manager in charge of a DevOps team; these are engineering teams, requiring an engineer to be in charge. Even if the team does no software development, which is often true for teams that test, deploy and run off-the-shelf systems, an engineer, ideally a test engineer, should still be in charge.

The “project manager” role is akin to “catering manager” in the kitchen of a luxury hotel. Junior engineers (dev, test, & ops) are the prep-chefs, skilled but still learning their trade. Senior engineers (again, dev, test & ops) are experienced sous-chefs, well on the way to running their own teams. The lead engineer (of which there can only be one) is the head chef. The lord and master of all they survey, the one who sets the standard for junior staff to emulate but most importantly the one with whom the buck stops.

Project managers are the hotel's catering manager - enormously important to the smooth running of the kitchen but ultimately subordinate to the head chef. Without the head chef, nothing happens. Without the catering manager (who knows a guy with a grind stone), we have to sharpen our own knives. We hate sharpening our own knives, hence we love the catering manager.

Enough with the kitchen analogy - what roles do we find (in order of importance) in a successful DevOps team?

1. Customer

2. Engineer

3. Fixer

That's it. No, really, that's it. They're all you need. Call it lean, call it agile, call it some-bloke-who-lives-next-door-and-wears-cut-off-jeans-at-the-weekend, I don't care. The point being is the customer is king. Engineers fulfil the customer's desires, fixers deal with stuff that absolutely has to be done but engineers tend to be too highly strung and insufficiently diplomatic to deal with.

In "big corporation" land, the role names change slightly:

1. Customer Proxy (because the investment banker / airline ceo / consultant surgeon is kind of busy)

2. Engineer

3. Project Manager (because people like the title - I don't understand why, but acknowledge it is so)

Note that the order of importance is retained. The customer (via their proxy) is still king.

Teams with a great customer produce great software. Teams with a crappy customer produce crappy software. Teams with a great customer but a crappy customer proxy produce crappy software. Teams with a crappy customer but a great customer proxy stand a (slim) chance of producing non-crappy software. Teams with a crappy customer and a crappy customer proxy may as well give up now.

Teams missing one or more of these roles will absolutely fail. DevOps teams with no engineers will fail. Teams with no customer proxy will fail. Teams without a project manager will fail. These three roles form a complete and sufficient set. You need no other roles, but neglect any one and your team will fail.

What do people in these roles do?

Customer Proxy

This is the customer's representative and usually represents multiple customers. There may be a bunch of these guys/girls representing many customers - in which case you need a lead customer proxy as someone has to arbitrate and have final say.

Customer proxies have a constant, two-way conversation with the actual customer(s) and are the only people who create top-level stories (sometimes called "Epics") in the story management system. Following consultation with the real customer, they are also the only people who prioritise top-level stories in the team's backlog.

When an engineer needs clarification of some sort from the customer, the customer proxy takes it on their self to find the answer and report back to the engineer. Usually only a small number of these (ideally just one) per team is necessary.

If we continue the hotel kitchen analogy for a moment, the client proxy is the maître d', the consummate professional. He understands his customer’s wishes almost before they do and possesses an uncanny knack for articulating them in an unambiguous, prioritised fashion. This paves the way for the head chef and their crew to do their very best work.

Fixer/Project Manager

When an engineer has a request along the lines of "I need accounting to assign a new project code for us to bill this work against", or "my laptop just died, I need a new one", or "those guys in cloud support are jerks, I need someone to whack their supervisor with a baseball bat" - the fixer is the one who steps up to the plate and makes the problem go away.

Teams with great fixers produce great software. Teams with crappy fixers tend to start fighting amongst themselves and fail to produce any software at all. The number of fixers you need per team is proportional to the size of your company; the more bureaucracy your organisation wallows in, the more fixers you need.

Engineer

Lead software engineer, junior test engineer, senior database engineer, apprentice sanitation engineer; I don't care. If your business card says "engineer" on it somewhere, you're one of these.

So if you're not an engineer (or customer, or fixer), please, get off my DevOps team.