Nach einem Organigramm und einer großartigen 1-Jahres-Geburtstagfeier, wurde es Zeit, den nächsten Schritt hin zu einem professionell aufgestellten Unternehmen zu gehen: Wir haben seit heute einen eigenen Personalchef – und der ist zu allem Überfluss bis gestern noch Betriebsratsvorsitzender gewesen…
Vor einem Jahr gründeten Michael Dombek und ich, Karsten Samaschke, die Cloudibility. Wir hatten einige Ideen und Erwartungen in Bezug darauf, wie sich unsere Firma entwickeln soll und was wir unseren Kunden anbieten wollten.
Die schlichte Wahrheit jedoch ist: Wir lagen sowas von falsch damit!
A year ago, Cloudibility was founded by Michael Dombek and me, Karsten Samaschke. We had some expectations in regards to how we wanted to grow the company and what we wanted to offer to our customers. Truth is: We were plain wrong!
Wie sollte man sich als Auftraggeber verhalten, wenn man in Analysen und Projekten aufgezeigt bekommt, dass man über – nennen wir es mal so – Verbesserungspotentiale in Hinblick auf agile Vorgehensweisen, Automatisierung und cloud-natives Monitoring verfügt?
It’s beginning of August – and today two new members of our Cloudibility Team start their journey with us. And, additionally, two others, who joined in July, need to be introduced as well.
Chris is a very skilled and talented Security Engineer, which is into DevOps approaches and -technologies, such as Ansible, ELK, Grafana, etc., as well. He will allow us to put even more focus on Cloud Security and Security processes. Welcome on board, Chris!
Sven is an experienced Project Manager, with a lot of knowledge around processes and ITIL. He will be working as DevOps Manager, utilizing his experiences in classical and traditional processes in order to learn from them when setting up agile DevOps processes. It will be a challenge for him, our customers and ourselves in each other projects, since he knows both worlds. We like that and are happy to have him with us!
Pratibha started working for us mid-July. She is DevOps engineer, has experiences around AWS and Azure, as well in automatizing processes and tools. She immediately impresses with her knowledge and open mind. We are glad to have her in our team!
Rahul is an experienced Java engineer, who joined us mid-July at the same time as Pratibha. He is currently working in our test department and does very important work for something yet to be announced. We love, how he takes responsibility and learns about new approaches and processes!
Is that all? No!
We will have another four people joining our company in August and beginning of September. We’re so proud of each of them, since they are hand-picked and bright minds, without any exception.
I love that company!
This is, what you have to take care of when trying to establish a DevOps-culture: Many, if not most, people being affected by a DevOps-approach, will agree with it. At least as long as it does not force them to change anything and as long as they can sell it to their customers or supervisors since DevOps is very popular these days and is to be implemented by them, not by themselves.
Just last week, we had such a situation: We are in a short-term project with an enterprise customer. We have been hired by the vendor doing operations for that customer in a somewhat-CloudNative-environment (they run OpenShift on BareMetal-machines).
The end-customer sees a lot of – let’s call it that way – potential in the collaboration with the ops-vendor. Or to put it in clear words: There is no transparency, no knowledge-sharing, no automation, no versioning and no proper mindset in place at the ops-vendors teams. As a result, a lot of the infrastructure is somewhat running, but not even close to the standards, the end-customers expects. Rightfully expects, in my opinion.
This was the situation when Cloudibility experts were hired to analyze and fix errors in the environment, the software, and the collaboration. We proposed an agile DevOps-based interaction- and operations-model to our customer (the ops-vendor) and discussed chances for such a model with the end-customer as well. Both parties appeared to be very in close in their expressed opinions – yes, they all want to switch to a DevOps-approach.
One week later…
One week later, one of the two companies still sticks to that opinion, the other one does not.
The ops-vendor changed his mind since we perhaps were too successful and identified as well as fixed a lot of improvement-opportunities. He simply does not see the need to change his processes (which lead to the situation we came in) and his way of executing anymore, since the fixes are actually working and the customer appears to be satisfied.
DevOps now is to be executed by his customer, he will be participating in this „a little bit“ (quote), but only „as long as it fits into our processes and does not imply ourselves to change our approach“ (another quote). Plus: „We want to keep our internal approaches a secret, the customer does not need to know about them or can even expect us to adjust to his way of interacting – he is the customer, we are <Company-Name ommitted>“ (quote). And: „Don’t forget, we are not even required to have a logging and a monitoring in place, by the terms of the contract that customer signed“ (quote).
What could possibly go wrong with such a mindset?
Frankly, we expected this behavior from this customer, but it is frustrating nonetheless since they offer a CloudNative and Enterprise-ready environment and operations-model to their customers – and simply can not deliver due to having the wrong mindset and approaches, which gets only visible once a customer signed the contract (we have seen this several times with this customer). They execute IT the old-fashioned ways, having SDM (Service Delivery Managers), steep hierarchies and ITIL-processes in place, instead of DevOps-managers, experts, and an agile operations approach.
So, be careful when someone tells you about executing DevOps. Chances are, all they want is to get their backs covered and they will refuse DevOps as soon as it would imply to change something in their own processes and approaches.
Are we stopping to help such customers and to propose modern, lightweight, cost-efficient and adoptable processes and approaches?
And we will – of course! – successfully end our mission in that specific project as well. But it is kind of sad to see a chance for establishing better approaches and better processes pass by just because one of the involved parties does not want to change anything on their side.
Sad from a mindset’s perspective. From a commercial perspective, it is not: We are happily there to help with the next failing project. Again.
I hear this quite often:
Yeah, we want to do DevOps. We understand this is a critical thing, it is important for succeeding in our Dev- and Ops-projects. We can’t do without.
…we need to get the whole picture first. We need to have a fully featured DevOps-concept. We need some infrastructure. We need top clarify with our Stakeholders.
You know what?
These are only excuses for not doing DevOps.
The best approach to DevOps is by simply starting it. Forget about that fully featured DevOps-concept to be discussed throughout all hierarchy levels of your organization. Forget about providing the perfect infrastructure. Forget about everything – just start it!
DevOps is a process and a mindset. It is an approach to collaboration, to transparency and to knowledge sharing. Yes, it always can be done better, more aligned, deeper integrated, etc.
But nonetheless: The best way to start doing DevOps is to simply start doing it.
I said this quite often during several projects over the last years – and often directed to persons being „difficult“ with regards to discussing hard, having different opinions, contradicting a Product Owner or an Architect with thoughtful arguments. This is something you will have to accept, even if it is hard to do so. And it is exhausting, it is stressful working with such people on a day-by-day basis.
But, I changed my mind.
Or, to put it differently, I am now in a position where I want to have such characters around me. Here at Cloudibility, we want persons having their own ideas and their own minds, we want them to contradict us and to proove us to be wrong.
We want to have such minds around us. Of course, they will have to stick to our rules of respect and culture, they will need to be compatible with customers and the team. But besides this: Have your own mind, contradict, improve, overtake us!
So, we are looking for the Crazy Ones:
Are you one of them?
Cloudibility is a company focused around knowledge and heads. We are not limited to a specific location – our German employees are located in Berlin, Magdeburg, Brunswick, Frankfurt, Karlsruhe, etc.
Today, we expand that a little bit and welcome our first Indian team members. They are located in Faridabad, next to Delhi, in the offices of our long-lasting partner AppFlow Solutions Pvt.
Different to other approaches, we don’t treat them as a remote team working for us, but as our team-members working a little bit down the road. They will be participating in our processes, meetings, etc. and will be a core part of our team.
Our Indian team members are „hand-selected“ the very same way as our German stuff – they have to have the same culture, the same approach to cloud-native infrastructure and processes and the same greed for excellence.
Within the next four weeks, our Indian team will be extended to at least three employees, but we are actively looking for even more of them.
Welcome on board!