Is Internal Tooling Holding Your Team Back? | DevZero’s Debosmit Ray

**Debosmit Ray** (0:00)
An engineer is never wrong, even when they are. And so if you ever ask an engineer to use a tool they don't like, they won't do it. If you ask them to turn left, they'll turn right.
So at that point in time, it's very important to first explain what value propositions the tool will actually bring to the engineering team. And then you all need to be very, very focused on making these tools very simple and easy to use. And once they see the value and actually derive the value in their day-to-day workflows, they will end up being your biggest champion.

**Conor Bronsdon** (0:33)
Are you an engineering leader and tired of constantly being asked when will it be ready? Stay one step ahead with Linear B's project delivery feature. Our powerful dashboard lets you visualize key milestones, forecast delivery accurately, and align stakeholders effortlessly.
With Linear B's product delivery, you can confidently showcase your planning, prioritize work effectively, and even make data-driven cases for additional headcount. Say goodbye to delays and missed milestones. Sign up for Linear B today and answer when will it be ready before anyone even asks.
Hey, everyone, welcome back to Dev Interrupted. This is your co-host, Conor Bronsdon. And today I'm delighted to be joined by Debo Ray, co-founder and CEO at DevZero. Debo, welcome to the show.

**Debosmit Ray** (1:21)
Thanks so much for having me, Conor.

**Conor Bronsdon** (1:24)
My pleasure. Before you founded DevZero, you had a really fascinating career as a staff engineer at Uber, where you worked in infrastructure and product security.
You've also founded two other companies before starting DevZero. So you're a perfect guest for us, particularly because, and I want to give you a bit of a shout out here, you graduated from my alma mater, the University of Washington. Go dogs.

**Debosmit Ray** (1:45)
Yes, the best school ever.

**Conor Bronsdon** (1:48)
Amen. It's clear that you are someone who's very passionate in everything you do, whether it's your work at Uber or DevTooling, something that you worked in deeply, both at Uber on the infrastructure side, you're on a mission to unlock developer potential is kind of how we've seen it defined for you.
And that makes you a kind of kindred spirit for us because at Linear B, we think a lot about these concepts and we both agree that when you get the tooling right, you make the developers' lives better and you make them happier, which the great thing is that helps engineering leaders, engineering teams produce higher quality work, produce things faster. So I want to kick off this interview with something you said before the show started, which is engineers join companies to do good work and help the business, but are held back by internal tooling.

**Debosmit Ray** (2:36)
Conor, like us developers, right, we join companies because we care about the mission and also about the learning opportunities that we'll gain in service of that mission.
And fundamentally as developers, we also have a pretty high bar for quality. Like there is this inner gauge that we have, which tells us whether a product or a feature or a service that we have shipped, if it's indeed good or not. And at the same time, we are also very impatient as people. And usually the path for me to launch and get some feedback on this new feature is often a pretty arduous one. And I have all of this context in my head.
And I just want to, I've written some code and I want to see this thing working end to end. And as developers, normally in companies, we have to go through these almost doilsome dev cycles where I'm constantly changing my mental context. And this is quite challenging and often unproductive in my opinion. And this is generally what we call the inner loop of software development. I want to constantly be in this state. That is where magic and creativity, everything's happening. But we end up spending most of our time in the other drudgerous aspects of software development. Be it debugging issues related to the environments that we are working in and all of the inconsistencies there, or being able to access some data so I can actually test this feature end to end, or actually trying to figure out what the best way to call the sister team's products or services is.
The worst one is when I actually have to get into a meeting and drive consensus with fellow teams. So, yeah.

**Conor Bronsdon** (4:16)
Yeah, it's tough because of the obviously crucial things for a development team. But most devs have been trained to be this kind of focused individual problem solver. And as we get into larger companies where you're relying on a lot of other people to get big products done, which is how you achieve incredible things, great teams, people don't necessarily have the tools, training, or time to make some of these team dynamics work the way they want to.