AI is a TOOL, Not An Employee w/ Winston Astrachan | Episode 199

Speaker A: AI is a tool. AI is not a developer today. AI is not an employee. AI is a tool that you can use as the talented engineer I hired you to be. And the second component is that you, as the user of that tool, are always accountable for what you do with it.

Speaker B: Welcome to Software Leaders Uncensored. I'm Steve Taplin and I get the privilege every episode sitting down with tech and engineering leaders to understand what's working, what's breaking and how SaaS enabled software companies are scaling in these crazy times. After over 195 conversations, we're seeing a lot of patterns form. In fact, we just released our initial report based on our first 195 episodes called why Software Projects Fail. And it is a collection of all the insight from the great leaders we've had that is available for free download. And that's what this show is all about. Identifying the trends, talking to smart people, seeing how they're working through challenges. Today we have Winston Astrokan who is the CTO at a company called Phobio. And he is going to talk about the challenges he's dealing with that we all are of doing more with less and how to be more efficient in these current times of AI dominating everything. Winston, welcome, buddy.

Speaker A: Thank you, Steve. It's a pleasure to be here with you.

Speaker B: So, uh, tell our audience about your company, Phobio.

Speaker A: Yeah, I'd be happy to. Phobio has been many, many things over the years and will definitely be many things in the future. But at our core, we are a company that is determined, uh, to find value in technology. And that's consumer technology. Cell phones, laptops, that's enterprise technology. We run a series of buyback programs across the industry. Uh, we run the program for Costco, we created the program for Apple. We have some of the largest MSPs in North America using our enterprise buyback services. So at our core, that is our identity, that is what we do. And we have a series of products and tools that enable that for our partners and customers.

Speaker B: You guys have had great success, you have great enterprise clients. Is this a crowded space?

Speaker A: It is a space that can be crowded, but what we've found is that most of the heaviest competition in this space isn't other companies doing what Phobio does, it's our customers themselves.

Speaker B: Okay.

Speaker A: One of the biggest battles that we've had to fight is our customers thinking, well, we could take this in house, we could do this ourselves. There's no secret sauce. All you're doing is buying widgets and selling widgets And a lot of our biggest competition is trying to convince those customers and partners that really there, there is a secret sauce, there is methodology, and there is a value that we offer that's very hard to replicate with an in house program.

Speaker B: Awesome. All right, so at your company, what is the work model? Are you in office, hybrid, remote, all the above?

Speaker A: We are fully remote. We have an office address, it is space, it has conference rooms. We don't use it. Um, we were like many companies in the wonderful infamous 2020, 2021 era where we uh, let go of our office lease because we were paying for a big chunk of space down in Atlanta and it was not getting used and we decided to let it go. And we have been remote ever since. It has been highly successful for Phobia. We've developed a really strong work culture surrounding that. Um, and we've, we are one of maybe the rarer cases where we have seen increases in productivity over the years since breaking up with the traditional in office model. So it's, it's been a great thing for us. Um, but we have been fully remote for the past six years.

Speaker B: So talk about your product and engineering organization, how many people you have, where they're located, whether it's all in the US or in other countries.

Speaker A: Yeah, product and engineering is a lean team and that's kind of been the name of the game. You hinted to it in your intro to the episode Doing more with Less. But we, we have a product and engineering team of less than 10. Um, and we have gone up against companies with 30 to 50 count, if I'm not mistaken. Engineering teams and constantly managed to swing well above our engineering weight class. We are all United States based engineers and product managers were spread out coast to coast. We have had engineers in California, engineers in Chicago, engineers in the Midwest, all across the country, spread out all different time zones, but all working together every day in that virtual format.

Speaker B: So tell our listeners about the platform you have that we were talking about previously before the show and then kind of some unique things that are future projects that you plan on adding.

