When agility and a business approach flow through your veins – meet our DevOps Engineers
What does a DevOps Engineer do daily? Do they have contact with the customer? What challenges do they mostly face? Find the answers to these questions in the following article, where I introduce the glories and shadows of DevOps life at Boldare.
Table of contents
Those whose career paths started before 2010 surely remember that back then, almost 15 years ago, there was no distinction between technologies, especially in smaller businesses. “Everything” was done by… software engineers. I remember it like it was yesterday. These were the beginnings of my adventure with Boldare, which is now in its 14th year.
Initially, I worked in the organization as a full-stack (PHP) developer. Over time, when specializations such as backend, frontend, DevOps, and product design started to emerge in the market, I steered my path toward DevOps. I have always been interested in infrastructure and automation, so it was a natural choice. As a result, today I operate as an experienced DevOps engineer, cloud engineer, solution architect, and site reliability engineer. Let me tell you a bit about what my work at Boldare looks like in practice.
Commercial and project work
The first thing you need to know is that I participate in both internal and commercial projects. My involvement in each area fluctuates and depends on Boldare’s current needs. Currently, I am focused on a commercial project, but my capacity balances healthily between commercial involvement and working inside the company.
What does this “internal” involvement actually consist of? Various duties related to developing and maintaining the internal company infrastructure and projects. I am a member of the DevOps Chapter, an internal community of DevOps engineers that meet regularly for weekly alignments to give each other advice and inspiration. In addition to regular slots, we do code reviews from time to time and support each other on a daily basis whenever one of us encounters a problem or tricky conundrum. I also act as a buddy for DevOps engineers new to Boldare. In this role, I provide them with support and help pave the way.
In addition to DevOps-related activities, at Boldare, I may engage in company-wide activities unrelated to my technical specialization (for example, I sometimes support the recruitment or allocation of DevOps engineers to individual projects). Holacracy, the management system that prevails at Boldare, allows me to work at an organization level (only if I am willing and motivated to do so).
Interdisciplinary crew
Who do I cooperate with the most? My current team includes developers and a Scrum master from Boldare, and a product owner with several developers from the client side. When I look at my interdisciplinary team, a set of values that guide our daily work comes to mind: commitment, proactivity, an Agile approach, and mutual support. Transparency is also crucial, which, by the way, represents one of the organization’s pillars. Our communication lives on Slack. In meetings, we remember to turn on our webcams. Teams generally work remotely, as Boldare people are scattered across different parts of Poland and Europe. Personally, I appreciate the remote mode of working, as it provides me with more focus.
Agility is our pillar
What also enhances my focus and efficiency is the Agile approach. Thanks to working in sprints, I always know the current main goal. A typical DevOps engineer’s working day largely depends precisely on the sprint phase. The beginning of a new sprint and the end of the previous one is mainly conceptual work. We then organize a code review, which is the culmination of activities in the previous two weeks. We participate in a retro – meeting to analyze the past sprint. Finally, we plan activities for the next cycle and define the main goal we will work towards together. During the sprint, the team meets daily to manage tasks and discuss any problems we encounter. Every day, team members focus on their areas, but we stay in contact with each other and the product owner.
Shoulder-to-shoulder with the client
A strong business orientation can differentiate a DevOps engineer’s role at Boldare from other places. Here, developers work within a business context. My team works directly with the customer – the undeniable advantage of this connection is the short chain of communication. The people directly working on the product and the client can and do talk to each other regularly. This is faster and more efficient than communication through intermediaries. As a result, we know what to expect from each other.
Such communication also builds and strengthens the mutual relationship between the client and the development team. From time to time, we meet with the client live to get to know and understand each other better. Thanks to this formula, the client sees the actual involvement of the team and gets to know in person the people who are developing their product and implementing solutions for their business. Invariably, we strongly emphasize mutual respect and trust in business relationships.
In communicating with the client, the team focuses on product development from a technical standpoint and business issues related to the product development strategy. There are product strategists who develop the next steps in product development and get the client thinking about what will be needed. As a developer, I support the client and product strategists on issues related to the practical operation of the product – I verify solutions and ensure they make sense.
Product building cut into phases
At Boldare, the product-building process is divided into four phases: prototype, MVP, PMF, and scaling. This division allows us to more accurately select the resources and technologies needed to achieve the desired goal – from a technical and business perspective. As you might guess, each phase requires different solutions. The earlier phases – such as prototyping or MVP – rely heavily on experimentation, goal-challenging, and rapid validation of assumptions. We choose the right technical tools for this. When dealing with prototypes or MVPs, we don’t use scaling tools. The speed of delivery and changing/improving the product efficiently is essential at this stage. Later phases, such as PMF or scaling, focus on product stability and performance.
The phased approach is vital for developers who work with code in practice. Solutions are implemented with the client’s business in mind, as it allows them to fully understand the different stages of product development and the associated user and market needs. The customer doesn’t always need a full-featured solution – sometimes the answer to their needs may be an MVP, for example. The key is to research the market and user needs in depth to define measurable goals for the product. Thanks to that, we can match the goal with the appropriate phase and provide our clients with their desired product without wasting money or resources.
Matching skills to the product-building stages
Do I feel and work better in a company that takes a phased approach to product building? I think so. What’s valuable for DevOps engineers is catching the difference between various phases of product development. It helps to build a roadmap of activities for the project more wisely. Not all functionality is needed right away, we can add it to the backlog at the right time. Working phase by phase also allows Boldare people to work in an environment they truly fit. Why? Because each phase requires different skills. Matching these skills to the particular stage of creating a product opens the door to freedom and therefore better work.
DevOps? Not home alone!
When I think of the challenges of working in a DevOps role, what comes to mind is working alone on a project. It is rather standard in the market that there is usually only one DevOps engineer in a project. As a result, the person requires more focus and self-discipline to work effectively. That’s why I appreciate that in Boldare, I have the opportunity to exchange thoughts and challenge each others within the DevOps community. The strength is always in the team, so the vital aspect of my day-to-day work is understanding my team and the Chapter to which I contribute. Being open and helpful, integrating with others, and sharing know-how (not only in my specialty area but also with people from other fields) are all integral parts of everyday life at Boldare.
Stare your own career path
The diversity of projects – both in terms of technology and industries – is the undisputed domain of Boldare. This dynamism opens the door to new opportunities like developing new specializations, drawing from experts’ know-how, getting to know different cultures, and having the courage to propose new solutions. There is no question of being “pigeonholed” into one specialty. Your development at Boldare depends entirely on you, your willingness, and your preferences. In addition, holacracy allows everyone in Boldare to actively participate in broader organizational topics - which also gives you wings and prompts you to make changes in your own development path.
Mission: possible
Someone might ask: why have you stayed so many years in one company? If this question has crossed your mind, here I am with an answer. What gets me going is having a strong sense of purpose. While building products for customers from different parts of the world, I always remember that there are real users who will use these solutions. Perhaps they will make people’s lives easier? As in the case of Mowaamah, one of Boldare’s digital solutions for people with disabilities. On the other hand, each time I participate in a well-known and reputable project (such as BlaBlaCar, for example) I feel motivated and energized by both pride and a sense of fun. This opportunity to carry out worthy projects with professionals in a great atmosphere is fundamental for me when it comes to workplace requirements.
Curious about new opportunities at Boldare? Check out our career site and find your dream job now, or join our talent pool!
Share this article: