Sevket Yapar

All right. Good afternoon. Thank you for coming to my session. I know it has been a long but great three days, or four if you were able to attend the DORA Summit.

My name is Sevket. I am a father, husband, friend, and a servant leader in my organization. It's unique, but it's towards the end of the seminar, I'm going to present to you how to start with DevOps, or the challenges that I run into on how to start with DevOps.

How to start with creating a DevOps culture. Why did I choose this topic? What is slowing down or preventing an organization's journey with DevOps? That's the question I have been tackling and wanted to share my journey with you.

Who are we? We are UKG. UKG was born about three years ago with the merger of two industry giants, Kronos and Ultimate Software. Both SaaS providers have been providing workforce management, human resources, payroll, and other HR-related solutions to their customers.

Even though UKG is only three years old, the two companies have been around for quite some time: Kronos, 46 years old, and Ultimate Software, 1990, so 33 years old. So it was an interesting challenge for us to bring our products together, our ways of working together, and becoming one organization.

At UKG, our purpose is people. Everything that we do is around people. We are a cloud-based solution, SaaS leader in, again, human resources, payroll, workforce management. We support 80,000 organizations across every industry, serving all their employees' needs.

My role at UKG is to serve the Pro HR, human resources components of the UKG Pro Suite engineering teams as their leader, supporting my peers and my leaders.

What is DevOps? I have heard so many different definitions. I like to start with referring to one of the industry leaders with DevOps, Scott Prugh. If you have watched his presentation, "Accounting vs. Physics," great. If you haven't, please watch it. I'm going to quote Scott, what his definition of DevOps is.

DevOps is a combination of leadership, systems thinking, culture, philosophies, practices, measurements, and tools that increases our organization's ability to deliver and operate high-quality services at high velocity, and continuously improve in order to delight our customers and employees and dominate the market. It's a humane way of delivering technology safely.

Now, this is a very elegant way of describing DevOps. Next, I'll share with you my less elegant way of what DevOps is.

I'm still learning. I'm in the very early stages of my DevOps journey. And if it wasn't one of my mentors, Nathen Harvey, I wouldn't even be here yet, submitting a speech and trying to share my journey with you. So this is my simplified version.

DevOps is to continuously measure, evaluate, learn, invest, and improve operations, while keeping that priority over working on new features in a Westrum organizational culture, where the goal is to become a generative, performance-oriented organization.

And I also want to highlight: I don't see DevOps just for software. I have seen the same principles that can be applied to almost any industry, whether you're building cars or houses.

How to start. Now, how do you change and influence a culture that prioritizes software delivery performance over new product features? It's not easy.

While the answer is likely to differ from one organization to another, the first step is to understand the why. But please note that it may not be just one why, right? The why may be different from one organization to another, one team to another one.

Why should any organization prioritize software delivery performance over the new product features? In the end, it all needs to be tied down to return on investment in the form of providing value to our customers faster and improving developer experience and productivity, hence helping with attrition, reducing downtime, et cetera.

Now, many leaders tend to prioritize delivery of software features over investing in development processes. That's why it's important to go back and start influencing your culture. Start with why. Build that momentum. Build that culture.

If you haven't watched the Tesla Investor Day in 2023, Tesla is a car manufacturer. They do an awesome job in software too, but they have invested in their build process, manufacturing process in a way that they really scratched the whole system, re-architected, redesigned the entire manufacturing, simplified.

As a result, now they're able to build cars much faster, therefore much cheaper, and make a meaningful impact to their margin. It's a very interesting story that made me realize that DevOps is a way of looking at things, not just software delivery.

Now, many people don't understand why DevOps is important and how it benefits the organization in the long run. Like, what is in it for me? What is in it for them? That's the effort that me as a DevOps evangelist, or you all, need to put into gaining that organizational support.

Even developers, they don't often understand what is in it for them, right? We are not in Japan. Our kids, we didn't grow in schools where we were responsible for the entire classroom, from cleaning to learning, right?

I know developers, they say, "Hey, listen, I just build code. I don't do support. I don't do night shift. If it goes down, that's not me. That's somebody else," right?