Speaker A: Yes, definitely. Our platform is everything we do and we. One of our unique things about Phobio is that we make all of what we use. I mean obviously things like Zoom and Slack, there's no need to reinvent the wheel. But everything from the way we do pricing, the way we acquire trades, our business operations, inventory, even how we sell the product as part of our platform, we have two really major flagship products. We have a product called Flex, which is what consumers would Use. You know Steve, if you went to Costco and heard about a, ah, program in which you could trade in your phone for, you know, a shop card, get some holiday shopping done way, way early. That's our Flex. And then we also have an enterprise product called Phobia for business. Award winning enterprise products that we position toward managed service providers. We work with some of the largest MSPs in North America as well as small and medium enterprise that just want a better solution for their technology life cycle. On the other side, obviously I mentioned we have all of our internal platform for how we grade and inventory and sell. But then we finally have a product called assembly which is an auction platform and obviously hand in hand with buying and selling devices that gives us an easy source to uh, to sell these to a network of qualified buyers. So in a nutshell that's what Phobia does and we've built it all over the past 15 years and we'll continue building it in the foreseeable future.

Speaker B: Yeah, I was going to say what are some cool features that you guys are working on that you can talk about, you know, with, you know, the theme of doing more with less and constantly innovating.

Speaker A: Well, the big thing that's coming up Steve, is uh, we have spent more than a decade curating the tools and the process and the methodology. And I mentioned to you earlier, our biggest competition is not other companies, it's our customers. We are undertaking an endeavor to take our product and break it down into modules and make it available to the world as a SaaS offering. We know that there will always be compelling reasons to hold onto your inventory. Let's say that you're a carrier and you know that you have an insurance program that you need to service and you want all of these devices to stay in network. Great. We want to enable that. So we are working to evolve from being a buyback company into a company that powers the technology of buyback and the technology behind retail. So that's the next big thing on the horizon that we're undertaking is taking all of this knowledge we have and making that in itself a product.

Speaker B: Nice. Very nice. So talk about engineering challenges in your space that are unique to your industry, whether it's the buyback industry or having to work with so many different, touching so many different people and entities in the process.

Speaker A: Yeah, definitely, uh, this is one where I probably could fill two or three episodes with the answers to that question. But the biggest thing I think that is a challenge for us working in this industry from an engineering standpoint. Is how quickly things change. We have to adapt to manufacturers that we don't necessarily have direct connections with or any insider information. They change something about their product and it can impact all of the way we do our business. And I, I think about a big, big example. I remember the day that we were watching Apple give a presentation and they announced for the first time that starting next week a thing called find my iPhone would exist. And good news for consumers. Find my iPhone will be on by default. You don't have to do anything. And we finished watching this presentation the same day the world heard it and we went, that's it, that's our business. We're done. We're going to get all these iPhones. You know, at this point a majority of our business was iPhones. We're going to get all these iPhones and we can't sell them, they'll be worthless. They'll be bricked six days we had to figure out how to check for this lock that nobody heard of, how to position it, how to train retail reps, how to work it into our product and into our operations to save the business. And obviously, you know, this is now we're 20, 26, we're well in to find my iPhone. We did it. That comes up all the time, not always at that scale, but it might be a partner saying, well, we need to do this kind of promotion and if you can't do it in four days, we gotta, we can't do trade anymore. It might be a uh, manufacturer introducing a new security feature that we have to be able to identify or price for. Always, always, always the industry throws something new. And our superpower from an engineering department, owning our own product and our own life cycle is we can adapt and we can do it quickly and we can do it before everyone else.

Speaker B: So along those lines with, so having this challenge of the trade in buyback space that you work with a lot of manufacturers, you're not necessarily completely tied in with them. Um, so they're probably not sending you alerts when they're changing something. How does your team be proactive on staying on top of those things?

