[prawks]

> Putting developers in charge of not just building an app, but also running it in production, benefits everyone in the company, and it benefits the developer too.

How do companies which do this keep the support workload of developers low enough so that they have time for development? It's a great idea, because as the linked interview with Wener Vogels proposes, it creates a developer that has more frequent contact with customers. I suppose eventually you have to shift resources around to start other projects, but then who supports what they're leaving? Even in large teams, eventually expertise will dwindle until you're adding new people to support an existing system.

[dasil003]

It's about striking the right balance.

I don't really agree with the original totem-pole idea that devs can do anything QAs and ops can do. While it may be true that a good dev is capable of muddling their way through any challenge because they know how to get around the numerous blocks thrown up by technology, there are definite skills to QA and Ops that developers may be lacking and which will lead to the dev being a poor substitute.

That said, I think devs have skills which are applicable anywhere in an organization. This goes back to the virtue of a programmer being laziness. Being able to see how to build systems and automate things is something that is potentially useful everywhere. In the cases of ops and product support, there is an especially large amount of value from having devs poking their head in from time to time to pick off easy targets for improved automation, reporting, logging, or what-have-you.

[bmj]

It's about striking the right balance.

Yes. My company has tried for a good many years to keep product development partitioned from operations. We build stuff, through it over the wall, and let the ops team deal with it. Certainly, we give support where necessary, but it tends to be grudgingly given, and we never actually track time spend doing that support. I've been pushing, along with several other developers, that we at least need some sort of rotating product support team so we can work with ops to resolve problems in the field without disrupting our own timelines. We've moving in the right direction, but there's a lot of inertia to overcome.

[sagichmal]

    > How do companies which do this keep the support workload  
    > of developers low enough so that they have time for 
    > development?

Development and operations are not distinct things. A novel algorithm, say, needs to be run to be useful, and the developer is best-equipped to shepherd his or her code through a production environment.

Of course, that's distinct from tier-1 customer support. "Devops" doesn't normally encompass client interaction.

[supine]

The concept of "everyone on support" is practiced in a lot of orgs, with varying implmentations (e.g. "one whole day a month", "one whole week per quarter", "one week of half days per quarter"). What works for your company depends a lot on it's current workflows and workload, how long support cases tend to last for. Most mentions of it refer to his post = http://signalvnoise.com/posts/3676-everyone-on-support