Interface with development department - any best practices?

Question

Our sysadmin/operations team does both development and normal operations today. But development tasks always suffer when there is any operations tasks that needs to be done. To remedy this, we're considering to split in two groups - development and operations.

We'll be very careful not to drain the ops department for anyone who can code, as we think its very important that sysadmins are competent programmers too. But we need to dedicate some people first, and then start hiring dedicated programmers.

But I need some advice on how we should structure this. Any tips/best practice on how we should do the split, and especially on how the interface between ops and development should be?

Thanks =)

Answer 1

BE CAREFUL!

You need to be very clear what you are trying to accomplish. If this is about trying to get more development work done with the same number of staff, changing titles won't do the trick. To do that, you need to reduce the operations work and/or increase the development productivity.

I would avoid restructuring or changing roles at this point. I would instead make changes around reducing operations work and increasing development productivity.

May I suggest ...

1- Measure where time is going. There are typically three "flavors" of work in this kind of environment: urgent support, minor development (i.e. small enhancements), and pure development. You need to know how much time is being spent on these. Do not trust your own estimates .. they are probably way off.

2- Designate a primary support role, and have that role rotate among the staff. The current "primary" is tasked to catch support issues and deal with them, leaving the rest of the staff free to work on projects. The idea is to give the staff more uninterrupted time for development, which should help productivity.

3- Implement a ticketing (i.e. issue tracking) system if you don't already have one. Press users and your team into using it, and make the team keep it updated.

4- Be open and clear with the groups you are support about what you are doing and why you are doing it. Push back on them about needless requests things and overblown urgency.

Once you have more data and have made some changes, then you can make better decisions about "structural" changes. If you do decide to split your team, you will likely have more data about which person belongs on which side of the wall.

Answer 2

Do your best to keep the synergy between these teams flowing. Make sure you plan some good team building activities outside of work. Watch out for behavior that will cause the teams to go into silos (such as "Those dam developers").

I would create a good communication plan for the teams that defines roles and responsiblities for the two groups. It would also define how the groups should communicate (i.e. team meeatings, deployments, documentation, ...).

Try to identify all of the interefaces between these teams and make sure there are good processes in place.

Answer 3

Splitting the teams is best - reactive operational work is very toxic to development productivity. Developer's stock-in-trade is uninterrupted concentration and a mixed operational workload is disproportionately disruptive to the development work.

Some ways you might encourage team cohesion:

• Keep some development resources attached to the ops team, responsible for automation, some bug fixing work on systems they are familiar with and possibly smaller changes or development projects.

• Keep the teams in the same physical area so they are socialised together.

• Regularly swap people between the teams - some people in each team should have spent at least 1-2 years in the other team. For example, try to get developers to do some time as a DBA (and pay them an on-call allowance if they are on call - you can be perceived as using a junior developer as a cheap DBA!).

• Have an architecture workgroup that has people from both teams. This group is not necessarily full time, but does things like build and configuration management infrastructure, DB architecture/development work that sits in the gray area between development and operational DBA work and web/application server configuration, particularly where this affects development.

• Encourage (and make time available for) people to do seminars or papers on topics of interest, such as applications that they have built or aspects of network infrastructure pertinent to development (e.g. how to set up a Weblogic server with a reverse proxy).

• Try to involve both teams in peer review processes.

• Integrity, Integrity, Integrity. Anything to avoid a finger pointing culture. For example, where there is a serious issue do some sort of post-mortem or root cause analysis. If appropriate, get someone to do a technical seminar on the solution.