Sovos Case Study

I’m a director of technology at Sovos. Sovos is a tax and compliance company and I am head of technology for one of their business units. I’ve been here for about a year and I’m pretty familiar with software development analytics tools. I used one of my last job to significantly increase productivity.

When I came to Sovos, I immediately went for Waydev to see if we can have some of those same results here.

The work that developers are doing, it’s often hard to track. Productivity was generally very low due to the civil issues, but it was hard to prove that it was that way and have some kind of quantitative metrics and then also track improvement.

That lack of visibility and overall productivity issues were the reason we said

“Okay, well, we need some visibility. We need a way to track this and we need a way to coach our engineers the best practices for commits”

There definitely have been some tangible benefits. It was a slow start : introducing the tool, getting everything set up and working.

At the beginning it helped pose the question –  why are engineers less productive than they should be?

We uncovered certain systematic issues in terms of their development environment and tooling. We started to fix those one by one and we saw productivity rise. And now we’re starting to get into coaching engineers about their commit practices – instead of making a giant commit once a week, start to break up your work, think more in an agile fashion. As we all know that increases throughput and has a very positive influence on productivity.

We’re already seeing that in the past three months compared to the previous three months that productive throughput has almost doubled and the commits per day and active days have gone up – 20%, 30% each.

We’re definitely starting to feel some productivity gains and we are getting a lot fewer complaints from stakeholders and we still have a long way to go. With my last team, I was able to double productivity and I think we still have a journey ahead of us – in coaching and establishing those best practices.

I do have some of the other company executives looking over my shoulder to see what is this tool that we’re using? Could it benefit their engineering managers in terms of helping teams become more productive?

They’re interested and they’re curious to see the results. I’m waiting a little bit for the results to be more pronounced.

The visibility that it gives, especially across complex teams with over 200 repositories, is the tactical advantage our managers love and it’s a real benefit for helping them to do their job more effectively.

Any kind of cross team standard runs in a little bit of friction because software engineering is like a craftsman, a trade, or at least it seems that way. Standardization across teams is always met with a little bit of resistance, but we’re all professionals, we’re all here to do a job and working as a team versus individuals is much more effective and people generally get on board with that technical issues.

We did have to do an on-prem install, which means we’re in charge of our own destiny. We did have some issues on our end. But eventually we worked through all that as a team and we waited to make sure that the data is all there and it’s reliable before inviting the whole team in. These are the typical challenges with on prem. That set us back for a couple of months and working through those, we just wanted the introduction of the tool to be very positive and to have a very positive effect.

My favorite one is active days because if an engineer has maybe five or six active days in a four week period, something’s not right. Even if they took a week of vacation, something’s not right.

Looking in that metric is a really great place to start and coaching engineers on – what kind of work are you doing? Can we give you a better mix of work?

If they’re only doing bug fixes for four weeks straight, they’re probably going crazy. They make one or two commits, a couple of lines here and there, but it’s not very satisfying.

And so I think the metrics really bring to the surface issues that perhaps are making the team unhealthy. Maybe they’re having personal problems and they need some time off.

So Commits/Active day is a good next step. I think it’s a much better discipline to commit code every day, as a starting point and then work on committing multiple times a day. It’s much easier to make multiple commits in one day than it is to commit every day of the week. That’s definitely an area that we’re working on and bringing everybody above that threshold of an average of having four active days a week.

Definitely the interpretation of the metrics. Maybe suggestions like –  this person seems to be struggling or  this person’s doing great, give them a high five or the team is less productive this month.

These kind of high level interpretation suggestions of the metrics would help the managers understand how to use the tool without any coaching and guidance. It’’s definitely great presenting the metrics, comparing them, but what do they mean? And what should you do?

Entering into that arena of providing advice and guidance would be good.