"The most important baseline skill for any position is communication. We want you to be able to explain what you mean; we want you to be articulate. That cuts out a lot of people, because a lot of people are probably pretty good technically, but if you don’t have excellent communication skills it’s going to be very frustrating for you and for other people. Other than that, then there’s just a core set of skills for the position.
We also want people who are reliable. It’s like, how often do you hear an excuse for something? They can be really great excuses, but if the last five times you were supposed to do something and you have a good reason for why you didn’t do it, then that starts to become troubling. We try to have the kind of a culture that doesn’t value excuses in the sense that when you’re supposed to accomplish something, and you’re at a high level, then your job is to accomplish it, in spite of difficulty. And you’re rewarded for dealing with that.”
Organizations must be selective about whom they put on the front line of the DevOps movement. First, team members should have some experience with operations. They should be familiar with the tasks, tools, and workflows that support applications and services. This will allow them to identify areas that are ripe for automation.
Team members should also be natural department straddlers — those people who can communicate with IT and developer communities as well as with lines of business. They should be experienced collaborators with a track record of working across traditional IT silos.
Zeroing in on these folks is important, because it also brings other departments along the DevOps journey.
Team members should also be prepared to specialize in automation. Automation is the only way businesses will realize web-scale objectives, so team members should understand they will build their roles and responsibilities internally around this function.
While collaboration and automation are the primary requirements, these team members will also require an appetite for continuous learning and improvement. No IT professional can be comfortable that her current skill set will suffice for the remainder of her career.
And there’s always room for improvement in the building, delivery, and operations of any application.
Aside from the talent issue, embracing DevOps also means changing the way the organization thinks about IT. It requires a shift away from IT as a firefighting team to one that delivers value to the business and its customers.
To jumpstart a DevOps program, you’ll need to pull a cross-functional team of DevOps ambassadors away from fighting fires and give them a special project: the company’s first automation project.
Internal support for automation and an appetite for a web-scale IT infrastructure should grow as this team demonstrates early successes and shares these outcomes with the organization as a whole.
So when you’re faced with a crisis, don’t blame the people who happen to be around when the crisis is made visible. Instead, look at the source of the illusion, look at the incorrect assumptions that were made, and get an understanding of how we managed to deceive ourselves for so long. You don’t prevent a crisis by developing a specially trained team to deal with the crisis when it occurs. You prevent a crisis by keeping things out in the open, by voicing assumptions and keeping them visible, and by actively preventing the illusion.
If there’s no illusion, then there can’t be a crisis.
“You work at one, or the other.
At the lab, the pressure is to keep searching for a breakthrough, a new way to do things. And it’s accepted that the cost of this insight is failure, finding out what doesn’t work on your way to figuring out what does. The lab doesn’t worry so much about exploiting all the value of what it produces—they’re too busy working on the next thing.
To work in the lab is to embrace the idea that what you’re working on might not work. Not to merely tolerate this feeling, but to seek it out.
The factory, on the other hand, prizes reliability and productivity. The factory wants no surprises, it wants what it did yesterday, but faster and cheaper.”
Fail as much as you can at Lab in order to have not surprise in the Factory.
At the lab, affront your solution to fail in all the ways you being able to imagine.
On production, keep thinking how to provoke your solution become easier and cheaper to manage.
Working on one or other means having quite different mindset.
The diversity of technologies, hardware, software, applications, networking, storage, cloud, dashboards, analytics, reports and reporting tools, mobile devices, data management, security, and what have you, each requires extensive effort to understand how they impact each other and then manage them effectively. I have yet to sight a person who had expertise in all of them; a team can collectively represent a potent unbeatable combination which when married with business will always succeed.
It is a fallacy to expect the IT team to give away their foundation of technology and embrace business skills only. To me it would be like choosing either work or life. Life gives birth to work and work enables a life. Similarly technology innovation opens new opportunities for business and new opportunities give rise to new solutions. I believe that a balance has to be found such that the two sides of the coin give different views to whoever is looking at it without compromising each other.
Technology needs business as much as business needs technology today.
Commodity based, e.g. Gold
Politically based, e.g. Dollar
Math based, e.g. Bitcoin
The other day one guy asked me how I keep updated regarding so many things. Immediately only one answer come to my mind: Twitter.
When I was a child (something that happened around the 70’s), my father used to told me that books will give me general or particular knowledge about an specific matter, but if I actually wanted to keep me updated the best material to read were magazines. Those were the days with no Internet. He also explained me that this happens due the long cycle needed to write and publish a book compared with the short cycle related to the same on a magazine. So If I read magazines, they could keep me updated in any fact that will appear published in books several months or years later.
Twitter has replaced magazines. If you are following the right person, Twitter becomes an awesome source of knowledge and news to keep you updated in your area of interest.
In some specifics areas like Information Technology, it is hard to understand why a smart IT guy is not actively using Twitter (meaning the right way of Twitter using, not only for fragile chats with friends or sports stars). There is no possible way nowadays of keep updated regarding the exponential rhythm of technology change if you are not watching through Twitter what is other doing, what’s new, how they have resolved the same problem that you have.
Keep this on mind, Twitter is a mind blowing radar to watch what is happening around you and understand why are we not being as awesome as them.
Staff who repeatedly violate the change management process are quickly assigned to roles where they cannot make changes. This is all part of having a true culture of change management.
All the high performers had a culture of causality, especially when resolving problems and repairing outages. This ensures that change is ruled out first in the repair cycle, and consequently, issues are resolved much more quickly. Furthermore, they were spending less than 5% of their time on unplanned work and service restoration, spending more time early in the IT lifecycle.
In each of the high performing IT organizations, the way that the staff implemented changes was not to first log into the infrastructure. Instead, it was to go to some change management board and ask whether the change should be made. Surprisingly, this process was not viewed as bureaucratic, needlessly slowing things down and decreasing the quality of life. Instead, it was viewed as absolutely critical to the organization maintaining its high performance.