devopsy.kinsta.cloud

Tag: job title

  • Yeah, You’re Doing DevOps

    Yeah, You’re Doing DevOps

    The Stack Overflow annual survey of developers came out this month, and it has a lot of interesting data points in it. There is a lot that I wish was different about their questions/methodology, but one thing caught my attention. Docker, Kubernetes and similar tools (Ansible and Terraform are in there at lower percentages, for example) make up more of the responses than can be accounted for by people with “DevOps” in their title.

    Sometimes by a lot.

    That means we have a fair number of developers that are doing DevOps, but who aren’t DevOps team members. Yeah, there are a few systems admins in the ranks of the respondents also, but not enough to cover the discrepancy. If every respondent that was in DevOps and sysadmin roles used Kubernetes, there would be just enough to cover the number of respondents that said they used Kubernetes “extensively” over the past year. It’s unlikely that all of them are Kubernetes specialists. And that doesn’t touch on Docker, with a whopping 40% of respondents saying they use Docker extensively. Any developer with recent experience can explain away Docker—though “extensive” is a bit strong for your average developer’s usage, it is becoming part and parcel of development, using containers to host dev environments, test, even build tools. And, of course, some deployments. But 40% is still a lot.

    So, if your title is developer, and you’re using deployment tools on a regular basis, go ahead and call yourself DevOps. That’s not the only criteria, but if you were going to pick one, the breadth that using deployment tools represents combined with the implication that there isn’t an ops person worrying about that type of thing makes “uses deployment tools” a good stand-in test.

    To the nearly 18% (20% of pro developers) of you using Yarn, I tip my hat. I used it for a couple of years early on in its life, and am happy to say I do not need to use it any longer. I assume your usage is not tied to Hadoop and that it has greatly improved over my 2015-2016 experience. Still, y’all rock, just by definition of using it to get resource scheduling down. It ain’t easy.

    Across the board, the number of DevOps/Ops tools that make these lists is amazing for a developer survey – nearly 9% of respondents use Ansible, and nearly 9% use Terraform. There is undoubtedly overlap, so the actual number that uses one or the other is less than 18%, but still, nearly one in 10? That’s huge. And that’s DevOps or Ops, not purely developers. Regardless of title.

    And that’s been a hallmark of development since the field took off—doing what needs to be done to deliver software. This is just another iteration, and you’re rockstars, regardless of title. You keep delivering apps that run the business—let them call you whatever they like. Money talks; titles are pretty much meaningless. Not like you’ll retire on a title, but bonuses or stock grants? Those you might retire on.

  • Why I’m Happy To Have DevOps Engineer In My Job Title

    Why I’m Happy To Have DevOps Engineer In My Job Title

    A recurring argument in the DevOps community is whether the word DevOps should exist within a job title.  Most people close to DevOps think it’s a potentially harmful anti-pattern which indicates a misunderstanding of what DevOps is all about.  A few years ago I agreed with this, but I’ve now changed my mind.

    Yes, DevOps is a culture, a mindset and all of those good things.  It is about how people work together much more than automation.  I also appreciate the argument that labelling individuals and teams with DevOps potentially introduces a silo where we are trying to solve a problem of siloes.

    With all of that recognised, I’m still more than happy to now call myself a DevOps Engineer.

    There were lots of job titles that didn’t exist 10 years ago.  Agile Coaches, Social Media Managers, Data Scientists and Mobile App Developers for instance.  Those fields evolved and there are now recognised experts in those fields who know how to apply the tools and help organisations be successful with them.

    DevOps is the same.  It is maturing as a movement and there is now enough specialist knowledge in the niche that people can build significant niche expertise, work within it full time, and even build long term careers as DevOps Engineers.   

    Definition Of A DevOps Engineer

    DevOps Engineers are the people who sit between or within Development and Operations and use automation across the SDLC to reduce the cycle time from development to production.

    These Engineers will bring knowledge across Development, Testing and Operations and help with gluing those areas together to ease the transition of code across them.

    They will have deep technical skills in tools such as Puppet, Chef, Ansible, Vagrant and Docker, and use these tools to help their organisations deliver better software, faster and more reliably.   They will also likely understand cloud and how to use infrastructure automation to leverage this to best effect.

    As important as the technical knowledge is what we call the ‘DevOps Mindset’ – a personality type and approach that can help the IT organisation move from traditional ways of working, break down siloes, and collaborate more effectively.  Technical skills alone do not make an effective DevOps Engineer.

    Why This Matters

    To me, this all sounds meaty enough to be a full time role and a career path.  Therefore, why shouldn’t it also have it’s own name to identify it by?

    I’ve always been pragmatic about this, but my main interest in this is how accepting DevOps Engineers as a job title might help to overcome the DevOps skills crisis – the huge shortage of people in industry who have this skill set and the fact that as an industry, we have still have no sustainable path to creating these people.

    By accepting DevOps Engineers as a job and a career path, I think the definition of one would become more concrete.  There would be more of a shared understanding over what it means, rather than savvy build and release engineers or system administrators re-badging themselves.

    More people could align themselves to DevOps Engineering and work towards obtaining this recognised skill set.

    Visibility of DevOps activities within the business would grow, and budgets would be created to support DevOps rather than it being an under the radar activity happening under other functional siloes.

    Training for DevOps Engineers might emerge, and one day, it might even end up as a University Level course.

    All of these things would help DevOps expand as a movement and practice in industry, which is ultimately a good thing for the sponsoring organisations and anyone who works in IT. Here at Contino, the more we interact with customers around DevOps, the more I realize this is the path things should take.

  • The Double-Edged DevOps Job Title

    The Double-Edged DevOps Job Title

    Last month at GWO in Atlanta I met Nathen Harvey with Chef. I liked his DevOps presentation, “DevOp With Me!”, especially how he used “Walk This Way” by Run DMC and Aerosmith as an example for how collaboration in a DevOps environment often ends up playing out. They literally break down walls in the music video.

    While not all of Nathen’s presentations are safe for work ( many include some explicit language. It’s safe to assume so unless clearly labeled otherwise) they are all entertaining and informative. I’d encourage you to check his stuff out, especially if you’d like to know more about how and why Chef and DevOps mix well.

    I asked Nathen if he minded me linking his deck and giving him a shout out in a blog post. I even promised to say nice things about him. The answer he gave me only reconfirmed he does really get it:

    Of course! (even if it’s not all nice things, as long as they’re honest)

    If I’m being completely honest I have to admit this changed the topic of this blog post. I liked the idea of setting devOps to music so much I was going to post a DevOps playlist. I may still write or talk about that another time. It ended up being pretty easy to think of other songs that would fit for one reason or another. It actually even makes for a decent drinking game in the right crowd.

    Instead I’m going to talk about the one thing I know Nathen and I  don’t see eye to eye on. Nathen’s an advocate for doing away with using the word “DevOps” to describe a role or a team. I, being a DevOps Engineer, strongly disagree with this perspective. When I asked Nathen about this he responded with a single question:

    Can you describe what you do without using the word DevOps?

    It’s true there are a lot of folks with the word DevOps in their title that are adequately described as a systems administrator or a build automation engineer. Coming up with job titles that don’t contain the word DevOps is also a decent drinking game in the right company. A good serious answer for me would be ombudsman or public advocate. I think KTLO (keep the lights on) custodian would also accurately describe how I’m earning a large part of my keep these days. Still, the job I interviewed for was DevOps Engineer, and for now I’m going to keep using those words to describe what I do. I like Nathen’s Socratic response to why we shouldn’t be describing people and teams with the word DevOps, but what I am doing isn’t accurately described by other job titles where I work. If another title is a better fit for the work you do where you’re at, then I would encourage you to take Nathen’s advice.

    The more common reason I’m given as to why I should have changed my job title on day one is really pretty disappointing. I’ve read more than once that I should be concerned that my head will be the first one on a pike should the devOps movement fail. This really isn’t a concern I have.

    First  of all, DevOps does work. I’m not sure who would dispute that the CAMS model for DevOps is made of things any organization should be trying to improve Kaizen style. I’d even say that improving Culture, Automation, Measurement, and Sharing together results in a sum that is greater than any of its parts.

    There are however places that aren’t ready to embrace the change needed for this type of improvement. I caught a quote from @filler when @RealGeneKim retweeted it last November:

    If you’re concerned about a lack of progress in echo chamber, go offer yourself up in a different forum. And bring cookies.

    Advice I took quite literally. I found a job with a DevOps title at a place that was actively trying to change. I regularly bring in food. Just this past week I baked six dozen toll house cookies from scratch for a DevOps round table meeting I hosted. Why? Because I genuinely give a damn. I want people to come to that meeting to listen and to share. People who are passionate about technology and have faith that there’s always a better path. This group should find such a round table conversation quite enjoyable. The cookies help us remember this is supposed to be fun. They help keep the mood collaborative instead of conflicting. Such a job shouldn’t be left to baked goods that have been sitting on a shelf for weeks. If I want the best from the people I’m working with then I should give them my best whenever I can. It’s often the smaller details that could be neglected or ignored without issue that are noticed and have a more lasting impact.

    Some of you right now are in an environment where the bigger details that are making life difficult for everyone are actively being ignored. You may have been told not to worry about them or that the real solution is for everyone to work weekends. This is garbage and you know it. Please do not change your title to something safe and hide under your desk while in the office. Be the change you want to see in the world. There are lots of opportunities to help organizations make this transition. Find one that’s a good fit for you and make the jump.

    My advice for businesses is to be very careful when you describe a position as a DevOps role. We know this to be a very specific thing, but if you’re simply shoving the word DevOps into a job title in an attempt to attract talent there’s a good chance you’re in for a rude awakening. The person applying for that position knows there’s always room for improvement. They know that any transition is going to cause some friction but are willing to work through it. They’re also not scared to rock the boat. So, if your organization is not ready and willing to collaborate as one big team it won’t take too long for your devOps staff to go somewhere else on their own. Threatening their job security in an effort to maintain the status quo will only accelerate the process. You may very well end up with a lower head count at the company picnic as warned, but if it’s because all of your talent moved on to greener pastures you’ve effectively turned a bad situation into a terrible one.

    If you’re a DevOp-er that has a work environment in that gray area between heaven and a coal mine I’d encourage you to push the envelope. Share your honest opinion with someone you know doesn’t agree with you. Set up a meeting to discuss conflicting perspectives diplomatically. Drop an F bomb in a conference room if it will wake the room up and get some blood pumping (use sparingly and with caution). Don’t expect people not to get upset. Instead, try really heard to shut up, listen to everything they’re trying to say and do your best to give them what they need. If DevOps is anywhere near your title then you have some responsibility in getting these conversations started. If your current employer didn’t know this when they used DevOps as an adjective then shame on them.

  • Defeating the irrational DevOps jobs displacement fear

    Defeating the irrational DevOps jobs displacement fear

    People are generally resistant to change, but when that change comes accompanied with the whiff of potential for job loss down the road you can count on gentle inertia to snowball in to out-and-out opposition.

    Unfortunately, as early misperceptions swirl around the DevOps philosophy, many in the ops world have gotten their backs up in fear that the automation that’s tied to DevOps will endanger their jobs.

    “I think it’s almost impossible to overstate the amount of angst that  DevOps creates in operations,” says Gene Kim, author of The Phoenix Project. “The big fear  in operations is that in order to get to lead times not in months, not to weeks, but to days, you can’t be  manually configuring servers, you can’t be manually reviewing things all of the time.  And so there’s a deeply held fear that these configuration management tools are going to automate everyone’s job away.”

    Now, to the degree that some within IT operations ranks rely solely on large vendors to set the course of their career track, maybe there’s some jeopardy there, Kim says, but competent and capable ops staff needn’t fear the automation reaper.

    “It’s a reasonable fear, but it is ridiculous at  the same time because we all have so much more work that we could get done if we had the time,” agrees David Mortman chief security architect and distinguished engineer for Dell Enstratius. “Doing things manually is negative value for most organizations.”

    And that negative value is having a direct impact on how IT services the business. In the mind of Shridhar Mittal, general manager of application delivery for CA Technologies, one of the big DevOps value propositions is that it helps IT from CIO on down to finally start to meet the pent up demand that the business has been clamoring for from the IT department.

    “I’ve yet to see a CIO tell me that they have more supply than demand. Why do you think the business is heading out to directly work with cloud vendors and doing their own thing? It’s not because the IT said no so that 10 people could sit on the sidelines,” he says. “It’s because these projects are added onto the list of 1,500 other things they got asked to do at once.”

    Mittal says that CIOs who are gung-ho for DevOps should be proactive about potential resistance from the trenches. This starts with open communication.

    “The first thing is start to educate staff that this isn’t about eliminating jobs it is about reducing that gap between demand and supply,” he says.

    And as IT leaders do garner more buy in, both they and operations staff will find that these workers actually become more indispensible rather than expendable through automation. DevOps allows workers that might have seemed lackluster to shine as rock stars because they’re more frequently doing higher value work.

    “Once you get rid of the garbage work or manual work, which is very time consuming and error-prone, you’re going to find that your engineering team is allowed to perform better,” says Nick Galbreath, vice president of engineering at IPONWEB.