Product managers, they also need to financially justify everything that they build. But show them the ROI, and we don't need to reinvent the wheel. It's not that difficult. Thanks to our community between DORA and IT Revolution, the framework is really well defined. Do you want to know how to do the ROI? Go to DORA's website. It's really well defined, and you can just take that, adapt to your organization, and then work with your product teams, work with your business leaders to make your case.

Now culture. Understand the current culture. Conduct surveys, interviews, and workshops to understand where you are. Now, each team might be at a different stage, might have big variances between the two, but start with understanding the existing culture in your organization.

And the Westrum organizational culture I mentioned in my definition of DevOps, defined by Dr. Ron Westrum, breaks organizational cultures into three: pathological, the power-oriented; bureaucratic, process-oriented; and generative, performance-oriented.

We, and I hope you too, should aim to become a generative, performance-oriented culture. Because in those cultures, information is actively sought after. Messengers are not punished when they deliver news of failures, outages, or other bad news, such as, "We're going to miss the delivery date."

Responsibilities are shared, not blame, not witch hunts. Cross-functional collaboration is encouraged and rewarded. And it's easy to say this, but you also need to make changes to the way of working and implement team topologies, create value streams, to create the right environment for that cross-functional collaboration.

In a generative organizational culture, failures are treated primarily as opportunities to improve. New ideas are welcomed. And it's just a great place to be working at that point.

Now, as our partnership with DORA, we have done a DevOps workshop, and at the end of the workshop, we did conduct a survey. And that was a great feedback. Feedback is a gift, and this was a big gift for me. It took me a few days to digest and understand.

One of our product members said, "DevOps doesn't seem to have a lot of value for our product teams. We are not like traditional product owners."

And I was like, "Wow." I mean, I totally missed the mark. I haven't done my job as a DevOps evangelist. If that's the feedback coming, clearly, I haven't really influenced the culture. I haven't really done my job to explain the why. I haven't done my homework, so to say, to gain that common understanding and align everybody behind this mission.

But we also need to define clear goals and objectives. We need to clearly articulate the benefit of DevOps, such as faster value delivery, improved developer experience, reduced downtime, and enhanced customer satisfaction.

We also need to ensure that these objectives are tied to measurable metrics and align with the organization's overall mission and vision. Now, for us, it's the combination of stability and throughput that will result with increased revenue and margins. And we are relying on DORA metrics to measure stability and throughput.

Leadership buy-in. It's essential. It's going to set the tone for the entire organization if your most senior leader comes in and stands behind this journey.

Another interesting feedback, my second gift from that workshop, came from the development organization. This took a few therapies with Nathen for me to get over. It wasn't easy.

The feedback was, "It would have been nice to have senior leadership buy-in to changes." Changes mean DevOps-related changes, right?

So what my team was saying: "Okay, we heard you. We heard other leaders. Yes, we heard the DORA team. Yes, when it comes to talk the talk, every presentation, we keep seeing DevOps and DevOps this and DevOps that, and measure these. But then I have a full roadmap of delivering features."

So they called us out, and again, this really was an aha moment, an eye-opener for me. We had to change the way we invested our time and our money.

Prioritize and invest in 41 key capabilities. I'm not going to go all over the 41. Again, these are all well defined in DORA and the book Accelerate. But it's broken down into three categories: technical practices; work process and measurement; people and culture.

Each team, each product, each organization needs to do an assessment and figure out what is the biggest opportunity, what are the capabilities that they need to invest in.

But at UKG, we did the assessment, and we did prioritize and invest into technical practices such as deployment automation, cloud infrastructure, test automation, continuous integration, continuous testing, continuous delivery.

And on the work process and measurements: working in small batches; make flow of work visible; gathering and implementing customer feedback; team experimentations; streamlining change approval. Streamlining might be a push, but we are making some changes, and we are yet to see the results of it.

On the people and culture: transformational leadership, right? It all starts with the leadership, not just talking, but supporting it with the right investment. Westrum organizational culture, culture of psychological safety, and trusting one another.