Speaker A: We maintain a constant priority exercise. And a lot of the times for us that looks like a weekly standing meeting with our engineering leadership and our product leadership where all we talk about is priority. This is not Sprint planning. This is not anything in the weeds. This conversation exists simply to discuss. Is what we thought was important seven days ago still important today? Every week like clockwork, we talk about this. And almost every week that shifts maybe not dramatically. Maybe not, you know, to the same tune as my find, uh, my iPhone example. But every week we sit down and say, is what we thought was important last week still important? And we're constantly pivoting because you're right. No inside information. Most of these manufacturers, we have no notice at all. We learn when the world learns. We have to be quick when they tell us.

Speaker B: That'll keep you on your toes. Winston, let's touch on your journey with the company. You were engineer number two and have been with the company over 13 years. Now you're the CTO. It's phenomenal and it's almost kind of rare in these parks or in this generation over the past 10 plus years because normally people are forced to jump around, talk about your leadership journey there. And you know, I think all of our parents always said this is what you're supposed to do, but times have evolved, but you've actually done it.

Speaker A: Yes, not without great difficulty, but it's a journey that I.

Speaker B: It's all about solving challenges.

Speaker A: Yeah, It's a journey I'm really proud of. So like you said, I started at Phobio over 13 years ago. I started when I was still finishing up my undergraduate degree and I would go to work in the morning and I would work and then I would drive down and take classes from 9 to 11pm to finish up that degree. And I grew from being engineer number two into DevOps. I built the DevOps organization because with one engineer, we had nothing.

Speaker B: Right.

Speaker A: I grew into engineering leadership. And then ultimately the journey culminated earlier this year in me taking on the CTO role. And I, you know, I kind of chuckled internally when you mentioned what we were told to do in all of this. Constantly my mentors, constantly my peers were saying, you've been there too long, you gotta go. You're, you're hampering your career, you're destroying your career. You can't stay at a company three years max. I disagreed because what I was doing was learning and growing something we all have to do constantly. That was school, that was, that was mentorships, that was experience. And I was building what I needed, but at the same time I was developing a really deep industry and company specific knowledge. So when I got to the point where I was ready to take on C suite leadership, I not only had the hard skills, I had such a knowledge of everything that had happened in this space and at this company. It kind of supercharged what I was able to offer. If I had been making this growth journey at other companies, it's entirely possible I'd be in my role at another company, but I wouldn't have anything but my learning. I wouldn't have the deep. The deep connected knowledge from the journey, and that has enabled me to really get in and make some. Some strategic choices with. With information that I don't think I otherwise would have had. So it's been a really interesting journey, and it's. It's been one where, you know, lots of people have told me it wasn't the right way to go, but I've loved every step of it, and I love what I get to contribute and do every day. So I would say, you know, it's worked out for me.

Speaker B: It says a lot about the company and the investment they made in you. You don't see that as much anymore, and that's sad. But, uh, I love it. You. You broke the mold.

Speaker A: I. Yeah, I. I do. And. And a lot of credit to Phobio and our founders. Uh, like you said, you don't see it, but were. We're huge on that. I mean, the number of employees that I've had, including on my own team, who have left for other opportunities or personal reasons and then returned because, you know, and I'll quote one of my engineers, I just never found anything I liked as much. And that, for me is such a powerful thing that I try to embody with my leadership, is that. That trust and that growth and the. I want people to be able to say, I want to come back. I want people to retire with us. And that's not something you see anymore. It's always, where do we get more output, where are we going? Who's our 10x engineer, and we're moving on. And for me, it's. I want good engineers, but I also want engineers that would love to stay very nice.

Speaker B: So as. As the company has grown from an engineering being the cto, what. What's getting harder as your company keeps growing?

