Compartir a través de

DevOps, The Art of Walking in Someone Else's Shoes

  • Artículo

All engineering teams are set up differently.  In the Microsoft IT department, we have a set of Software Engineers that work on designing, implementing, and testing the software solutions needed to run the company.  We help deploy our builds, but most of the work of getting our new bits out to production servers and live for our customers is done by our Service Engineers (or the Operations team).  Lately, the buzz word around the industry has been DevOps and it’s starting to take on different meanings depending on who you talk to.  In my world, DevOps is used to describe the general team culture shift to having Software Engineers and Service Engineers (or Engineering and Operations) work more seamlessly together.  You can find similar meaning of devops on the Internet but I like this statement of its background:

“The old view… tended towards the “Dev” side being the “makers” and the “Ops” side being the “people that deal with the creation after its birth” – the realization of the harm that has been done in the industry of those two being treated as siloed concerns is the core driver behind DevOps.” (found here)

There are a lot of engineering excellence concepts that are dependent on this seamless relationship and collaboration, such as Testing in Production, Flighting & Experimentation, and Agile delivery.  So how do two teams get to DevOps?  Or sometimes we call it OpsDev to make sure devs don’t always get priority over operations.

Here are the two scenarios that you need to be comfortable with:

Speaking as a Software Engineer:  “I give my service engineer access to my source code.”
Speaking as a Service Engineer: “I give my software engineer access to my production servers.”

Simple statements, but there are a bunch of things behind those phrases to consider and that’s why a team who isn’t truly practicing DevOps will feel uncomfortable with these statements.  The biggest hurdle is the distrust that may exist between the two teams.  Trust is formed once there is a relationship built that makes you think of each other as people with good intentions and not as coworkers only concerned about their own work.  You need to talk to your Software or Service Engineer counterparts and get to know them and find some common interests and goals.  As the trust starts to build, find out what they do in their jobs and what they struggle with.  Spend some time walking in their shoes.  It will be an enlightening experience.  What you may find is that Software Engineers don’t think beyond the features created and don’t think about how to deploy the code more easily or how to make it more supportable when it goes live.  You may find that Service Engineers don’t think about how design changes could help make their jobs easier or about how their opinions during planning can make the release go smoother.

Once you understand each other and have built some trust, it’s time to show your vulnerabilities and ask for help and training.  Actually, to build trust, you may want to show your vulnerabilities early.  So here are some questions you need to be asking:  What skills do both teams have?  Do the service engineers know how to write code, not just scripts but code in higher level languages you may be developing your features with?  If not, teach them.  Or you may be surprised and find out that they do already code very well.  Most people in the computer industry, no matter what job they are in now, started out as Computer Science graduates.  What about the Software Engineers?  Do they understand all the nuances of a production server?  Do they know how load balancers work or how the network is set up?  Do they know what services are running on the servers and why?  I am a manager of Software Engineers and I would be concerned giving some of them full access to production servers without first giving them training around system level settings and configurations.

There are a lot more things to consider as you navigate through the new world of DevOps, but focusing on these two scenarios, their current discomfort, and the ways to start building trust and gain knowledge of each other’s space will help move your team in the right direction.  It is a cultural shift and you’ll find that you don’t know what you don’t know.  So try to walk in each other’s shoes.  At first they won’t be the right size, but over time they may be the most comfortable shoes you can wear while delivering software.

Comments

  • Anonymous
    March 01, 2015
    Great information. Thanks Anita !