I know that these are a bit of a repeat maybe, right? I have seen the DORA presentation, it was covered there, the trust, retrospectives, belonging, and inclusion. But these are all the things together will help us, will help you, to start your journey, your transformational journey with DevOps.

So our journey with DevOps, again, starts with the transformational leadership that leads an investment into technical practices with continuous integration, deployment automation, monitoring and observability. That gives us the ability to continuous delivery, which results with less pain of deployments, less rework, and less burnout.

Now, streamlining change approvals also gives us a better culture and work environment, and all that together gives us a better software delivery and operations. So with the right cloud infrastructure and organizational performance.

Cross-functional collaboration. Since UKG's purpose is people, we started this by focusing on people, by fostering collaboration within and across the teams. Again, we changed the way we were working. We adopted the ways of working between the two organizations of Kronos and Ultimate, and aligned everyone on the same PI schedule, program increment schedule.

We did adapt to team topology, and we are still, I mean, we are not done, but we are still in the process of creating the right work environment for cross-functional collaboration.

Fostering collaboration between different teams, such as development, cloud, security, and product management, was only possible by changing and adopting our ways of working.

Cross-functional teams can work together to achieve the common goals and break down silos that may hinder your progress otherwise, especially if you're a growing company or if you're a company that's getting merged by other companies that have different processes and products.

We need to create incentives and recognition programs that reward team members and individuals for progressing with software delivery and operational performance. It'll help reinforce the desired behavior. So we need to bring in celebrations as often as we can.

Feedback loops. Continuous evaluations and improvements of existing processes, skills, and tools are at the core of DevOps. It'll be a never-ending process.

Establishing feedback mechanisms to gather input from the teams and stakeholders, regular retrospectives, and not just when something goes bad. "Let's just do a retro." You've got to bring retros to your routine to also do a retrospective if something went well. Like, what did we learn from this, right? Don't just focus on the failures.

And post-implementation reviews, those will help us identify the areas for improvements.

Pilot projects. Start with small pilot projects or teams to test and demonstrate the benefits of DevOps, which is prioritizing build and delivery. Use these successes to build momentum and gather support from other areas of the organization.

Measurements and metrics. Again, these are a lot of repeated information for you. I apologize. But it's important. You pretty much heard this in every other conversation, but the key indicators, right? Cycle time, lead time, deployment frequency, MTTR. We need to measure to get a base and keep improving from that moment on.

We need to regularly report progress and, again, celebrate achievements.

Continuous learning. Encourage a culture of continuous learning and adaptation. Emphasize that change is an ongoing process.

At DevOps, we really have a great community, right? So we will continue to grow and learn together. And we cannot think of this transformational journey that has an end to it. It doesn't. It just keeps evolving.

Organizations should be open to refining their approach based on the feedback and, again, evolving industry best practices.

Celebrate milestones and successes. Recognize and reward those who contribute to the cultural shift. We need to be persistent and patient. Cultural change takes time. Be prepared for resistance and setbacks, right? Not everybody's going to get on this train all at the same time. It's essential to remain persistent and patient throughout this transformation journey.

Now, clearly also Kronos, Ultimate, UKG, we have been doing just fine. I'm sure there are many other companies just fine, right?

What if we don't do anything? What is the opportunity cost? Well, a lot to cover here. But if we don't, and if we don't change the way we work, and if we continue to grow, add more products, add more features, the net result is going to be creating more dependencies that will lead into more outages, longer MTTR, time to restore the service, higher change failure rates.

Employee retention will decline, which is very costly. Developer burnouts, which will impact the productivity. Less innovation. Client retention decline. CSAT decline. I mean, you get the picture, right?

So if you are a growing company, growing means not just sales and revenue, but adding more to your products. You have to adopt and you have to change to DevOps.

So in summary, we need to operate before we can innovate. We need to start with the culture. We need to start with the why, and we need to understand each why might be different, right? The why conversation with a developer versus a business executive is not going to be the same. A product owner versus a support person is not going to be the same.

We need to set goals, and we need to continue to push this forward. We need to crawl before we can walk, and walk before we can run, and run before we can fly.

Thank you so much for your time.