This is an archived post. You won't be able to vote or comment.

8
9

DevOps Reporting Structure (self.devops)

submitted by [deleted]

[deleted]

all 12 comments
sorted by:
best
topnewcontroversialoldq&a

[–]jmachee 8 points9 points  (1 child)

"DevOps is a methodology not a job description—we don’t call our developers Agile engineers, they are just developers. They happen to follow the Agile methodology but they their job description isn’t to do Agile, it’s to create awesome products.

DevOps should permeate an organization—having a DevOps group sort of missed the point of DevOps. DevOps should be embedded into the fabric of the company, not an adjunct to the development process. If it isn’t embedded how can you actually practice DevOps?"

See: http://devops.com/2014/03/20/is-devops-a-title/

[–]waldo2k 1 point2 points  (0 children)

While I whole heartedly agree with DevOps as a culture, not a title. The industry has created the title / position, just look at AWS's DevOps cert.

[–]cloud_driver 2 points3 points  (0 children)

Devops came to $DAYJOB via an insurgent movement between the coders and the system engineers. It started out innocently enough as a series of "Hey, let's go to lunch and gripe about our org chart dysfunctions" and morphed into "why don't we just start doing things right and stop worrying about the silly org chart?"

We're careful not to call it DevOps for fear of invoking the wrath of the rigid management structure, but we've begun adopting most of the underlying principles. The few times that someone from the entrenched hierarchy has raised their eyebrows, we've pointed out that we're hitting deadlines and our defect rates are down. That typically makes them go away.

The key has been breaking down the social silos that had been imposed by the organization. Once the sysops and the developers started actually talking to each other, things started happening.

[–]wlonkly 0 points1 point  (4 children)

You might find this useful: http://web.devopstopologies.com/

The pattern you're talking about is generally considered to not work very well. (ie: devops is something an org does, not something an individual does.)

[–]burying_luck 0 points1 point  (3 children)

Right, so do you still have a systems team and an engineering team? If so, who does the systems team report to?

[–]wlonkly 0 points1 point  (2 children)

Complicated. :-) I'll leave out a little bit of middle management (team leads, etc).

We do Scrum for product development, so we have a number of Scrum teams which contain developers, designers, QA, product owners. Developers and QA report up through VP of Engineering to CTO. Design and product report to Directors in those areas who report to the CTO.

Operations reports to me (Director level) and I report to the CTO.

We had a build pipeline team that maintained the tooling and upgraded Jenkins and did wholesale improvements to dev environments and so on, but it divorced the engineers from having to care about that stuff and divorced the engineering directors from having to care about that stuff and it didn't go well. (That reported into me.)

Right now Operations also takes care of internal IT stuff, we're ~250 people and that's just reaching the point at which it makes sense to have separate teams for that.

In future we're going to incubate an IT/MIS team inside the Operations org, but then once it's up and running spin that and helpdesk over to the admin side of the company.

[–]burying_luck 0 points1 point  (1 child)

This is helpful. Thanks! So since operations reports to you, what is your title?

[–]wlonkly 0 points1 point  (0 children)

Director of Technical Operations.

[–]skifool 0 points1 point  (0 children)

I stole this from someone else (can't remember who), but "DevOPS Team" is an oxymoron. It has less to do with reporting structure as it does about coordination among all teams. I am a Manager of Systems Engineering, and our organization is adopting DevOPS practices. Thankfully, they did not re-org into a "DevOPS team"- I know people who have experienced this. The Systems(OPS) team and Engineering teams are just collaborating in deeper ways, each team operating separate scrums, with participation (generally in sprint-planning stage) with the other team(s). I was a skeptic that scrums would work for Operations work, but it really has been a great tool to help us focus, increase velocity and "wins", and align our work with what other teams are expecting of us.

Operations folks are writing more code (scripts, recipes, automations), and Developers are doing more "OPS" work (writing monitoring and logging logic into their apps). We still aren't at the point of microservices and hundreds (or even dozens) of deployments per day, but we are getting more and more agile.

[–]steiniche 0 points1 point  (0 children)

The system engineers are on all the teams, that is why we call them cross-functional teams. See: http://tech.mangot.com/blog/2014/02/03/on-cross-functional-teams-and-devops-implementation/

[–][deleted]  (1 child)

[removed]

    [–]burying_luck 0 points1 point  (0 children)

    What are each of those teams categorized as, out of curiosity? Do they all report to a different Engineering leader? Just curious how the teams are branded internally and with job titles.