This is a guest blog from Michael Kren. Michael is a DevOps Manager at JAMF Software, which makes software that helps IT teams manage their Apple devices. This is part of a blog series about how he started a culture of DevOps at JAMF Software, how he built up the team, and what tools that they use. To read the first in the series, check out DevOps case study: why we have DevOps at JAMF Software.
This is a guest blog from Michael Kren. Michael is a DevOps Manager at JAMF Software, which makes software that helps IT teams manage their Apple devices. This is part of a blog series about how he started a culture of DevOps at JAMF Software, how he built up the team, and what tools that they use. To read the first in the series, check out At JAMF, we’ve always had a GSD (get stuff done) attitude, but we were running into the same challenge most teams hit when they are trying to build too much, too quickly: everyone was trying to do everything, and it just wasn’t sustainable.
We knew we wanted to transform into a true DevOps team, adopting a DevOps culture — but our old ways of working were pretty entrenched, and change can be difficult.
The biggest fear we had to overcome in the beginning was that we might eventually automate ourselves out of our jobs, and straight into the unemployment lines. So I mentioned that fear to my boss, and he told me what has now become my biggest mantra for implementing DevOps successfully:
Automate yourself out of a job. We’ll give you another one.
If your team members exert all their energy trying to keep their jobs exactly the same, instead of embracing improvements, it might be time to make a few roster changes. In order to truly build a DevOps Team, you first need a DevOps culture — and that means one that embraces creative and smart approaches to automation and efficiency, and rewards the teams and individuals who uncover them.
In this case, “reward” means giving them new roles and responsibilities. You want your team to be looking for smarter ways to work — and if what’s discovered happens to create job redundancies, don’t worry – there are more jobs awaiting the same treatment.
You may have one or two teammates who don’t make the cut, because they can’t adapt to the new ways of thinking and working. That’s totally normal, and it doesn’t make them bad at their jobs — just not the right fit for the task at hand.
In my free eBook on taking JAMF from zero to DevOps, I cover the hiring criteria I use to find people who will thrive in a DevOps culture. For starters, though, I always look for people they can do my own job even better than I can, so our DevOps team is always getting smarter.
Some things we look for in a nutshell:
- Can do my own job better than myself
- Motivated laziness: Smart enough to figure out easier and automated ways to get manual jobs done
- Willing to spend the time to get work done right
- Not afraid to automate themselves out of a job
- Someone who brings change and thrives in it
The last is the most important. Sometimes painful change is needed in order to truly deliver the best value to the customer.
DevOps team structure counts — but it isn’t critical
I’ve been asked a lot about team structure, and the roles and responsibilities. At JAMF, we have 120 people in our engineering department, and only five on what we call our DevOps team. I lead the team, plus we have three more DevOps engineers and one Release Manager.
But here’s what I really say about DevOps team structure: If your team members are truly focused on automating themselves out of their roles, structure will change. There is no one-size-fits-all.
Our team is responsible for all the following things:
- All things Docker, since about everything our team does goes through Docker
- Bamboo / build administration
- JIRA administration
- Release process and compliance of that process
What works for JAMF might not be right for you, since you build different products, serve different customers, and have different resource allocations than we do.
In short, if the entire team is actively (and successfully) adding smarter, more scalable automation, you don’t need to worry about the ratio of developers to DevOps engineers. The work will motivate you to build efficiency at massive scale. So don’t wait for the perfect org structure. Just dive in and start doing, and you will find the right rhythm for your team.
My biggest takeaway, though? Start with your culture before you add new tools. No amount of tools or process improvements can make up for a deficiency in how you work together.
Want the full story? You can download the free ebook, in which I cover all the details of the journey to DevOps at JAMF.
Did you find this post useful? Share it on your social network of choice so others can learn more about how to start thinking about DevOps at their company!
The post People shock: building a DevOps team and culture appeared first on Atlassian Blogs.