Speaker A: There's really. Well, there's a lot of things, but I'll. I'll focus on a couple as they're relevant to everything going on in the world today. Uh, the first is navigating AI and what that does for us, what it doesn't do for us, how it positions us as an engineering firm and as a technology firm. We have to figure out where the pieces fit in in a way that benefit everybody and don't force really talented engineers out and don't cause an overwhelming workload on product or qa. We have to navigate that. In the same vein, there's constantly pressure to do more with less. Part of what's made our team very successful is that we can output massive amounts of code and technology with always a lean team. I don't think we've ever had more than 10 engineers in our company history at a single time. But the other leadership and the rest of the C suite, you get used to this level of output, so you start to expect more and more and more and constantly having to balance the demands for output with my demands for quality. My M demands for uptime. I'm not going to accept a 1.9uptime. I've seen a lot of companies say, well, you know, we've developed so fast. This is the price we pay. I was in a meeting, I was in a roundtable a couple weeks ago where this question was asked of a very, very large billion with a B company, you know, how do you maintain quality? And the answer was, we don't. Things will break. That's okay. We just want to answer. Yeah, it is an answer. But I, I, I demand more. The, the carrier partners we work with demand more. So how do I balance the need for speed and the need for output with the quality that I think every customer of ours deserves? Those are huge for me as we're

Speaker B: now halfway through 2026. I know a big challenge that me and my company see in the marketplace is that engineers are doing a good job of using coding assistance and tools to help them be more productive. And the bottlenecks are changing from it used to always be every engineering, uh, and I'm seeing the bottlenecks shifting a lot to the product side, sometimes even to the deployment side. What are some things you're seeing that are slowing down your engineering or product teams?

Speaker A: It's interesting because for us, I will say I have seen that it's not as big a problem for phobia at the moment because there's only so much you can accelerate a team of that size. And we scale the other elements too. If we need more, more product pipeline, we work on that. I'm sure we're going to hit it. But the big thing that we see is deciding what to do and when we. And, um, I talked about this earlier on the episode, but we need to be incredibly timely reacting to industry changes, and we have to do that at the right time. But likewise, there are other things that we can't wait on too long to do or the opportunity will have passed. So one of the biggest things actually that slows us down is knowing what to do next. And I Guess we could call that a product challenge, but it's almost in some ways an industry and market challenge because the industry hasn't necessarily spat out what we're going to do next. So it's a gap of information that helps us be prepared to start that right project at the right time. I'm sure we're going to see more of these issues as engineering output ramps up. How do we test? How do we deploy? For me and my policy, always humans. At the end of the process, there will be no, you know, AI approved features, no AI completed testing. I need my people to sign off on it. But for us today, it's all a priority question and it's a knowledge question as to what's, what's going to be the next thing for the industry.

Speaker B: So building on that and we, of course, there's a lot of industry stats out there of how people are working throughout the software development life cycle. Uh, when you look at, you know, the quote unquote industry sources, they'll normally say that the product team needs to have enough approved features made it through the backlog to cover a minimum of three sprints. Are you guys meeting that? What are you seeing?

Speaker A: We, we don't buy it. I mean, I, I'm not going to say there isn't a lot of legitimacy to it. And there are so many methods of managing sdlc. There are so many ways to manage products. I can't afford to have my product organization spending a quarter of their energy with a process. We measure success on a constant stream of things getting done and getting done correctly. There is no number, there is no, oh, we need, you know, three features, three sprints. Our success is, are we continually hitting the targets we need to hit with quality? And I think largely, and I may be wrong, and that's okay, but it works really well for us largely. We're going to meet the same goals. We're just doing it without the same amount of framework and without the same, you know, sprint planning scrum, all this stuff, it's valuable in the right context. But with a team like ours where we can get everyone on a call and say, you're doing X, you're doing Y, you're doing Z. Here's the expectation, we'll talk in three days. It doesn't add value for us. It's just a lot of noise.

Speaker B: Let me challenge you here. So you have a lean team, you set around 10 people on product and engineering, so you're able to do some things that larger organizations can't. Let's Say you guys blow up and in 12 to 24 months you have over 200 people on product and engineering. How would that shift for you?

