As an engineering leader at Duda for over ten years, I’ve watched as our organization evolved from one deployment a month to deploying multiple times a day. This transition started with the adoption of CI/CD, but to take advantage of its true benefits, we had to build a culture around small changes, code reviews, and a strong collaboration between developers. LinearB ensures we’re developing software in a continuous deployment way and building a culture we’re proud of. 

This blog is a guest post by the VP of Engineering at Duda, Ronny Shapiro

Building a Culture

Every engineering leader likes to think their organization is working really well. But you probably don’t have the data to back that up. When I first adopted LinearB, it helped shatter some thoughts I had about how my organization worked. It helped me know the truth about what I just had a feeling about. It’s really about understanding how the organization actually works vs. how you think it works. 

"Dev Culture isn’t something you can see or measure, but in our case, it is. You can preach about CI/CD and small changes, but in LinearB, you can actually see the data."

Over the past several years, the software engineering department at Duda has gone through a significant transition adopting CI/CD. When I first started with Duda, we deployed once every four weeks. We eventually shortened it to once every two weeks, then every week, every day, and now we’re practicing true CI/CD. 

CI/CD is typically based on using really good automation to ship small changes rapidly. But it’s not that easy. To take advantage of the benefits of true CI/CD, you have to build a culture around it, around small changes, short living branches, test automation, code reviews, and a strong collaboration between developers. 

Dev Culture isn’t something you can see or measure, but in our case, it is. You can preach about CI/CD and small changes, but in LinearB, you can actually see the data. 

Opportunities to Improve 

At Duda, we’re not as big as other competitors in our space, so we need to be really efficient and effective with the resources we have. That means when a developer writes a line of code, we want to get that code to our users as quickly as possible. Major  investments in devops and automation helped  us put the operations in place to accomplish this goal, while LinearB gives us the data to back up what we thought was happening - both in terms of our achievements and where we had opportunities to continue improving. 

LinearB spotlights the areas we need to invest in while educating us on what’s working. By providing visibility into all phases of the development process, it identifies bottlenecks - creating opportunities for us to improve. Sometimes, it proves that we need to break down a large task into 5 or 6 PRs - but it could also be cultural. For example, after identifying a PR Review Time bottleneck in our Cycle Time, we discovered that since our Israeli dev team worked on Sundays instead of Fridays, our dev teams in Ukraine didn’t have any reviewers available to them on Fridays. Our ability to discover the bottleneck and analyze the situation led us to actively build stronger working relationships between teams working on the same days to ensure those devs aren’t stuck. 

Results

Today, we deploy 20% more frequently than a year ago, with a 75% improvement in Cycle Time since we started measuring with LinearB. I’m proud of the culture our engineering organization has built. It’s not easy to show others that we’re as good as I think we are, but when I can show some data like the LinearB benchmarks that say we’re in the top 5% or 10% - this is something that builds trust across the company and with our customers. Most importantly, it makes the engineers proud, knowing they work for a strong team.