#TeamSpeednet: Leszek, DevOps
Meet Leszek, a DevOps engineer who has been supporting the development of innovative solutions for years, automating processes, and ensuring team efficiency at Speednet. In this interview, he talks about his work, daily challenges, favourite technologies, and what brings him the most outstanding professional satisfaction.
How long have you been working at Speednet, and what do you do?
Leszek: I’ve been working at Speednet for seven years, dividing into two distinct phases that differ in role and responsibilities. I was an IT administrator within the company for the first four years. I was responsible for our internal network, office IT infrastructure, and all tools supporting software development, such as developer environments.
For the past three years, however, I have been fully engaged in a project for an external client, which means I no longer handle our internal infrastructure or other internal projects. My current responsibilities focus exclusively on managing the client’s infrastructure. This change has brought about some significant differences. While working internally, I juggled multiple projects simultaneously, sometimes leading to conflicting situations. Each project had urgent needs, and effectively dividing my time was challenging. Now, I concentrate on a single project, which allows for better work organisation, even though prioritising various tasks is still required.
Additionally, I no longer worry about physical infrastructure. At Speednet, we had our servers and various networking devices that required constant oversight to ensure everything ran smoothly. In my current project, however, everything operates in the cloud, and I much prefer this setup.
How does the role of a DevOps engineer differ from that of an administrator or programmer? What are your primary responsibilities?
Leszek: From Speednet’s perspective, a DevOps engineer primarily focuses on automating processes that support software development. Developers need proper infrastructure, tools, testing environments, and deployment platforms to efficiently create code. My task as a DevOps engineer is to ensure that these processes are as automated and intuitive as possible, allowing developers to be more self-sufficient. This means they don’t have to rely on an administrator to upload, update, or prepare something at every stage of their work. Automation enables processes such as automatically verifying code for errors, deploying it to a testing environment, or even creating the atmosphere after the code is pushed to a repository.
Software development also takes place in the client’s context but in a slightly different manner. The client has internal applications that must run on environments meeting specific requirements (such as security, availability, etc.). My responsibility is to maintain these environments, ensuring they operate efficiently, are correctly configured, and are as automated as possible. The goal is to enable internal users to manage their applications in these environments with minimal involvement from the DevOps team.
It’s essential to highlight the difference between an administrator and a DevOps engineer in the traditional sense. Administrators usually configure systems manually using interfaces or management panels. On the other hand, DevOps engineers work with the “Infrastructure as Code” (IaC) methodology. Instead of manually clicking through panels, they describe infrastructure in code form, defining configurations and the state of environments using tools that automatically deploy these configurations. This way, infrastructure is created and managed through code. While this involves writing code to describe the infrastructure, it’s not classical programming in the sense of a developer’s work.
What tools and technologies do you use most often in your work?
Leszek: Currently, I work exclusively with tools and environments provided by the client. As a result, my work is entirely focused on the AWS cloud environment. Most of my tasks revolve around AWS and Kubernetes, the two key infrastructure components I manage. The platform I oversee for the client is used to run applications and is built on these technologies.
I use LENS to monitor and manage Kubernetes. Application deployment follows the GitOps methodology, utilising ArgoCD. I manage infrastructure using Continuous Deployment with GitLab Pipelines. For configuring services in the AWS cloud, I utilise the AWS Cloud Development Kit (CDK), enabling infrastructure definition as code. I primarily work with Python in CDK, and my preferred code editor is Visual Studio Code.
When I started working on this project, I had to learn to use some new tools, especially AWS-related ones. Kubernetes and GitLab Pipelines were already familiar to me, but some of the tools for managing AWS were entirely new experiences.
What challenges do you encounter at work, and how do you handle them?
Leszek: One of the most common challenges is communication issues, particularly with users of the platform I manage. In addition to developing the platform, we support its users, who often report various questions or problems. These issues are frequently described in very general terms, such as, “Application XYZ isn’t working,” which, from our perspective, does not provide enough information to diagnose the problem. In such cases, we ask detailed questions to understand the issue better. On the flip side, we sometimes use overly technical language that may be incomprehensible to the user. When this happens, we try to avoid jargon and explain technical matters in a simple, accessible way.
Another challenge is limited access to information, which stems from working within a large corporation. Areas of responsibility are strictly divided, and as platform administrators, we often lack access to specific components, such as network connectivity settings. This can lead to difficulties – when something isn’t working, and we don’t have visibility into what’s happening at the network layer or when some traffic is blocked. In such cases, we’re often left to infer the root cause of the problem. This becomes particularly challenging during infrastructure-level failures that impact the platform’s functionality. Users report issues, but from our perspective, the platform functions correctly due to our limited visibility scope. In such scenarios, we must collaborate with other teams to identify the root cause and find a solution.
By addressing these challenges through effective communication, cross-department collaboration, and a focus on clear problem-solving, we strive to minimise disruptions and improve the overall user experience.
What does a typical day look like for you? Is there such a thing as a “typical day”?
Leszek: It’s hard to define a “typical day” in the complete sense, as each day brings different meetings and tasks. However, certain recurring elements are part of my daily routine.
I usually start my day by commuting to the office, as I primarily work onsite. After turning on my computer, I check the day’s meeting schedule to plan time slots for completing my tasks. Then, I review messages and emails to see if anything urgent has come up since I left the office the previous day. Our clients work across different time zones, so messages sometimes arrive outside our standard working hours. If something requires immediate attention, I address it right away. Otherwise, my next stop is a coffee break.
After coffee, I focus on my regular tasks assigned during the sprint. I typically attend 1-2 scheduled meetings throughout the day, although ad-hoc meetings often arise based on current needs. Routine tasks include activities like code reviews for teammates and “firefighting” – quickly responding to incidents or problems that may occur suddenly and require immediate resolution. Occasionally, larger tasks occur, such as updating the Kubernetes version on the platform, which triggers a series of actions. However, functions of this scale happen roughly once a month, mainly when dealing with critical component updates. While each day varies in specifics, this framework of balancing planned work, meetings, and unplanned issues gives structure to my daily routine.
What brings you the most satisfaction at work?
Leszek: Building solutions from scratch, designing the architecture, and implementing them gives me the most excellent satisfaction. I enjoy seeing a tangible result, whether it’s a tool, service, or solution that reaches users and makes their daily work easier. Typically, such creative projects arise quarterly, and I work on them for about a month. It’s advantageous to see something I’ve created make a real impact.
You mentioned that you primarily work from the office. Please share why you chose the office over remote work.
Leszek: The main reason is probably mental health hygiene. During the pandemic, I worked from home, and it wasn’t easy to separate work from my personal life and maintain a healthy balance. There were too many distractions – I could easily get caught up in a million other things instead of focusing on work. I’m fully dedicated to my tasks when I’m in the office. Additionally, I enjoy meeting people and having a good coffee from our office coffee machine. It’s part of my morning ritual and something I look forward to.
In addition to working as a DevOps engineer, you’re also a DJ and have played at several company events. Which event do you remember most fondly and why?
Leszek: I have the best memories of our winter ball, which took place at Stary Maneż. It was a unique event because I performed in two roles: as a vocalist and a DJ. It was an incredible experience to stand on a stage where some of the biggest Polish stars have performed. Additionally, I got to see what the backstage of such a venue looks like and work with a professional sound engineering team.
My DJ set was less extensive, and I felt a bit nervous, but at the same time, I felt immense satisfaction from being part of such an event.