Speaker A: It would probably shift everything. I mean, and that's kind of, I think the beauty of thinking about things scientifically is I accept that what I know today, based on all the information I have, is correct. I may come and talk to you again in 24 months at a different scale team and say, here are the methodologies I subscribe to and here's what works. But I can't. I think the big thing for me, Steve, is I can't shoehorn something that isn't made for something of my size or structure in just because a talking head on LinkedIn said so. And I recognize that I'm, uh, a talking head on, you know, I recognize that that's going to ruffle some feathers. But I have to do what works today for my organization, and that won't be what works tomorrow. But that's the exciting challenge of growth.

Speaker B: So are you telling me, like, if we were to look in your backlog, you wouldn't have a backlog of hundreds and hundreds, uh, if not more Items where maybe 50 to 75% of those should even be in there anymore? Like, it should be cleaned up.

Speaker A: It's probably 20% of those items need to be cleaned up. We do backlog reviews pretty, pretty frequently.

Speaker B: Okay.

Speaker A: And again, that kind of goes back to that, that ongoing conversation about priority. There are certainly things in the backlog that are a year old that, uh, suddenly, because of a change or something a partner needs, have immediately skyrocket to the top of the list. They just become relevant overnight. We, I mean, we do have plenty of backlog and there are plenty of things that don't belong on there, but I think that's kind of, that's always going to be the case, regardless of your methodology. I've never seen somebody totally tackle the backlog problem in any of these frameworks.

Speaker B: It's something everybody is dealing with, to say the least. Now, you have been with your company over 13 years. As an engineer, I gotta imagine you guys have a decent amount of tech debt built up. How do you guys manage moving forward quickly while managing existing tech debt that might be slowing you down?

Speaker A: The best we can? I mean, it's a fair answer, and I think it's probably what anyone would tell you. Uh, in reality, my team tries to be judicious about constantly fitting things in. We can't handle all of the tech debt all of the time, but we try to make sure that at any given point something is getting worked on. We don't do, you know, here's a feature Sprint now. We're going to do a maintenance Sprint now. I mean we, we do our best to say, okay, you know, here are the three big new feature projects we're working on. What's the tech debt item we're going to address at the same time? And bonus points if it ties back into a feature. You know, I can think of a good example of how that, how that plays. You know, we're, let's say we're building a new inspection journey for this future SaaS offering to make it more intuitive for companies to process devices coming in. I know that I have four tech debt items that are related to this journey. I have one that is to upgrade to a new version of an API for checking lost stolen statuses. I know that I have one to handle an image compression pipeline for inspection images. Great. That code is getting touched. We're now pulling those forward. We don't need to wait for a dedicated time. We're going to find a way to balance that effectively with what we need to get done.

Speaker B: Makes sense. Makes sense. Let's go back to the question on AI throughout the software development life cycle.

Speaker A: Mhm.

Speaker B: And you made a comment earlier. You don't want AI involved in any testing. Where are you guys using AI? Whether it's on the product side, throughout engineering, throughout testing and deployment versus where are you not? And give me the justification.

Speaker A: Sure. The, the, the gist of it is if I'm going to condense the policy and structures that we use it up to, but not including the commit and my thought process on this. And the justification is I with my team espouse really two big core criteria for AI use. The first is AI is a tool. AI is not a developer today. AI is not an employee. AI is a tool that you can use as the talented engineer I hired you to be. And the second component is that you as the user of that tool are always accountable for what you do with it. And so I draw the line right now at the commit, when you open a pull request, you are representing to your teammates that this is the best that you can give us. And I don't really care if you used a QWERTY keyboard or Dvorak keyboard, if you did text to speech, if you did it with an agent. At the end of the day, when you share that with your peers and ask for their time, you represent that this is the best you've got to give and that is where we build that accountability boundary. Because nobody wants to have their peers say, hey Winston, you did a bad job. You missed all of this. You've got an anti pattern here. You've imp, you know, you've made a memory leak. But I, I am going to be under the same scrutiny, whether it's me contributing the code that I wrote or me contributing code that I used a tool for. And that's in our life cycle where we put that accountability boundary. And it's been really good for us. We've had, I think four would have been, you know, almost downtime level P0, P1 bugs that have been mitigated because people have taken the time to look at their code before they get that review. And I know it seems like it should be a given, but at so many, at so many companies in the industry, that's gone. It's how quick can I get the feature? It, uh, checked the boxes, the automate, and in all of these cases, Steve, the test harness went green. You know, we have something like 6,700 unit tests and in all of these cases, all of them went green. Because AI can run those same tests. It can adapt to make sure that those tests all go green. So I'm, um, kind of, you know, in a very long winded way saying for us the rule is use it. Use it like a tool. Use it in a way that you can be accountable for or don't. I don't care. I just need your best. I need your best every day.

