Code with Jason
Code with Jason
276 - Todd Kaufman, Agent #001 at Test Double
In this episode I talk with Todd Kaufman about founding Test Double, focusing on hiring senior consultants who excel at communication and empathy. We discuss how consulting is 90% psychology, the importance of seeking to understand before being understood, and why most software projects still fail due to organizational rather than technical issues.
Links:
- Test Double
- todd@testdouble.com
- Nonsense Monthly
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right, I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says, just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsense monthly.com I'll say it one more time nonsense monthly. And now without further ado, here is today's episode. Hey today I'm here with Todd Kaufman. Todd, welcome.
SPEAKER_00:Thanks. Appreciate you having me, Jason.
SPEAKER_01:Yeah, appreciate you being here. Um so tell us a little bit about yourself. You run uh Test Double, right? Correct.
SPEAKER_00:I'm uh one of the two founders of Test Double, Justin Searles and I started the business back in November of 2011, and uh I've continued on as some form of leader, president, CEO uh here since its inception, and that's that's still my current role.
SPEAKER_01:Okay. Um and what led to test double being created?
SPEAKER_00:Yeah, I uh I think of it as the the scene from Jaws where they're comparing like scars around the table from various like shark uh bites. We were Justin and I driving back from a client where we were frustrated maybe by a lot of the challenges, and we were kind of trying to do some root cause analysis. We kept pointing to, you know, really the consulting company itself had set us up for failure. They were very aggressive with how they positioned the project in order to win it, and then sales ejected as soon as they started getting commission checks and left the delivery team to kind of pick up the the pieces and try to deliver this thing that was highly unrealistic. And as we rewinded back to our experience with a lot of other consulting companies, it really felt like they all behaved this way. They had a separate sales team that was very aggressive and would say whatever they could to try and win the business. And then they basically shoved all of this challenge and unrealistic expectations onto the delivery team and you know just said good luck. So we we started the business really feeling that one, most most software projects still fail, they come in way late, uh over budget, with features no one wants or needs, or with features that are completely broken in some way, shape, or form. Uh, we felt like we could, you know, really focus on the practice of software engineering instead of a lot of the process changes that people were advocating for at the time, and we'd stand out. And yeah, lo and behold, uh you know, almost 14 years in, uh it seemed to have worked.
SPEAKER_01:Yeah, wow, there's a lot there. Um so there's there's that law, I forget the name of the law, but 90% of everything is crap, is the content of the law.
SPEAKER_00:We'll call it Jason's law.
SPEAKER_01:Um, I can't take credit, but um, it's very true. It's it's sad but true. Um and I've said before that like the miracle of the world is the wonder of the world is not how we have so much that's so broken, but the fact that anything works at all. Yeah. Um yeah, and if you if you go inside of various agencies, I've I've gotten a front row seat to a lot of different agencies, and it's pretty bad out there. Um there's there are some like natural laws that like lead to to agencies um kind of being a certain way. Um from a developer's perspective, a developer who works at an agency, it's often not the most glamorous work, or like it's kind of it can be kind of unpleasant. I'm not sure exactly how to characterize it, but you can get thrown around from project to project, maybe not really get to see the fruits of your labor, you don't get to talk with the people you're building the stuff for, perhaps. And so it there tends to be a lot of developer churn in agencies, and so developers tend to skew junior in agencies, um, and then like the people who stick around for a really long time, it's like, hey, if you're if you're so smart, why'd you stick around here for so long? This is terrible. Um, so it like has this selection effect. Obviously, that's not true in all cases, but it happens a lot. Have have you seen those phenomena yourself?
SPEAKER_00:Yeah, it's interesting. I think the um the trade-off I always tell people who are maybe new to consulting who are considering joining Test Double is you're you're not gonna have that seeing something through from idea to like operations for years and years and years. Like we're typically much more ephemeral, right? Like we come in for portions of that story, but not for the whole thing from front to back. That means um it's maybe a little bit more challenging, it's maybe a little bit less fulfilling. Uh, you feel just like a little bit distant, more of a kind of part-time player for those successes, uh, which I think is is very frustrating. The flip side is consulting is a career accelerant if you're at the right agency. So for us, we've had the ability to, you know, really see from client to client, project to project over the years, a lot of the same patterns emerge. So it starts to build up, you know, a really unique set of experiences where when clients are running into, hey, it seems like the team's you know cutting corners and sacrificing quality. We have, you know, hey, let me tell you about this client where we ran into this. And what we found was, you know, the team was really being beaten upon by higher-level executives, uh, milestones that had to be hit that they didn't have any part in creating, and all that they were left to do was to basically, you know, cut corners. So we have to fix the root cause of that problem. And I think consulting is really good at like broadening your experience and and helping you with some of that pattern recognition that, hey, a lot of the team and process and organizational dynamics that go into creating good software, um, those things we get really well attuned at spotting and sniffing out and addressing. Um, that may be a little bit unique though with Test Double, though, because we're almost the opposite of what you described. We're an agency that focuses on our average like years of experience is over 10 years. So we're we're much more a more senior consultant uh who is looking for opportunities to solve those challenges of scale and things like that uh instead of just you know product delivery.
SPEAKER_01:Yeah, yeah. Obviously the the quality ranges a lot with agencies, and just like everything, you know, like the top 10% of agencies are pretty good, and the bottom 90% is just I hate to say it, but just really bad. Um, just like with the bottom 90% of almost everything. Um, I worked at this agency when I was in my early mid-20s. Um, it was really fascinating. Um I was getting paid like$45,000 a year. The agency was billing me out at$160 an hour, and so it for one, it's just comical that gap. Um and what were clients getting for that$160 an hour? Like nothing, not something that was worth$160 an hour, I don't think. Like I didn't know anything back then. Um and and it's kind of like everything's everything's connected and everything influences everything else. Like if you have really strong leadership in an agency and you know how to like pick really good developers, and then that can help attract better clients, and having better clients helps you retain better developers, and like either the whole picture is good or the whole picture is not good. Um and like you said, like it really depends a lot on the agency. Um, it was it was interesting when you mentioned the kind of structure and incentives and stuff like that. I've worked at agencies where there's a separate sales team, including one. It was it was fascinating. The sales team was incredible. Um, they sold to clients like Google and Facebook and stuff. And as incredible as the sales team was, the development team was equally incompetent. So the sales team would sell these amazing deals, and then every single time the development team would just completely fail to deliver, and then it would all it would happen all over again. And somehow nobody ever felt bad about that. They're just like, well, uh on to the next one, I guess. It was it was amazing. Um, but I'm I'm curious at Test Double, how do you avoid that scenario where the sales team sells the moon and then the development team has to scramble to keep up with it? How do you not do that?
SPEAKER_00:Yeah, it's uh it's interesting. I think we're almost the opposite of what you described. Uh so Justin and I, for the vast majority of the history of the company, sold all of the deals. And we're both software developers by trade and consultants based on our professional experience. So we didn't really know what we were doing with sales, but we knew how to hire people who were really successful at software consulting. We stumbled upon that formula really early on. So we were almost the opposite effect where if we could just get in the door, our consultants like delighted and blew the doors off of uh our clients. So like they were all, you know, very happy with our services, and then from there things just kind of expand organically. We still do that to an extent, but um we do have a head of sales and we have a marketing team now, and they're you know more uh professionals in that space and really good at at finding, you know, people who can use our services. For for us to make sure we're not like overpromising and under-delivering, I think you know, expectations, it's very key to get those things just hammered out and made explicitly clear at all levels uh at the outset of an engagement. Um, and that can be you know, high level, what are we building, but also lower level, like on the spectrum of like quality and like pace of delivery, like where do you want us to operate? Because you know, no two clients are alike. You may be in an early stage startup where customer acquisition is the priority. Maybe you're more tolerant of you know defects and issues and things like that. Or maybe you're like building like enterprise financial software, in which case like defects are unacceptable, so you're happy to move slower at the at the um benefit of of having higher quality and fewer issues. Getting all of that stuff on the table at the outset tends to set us up for success. If we're ever, you know, kind of taking a shortcut and not really explicitly defining those things, that's when we see potential for us to be delivering something that we think is good, but isn't really what the customer's after or isn't really what they value.
SPEAKER_01:How do you make sure that the developers who are working on a project are on the same page uh about these important things? Because like it's pretty rare to find a person who has both uh really strong development skills and has the presence of mind uh uh to ask the kind of questions that that you're asking. So how do you ensure that people are on the same page?
SPEAKER_00:Yeah, we definitely skew towards hiring highly communicative developers. So that's that's really the first interview that you go through at Test Double. One of the big things that we're looking for is how does this person communicate? How do they deliver feedback? Like, how do they ask questions? Do they approach things from a position of seeking to understand or seeking to be understood? Like we recognize that all of those things are really the the basis for good software consulting. You have to be able to communicate effectively, broadcast progress, ask the right questions, and you know, obviously see the root causes and and try to influence things in the right direction there. But if we do a good job of hiring people who are really good at that, and then we give them space to to communicate and and make sure that they have what they need from the clients, like we tend to normalize pretty quickly. When when you don't do those things, it tends to take a lot longer or you tend to go off in the wrong direction uh a little bit too far.
SPEAKER_01:Yeah, it's so interesting. I I'm sometime last year I like wrote this little document. It was like some kind of guide for uh engineering leaders, and I had like four principles in there. I don't know if I remember all four of them, but I definitely remember the first one, which was um to make sure you have the right people, um, be careful about who you hire and don't be afraid to fire people. And that makes the reason I put that first is because that makes all the difference. If you have really excellent people and nothing but, then you almost can't go wrong. Um and if you don't have good people, then you almost can't go right. So that makes a lot of sense to hear you that that you focus on hiring those kind of people who have those capabilities.
SPEAKER_00:Yeah, it's there's never a a system that's good enough to take people who aren't a culture fit or really like you know, inept at what you're asking them to do and have it accelerate their growth to the point where they're successful in a reasonable manner of time. So we've again skewed almost in the opposite direction of hire awesome people and kind of get out of their way. Like let them do good work, trust them to to come up with the right solutions to problems. Um, almost to a fault. I mean, I think that as we've grown, we've we've broadened a little bit the the stratosphere of people that we hire. So, what used to be, hey, we hire somebody who's only done consulting before and they've got 12 plus years experience in this space. Now we'll hire somebody who maybe hasn't done consulting before, or maybe they only have like six to eight years experience in this space. We need to start, you know, kind of understand like the dryfus model of skills acquisition. You need to put a little bit of structure and support out there so that those people can, you know, operate in the way that you want them to work at Test Double and at our clients. Um, what's something that the Dreyfus model of skill acquisition? Yeah, Dreyfus model of skills acquisition. At a high level, it talks about like at the early phases of learning something, you need to know all the rules, right? You need to have a lot of like prescription for here's how you do things in order to be successful. When you're at the higher level and like you you've in essence achieved mastery with something, you know when to break the rules and you know when to kind of deviate from that playbook, and and you really don't need much support. So I think for for us, like what we're seeing is consulting is a hard thing to teach because like every client's different, the problems are unique, um, how you approach them is unique. But we've seen some overarching themes and we've seen like some patterns emerge there that we need to kind of do a better job of communicating those things to people who are newer to consulting just so that they're successful even if they haven't done it a lot before.
SPEAKER_01:Yeah, to me to me, consulting is like 90% psychology. Um it's funny you said that.
SPEAKER_00:Someone asked me recently, like, if you could go back and have any other career, what would you do? And I was like, probably a research psychologist, honestly. Like, I'm fascinated by a lot of things there. I never attributed that to my experience with consulting, but I think you're right. Maybe that's that's my part-time hobby, uh, regardless, just by virtue of doing consulting a lot.
SPEAKER_01:Yeah, yeah, it's like the technical skills obviously have to be there. Um, but that's not enough by itself. You have to have the psychological competence also. Um, and like everything to do with like business and sales and marketing and stuff like that, that's all psychology too. There's this really illustrative quote that I read one time. It was like, um, if you're if you're not good with people, it it was like Lee Ayakoca or something like that, one of these like auto executives. Um he's like, if you're not good with people, you're not gonna succeed because that's all we have around here. And it makes total sense. Like you're dealing with people all day, every day, so you have to have good people skills.
SPEAKER_00:Well, and it's never more evident than in a services business, right? Like, we don't have a product that we can hide behind. So we don't have you know a bunch of cars or anything like that that we can point to. Like, all we have is our people. We are 100% a people organization. So, yeah, for us, it's it's definitely a situation where you have to hire the right people, make sure they're a good fit, make sure they're supported, they have what they need to succeed. And and I think that that piece we were talking about earlier is make sure they have 100% clarity in like what's expected of them, you know, what how everything that they're doing affects the business and is intertwined, etc. And those are areas we've learned along the along the way that we need to lean into and be more clear about.
SPEAKER_01:Yeah, yeah, and I realized at one point that like at the root everything is emotional and everything's subjective. Like nobody does anything for a rational reason. I I mean you might do something for a rational reason, but the rationality is only in service of a greater emotional uh drive or something like that. And with a consulting engagement, like really the only thing that matters is like how does the client feel about it? Um, you know, there there could be measurable numbers that are going up or don't going down or whatever. Um, but that's like a secondary thing. The the primary thing is how does the client feel about it? Um, and a big part of that is just like um what's the relationship like? What's what are the interactions like between the client and and the person serving the client? Um and so I myself have made a very deliberate study of psychology, which is ongoing to this day, and I'll I'll never stop trying to learn about psychology because it's it's every day, all day. It it helps you.
SPEAKER_00:Yeah, I agree. I mean, starting the business and working in here and basically every role, you really start to understand how it's your ability to communicate, influence, lead, um, you know, deal with issues with others, like all those things are are paramount to to almost every role within the business. Um so again, having having people who have like a high level of like emotional intelligence and who skew towards like a level of empathy, not just for the people like them, but especially for the people that aren't like them, uh, we've seen that that that tends to be a good leading indicator of whether or not someone will succeed with consulting. Because it's easy to have you know a lot of empathy for the developer who's side by side with you on a project who's also getting you know smacked in the face with deadlines. Harder to have empathy for that you know stakeholder of the business who keeps espousing like why these deadlines are important. Uh, it's much harder for us to kind of connect with them and empathize with them. But if we do it successfully, you tend to have a lot like greater results.
SPEAKER_01:Yeah, it's really interesting. Um, to me, there's almost like two levels of empathy maturity. It's like the first level is empathizing with people who are easy to emphasize empathize with, people you agree with and stuff like that. It's a lot harder to empathize with people who you disagree with. Like, for example, if if you're a liberal, can you empathize with a conservative? Um, you know, for for most people, and and it goes both directions. Um for most people, the answer is absolutely not. Um, like if somebody has a viewpoint that you disagree with, you're like, I can't imagine how you could possibly get there. It's like, okay, well, maybe that means it's time for you to try to put yourself in the other person's shoes and figure out what got them there. You don't have to agree with them. That's not what empathy means. Um, empathy just means understanding uh why they feel the way they they feel. And that can be tough for like, for example, a developer. Developers and salespeople are cut from very different cloth. Um and and so to empathize with a salesperson or some manager who who is doing all these things that are from your perspective really irrational or even just stupid, like I think it's a good idea to pause and say, like, hang on a second. Could there maybe be good reasons for the re for for why this person is doing the things they're doing?
SPEAKER_00:Yeah, we we have a leadership coach and he's been um really amazing at hammering home a lot of like lessons from from others, really. Uh Covey's one of his uh, you know, kind of big sources and in seven habits, like he talks about seek first to understand, then to be understood. I think that we we really struggle with seeking first to understand uh at this moment in time for a lot of different reasons that that makes sense, right? But we talk about that a lot in our business. Um, you know, decisions are made by people in the highly autonomous business that we have because they are closer to the problem. And from the outside, you can, you know, it's easy to question or judge, but uh the more you talk to people and kind of understand their perspective and their context, the clearer it becomes that, you know, either maybe hey, they they actually made the right call, or there was a valid reason for them making the call that they did, and and you can kind of go on from there. It's hard though.
SPEAKER_01:Yeah, I want to talk more about that seek first to understand. So I read that book, Seven Habits of Highly Effective People, many years ago, and then I went back and reread it a few times. Um, because it's just it's such a gold mine. Um and the seek first to understand, I apply that all the time in my work because it's astonishingly difficult to communicate an idea from one person to another person. And so the tactic that I use a lot is like when somebody tells me something, you know, we're we're talking about a piece of work we want to get done or something like that, or some objective. Um and to make sure that I understand, I will maybe take some notes, maybe not, but in any case, I'll repeat back to the other person my understanding of what it is that they're trying to communicate, and then say, do you does it sound like I have it, or is anything wrong or missing or something like that? And quite often there is something missing or incorrect.
SPEAKER_00:Yeah, I think it's it's paramount for me as the business has grown. You know, when I used to when it used to be 20 people, I I kind of managed all of the consultants here. And they maybe worked at eight different clients, and I managed all those client relationships. So just by virtue of proximity in my work, I had a much greater context of what people were running into. So, you know, I I would almost implicitly understand like what people were facing and and why they made decisions the way that they did. We're up to 120 plus people now, and we have, you know, we'll work with 60-some clients this year. I'm distant from all of them, right? I don't have any of that proximity that I used to, and and I can't rely on that to have a you know a firm understanding of what exactly is going on with clients and why decisions are made. So for me, you just can't operate from a position of judgment in those cases. You have to always seek to get more context and and really to to better understand why decisions are made the way they are. Um, only then can you you maybe share your experience or your perspective on something that you would do differently. So I think further, like the state that we're in right now, there's there's just a almost uh a step backwards of assuming positive intent. Even saying assume positive intent is is uh oftentimes labeled as you know um uh a privilege that doesn't apply to others, which I I acknowledge that is the case. Um but I think it's also a pretty miserable way to live to assume bad intentions, uh especially in in a business with your coworkers. Uh, because you know, we're we're an employee-owned business, everybody here is is interested in seeing Test double succeed. Um so normalizing there and and kind of again trying to just better understand the other perspectives, uh, I think is is the only way you can really get to uh a better understanding.
SPEAKER_01:Yeah, yeah, I'm I'm trying very hard to suppress it ideological political rant that that is bubbling up inside me right now. Um, but that's that's not what we're here to do. Um Yeah, so here's here's a question the term consulting is extremely ambiguous. Um, it can mean everything from being hired purely for advice um that's that's what I did for a period of time uh technical leaders would would hire me and we would just talk um and it's everything from that to somebody hires me and they give me tickets and I fulfill the tickets and we call it consulting even though it I'm just a a pee on being being given decisions that somebody else made and I just implement those decisions and then there's everything in between. Do you have a specific way that you define consulting?
SPEAKER_00:Yeah it's um in the early days it's evolved as we've gone you know uh along here in the early days I would have lumped in you know if you needed your car washed and you were comfortable paying our rates uh that would have been work that we would have taken on right so I would have had a really broad umbrella of what consulting means. Uh as we've progressed I think you you hit upon really the two probably main problems that we solve for clients. One being capacity they don't have enough capacity to get things done. And you'll hear people talk about this as like staffing and stuff like that. Anytime our consultants hear staffing right they all have PTSD because they've been in like some giant cube farm at a bank or insurance company where they were just asked to code stuff and and it's kind of miserable. Capacity I think of a little bit differently because I do try to put like the consulting hat on and like well what is the root cause? If the client needs to reach out to a another firm for capacity maybe they aren't as efficient as they should be so we try to stretch every capacity engagement that we have into lasting improvement and change for those clients. So if they're saying hey we need more developers we want to as we're going through and as we're delivering features for them really shine a light on what are their main inefficiencies? Is the build time too slow? You know are they taking too many shortcuts and not spending enough time on automated testing or simple design or things of that nature? Have they just like grown this app into a giant monolith that is like extremely hard for people to work within what can we do to help them you know get to a better state to where they don't need extra capacity in a temporary phase moving forward I think that's that's one of the main problems that we solve and that's that's really hard to do. The first thing that you mentioned is really you know experience and insights and that's I think what what people really value when they bring us in. So our consultants are able as I mentioned earlier with that pattern matching and that sharing of hey I've I've worked with five different clients in the last two years and they all were struggling with how do we make our devs you know more efficient or or how do we speed up um you know build times or how do we take advantage of of AI tooling and things like that for developers. All of those things you know we we have consultants who can come in and and really share perspectives on that are based on what they've done at multiple other organizations. And I think that's that's the piece that I think sometimes is uh hard to put a price upon because it's it's invaluable.
SPEAKER_01:Yeah um I'm thinking back to some of the engagements that I've done and just the jobs that I've had over the last 20 years and stuff like that. Um quite often if if if we look at a problem or what you might call a a symptom um and do a root cause analysis on it and go through the the layers um because usually a problem is a symptom of a different problem which is a symptom of a different problem and so on. Often the root cause is either they have not the right developers on staff, you know they have the kind of developers who are just they're never going to be good. There's developers who are good there's developers who are inexperienced but they might be good eventually and then just the reality of it is there's people who aren't ever going to get good no matter what. Not a lot of people want to admit that. So that's that's one problem and or they have the wrong people in leadership which is even worse because if you have you know five crappy developers you can fire them and get five different ones in theory but if you have if the root cause of the problem is that the the you know the CTO is is is the root cause it's a lot harder to to say oh let's just fire the CTO and get a new one that's never realistic. Do you run into those kind of issues?
SPEAKER_00:Yeah I think it's it's definitely fair with um our own personal experience I think hiring leaders from the outside is extremely difficult. Part of it is is what you're referring to where like the they seem more permanent on at the outset almost just based on the role um but in essence you're you're trying to assess two things when you're hiring people right like are they a good fit for your culture for your business for your organization and also are they capable of like doing the the responsibilities that you're expecting within that role I think that it's a lot easier to assess with say developers like are they capable of doing you know what what's expected within the role the more it becomes leadership the more it becomes like softer skills and people focused and things like that. And I think it's just really hard to assess people's ability to collaborate and influence and lead uh others. So yeah I think that you know from us personally like we've probably had uh a higher hit rate on hiring developers because we kind of stumbled upon that recipe for success pretty early on with leadership hires we've probably had less success there hiring from the outside just because it's taken us a long time to to really assess what it means for someone to be successful with leading others and collaborating with others and things of that nature. I'll throw out like on the on the dev side too we probably see more clients than not struggle with actually assessing is someone capable of doing the responsibilities in that role. So this is where you you know our industry just is comical with the whiteboard Fibonacci you know crap that people use to assess like hey are you able to build a uh an online form in a web app using Ruby on Rails okay show me you know a recursive algorithm for this thing that's like that's totally irrelevant to what we're doing. So like why why waste any time with this stuff uh I think that's where you know if we could snap our fingers for for one aspect of this industry it'd probably be to improve how clients go about interviewing. And that's something that we've helped a bunch of clients with just because it is such a low-hanging fruit um and it's something that's like you know drastically impactful to their success.
SPEAKER_01:Yeah and assessing developers while they're on the job like I I had one specific client engagement last year um and I spent a lot of time with their developers and working with some of the people it's like how did they ever get hired and how is nobody noticing that these people like aren't really accomplishing anything um so that's and and again people are afraid to let people go. It's really unfortunate because if you're afraid to let it okay so you can't avoid making bad hires entirely I don't think that's very realistic. So the question isn't how do we make sure we never ever hire the wrong person although obviously you should try um the question is how do we how do we deal with the situation where we know we have the wrong person um and to me it's like usually it's pretty obvious this is one of the cases where like if you you you can try to do all these calculations in your head about like okay like they messed up this project but this project was good blah blah blah. To me it's like if you find yourself doing all that kind of stuff it's like deep down you probably ought probably already know it's like one of those cases where you can just consult your gut and it's like okay how do I really feel about this if I'm being honest with myself it's like you already know and for me it's like from the second that you know for absolute certain the way you feel about it there's no benefit in waiting just just cut it as soon as you can yeah I I agree with that.
SPEAKER_00:I think the um the challenge that people have is is in the middle somewhat like someone who's just crushing at day one you obviously know that they're a good fit and and move forward someone who's either a complete like cultural mismatch or or totally inept at what you're asking them to do, you know you need to move on pretty quickly there. In the middle is someone who maybe needs support to succeed. And the question then becomes do you have the desire and capacity to provide the level of support that they need to be successful? And that is a much harder question to answer at times, right? I think as an industry we would all be well served in making sure that we're helping to accelerate the growth of people on our teams and maybe we're hiring a little bit earlier in their careers but able to like really set them up for success. But at the same time there's a bunch of business outcomes that we need to generate so how much time can we spend you know investing in support while we're still trying to make sure we're running a profitable business that's growing and market share and things of that nature. I think like finding that line is like really really difficult.
SPEAKER_01:When you say support what kinds of support do you mean?
SPEAKER_00:So it could be you know uh say you're hiring a senior engineer and giving them a a front end you know solution to build and React maybe they're sitting down immediately and they're just like off to the races. Maybe you have a really good engineer who's just kind of out of the cusp of like a junior engineer. So maybe they are able to slowly muddle along and build the thing but you know once they're done with building it it looks as if it was built by someone who didn't understand the idioms of React or maybe didn't understand some of the principles of good front end engineering or simple design or things of that nature. So support could look like for that person hey maybe you're pairing them with a senior consultant for six hours a day or eight hours a day to really try and like make sure that knowledge transfer is happening and they're coming up to speed with like what are the idiomatic ways of doing things in React or Rails. Or maybe you're you're just providing more thorough PR reviews and kind of walking through those reviews with them after the fact because that's less time commitment for your senior engineer but it's also probably not as great a learning experience for for the less experienced person there.
SPEAKER_01:Yeah I was going to bring up testing that's one of the things that I would get hired for a lot um and it's it's hard sometimes not to get depressed because every single time when I'm asked to help with testing the root cause is something else uh the the root cause of the problem that presents itself as there's not good enough test coverage or or whatever it may be. It's always deeper than that and these these deep problems take an extraordinary amount of time and effort to address. And usually it's like you know I thought naively years ago I I thought that I could go into a client engagement and help them understand testing and then leave them in a better place and they would have undergone this sort of transformation. Now I I don't I I never ever expect transformations. Maybe you can have a transformation with a single individual or something like that. But for an organization the most that I expect is if we make any improvement at all even if it's a tiny barely noticeable improvement then that's a win. Because it's just okay for example maybe the reason that they're the developers aren't writing very many tests is because when when an idea is conceived of a change that's going to be made to the system nobody ever makes a plan and so they just say hey developer do this like vague thing and the developer says okay I'll do this vague thing and they just start coding and so their development process is at an extremely low level of maturity for example and and testing can't be part of that picture until you increase that maturity a little bit. So I found that very difficult but I'm curious what your experience has been like yeah we talk a lot about root causes because it everything takes you know two things motivation and capability.
SPEAKER_00:So if people aren't writing automated tests we gotta get to the the crux of that. If it's capability I think the training that you're talking about or pairing or things of that nature I think that is wildly effective at helping people get the capabilities they need to to write automated tests. I maybe think training is is more about motivation depending on the training. So we used to see people do like two-day training sessions on hey well let's do the bowling kata and we'll we'll test drive solutions for the bowling kata. I felt that that was very surface level and it would show a little bit of the principles and it would get people excited about it and then they would go back to some gnarly enterprise app and try to do the same thing and they'd be scratching their head. We didn't really show them how to apply the principles in the context that they were typically working with. So we would always suggest to people hey bring in consulting have us pair up with people or you can have us like do the things that you're expecting them to do and then kind of show it off after the fact and and that would start to get some momentum for um you know really having a change and an impact on those businesses really helping them to transform into a more productive firm as as far as writing automated tests goes. The bigger piece though is oftentimes it's motivation. So either people have always done it this way and they don't see a reason to change like winning the hearts and minds of people and getting them to like change their beliefs that's much more difficult and and maybe not going to happen no matter how much pairing uh you do with them. Or you know as I mentioned with root causes earlier maybe somebody's just beating them over the head with a deadline all the time. So the thing that they feel like they can cut with like least impact is automated testing. So you don't fix that by trying to get them motivated to write more automated tests. Like if they're still going to get yelled at by the the VP of engineering when they miss a deadline they're gonna skip the automated testing and and move forward. So I think like sussing out what is the root cause and then looking at it through the lens of like is this a capability problem or a motivation problem kind of helps you figure out how to approach you know the the right level of pairing or coaching or or training for people.
SPEAKER_01:Yeah it's so interesting I I think there's okay so you said capability and motivation there's like one or more even additional elements I think and I I only realized this just recently and I was surprised that I had like missed something so big for so long. Um but I had a moment where I was working with a developer in a consulting uh client organization um and and this team that I was tasked with helping never asked for my help and they didn't really understand why I was there. Um and I was talking with one of the developers there the the code base at this client was you know it was par for the course it was big and it was a giant mess. It was just it was it was really rough. Um and we were talking with I I was talking with this guy because he didn't really seem to engage with like anything I was doing or saying and I asked him how he felt about our code base and he's like I don't know seems pretty good like it's just a standard straightforward Rails app. And I'm like huh I I asked him if he found it easy to work with and he's like yeah it's easy to work with and I was like wow like are we looking at the same thing like it it was just never in a million million years would I have guessed that that would be his answer. And there's a question of like was he being sincere or was he just telling me something to try to get me to go away or something like that. I'm not sure um but I never imagined that he could think that this no offense to this this code base but it was just like a really rough code base. Could imagine he would think it's fine. And so it's like okay I'm never gonna help this guy like um mitigate his pain because he's not feeling any pain at all. So there's just nothing to be done.
SPEAKER_00:Yeah it's uh that's also part of the problem you mentioned earlier with uh consulting is that we don't see things from like beginning to end.
SPEAKER_01:I think it's easy to be judgmental as a consultant and you know sweep in do some stuff sweep out you you want somebody to be motivated though uh give them the you know on call duty uh so when at 3 a.m the system goes down they're the ones actually feeling the pain of oh all of the shortcuts I took over the last six months to to kind of get this thing into production um without focusing on quality like now they're biting me and uh now I have some you know very visceral uh suffering that needs to happen uh by virtue of my my actions here right sometimes like that's that's kind of the thing you have to get get really you know out there and and kind of see the impacts of your work uh for you to really feel the need to to change or move on yeah I agree with all that in some cases it's just like slapping slapping you in the face it's so obvious and not everybody feels it um I I've had the thought before that like I kind of prefer lazy developers over hardworking developers because like uh hardworking developers and I mean that in a very specific way like they won't be bothered by like stupid painful manual work like for example uh going through some kind of really tedious lengthy manual testing process after every single change some people just don't feel that pain and for me I'm like are you kidding me like I'm not gonna do that but some people don't feel that pain uh you know give some people a nasty nasty code base and they're just gonna they're they're gonna not like okay for example somehow some developers in the world work with WordPress and they don't shoot themselves in the head like every time I get into the guts of WordPress and like try to do something I'm like my God like how does anybody live with this is so stupid but some people make whole careers out of working with WordPress. They just are numb to those certain pains. And my like cold heartless view on that is like if you have a developer who's numb to these pains just let them go. Like that's not the kind of developer you want that's my personal view.
SPEAKER_00:Yeah the uh we always get worried when we hear clients talk about well that's just the way it is here uh there's uh the late great Jerry Weinberg had an awesome book the The Secrets of Consulting and he talks about it's uh Prescott's pickle principle uh in which he describes how consultants feel like they are the brine and that the the organization they're working with is the cucumber that's going to turn into a pickle they think they're gonna go and and have that effect. The reality is typically larger organization wins and uh in essence the consultant oftentimes is the cucumber and after a while they get pickled and they adopt that mindset of well that's just the way it is here. When we see that with our consultants like it's a good reminder to us that hey we may need to swap somebody else in because we need the fresh perspectives. We need someone who's not complacent and and okay with the status quo of just that's the way we do things here. I think back to our first client we ever worked at Justin and I were both doing it was a big Rails uh code base and Justin and I were both working there they started trying to measure developer productivity and they were doing it via lines of code added to the code base. Amazing and they did this it was probably we'd worked there for six months uh Justin was like negative 15000 lines of code at that point he had removed a more code than he had added and justin was like I am the most productive person here like he he was hanging his hat on that and I was it was hard to argue with and that ultimately like got them to realize okay lines of code is not the goal here every line of code is a liability Justin is in fact you know worth his weight in gold on this engagement that is so interesting um so this client was able to get from there to here they they had that that view of you know more lines of code equals productivity but they were ultimately able to see the light yeah I mean it was hard at that point I think the the tooling we had to measure even lines of code contributed didn't really reflect like two people pairing on a solution and one person's username being tracked uh in GitHub. So it it was a pretty quick uh I think uh experiment to see that okay this is not the right way of measuring productivity but we still we have clients right now who also struggle with this and they use worst metrics like story points delivered and and we have to you know gently remind them how easily gamed that system is and how it's never a real reflection of the the value and the impact that people have uh on on teams as much as code bases.
SPEAKER_01:Totally agree um well it's time for us to start wrapping up soon I I want to mention a couple things um that book that we talked about the seven habits of highly effective people by Stephen R. Covey um dear listener I can't recommend that book highly enough I think no matter what your like professional interests are it applies to every single human being because these are just universal human psychology principles. It helped me so much if I made a list of like the five books that have changed my life the most that book would definitely be on that list.
SPEAKER_00:If you're interested in consulting I found that book The Secrets of Consulting by Jerry Weinberg to be a great one yeah those are the things that I wanted to underscore from our conversation um before we go Todd is there anywhere where you want to point people to learn more about you or Test Doubler or that kind of thing yeah uh would always love talking to to people about software development our industry and and how we can improve uh that's that's my life goal uh my mission our mission as a company is to improve what we really still feel like is a broken industry of software development so uh always happy to talk to people about that if uh you feel like you need additional capacity or experience or uh perspectives on what you're facing with your teams feel free to reach out uh I'm Todd at testdouble.com and you can see more about our firm at www.testdouble dot com.
SPEAKER_01:Well Todd thanks so much for coming on the show.
SPEAKER_00:Yeah thanks Jason I enjoyed it we can we can make a week and we can we can week we could