Observe
Whenever you start a new Devops role or project, you'll generally be joining a team that are doing good work but for some reason they are being frustrated in some way, it is at this point you need to get stuck into an OODA loop, and your first task is to observe. So listen in meetings, have a beer with your colleagues, and sometimes even try to figure out what the hell the project your working on is and why your there in the first place, but observe, don't jump in and solve problems, or change things if you can, just Observe.
This is where you get the benefit of being stupid, for at least a little while, you get to ask the hard questions, the obvious questions. E.g. why do we do that, what tools do we use for this, what stopping us doing a thing, and most importantly where's the bar ?
Orient
Now before you even get started there are things that are going to get in the way unless you get buy in such as Product managers, C Level execs, developers, old etimes even try to figure out what the hell the project your working on is and why your thschool sysadmins, manual testers, basically everyone.
Why ?
Because you are likely going to be changing the way they work, what tools they use and they think it's going to either cause them extra work, or take away all of their work causing them to lose their jobs, and hell they've been their longer than you so what can you change that they haven't tried yet.
So how do you manage the transition,
Throughout my career as a sysadmin, developer and now doing devops, I've always asked a couple of questions, and it is these questions that always allows me to figure out what the best thing to work on at any time.
- What is your pain point ?
Most of the time people won't actually know what their pain points are, or they will think they are something different to what they actually are, but if you ask this question in every meeting, and in every conversation you will eventually find out what the pain actually is, in fact people will start asking themselves this question as well and maybe even fixing it themselves, but it could be such things as:
I can't get a new server quick enough ?
I can't do enough feature work.
I get called into too many meetings.
Our deployment time is too long.
All our environments are different.
Tests take to long to run.
- What takes up most of your time ?
This is usually linked to the above problem.
Decide
So how do we fix this in a Devopsy way ?
For me it's about using the 80/20 rule, basically if you can find out the 20% of the work that takes up 80% of the time/effort and automate the crap out of it so that it takes 1/5 of the time it used to take, you will have bought yourself a whole heap of capacity, in fact you will likely have reduced you workload by 80%, so of you go again and find the next area that is taking up the next 80% of the time/effort.
So one thing your going to be spending your time doing is trying to reduce the friction in your process, but your not going to reap the benefits straight away, this is because the benefits are cumulative, but they will come, of yes they will come.
Act
If I spend a day bringing an hour process down to 5 minutes then this initially doesn't seem like a benefit, and certainly not to a manager initially. But if this process is run once a week, I will break even after 2 months, and after that I'll have saved 44 hours in a year, or over a weeks worth of work, unfortunately your not gonna get that 44 hours given to you to take as additional holiday, but it does mean you have more time to spend of automating more stuff, and if anyone else has been doing the same process weekly, then you've saved them 50 hours as well, keep inverting in finding areas like this and it's the same as investing, the power of compound interest will make you happier devops, in fact Dev and Ops might even start playing together nicely now creating a devops Culture.
Conclusion
And because this is a loop we then start again, Observe, Orient, Decide, Act.
And keep asking the stupid questions, I guarantee 80% of the time they aren't stupid.
But mainly it's a culture thing, so from Wikipedia
In 1986, philosopher Edward S. Casey wrote, "The very word culture meant 'place tilled' in Middle English, and the same word goes back to Latin colere, 'to inhabit, care for, till, worship' and cultus, 'A cult, especially a religious one.' To be cultural, to have a culture, is to inhabit a place sufficiently intensive to cultivate it—to be responsible for it, to respond to it, to attend to it caringly."
So care for your Dev's, your Ops people, even the QA people, but also care and feed your systems, and you'll reap the rewards.
A lot has been said about the Phoenix Project and it is a great book and I recommend anyone interested in Devops to read it, but even more than this I recommend reading "The Goal" as what we are really talking about here are bottlenecks in development/operations process.
80/20 Rule : Pareto principle. https://en.wikipedia.org/wiki/Pareto_principle
Ooda Loops : Observe, orient, decide, and act. https://en.wikipedia.org/wiki/OODA_loop
Top comments (1)
I love the model of OODA loops, they can fit just about any situation, but they also are like orbits, with multiple loops all affecting each other each iteration.
Also a very useful model for being able to deal with the unexpected:
dev.to/iedaddy/how-to-address-tact...