Speaker B: So let's say nothing changes in your engineering organization at all. You guys keep how you're doing it. Let's just say you're not. You don't continue to adopt or over adopt AI or other new things that come out. What will break first in the next 12 to 24 months?

Speaker A: I certainly hope the answer is nothing will break in 12 to 24 months.

Speaker B: Last time I checked, the world of engineering is far from perfect.

Speaker A: Yep.

Speaker B: And it's not, it's not if problems occur, it's when.

Speaker A: Yep, you are, you are totally right. The most likely thing that's going to break in the next 12 to 24 months is that this lean team will have had all the juice squeezed from it and we won't be able to keep up anymore. And that is a problem that I am thrilled to be able to face because I know there are a lot of really talented engineers out there and I'd love to work with them and I'd love to be able to, you know, come back and tell you that I was, you know, my, my approach on, um, not adopting all of these rigid structures for, for project management have, you, uh, know we've outgrown that. But the, the thing that's going to break for us, I think, in the next 12 to 24 months at the scale that we want to reach, transitioning more to software as our primary offering, it's going to be the size of the team. We're going to need more, and I can't wait for that challenge.

Speaker B: All right, Winston, last question. But what advice do you have for other engineering leaders out there who have gone through what you have?

Speaker A: I'm going to pivot back to the AI component for advice. If the person selling you the thing is going to make a lot of money if you buy it, think about their intentions before you buy it. And that's not just cash. That's not just capital outlay. That's strategy. And I think a lot about the people who tell us, your engineers need to be spending their entire salary worth of tokens in a year or they're no good. Great. How much money do you make when they do? And that would be my, uh, advice to other engineering leaders and tech leaders. Right now. The answer might be that the intentions are good and the advice is good and everything being sold to you is good. And, uh, certainly again, back to AI. We've seen good success, but consider. Consider what the sender of the message stands to gain if you receive it and make good judgment, make strategic judgment and make good choices for your business and your team.

Speaker B: I like that. And that is a unique answer that makes a lot of sense. Winston, thank you so much. It was great getting uncensored, um, with you today. That's it for this episode of Software Leaders Uncensored. If you're leading an engineering or tech organization, any of these patterns sound familiar? Make sure you hit subscribe. Also, we have our recent report, why Software Projects Fail, based on the first 195 episodes of this podcast. This isn't some fluff survey data. This is hearing from experts like Winston who are out there fighting the good fight every day. I'm Steve Taplin. See you next time. That's a wrap. Another great episode of Software Leaders Uncensored. Thank you guys so much for listening.

Speaker A: I really appreciate it.

Speaker B: It's a lot of fun doing this show. I love talking with great tech leaders. As a side note, if you're interested, check out my new book, fail Hard, Win Big. This is the story of how I built 30 companies failed on 20 and turned 10 into multi million dollar wins. The common thread with all of them was custom software also. Ah, if you need software development help out there, My company Synodify Technology, we deliver world class software development engineers out of Latin America. We have a solid track record of helping companies launch better products and faster. Thanks again for listening. Appreciate it and appreciate you.