If you had to help your software engineering team deploy three times more frequently, boost quality by 50% and do it all with 10% less budget…what would do?  That’s the question many CTOs face today, and one I’ve had to answer myself – several times.  Throughout my career I have help CTO, CPO and VP of Engineering positions at companies like Oracle, Dell, IBM, Wrike and Wunderkind.  And while the challenges in each position have been different, they all demanded that I develop a strategy to do more with less. 

At one company, I’ll never forget my first board meeting as the new CTO. I was grilled about why engineering took so long to release new features and why quality was so bad – all before I’d even taken the reins. With no real-time insights into my 110- person software development team, I struggled to explain how to improve pace and quality. But within 6 months we’d managed to:

• Reduce cycle time by 85%
• Decreased technical debt by 28%
• Reduced average engineering-to-QA cycles from greater than 4 to less 1
• Moved from bi-weekly deployments to CI/CD
• Introduced an SRE/DevOps team that decreased hosting costs by 17%

Since then, I’ve taken what I learned from that experience and developed proven methods for dramatically increasing deployment velocity, maximizing release quality, and maintaining consistency, even in the face of tight budget constraints. In this article, I’ll share the tactical, leadership and process strategies I’ve used to transform teams. Whether your goal is monthly versus quarterly deployments or to enable continuous delivery, you’ll learn techniques to guide your organization.

The proof is in the metrics though, so before diving in, here are a few examples of how these strategies have accelerated software engineering at companies in 90 day time frames:

Decreased Cycle Time from 9 to 4 days

Lowered PR Review Time to Approval from 6 to 2 days

Increased Deployment Frequency by 250%

 Who Are These Strategies For?

The strategies I’ll cover will work for most software engineering teams, but become more relevant with scale. So if you are a CTO, VP, or Director of Application Development managing a team of more than fifty engineers, you should understand and implement these strategies and tactics.

This is especially true If you feel like you don’t have full visibility into what your team is doing, feel like product releases are continuously behind schedule, have seen an increase in developer attrition and notice that your team spends most of their time working to resolve technical debt.

Understand your Baseline

The first time I faced these problems and had to turn a team around, I had limited tools. That said, I knew that I needed to create a baseline on all the questions we cared about, such as:

• How long did it take for us to go from ideation to production?
• Were we creating more bugs that we resolved?
• How often we’re we deploying new code?
• What percentage of our work was actually innovation that drove revenue?

At first, gathering this data was cumbersome and manual. I drafted someone from our quality assurance department and had her sit in on meetings and gather stats in a spreadsheet. We reviewed her notes three times a week and it took time, but eventually patterns started to emerge and we had enough to paint a picture.

What I really wished for was a solution to automatically collect this data across the tools used by the team during the software development lifecycle. It also would have been helpful to not have to manually create each metric. And having industry benchmarks would have also helped contextualize which issues needed urgent focus. But we made do with what we had.

Root Cause Analysis

With the baseline data in hand, we performed root cause analysis to uncover why productivity was so bad and quality suffering. Three key problem areas emerged:

• User stories were full of ambiguous requirements and most were way too long. This led to developers building features that they didn’t understand and that didn’t meet the customer’s needs.
• Code was consistently getting rejected by QA. While some of this was due inconsistent stories, it also showed that the code review process was letting errors slip through – and that the QA team may not have consistent success criteria.
• There were major bottlenecks at various stages in the SDLC. Poorly defined stories led to longer coding durations, PRs waited for days before they were opened and the number of rounds between deployment and QA rose to unacceptable levels. Work stalled in hand-offs and work trickled out of the pipeline

What we ultimately found was that technical debt and process gaps had accumulated to a point where things broke every time we tried to add new features. The pressure to deliver and fix things led developers to cut corners – all in an effort to meet the demands of the development calendar. And as the weight of the tech debt got worse it further slowed velocity and drove developer morale to an all time low. It became a vicious cycle – developers were burning out, losing focus and that caused more bugs and errors. The team was trying their hardest but the process had broken down.

