This is a transcript. For the full video, see More affordable doesn't necessarily mean better: Challenging the false economy of low-cost contractors - Tag1 TeamTalk #020.
Preston So: [00:00:00] Hello, and welcome to Tag1 TeamTalks, the Tag1 webinar series about emerging web technologies. Today's episode is going to be about a topic that I think is very near and dear to a lot of us who work in the agency and consultancy world, the false economy of low cost contractors.
It's a very common misconception that you know, less expensive or more affordable resources can help you save money in the long run. Um, well, let's go ahead and challenge that myth there. I'm Preston So, I'm the editor in chief at Tag1, and I'll be the host of today's talk joining you here from New York City.
I'm joined today by two of my dear colleagues and friends. First, Peta Hoyes in New York City. She is the chief operating officer and one of the partners behind Tag1, as well as Michael Meyers, joining us from the Berkshires, Massachusetts, managing director at Tag1. So Michael, quick question for you, what exactly is this kind of false economy of cheap labor that we're talking about today?
Michael Meyers: [00:00:52] Thanks, Preston. You nailed it in the opening. I mean, too often, people believe that hiring inexpensive resources for a project is going to save the money. And what we're going to talk about today is that. in most cases, in fact, the opposite is true. And like you said, whether you're an independent contractor, whether you're an agency, this is something that I think that we all deal with on a regular basis.
Um, it's not surprising to me that this comes from new clients, you know, people that we haven't worked with before, where, you know, there isn't a disaster that they're coming from. but you know, more surprising to me, you know, Tag1 does a lot of emergency rescue gigs. people come to us because they did hire an inexpensive agency or an agency that got in over their head and they couldn't deliver.
And we ended up working with these organizations for years and things go great. And then they turn around and say, Oh my God, why are we spending all this money on these projects?
And so, you know,, even an organization that learned this the hard way too often, once things start to go well again, you know, revert to that.
and you know, I think. I think there's two, two main problems, you know, psychologically. And one is that you want to believe it, right? You don't want to spend a lot of money. It's this really alluring siren song. and, and no one's immune to it. Like, you know, even though we make this argument, you know, every day to our clients and, you know, and, and new prospects, You know, we were recently hiring for one of our internal software products Tag1 Quo, and we had to have this argument with ourselves.
And so it's just, it's too easy to believe. You want to believe that you're going to save money. And what we're going to dig into is the various aspects of this myth.
Preston So: [00:02:33] I think it's very interesting, the way you phrased it there. you know, it's a very alluring kind of siren song. It's a very, you know, kind of great thing that we hear a lot about, but it's also a very deceptive kind of a thing. so why exactly is, this kind of notion that, you know, hiring somebody who's a more affordable or low cost contractor translates directly into greater success?
Why exactly is this something that we need to challenge?
Peta Hoyes: [00:02:57] So I'll take that one. Um, you know, software, I think in recent years has people have thought that had it has become a commodity business and that is completely false. And, you know, that it's evolved to a point where any engineer can quickly assemble software, from different components that are already out there and basically build solutions in a day or two and no big, no big deal.
You don't have to put a big investment into it. Um, you know, and while it is true, that technology is very Legolike, I guess, you know, it's quick, it's reusable. You know, and, and small teams can have a big impact, but ultimately Lego isn't the same as replacing architecture. you know, there are big differences for instance between building the foundation of a high rise building versus building, you know, building the foundation of a two bedroom ranch, you know, especially if you're doing it in sand, you know, where everything shifts and there are lots of unpredictable, unstable mediums and unknowns.
So, you know, there are other things like, I call it the, I like to call it the Frankenstein effect. How many organizations have you ever worked with that have just one big monolithic system that they build everything in. I don't think there are any like that anymore. So you have to figure out how to cobble together or how to make these large complicated systems that have a patchwork of different tools, work together, optimally.
You know, the other thing I'd say is that, you know, building high availability systems, not just something that's a prototype that you've put out there in the world to prove your business case, but something that ultimately will perform well, because if you don't, if it doesn't perform well, even if you prove your business, someone wants it.
That doesn't mean that you can have everyone come and buy it or use it. Right. so building high availability systems is more of a science. Then it is a commodity and that requires knowing best practices, right? At different layers, hardware, software, databases, network. it requires having foresight, predicting where systems might fail.
Um, it takes innovation, um, you know, Facebook and Google do this really well. Right. They're constantly innovating, different kinds of databases or monitoring or caching algorithms. And sometimes it even takes a little bit of luck, right? Because people use systems in ways that we don't predict. So you can't always, it takes a little bit of guesswork sometimes.
And ultimately success itself is not a technology solo kind of venture. you have to have good communicators and communication to understand what the core problems are. you have to have independent focused workers. You know, they don't need a lot of management overhead and they can sustain their focus and they can prioritize what needs to get done.
And ultimately, they have to be empowered to make decisions and learn from mistakes that they may make. That's pretty much, you know, why I think it being a commodity business, isn't it isn't true anymore.
Preston So: [00:06:11] I think given a lot of the case studies that we've seen coming out of Tag1, this is born out, in, in the great deal of truth.
I think a lot of people are looking for that next level of expertise that you mentioned, Peta, where, you know, we want to have really, really talented developers who aren't just going to put a, you know, pieces together and just kind of connect the dots and, and, you know, cross all the wires. I guess, you know, turning to,~~, ~~kind of questions of revenue and questions of being able to manage one of these kind of projects, what is the business impact of, of kind of acknowledging this myth and saying that, you know, this is actually a really kind of false thing.
You know, we really do need to have people who are very, very specialized, very skilled, be able to do these things.
Michael Meyers: [00:06:56] Yeah.
The, the true cost of a software project, isn't the hourly rate. Or the project costs, that's just a factor, there's value that it generates for your business or, you know, a value that it takes away from your business and it can be serious business impact.
And so, um, there's also long term costs.
Support maintenance upkeep, future evolution. Right? And so it's hard to consider the future when you have limited budgets, but, you know, it's definitely something that you need to be thinking about. If you, as Peta said, lay a really terrible Frankenstein foundation, it could come back to haunt you and lead to, you know, an inability to meet the business's needs in the future and significantly more costs.
You know, and it really has this, this cascading effect, because it just permeates every aspect of the organization. So for example, the development team, right? You have engineers internally that have to work with whoever you hire to do this project. And if you hire resources that don't have a lot of experience.
Now they're doing a lot more handholding and gatekeeping. They have to spend extra time reviewing code. That code may need to be rewritten. And you know, so now you're slowing down your team. You're taking resources that could and should be doing other things. And you're making them invest time in, in, you know, you know, rewriting and trying to get code to be quality.
You're inherently getting more technical debt, which speaks to the, you know, the challenges that are going to come down the line. Complicate your projects. you know, your team loses, you know, confidence in code. you know, as you know, bad code makes it out into releases, then you start to have, you know, problems in production.
You know, then you start having this deadline because you're dealing with, you know, all of these extra time on code reviews and hand holding people and fixing problems. And now this, you know, erodes trust with the business. So now your technical team isn't just battling you know, their, their software and the contractors and people they're working with now, they have this adversarial relationship with the business, which put them in this position to begin with.
And they don't understand there's this complete disconnect I don't, you know, from, from the business's standpoint, they're just like, Hey, you're not delivering, you know? And I don't understand why. and so it just, it just cascades and you have to think about your resources, right? Like who wants to work in that environment?
You know, I love Tag1 because I get to work with really amazing, brilliant, interesting people that teach me new things every day. You know, I think people want to be surrounded by people that interest them and that they can learn from. And so if you're surrounded by people that, you know, really need hand holding and are causing a lot of problems, It creates retention issues.
Like not many people want to work in that environment. It's not very encouraging. I'm not learning anything, you know, I'm constantly teaching and taking care of crap. And it also makes it hard for you to bring quality employees into your organization for the same reasons, right. People want to work with other interesting, smart people where they're going to learn and grow their career.
And so, you know, on top of all of these issues, it really then destroys your team. And you know, now not only is this individual project suffering, but potentially, you know, all of your software projects, you know, you're resourcing sort of the foundation, the technology of your business has, you know, eroded.
Peta Hoyes: [00:10:30] And there's another part that I'd like to add to that I think is also important, but a nuance. You know, we often talk about software development being iterative, and the reason why it's iterative is, you because you, you take the risk out. The initial stages of it. And when you can do that and you prove something that it'll work and that the foundation solid you actually speed up cadence, not just with having really efficient people that know what they're doing, and that you can break down a project into smaller bits and pieces and give it to other people to do and check their work.
But ultimately it just means that your time to market plus what you're essentially giving to people to build on top of is so much more solid. And that means that you've done the first hard job of doing risk management.
Michael Meyers: [00:11:20] Yeah. And it's not just your development team and the businesses perception of them.
You know, it impacts the product managers, the project managers, the stakeholders. You know, they in turn have higher management overhead. and you know, this is where there's like a really, obvious cost to the business. You know, we work with an organization that came to us, like I said, you know, when an agency failed to deliver, they ended up spending multiples of what the project was supposed to cost, like well, into the seven figures, millions of dollars.
And. It took multiples of the time to get to that, you know, to the point where they had a semi-functioning system. So by believing that they could build something inexpensively, you know, with low cost contractors, they ended up spending multiples, it took so much longer and the end result never met the needs of their business, you know, they're handcuffed.
And so, you know, now they're in a position where they have to start over and they've spent a small fortune and their business has barely been able to operate, you know, forget about the project costs. You know, the way that this has dragged down the organization for years is, is just so crazy.
And you know, that that is what is really scary.
Preston So: [00:12:51] So, but you know, one of the things that I wanted to do here is it's a challenge that a little bit, you know, because doubtlessly a lot of folks out there are looking at a lot of these lower costs, more affordable companies and thinking that, Hey, you know, this, this has to save me money.
You know, you know, there has to be a way that I can find some efficiencies from this. So, are there scenarios where some of these more affordable or less prohibitively expensive, contractors can save businesses money? Is that something that is true?
Peta Hoyes: [00:13:17] Definitely one of them right off the bat, if it's a known problem space, and this has been this feature or this function has been built a time and time and time again. Yes. You know, definitely.
Michael Meyers: [00:13:30] Yeah. There's there's, there's no absolutes, right there. There are definitely scenarios. You know, Peta talks a lot about high availability systems and mission critical systems. And those are without a doubt, the places that you want, really good people. if you're building a website or application and with almost no functionality, cookie cutter, it doesn't have to scale.
You know, there are many reasons, you know, there are many sites that, you know, I don't want to say don't matter, but don't have, you know, any material requirements. In which case, you know, it doesn't matter who built it, you know, it doesn't need to scale it doesn't, you know, it doesn't have a ton of complexity.
Anyone can build it. So there's definitely, times and cases, and it comes down to making a judgment call. You know, what is the value of this project to your organization? What is the impact of not getting it right? What are the long term consequences of that happening? You know, what is the impact on your team?
And if you know, the answer is we don't need a piece of quality software, then you don't need quality development.
Preston So: [00:14:38] So how exactly does one avoid falling into this trap? I mean, you know, I think a lot of people want to make sure that they're not letting their projects get derailed. They don't like to see, you know, obviously there's, there's some really cautionary tales out there. I think a lot of us saw what happened recently with not only the builds of canada.ca on Adobe experience manager, but also on Hertz.
It says, well, another company that kind of struggled through this, this kind of a process where they embarked on a project, turned out to be very expensive, much more expensive than anticipated. Came out with this thing that wasn't really quite what they wanted. Um, I guess, you know, one of the things that I struggle with is how exactly do you understand where that threshold is?
You know, like, like what's the threshold at which someone could call Tag1 and how does one avoid falling into this very trap?
Peta Hoyes: [00:15:23] So I had a thought about this because we've been down that path a few times. And in one particular instance that reminds me of why this is so important to get, right. Um, there are lots of ways to solve problems out there, right.
And not always every, there can be more than one answer to one question. but if you don't have enough experience, for instance, with a range of different things, Then sometimes you can mis-solve a problem. Right. And that also takes that good communication thing that I mentioned before, which is, you know, people that know how to decipher a client, telling them this is what the problem is.
You know, it takes some good follow up questions to actually understand what the problem they're describing. Right. plus what's the best solution for it. it doesn't mean you can't solve it multiple ways, but there are oftentimes a better one solution could be better than another, depending on a host of other factors in the organization, like who is going to have to maintain this thing long term, how much money are they going to invest in it to get it to where it needs to go over some period of time?
You know, what else is going on in priorities in the organization? So I, I definitely think sometimes it's, it's about understanding the problem and making sure that the solution that you pick is also a good fit for not just that short term, but also a medium and a long term.
Michael Meyers: [00:16:49] Yeah.
I think that, you know, tolerance for error, you know, if it's a mission critical system, You don't have a high degree of tolerance for error, you know, that's, that's probably not a place that you want to be working with a lower cost contractors, you know, experience doesn't 100% equate to cost. you know, again, there are no absolutes, but generally speaking, you know, people that have a lot of experience and are at the top of their game are going to be much more expensive.
And worth that effort. So, you know, anything that has to do with eCommerce and revenue, you know, another obvious choice, you know, things like milliseconds matter, you know, for every millisecond that your site is slow, it's been proven that you're going to lose conversion rates and revenue and checkout.
And so there, there are, you know, some easy places, I think, you know, where there's revenue involved, where you can justify it. I think where it gets challenging is, you know, internal business systems that are critical to the organization, but are just a cost center. And aren't necessarily like a direct revenue driver where an organization has a hard time saying, you know, Oh, I can invest this kind of money.
You know, and it comes down to the factors that we talked about, you know, understanding, the value it's going to generate for your organization. you know, the speed with which you need to achieve that value. You know, if it takes you significantly longer to get there, what is the business impact of that?
If you have hundreds, thousands, tens of thousands of employees, and this is a month, three months, six months late, you know, what is the aggregate cost of that? A tiny fraction. That project is a tiny fraction of that value that's lost. And so, you know, I think that you need to look at it, not at, you know, an hourly rate or a project cost.
You need to look at it in the context of, you know, the value and loss of your business. And that's really hard to do, and even harder to justify, you know, up the chain.
Preston So: [00:19:03] Well, I think that was a great, you know, rejoinder to kind of, you know, the way in which we want to make sure that, you know, folks who do have that lower tolerance for error are able to get the resources that are appropriate for, their projects. I guess, you know, one of the things that I wanted to ask.
Both of you is, you know, what is some advice that you would give to somebody who is, who is in this dilemma right now where, you know, I think, you know, we've talked a little bit about some of the fact of, you know, looking at the total cost, not just kind of the, the immediate sunken costs, but, what are some other things that organizations who are looking at these kinds of questions and grappling with these kinds of issues can do to, you know, kind of get a better understanding of their own.
Let's say tolerance for, margins is there.
Peta Hoyes: [00:19:47] You know, talking about trial and error. Are we the best architectures that I've come across are the ones that do take quite a bit of trial and error and testing right over. Over periods of time. Right. but ultimately the people that are building them are very determined.
They're very hardworking and very innovative. you know, these are qualities of people, not of systems or components or Lego, right? You don't, you, it's really hard to find people that can put in the effort that it takes to, to build something great. For very little money with just a few people and definitely no glory about it.
You know, and, and, and there are a few, there are fewer engineers that have the chops to build. You know, solutions that, that not only hit the mark in terms of what you need them to do or how you need the system to function, but, you know, the architecting it to perform and scale at that level. Um, you know, it, the kinship is kind of, they're there, they're lots of writers in the world, right.
But how many of those writers can build great can write great books, right? It takes again that kind of innovation, determination and hard work to make a good book.
Michael Meyers: [00:21:05] Yep. And the reality Preston, is that that is a really tough question to answer. And that's why we wanted to do this talk and write some blog posts and engage people in this conversation because you know, it isn't just us, that deals with it. You know, stakeholders and clients that love us, you know, or that understand the problem, have to battle this internally, you know, you know, through their organization.
You know, so I think whether you're on the client side, you know, the consulting side, you're struggling with this and, and our hope in, in doing this talk and kind of kicking off a debate around this is that we can arm people with. a set of facts and ammunition that they can take into organizations to say, Hey, you know, how do we value this project?
What's important to us? Is this the, you know, the right scenario? How do we make that decision? And when they come to the conclusion that they should be hiring, great contractors at great prices that they have the talking points. To help them make that argument, you know, that they can talk people through the myths, they can talk people through understanding the true value in consequences and impact.
And it reminds me like back in the day, when people would say like, why, you know, try and try to make that argument to use open source, you know? And, and now, you know, no one really thinks twice about using open source. And so, you know, it's, it's sort of a very similar problem. It's a very challenging and difficult argument to make.
Because it is that entrenched belief. It is that beautiful siren song that is impossible to ignore, that we're battling up against.
Preston So: [00:22:50] Wonderful.
And now for something completely different, we have a little segment on our Tag1 TeamTalk show where we do what's called the Aside Tag; a little bit of a sharing experience for each of us.
One minute per participant, just to share a little bit about what's going on. It's interesting or cool with the audience. whether it's something that you've learned about or you've been toying around with, or saw an awesome movie or read an awesome book, Meyers what's going on in your world.
Michael Meyers: [00:23:14] I'm going to take this opportunity to do a shameless plug.
We just released a new open source project called Goose. It's a load testing framework. it's based on Locust, which we love. It's a Python based load testing framework and while Python is awesome and it was easy to write load tests, swarm shifts were really difficult to scale for big clients.
And so we rewrote it in Rust, keeping what we love, getting rid of things that we didn't use and adding some cool new features. We'll put a link in the show notes. We'd love for people to check it out. give us some input and feedback so that we can continue to iterate on it. the initial alpha release is already 11 times faster than the Python-based Locust.
So I'm really excited about this. performance and scalability is something that's core to what we do here and check it out.
Preston So: [00:24:08] And by the way, in case you missed it, we did have a Tag1 TeamTalk episode about Goose. it's about to be released or what has already been released. I'm not sure we do these things out of order, but, please be sure to check out that, talk about a whole lot of information that you can get about this amazing load testing framework called Goose.
Peta, what's going on in your world
Peta Hoyes: [00:24:27] So I think the thing that's been most consuming of late is watching current events. you know, not only is the planet in the midst of a pandemic, but America itself is dealing with a 400 year old quagmire of managing bias and racism in particular, in policing.
But that's kind of pervasive throughout, most sort of, you know, communities, whether that's your work or the place that you live. and I think what's most important for any organization, whether you're a nonprofit or a, you’re a company, you know. Diversity is something that, you know, people pay a lot of lip service to, and people are certainly paying a whole lot of lip service to making corporate statements around Black Lives Matter, for instance, and their support of it.
But I think the, the two biggest things that people can do in an organization as to what I like to say is hold space for people of color, who show up every day to work, given all the things that go on are going on in the world, especially the ones that we that are seen and unseen in, in the places in which they interact.
Um, and by that, it just really means holding space is. It's about making room for anyone that has emotional trauma and, you know, no, one's perfect. Tag1's not perfect. but one of the things that I think, helps allow people of color to feel like they belong or that they can be successful in a place is giving everyone the opportunity to feel unconditional positive regard.
And, to give each other the benefit of the doubt, even when the words that people use, aren't the perfect words to describe what's going on. so, you know, we start there in any environment where you have a community of people that have to work together and making sure that everyone has the confidence and courage and that we make space for them to, to have those hard discussions without judgment.
Preston So: [00:26:36] Absolutely. And I couldn't say it any better myself, Peta. you know, I really do think this is a time that calls for a great deal of reflection. We see a lot of performances going on in terms of the corporate world. and, we at Tag1, certainly stand in solidarity. with of course not only all of the people who have been suffering through.
This horrible period of, and just, you know, 400 years obviously, of anti-blackness police violence and white supremacy. I want to also go ahead and take my Aside Tag and commemorate, and also encourage that folks on this call who have been watching this software. It doesn't operate in isolation.
Software does not operate in a foreign place from society. Software is something that is completely part and parcel to the experiences and lived experiences of people, of color in this country and so we had, we did have a moment of silence for, George Floyd and other victims of police brutality during our episode about Goose.
I also shared some organizations in the previous episodes about, where you can direct your donations, but today I want to take some time to commemorate not only the black lives that we have lost over the course of the last couple of weeks: Tony McDade, George Floyd, Breonna Taylor, you know, all the folks that we've been hearing about, but also the forgotten folks, the black trans women who have died over the course of the past week in Pennsylvania and Ohio.
Despite of course, the amazing gains for LGBTQ legislation that we've and, and, activism that we've seen this morning. There are still a black trans women who are dying. And I also want to mention that I hope that Oluwatoyin Salau, obviously a very prominent black lives matter activist was found murdered.
And I want to commemorate her as well. Obviously this kind of activism is very dangerous and it involves a great deal of hurt and trauma for the people who are at the very front lines of fighting for, the kind of justice that we want to see in this world. so thank you Peta for that statement and thank you so much to our Tag1 audience for not only supporting Black Lives Matter and supporting the ways in which we can help black lives and black people and people of color in this world from the confines of our own.
Work and from our own jobs and careers, but also from the standpoint of what we can actually influence in terms of our software and in terms of our code. So with that, we are out of time. I do want to note here very briefly that in case you wanted to get more information about this and learn a little bit more about Peta and Meyers his views on exactly.
What's involved in this kind of false economy of low cost contractors. Please remember that all the links and all the articles that we mentioned today are going to be posted online with this talk. And if you did enjoy this talk, if you want to hear more about some of these topics, please remember to upload, subscribe, share it with your friends and family socially distanced, of course, with a mask on and check out past talks at tag1.com/tagteamtalks.
And as always, we'd always like to hear about your feedback and any topics. If you want to bring Peta back, if you want to bring, anyone else from our show back, or if you want to bring someone new on, especially someone who was a person of color or a queer person of color that you might want to have on the show.
Please hit us up at tagteamtalks@tag1consulting.com. I want to thank my dear colleagues and friends, Michael Meyers and Peta Hoyes today. And until next time.