The term DevOps conceals many different roles and practices, which cannot be described in one sentence. We asked Aleksander Czarnołęski and Michał Piotrowicz from Sollers Consulting about the topic of working with DevOps, its characteristics, and the path to becoming a DevOps Engineer.
What does DevOps mean and what is its role in projects?
Aleksander: It all depends on how we define DevOps. Most commonly, we encounter the role of a DevOps Engineer, whose goal is to automate the software development process. This is partially in line with the overall DevOps approach, but it overlooks a crucial cultural and process organization aspect – a poorly designed manual process, when automated, will become a poorly designed automated process.
DevOps is a very broad concept that encompasses many practices. I usually summarize them with the following definition: optimizing the software development and delivery process by ensuring the right organizational culture, processes, and, ultimately, tools.
Considering market perception and our experience with DevOps, we usually distinguish two types of projects:
1. If we work on a single project for a client and have limited influence on the entire organization, we focus on building the highest level of maturity and automating the development process at the project level. This involves optimizing and automating the software development and delivery process, as well as building awareness among clients about DevOps practices such as close collaboration between development teams and the business, early testing, empowering the team to make decisions, providing the team with end-to-end solution-building tools, etc.
2. In projects aimed at transforming the client’s organization, we have a much greater impact on establishing the right organizational culture and designing processes at the company level. We try to find a middle ground between providing teams with the right tools and freedom to create, as well as introducing certain frameworks that allow maintaining a consistent technological approach, supporting the reuse of prepared solutions, and ensuring consistent development across the entire organization.
Did you know from the beginning of your career that you wanted to be involved in DevOps? What was your journey like?
The path from Business Analyst to Senior Consultant
Aleksander: My path was quite unusual because I started at Sollers as a business analyst. Initially, I was responsible for gathering and creating functional requirements, contacting domain experts, sometimes preparing test scenarios, and later testing them. Since Sollers provides many opportunities for horizontal development within the company and beyond the currently performed project, I was offered the opportunity to coordinate the DevOps competence within the company. The task involved organizing people within the competence rather than creating solutions myself (at that time, I barely understood the concept of DevOps!). Initially, I didn’t see where I could add value because I was not technically inclined in any way.
It was only later that I understood a more comprehensive definition of DevOps and realized that if I train properly and better understand the software development process, I would be able to help build the right organizational culture and optimize processes. So, I started reading many books, presentations, and attending training sessions. Above all, I started talking more with developers, architects, and infrastructure engineers to better understand their daily routines and the problems they face. As I gained knowledge and made the strategic decision to invest more in the development of DevOps products, my career began to revolve more around this area. Then there were projects where I helped build the organizational culture and optimize development processes for clients. That’s how I ended up where I am now.
The path from IT Admin to IT Manager/Head of DevOps
Michał: I started my career as a systems and infrastructure administrator. Over time I became more involved in external projects for clients because I wanted to solve the problems my colleagues in development teams were facing. Previously, I often encountered ironic comments from business colleagues who would say, “Why can’t it work like it does for us?” At that time, the term DevOps was still in its early stages, and we ourselves were unsure how to define our ideas and initiatives. Agile methodology was gaining popularity at that time, and we translated it into our work on infrastructure. As we completed more projects and solved problems, we increasingly came across new tools and resources that mentioned DevOps as a practice for efficient software delivery. All of this solidified the competence of DevOps in Sollers.
Looking back, in my case, reaching the role of IT Manager was mainly the result of two things. On the one hand, it was technical knowledge combined with self-assurance, which often led me to question the common “it can’t be done” statements that are surprisingly common in IT. On the other hand, it was a willingness to work as a team. I quickly realized how much depends on the people themselves and their commitment – whether we share common goals, what drives us, and whether we understand the value of our work.
How did you end up at Sollers? What do you value in this job?
Aleksander: Working at Sollers was my second job, which I started during my studies. I had previous experience in IT recruitment, which was a good starting point as it gave me a better understanding of the industry.
After four years here, I value the flat organizational culture and the opportunity to get involved in various projects and initiatives. I’m an example of that because I started as an analyst but had the opportunity to develop in a different direction. I feel that Sollers cares about its employees and pays attention to making every change genuinely improve the work environment. All such changes are discussed and don’t come from the top-down but rather because of teamwork. Being open to feedback is crucial. If a change meets dissatisfaction, it is considered and adjusted to meet the real needs of employees. I believe this is a good approach because since I started (over four years ago), the company has grown by several hundred new people.
It’s also important to me that Sollers provides many integration opportunities from monthly meetings and team-building trips (such as to Malaga or Crete) to integration budgets that employees can use for joint outings. This year, we’ve had several trips to the mountains, sailing, and cycling trips across Europe.
Michał: For me, Sollers was the first serious commitment after a few shorter episodes in my career. What I liked from the very beginning and what hasn’t changed to this day is the high level of commitment from people and their openness to change and continuous improvement. This, combined with the flat structure mentioned by Aleksander, allows me to pursue two dimensions: supporting clients in digital transformation projects and working on my own development and the development of the entire company. Development is one of the keywords in Sollers, not only in a business context but also from an individual perspective for employees who want to enhance their skills.
What connects DevOps and Agile?
Aleksander: Agile is becoming present in practically every software development company. However, from our observations, most implementations of Agile practices are done only to a certain extent and only in parts of the organization. There is even a term that illustrates this: “water-scrum-fall,” which means that development teams follow Agile practices, but everything that happens before the development process (such as goal setting, budgeting, goal decomposition) and the subsequent maintenance process are done in a Waterfall approach. Organizations then become disillusioned with Agile because despite its implementation, the pace of product delivery to the market changes little or not at all.
This is where DevOps practices come in, breaking down the silos in the software development and delivery process. They also help development teams to acquire all the necessary tools and competencies (both business and technical) to be responsible for the process from start to finish.
Michał: I agree with the previous speaker! Business agility cannot be achieved without the proper foundations of technical agility. As long as the technical side of software delivery is a constraint, companies will not fully realize the business value of implementing Agile methodologies. By implementing DevOps practices in our projects, we enable teams to focus on what matters, which in the long run translates into business results.
What future awaits DevOps?
Michał: I think we will continue to refine what DevOps is and how organizations understand this concept. We are already seeing a shift towards greater awareness that investing in a DevOps culture is worthwhile, and the term itself is no longer just a rebranding of ordinary IT Operations. Our clients have started to recognize the value of implementing DevOps practices in conjunction with an Agile approach, as they can achieve much better results not only in software development but also in other areas. An example is the increasing number of job offers with different variations of “DevOps” – “DataOps”, “SysOps”, “SecOps” etc. These names represent the implementation of practices that aim to bring value, improve work in a specific area, and eliminate team silos. Value Stream Management (VSM) is another complementary concept to DevOps. It is a technique that allows for a holistic view of the quality of our products and whether they meet the needs of end-users. Agile and DevOps have primarily focused on delivering efficiently and with good technical quality. VSM adds another factor to this – analyzing whether what we create is valuable to the end-user.
Aleksander: I have a feeling that over time, DevOps and the practices that fall under this term will become a natural part of every company that has anything to do with IT (which, in today’s times, practically means every company). Of course, this requires numerous transformative processes that prepare the organizational culture for a new pace of work and a different approach to problem-solving. I believe that just as it is now natural for most companies to conduct projects in an Agile spirit, soon the same will happen with DevOps practices. Due to the broad scope of DevOps, I believe that its implementation will become increasingly intertwined with other currently crucial technologies such as Cloud, big data, AI, or machine learning. This will facilitate the adoption of the best practices in the market and, as a result, allow for the development of the most efficient software development methods.
Aleksander Czarnołęski – Senior Consultant at Sollers Consulting. He graduated with a degree in Management from the Warsaw School of Economics. For nearly 5 years he has been implementing IT solutions for international companies in the financial sector. For the last 3 years he has mostly focused on the implementation of practices and tools to increase the efficiency of IT software delivery according to the DevOps and Agile approaches.
Michał Piotrowicz – IT Manager at Sollers Consulting. He graduated from the Faculty of Cybernetics at the Military University of Technology in Warsaw. For 11 years he has been working in projects related to the implementation and administration of IT systems, and for the last 8 he has been focusing on the efficiency of manufacturing processes and the implementation of DevOps practices in IT.
Source: