In this 7-minute video, Enterprise Coach Randy Hale interviews Principal Software Engineer Joshua Meriyah on the biggest challenges impacting development teams.
They focus on technical debt and organizational strategies to prevent debt from bankrupting your teams and product.
Technical Debt Video Transcript
Randy Hale
This is Randy Hale and I’m here with Josh Meriyah, who’s one of the key leaders in our technology organization. We’ve been talking about creating the right environment to enable improved team performance.
I wanted to definitely hear from Josh on his perspective here. Josh, what are some of the more important challenges that you’ve been facing lately?
Joshua Meriyah
I was hired here to work at Path to Agility and when I started working for this software, we had some huge challenges in terms of the software. At that point, it had been entirely written by contractors and we didn’t have anyone in-house overseeing it. We had some serious quality issues so we had a lot of debt when I first got here.
The question was, how do we clean up that debt effectively?
How do we make sure that we’re still adding value to the company, but while we’re adding value to the company, we’re doing it in a way that our quality is going to get better and that our software is gonna be reliable.
And we’re delivering in a way that feels like it’s sustainable.
Randy Hale
Absolutely. That is definitely a consistent challenge. I see it in organizations that I work with is how do you create that healthy balance of we need to be evolving, we need to be continually solving bigger and better problems for our customers and users, and how do we balance that with the technical debt?
I often like to describe that there’s different kinds of technical debt. There’s the mortgage kind of technical debt which is, a savvy, intentional, long-term beneficial balance.
But then there are some types of technical debt I correlate to more like your 26% credit card that maybe you should pay that off a little quicker.
How is that kind of dynamic showing up in your world?
Joshua Meriyah
When I talk about technical debt, I I would say to my team that technical debt has compound interest. So if we’re going into a code base and it’s a mess, and we just add to that mess, that software is going to be harder and harder to get clean as we go along. We’re going to have more and more problems.
Any time that we touch something, it is top in our minds. How do I do this in the right way? How do I look at the way it’s been done? How do I make sure that I get this in a way that the next person is going to have an easier time looking at this, easier time fixing this or changing it, which are the most dangerous things we can do to code is make a change to it.
Randy Hale
As a leader, what are some of the things that work for you to help calibrate that balance on building something new versus retiring technical debt?
Joshua Meriyah
There has to be a cultural component to this that we have to have an agreement obviously within our team. I think a lot of software teams really do. A lot of software teams, if you said, “hey, you can spend the next week just paying down your debt, they’re overjoyed to do that, right?”
So the question is, can you get the rest of the company to buy in?
Because with the company, [it looks like] they just spent a week doing a bunch of stuff to the software that’s not going to impact users directly.
They don’t necessarily feel good.
So you have to have buy-in. You have to have good communication with your product leader and with everyone who’s on the other side of the company to say, “hey, [addressing technical debt] is worth it in the long run.”
Your features might not come at the super fast pace that you might have gotten them otherwise, but it’s going to be reliable in the long run, you can count on it.
And when you need new features, we’re going to be able to do that over time much quicker because changing and [maintaining] the code is going to be much easier.
Randy Hale
The thing I like about what you just said, it rings so true for me in the work that I do with organizations who are also in pursuit of better, is we need to make sure that the measures that leaders are looking at have the right balance as well because it’s very easy to steer the organization to a subset of metrics that are lacking that health dimension.
What’s the health of our code base? What’s the health of our team?
To your point, as an engineer if there’s areas of the code base that [you] dread having to go do work there, that’s not a great feeling.
There’s a multifaceted aspect to making sure the right focus on the right blend of things is there.
It’s not just about being a feature factory cranking out new capabilities because at some time you’ll hit a breaking point.
Joshua Meriyah
I think there’s a level at which people understand that. It depends somewhat on maturity of the company, right? When people are in startup mode, you just need to get stuff out and you want to see things. If you just kind get used to that,more, more, more, build, build, build, the idea of slowing down and introducing that element of quality can be scary.
But I think when it’s explained, what happens when you’re in that build, build, build is things start to break, you start to see that this isn’t going the way that I actually wanted it to.
So now you’re demanding tons of fixes on top of tons of features and nobody’s keeping up.
That’s when youhit that level of, we have to change the way that we’re doing things and we have to have some different agreements.
Randy Hale
What do you wish was sort of a universal truth for technology teams
Joshua Meriyah
In terms of this, relating to tech debt, the biggest thing is having the standards and the agreements of this is what good code actually looks like. I think most people mostly agree, you can argue over some of the smaller things about some ways you do things. Mostly can I go into this, understand it really quickly and be able to work with that.
So it’s really about [creating] those standards and then can we work with the business so that they’ll give us the time that we can enforce those standards, that we can make sure that we’re writing to the standards?
If you’re working at breakneck speed, the first thing that goes is your standards.
Randy Hale
I think there’s really sage wisdom, guidance for everyone to take away from this conversation, Josh.
It’s been great focusing on this important topic with you and we look forward to the next conversation.
About the Authors
Principal Software Engineer Joshua Meriyah is a senior developer and engineering manager with a passion for education and creating software that can improve people’s lives. Joshua joined Agile Velocity with experience in both creating his own cloud-based educational software and leading high-performing corporate teams of developers. Joshua works from a foundational principle that writing software constitutes a unique and valuable form of service–the best code can create helpful and high-quality experiences for end users, while also supporting developers to understand the purpose and function of each part of the code.
Prior to his current career, Joshua worked as a public school teacher in Baltimore city, where he strove to inspire his students to develop the discipline, determination, and belief in themselves to live their dreams. Joshua is a certified teacher of meditation and yoga. Outside of work, he loves to spend time adventuring, being active and baking bread with his family–wife Kelsey, daughter Sage, and crazy puppy Sitali.
Randy Hale has been guiding companies through Agile transformations for over 10 years. He has worked with companies of all shapes and sizes, from startups to Fortune 500 companies, including Nike, Petco, CenturyLink, Rockwell Automation, and Charter Communications. Big or small, every business has potential but can be hard to see the path forward when all you can see are the minutiae, problems, and pain points.
As a Transformation Coach, Randy brings his knowledge and training to each business, guiding them to greater success through Agile and Lean thinking. Randy has experience with Enterprise Lean-Agile Transformation and Product Development Strategy. His deep background in Agile consulting means that Randy knows how to focus on the most important issues for each business he coaches. He is an experienced leader in driving strategic organizational, product portfolio, cultural, and process change.
Randy has trained leaders and executives, both individuals and teams, in Agile thinking methods. His experience in Enterprise Agile Transformation and Product Strategy and Implementation brings hands-on knowledge to each training scenario, helping businesses learn and grow from past mistakes.