Unfortunately, you are probably resonating with some of this as it is a common scenario. As an engineering leader you are under constant pressure to deliver. No one has ever said that this month’s roadmap is easily doable and I have way more resources than I need. In fact the opposite is true more often than not. As an engineering leader it’s crucial to recognize when your teams are stretched too thin and to not let the pressure to deliver, and deliver quickly, force you into making bad decisions. I can’t tell you the number of my peers who have regretted trading quality for speed. Sometimes decisions like this may seem like a necessary evil, but inevitably they always backfire with unintended consequences.

For us, having clear metrics and baselines on team capacity, productivity, efficiency and performance helped to highlight our delivery issues. It also enabled us to identify what was a symptom and what was a root cause. With our true problems identified, we could then take steps to systematically improve workflows, tooling, and processes. So what did we do?

Rally Around a Unified Vision

When we started, I was concerned that the team would feel demoralized when we shared how poor our delivery process actually was. What I didn’t understand was that they already knew it and were frustrated by how their hard work wasn’t paying off.

Once we shared the results of our baseline analysis the team was nodding their heads in agreement, happy that management had finally realized how bad things were. That led to a very open discussion where everyone agreed that changes needed to be made.

Monitor Processes, not People

Once it was clear that we weren’t looking to blame anyone, everyone felt empowered to make suggestions on how to improve and where to improve. It’s probably important to note that while measuring the process we never measured individuals.

I am a strong believer that software engineering is a team sport, and that using metrics as a replacement for good personnel management is a great way to start a team revolt. We also never tried to hide anything from anyone. All of our research, data points, baselines, goals observations and recommendations were visible to the entire company, as were all our successes!

Finding a Winning Formula

A few weeks later when we came back with the plan to improve the process, the entire team was excited. Every week we posted our improved results vs our baseline in Slack and the number of comments and thumbs up was overwhelming. When we reached (and exceeded) our goals, we took time out to celebrate and later identified new areas where we could get better.

Word of our success got out and before too long CTOs from companies large and small were reaching out to learn more about how to improve their software delivery operations.

Building my ideal Software Engineering Intelligence Platform

After living through this same process several times, I realized the main blocker for software engineering teams was getting the metrics they needed. What if instead of relying on meetings with teams or spending months tracking down data points, I had a tool that plugged into all the tools I was already using and gave me visibility into how my team builds software?

That’s when I decided to build Treno. Treno arms software engineering management with real time information that allows them to make data decisions that foster continuous improvement. The data you need is already in Jira, GitHub, Sentry, Datadog, Slack and other tools, it’s just not readily accessible and not easy to calculate the metrics you’ll need.

Treno integrates directly with all of the tools used by your team and allows you to see, in detail, every commit, every merge, every error generated, every review and every deployment. It models how your teams actually work, identifies process improvements that increase productivity levels, and helps to improve the speed and output of their development process and quality of their released software.

Take the First Step to Delivering More Software, Faster

If you are like most engineering leaders that I know, at this point you’re probably thinking “here’s the part where Andre tries to sell me his product.” And you’re not entirely wrong, I do believe every software company could benefit from using Treno but I’m not going to try to sell it to you.

I believe that Treno is so easy to implement, and that the data it provides is so valuable, that it speaks for itself. For that reason, I’ve decided to offer a no-charge audit of your company’s SDLC. In this audit, you’ll have access to our software delivery experts and we will review your team’s SDLC, analyze any delivery problems you may have and allow you to see your DORA, SPACE and other key delivery metrics. And you will also be able to see how your team rates when compared with the best in the industry (see below):

If you’re interested in learning more, just schedule a 15 minute call via my calendar link. I’ll meet personally with your team to discuss options and see if an audit might be able to help your team.

>> Schedule your Appointment Here <<

Looking forward to connecting with you soon.