Episode Transcript
[00:00:07] Speaker A: Yay. Episode two.
[00:00:09] Speaker B: Good evening, welcome.
Welcome to HallwayCons episode two. And we'll be discussing a little bit about the differences in consulting versus full time. Yeah, this is honestly like a conversation I've been looking forward to having with you because I've never really worked at or like, I've never worked as a consultant. I've worked with consultants and I've been spent significant time over in consultant offices. But I've been kind of fascinated of like, what is it like on the other side where you're seeing different clients coming in, some cool, some not, and having to like quickly adapt to some work styles where like, it is obviously going to be a train wreck, but they're paying you to like fit into their process. Or maybe like. Or maybe they're paying you to like, also advise them when it's going to be a train wreck. I imagine maybe the good clients will be asking that. But then I'm sure sometimes you have like nightmare clients. So I guess maybe before we dive in deep, we can share our experiences on both of those so far.
[00:01:23] Speaker A: Yeah, they're definitely great clients and they're nightmare clients.
[00:01:26] Speaker B: What was your experience with consulting?
[00:01:28] Speaker A: Yeah, so I did that for six, a little over six years.
I loved it. I think I was working at a very unique place where Carbon five. Yes.
[00:01:36] Speaker B: Legendary consulting company.
[00:01:39] Speaker A: It was just a lot of super senior talent. Everyone was really seasoned and low ego and it was a very collaborative. It might be one of the best jobs I will ever have. And so it was a lovely place to work. And because there was so much experience in the room, there was a lot that you were able to learn because a lot of people in the industry. I got there and I was still pretty early in my career. It's only a few years in and there are a lot of people had been there for like 20 years. Right. And so worked a lot of different companies, had seen a lot of different things. And so it was like. I think consultants are amazing, especially if you are in software and are early in your career, you can find a good one because they are not all the same, but if you can find a good one, they're amazing because I think they accelerate your learning in a way that you just can't in house. Right. Because you're working on so many different domains.
[00:02:24] Speaker B: Yeah.
[00:02:24] Speaker A: You're learning new tech constantly. You're kind of always. I feel now that I've been in house for a few years, it's actually like I've lost the pulse on it as much. Because you were always Kind of on the cutting edge and always learning new things and paying attention because we had to. And so you learn a lot very quickly.
[00:02:42] Speaker B: That sounds fascinating. Is there like a lot of pressure.
[00:02:44] Speaker A: Of like that was the awesome thing about. Well, I think because everyone was so senior, like, there's sometimes pressure, but not. It was like we. It was also a very unique situation. Like this particular consultancy, we worked 40 hours a week, we were not on call. Right. Like, it was very, like, these are. And because. Because we delivered really good work. Because everyone was so senior, like had very strict parameters which made it lovely. The thing I think that is most interesting, I think the skills that you, you learn a lot of technical skills, right? Because you're working across a bunch of technologies that ramps really quickly. You learn how to learn quickly because you're constantly moving from one thing to the other. The skill that's honestly the most valuable is you become very comfortable being uncomfortable.
[00:03:23] Speaker B: That's nice.
[00:03:24] Speaker A: And so you're like, okay, well I don't know how to do this, but I have confidence that I will figure it out. And the team usually does. And so these are all the positive things. I think the other skill set that's really valuable is a lot of a people oriented skill set where you're managing stakeholders and you're managing clients and sometimes clients are challenging and so you have to figure out how to coach them to decide to make the right decision. Right.
[00:03:46] Speaker B: You're very good at managing up and I can feel that like when we're working together, sometimes where it's just like you've been here before, you've done that before.
[00:03:56] Speaker A: It was like equally valuable, if not more valuable of a skill set. And so I think those are a lot of the pros, right? Like you learn a lot quickly. You learn really how to manage.
You learn how to manage lots of different stakeholders and stakeholders at different levels within an organization and you become comfortable being uncomfortable.
[00:04:14] Speaker B: Do you ever feel like there was a trade off of being comfortable being uncomfortable quickly learning new skills? But did you feel like you were still able to get the depth that some people want?
[00:04:25] Speaker A: So I think it depends. I think after a while, yes, because a lot of the technologies do resurface.
[00:04:31] Speaker B: So I imagine like your group kind of gets known for like a specific stack and you get more projects like it.
[00:04:37] Speaker A: Yeah, whatever's popular in that time. So like it's interesting because like for a while it's like react was the thing and then go. There was a bunch of go projects and then blockchain was the thing. So there's some blockchain projects. So like in some cases, yeah, if you want to be really deep forever and it's the only thing you want to focus on, consulting is not for you. We were generalists, all of us were. Everybody was full stack. So everybody was generalized. And within that you have people who had like more expertise on the front end or more expertise in the back end or more expertise at the networking layer or because of previous experience, experiences that they'd had. And this company also skewed older. Right. Like everybody was, everybody had a lot of experience in industry. So I think that was. But, but yes, I mean there are cons, right? Like it is sometimes harder to develop depth if you, especially if you're early in your career and you know, like if you're already a seasoned professional, you know how to pick things up and programming patterns, the paradigms don't change that much. Right? Like for an object oriented language there are paradigms. For a functional language there are paradigms, right?
[00:05:29] Speaker C: Yeah.
[00:05:30] Speaker A: For interpreted language versus a compiler. Right. Like it's not. The patterns still follow, but you're picking up a different language. Right. And so if you're early in your career, it's more challenging because you don't have that depth to rely on. I think the one, one of the things that, that I noticed is and we tried to be as cautious as we could and thoughtful as we could, but you don't have to live with your decisions. True, long term you try to do the best you can, but you don't know how things are going to manifest. And so because you're not, you're not doing the maintenance of these systems that you're building. And so I think being in house you do have to do that.
[00:06:07] Speaker B: And that's I think the major, kind of like it's a harsh term but like that's usually the thing that, I guess when you're interviewing someone for a full time role who has a strong consultant background, they always ask the question of like, well, but do they know how to own things in the long term?
[00:06:24] Speaker A: Like I think they do. I mean, I think like everything, everybody had a really strong sense of ownership. Everybody had. Again, not all consultancies are the same. Yeah, I think the folks that I see out of consultancies are often, if I were to compare apples to apples, the folks out of consultancies and the folks in, in house, I've seen more stronger developers out of consultancies.
This is a blanket state. This is an overgeneralization and I don't think it's necessarily true, but I think again, because you learn how to deal with so many different, different types of technologies and because you are constantly learning and because you're constantly adapting inherently, I think it attracts people who are curious and who want to keep learning and driving. And so like there is actually a depth of knowledge that I found in those folks that I sometimes don't find from people who have been in house. Right. And so I think it's the wrong question. I think the question of like, well, do they know how to maintain systems? That's just a different type of program, like a different type of problem. Right. And so I think it's a little bit shortsighted because when you're hiring, I think it's like, how do they think about the problem? Right? And they're probably, if they're good at what they do, they're going to adjust for a different time horizon and consider it differently. Right. If you're a consultant, you're like, we have three months to build a prototype, that's one thing. But if then you're in a house and you're like, okay, well this is going to be a long lived system at scale, I imagine they would approach it differently. And so I think if they're experienced, I think if they're early in their career, that's a different question. But I think if they're experienced, it's the wrong question.
[00:07:48] Speaker B: It's always been a little bit frustrating that question for me as well because it feels like companies also like full time are often imposing those same short time horizons on themselves of like, we need to build and launch this within three months. And so it's like, how is that any different than a consultant? And then also how many large companies are hiring consultants because they're like, yeah, we wrote this garbage fire and now we have been hired a lot.
[00:08:14] Speaker A: Interesting that even some of the folks that we currently work with in house I've talked to who have done consulting in the past, they feel similarly. Like everyone I've talked to feels similarly. Like folks who have done that type of work seem to have a depth of understanding that is different. Not always.
[00:08:29] Speaker C: Yeah, yeah.
[00:08:30] Speaker A: Which I find really interesting. I mean, how about you? For you've worked with consultants before, you haven't necessarily been one. But like, yeah, what was that experience like? Or how did you feel about that?
[00:08:40] Speaker B: It was very interesting. There were a lot of things about the cons, like, I've definitely worked with some tremendously talented consultants that were like, you are amazing. And we often would want to hire them. Some we even did and paid the ridiculous fees in order to do that. But sometimes the consultants themselves were just like, I actually like the variety of the different projects and kind of that excitement of like, you know, I'm on this engagement for three months and then I'm going to get to do something new and exciting, separate. So I think that is really amazing. And their ability to just be relentlessly focused on delivering impact, like the good ones is impressive. Of like, that's cool, but I need to like, you are paying me oodles of money right now to crank out this feature. Like you need to do, here's the homework that I need you to do to present to me so that we don't waste anybody's time because I don't want you wasting my time. And like, you don't want to be paying me for work that's not ready. And so I loved how when I was working on a project that had consultants, there was kind of this like clear priority. And even before we, like before you write the first check, you already know that you have the designs, you have the product questions sorted out, you've thought through everything. And you're also more willing as a customer to just be like, we're just going to figure this out, just go, we'll revisit this later if we're absolutely wrong and need to. And I think it gets everyone moving a lot faster. As like an engineer who was working at consultancy for a while, I really thought it was mind blowing as well. How they were able to be so productive while respecting work life boundaries as well, that, that blew my mind.
I was, you know, I had been at really small startups where it was just a bunch of people running together with no idea what was going on. And it was really, previously I had been thinking that, you know, like, just throw in more effort, just work harder, work longer and you'll get over it eventually. But I was able to work with some brilliant people and they like started work at 8, which was super early for me at the time. And we had a nice breakfast, started chatting and then we like, you know, kind of started sitting down and coding at like 9, I think it was. Went until noon. Yeah, a pivotal, like went until noon, had lunch and then came back afterwards and it was very like by the clock, very rigorous of just like, it is noon, we are taking lunch now, we are not coding. And I was so much of like, oh, I'm going to do this. And when I first started at the engagement, I remember I Was still in, like, full time kind of work. Harder work more rather than. And I worked, I stayed up late, kept coding, and then the next day, my pivot just, like, was like, oh, I see you were working overnight, like, alone on this. He's like, but, you know, we pair on everything here and just like, selected all the code, deleted it, and was like, okay, let's do this again. Like, I hadn't written tests or anything. And I was just like, well, it works. Like, I tried it. And that, like, blew my mind also, because I was like, what did you just do?
And it was an interesting time to see how, you know, with these consultants, you are not only paying for the code and the product to be developed, but also to learn how they do it. And I think pivotal was a bit more, you know, and I use this in, like, a loving way of, like, very dogmatic about their process. They were about their process, which was interesting. And then when we later worked with carbon 5, I found that they were much more pragmatic of like, we'll come in, join the party, and, like, help out, however is necessary. How is that on the consulting side when you're working with some clients who are like, very rigorous versus others who are super chaotic?
[00:12:42] Speaker A: We adapt. I think that's part of it. That was enjoyable. We had some, like, really garbage fire clients and we had some really great clients. And, like, I think we adapt, but we still hold. I think the thing that I appreciated is that we still hold the boundary. Right. It was still like, we work this many hours.
[00:12:57] Speaker C: Yeah.
[00:12:58] Speaker B: That was also incredible of, like, a lack of planning on the client side does not necessitate an emergency on the.
[00:13:05] Speaker A: On the consulting side. No, exactly. But I think, I think similar to you, I learned that, like, I think the thing that really surprised me when I first after Carbon five went in house is like, you have to build trust quickly. And so you learn how to, like, move quickly and deliver fast. You can be very productive and very effective in a condensed period of time. Yeah, right. And so I feel like when I first got in house, I was like, everything is so much slower. I was like, this is going to take two weeks. Really, it's going to take a month, really. And I had to remind myself, okay, it's like, it took me a while to adapt and learn, and there's like, it's a bigger company, there are more stakeholders, and there are reasons for the reason why things. Why things move slower. But the fun thing about being in house is you were removed from all of that and that you were hired for a specific thing and so you could just run. And that was. We run into issues with clients. There were things. But that was really nice.
[00:13:54] Speaker B: Now that you're in house, you are just like part of this like continuous development cycle of this single product. Whereas with like a consultant, you are hired for that specific thing. And all of the prep work was done. All of that, like week and a half of prep for that two week project was done before you started on the project. Or is there just something else about the question?
[00:14:15] Speaker A: So they hired us similarly, not just to like write code, but like to help them with process sometimes to define what needed to be built. Like they had a problem and they. How would we actually build this? How do we solve this problem? So there's a lot of that. I think, I think we were removed from the politics. Like oftentimes sometimes we had to go navigate it and it was. We would help our clients. But oftentimes because we were very expensive and because people were hiring us, they would protect us from whatever. And because we were very expensive, it almost created a like, okay, yeah, how do we unblock them so they can keep working because they're very expensive as opposed to like the general rigmarole of like the day to day within an organization. And so I wonder if there are ways we could implement more of that. Not a sense of urgency, but like clear prioritization. Clear prioritization and consistent. Like one of the things about that. And it's hard for I think some of our teams to work this way, but currently. But you know, Carbon five, because we were like super agile, it was like. And everyone was on the one project and it was like we worked from the top of the backlog. It was literally like a list. And everybody had the same skill sets. They would just pick stories off of the top and the most important things were the ones getting done. So we're never like, that was the idea.
And so priorities were generally very clear.
[00:15:26] Speaker C: Yeah.
[00:15:27] Speaker A: And we forced because we were, again, because we were expensive and because of everything. It was like we could force the client to say, I need a prioritized list.
[00:15:35] Speaker C: Yeah.
[00:15:36] Speaker A: In house it's different. Right? Like there are politics at play, There are different priorities at play. There are different stakeholders at play. Sometimes there are 10p zeros. And so you have to kind of. I think one of the skills of a good manager in house is knowing we talked about this before, which balls to drop and then also how to figure out what the priorities actually what people are saying and what the priorities are. Because There's a disconnect.
[00:15:58] Speaker C: Yeah.
[00:15:59] Speaker A: Sometimes between what people are saying is important and what feels actually important.
[00:16:02] Speaker B: Is there maybe a kind of like, we're not. Because in house, resources are also incredibly expensive and just as like consultants are sometimes.
[00:16:15] Speaker A: Yes.
[00:16:15] Speaker B: Do you think that there could be a way of like, an engineering manager can help others understand, like, the true cost of. The true cost of the team and the true cost of like, stalling out a team or changing direction and losing momentum or something like that? Is there like a way we can try and like, instill that value to.
[00:16:38] Speaker A: That's a great question. I feel like there's a series of, like, sometimes people ask questions and I feel like I find it very interesting that they're asking those questions. I'm like, is that even a. Like, I think, like, it's interesting to me that they're not already, as an engineering manager, have that frame of thinking of like. Right. What is most important? What is most impactful in the business? How do I figure this out? So, yes, I think it would be if we could figure out a way to help instill some of that and some of this learning how to read between the lines a little bit. Learning. Because that's part of whether we want to say it or not. That's part of our job, figuring out how to unblock our teams, figuring out what the priorities really are, figuring out which stakeholders are really important. And a lot of that is not always super intuitive. Right.
How do we help, especially younger engineering leaders, build that skill set which is just as valuable as the technical skill set in this particular role? Right. And so, yes, I 100% agree if there was a good way. I wonder if, like, again, people say it's a harder thing to teach. I would argue we just haven't figured out a way to teach it.
[00:17:38] Speaker B: Well, I would argue we haven't talked about it. Yeah, I think it's one of those things that like, we just leave implicit too much. I've been thinking a lot about implicit versus explicit. And I feel like that's like one of the phrases I'm just using all of the time. And I think that we. When you hire a consultant, you are explicitly saying that something is a priority and you've been able to give them that charter of like this specific thing we need you to do to focus on. And you're absolutely right that like as an in house team, you have a lot of implicit things that you need to be balancing all of these different priorities. But I think it is the engineering manager's job to try and make the implicit explicit. And sometimes that is saying the things that everyone already understands just to make sure everyone understands it. Because when like the devil is in the details. And so many times I feel like we've. Especially when you're a engineering manager of like a team and you're seeing a specific project going through and you're like doing a project review and you're kind of like oh, that button behaves really weird and you're kind of like oh right, that's. That was like left implicit. And so the engineer had a different understanding of that and like a totally valid other understanding but not what the team needed. And then you know, up a level I think there is the implicit priorities that the team has. But again like making those explicit is valuable in both directions because for the team it's really valuable to know like what is the top priority for us right now at the moment. And then for the partners, for the cross functional partners, especially those in the EPD triad, I think it can be sometimes a good EM can overly abstract the notion of the team from those partners and they may not understand the thrash that changes in directions or lack of clear direction are having or they may feel like they have more time to be working on fleshing something out when really kind of the team is like no, we need projects right now. And as the em, I remember getting some advice early on of like your job is to make sure that your team is working on the most impactful thing at all times.
And it is, I think more challenging potentially as an EM when you are with that full time in house team because you have to be constantly keeping your fingers on the pulse of the implicit to make sure that it remains aligned with what's being communicated explicitly.
[00:20:15] Speaker A: I would agree. I mean I think that's one of the skills. I feel like there needs to be implicit skills for engineering management or something. I don't know, non intuitive skills, some kind of thing that explains some of these things around. Yeah, reading between the lines like, and if you think about it, the team is a stakeholder. Like when you're an em, it's like the team is a stakeholder, your product person is a stakeholder, you have leadership about like everybody's a stakeholder and it's your job, you're on the hook for delivery. So it's your job to figure out how to align all of those stakeholders and make, make sure that you're making the right decisions. Right. And so that's where the complexity comes in. When you have like conflating interests or conflicting interests is again, reading between the lines, being able to figure out, okay, well, the team needs this, but this stakeholder needs this, but the business priority is actually this.
And somehow you grease all these wheels.
[00:21:02] Speaker C: Yeah.
[00:21:02] Speaker A: And make it move.
[00:21:03] Speaker C: Yeah.
[00:21:04] Speaker A: That's also the interesting part of the job, I think.
[00:21:05] Speaker B: That is the job.
[00:21:07] Speaker A: Right. And so. But a lot of the job, I feel like is, to your point, implicit. Like, yes, there's like, there's frame, there's like frameworks for running teams and there's.
[00:21:16] Speaker B: Process.
[00:21:19] Speaker A: And there's like charts around. Like, you know, all these, like racy and Daisy, whatever. Like, there's, there's a lot of potential structure you could use. But I think that the most important skills you can. Those are tools and the skills that you need to like effectively grease the wheels. I think we don't talk about those as often. And those are like the implicit. That is very implicit that you need to be successful.
[00:21:43] Speaker B: Yeah, yeah. It's kind of the, the dealing of how do I support other people when and where I can, but then also how do I say no when and where I need to.
[00:21:54] Speaker A: Yeah. And like how do I. You have to keep all. They have to keep like this fairly big picture in mind that is sometimes ambiguous and sometimes moving and it's like not quite pieces on a chessboard, but kind of where you're like, I need to get to this result and how do I get there? And there isn't a particular. There isn't. There's one path. Right. And everyone's a little bit different in how they would do it. I think one of the things consulting gave me is a lot of those implicit skills.
[00:22:20] Speaker C: Yeah.
[00:22:21] Speaker B: And kind of like with that, like bringing it, you know, comparing and contrasting again, like those are like some of the challenges as an in house em. How does that compare with the challenges of like a consulting Em?
[00:22:32] Speaker A: Well, it was interesting because I think in a lot of consultants, especially because the teams are constantly moving because of projects. Like, I was a manager and I had reports but it was matrixed so they weren't always working on my projects.
[00:22:43] Speaker B: Which is like an in house nightmare in house.
[00:22:47] Speaker A: It's a nightmare. Externally it's really not. Because as a consultant it was fine because this is where a lot of the implicit skills come in. Because I would be leading projects with engineers who didn't directly report to me, but who I still had to like manage in that I was running this project with the stakeholders and the clients.
[00:23:03] Speaker B: And so when you say manage them, is that like managing their workloads or managing the project.
[00:23:09] Speaker A: Like I would be running these teams because somebody's like, like we did a project with Coinbase, right. And I was leading that project and so I had to make sure it happened right. People knew what they were working on, what the priorities were, they understood what they needed to do, they understood why, like they were happy with the whatever. And then I had to manage the stakeholder, the client and make that all run. And then some of them might have a couple of them, maybe they were my reports, maybe not. And so it was the same skill set, it was just split. Right. Where it's like in this case you're running the team and in this case you are effectively helping somebody with like their individual career growth and making sure that they are happy in their current work situation, even though you don't necessarily have direct control over the project because you're not running it.
[00:23:50] Speaker C: Yeah.
[00:23:50] Speaker A: And so then again, it's like, so.
[00:23:53] Speaker B: There'S some that you are managing directly and managing the workloads of, and there are some that you're managing directly but not managing to work depending on the project.
[00:23:59] Speaker A: So.
[00:24:00] Speaker B: Oh boy.
But it's like how long does a project last on? That depends.
[00:24:05] Speaker A: Like three months. Sometimes they're three months, sometimes project last. But they would rotate people out if they had been on a project for more than like six to eight months because it was long.
But so I feel like it's the same set of skills, it was just split as opposed to being condensed into one team.
[00:24:21] Speaker B: I think the aspect though of managing people's careers without managing their workloads is a little bit different from the in house because now as in house you usually have that alignment and that definitely helps as you're planning the long term, the long term career trajectories for people and you're able to tie that in with the projects. And also because I think you have to do a very good job of keeping an eye out for the projects that fill the missing gaps to help you get the signal for people. And without the musical chairs every six months, it can become potentially pretty challenging to keep your eyes out for that all the time.
[00:25:01] Speaker A: That's true. Although I would say it's interesting because like you, it's similar to how we work cross functionally or whatever. I could go to the person leading that project to be like, this person's interested in X.
[00:25:10] Speaker B: That's true.
[00:25:10] Speaker A: Right. And so, and because of when I was a manager, I was part of the meeting there where the projects were like assigned and people so that there was room for that conversation. And because the projects switch fairly quickly, it's actually, I think easier in some ways to be like, this person wants to build this skill.
Yeah, right. And these like it was, sometimes it was challenging because like we needed experienced people. And so if somebody was trying to learn a really new skill, maybe we'd have to wait for a couple projects. But sometimes it's great because you have three senior people and this person knows what they're doing, but they're building this new skill. Like put them on this project and you can ramp.
[00:25:43] Speaker B: Yeah, that's pretty awesome.
[00:25:44] Speaker A: So it is definitely different, but I don't think it was so far. I didn't feel like having been in consulting for a long time and then going in house, there was a significant gap in the skill set. I do think I just had to think about it a little bit and differently.
[00:26:00] Speaker B: Like how?
[00:26:01] Speaker A: I think in some ways it was easier because everything to your point was aligned and so it was easier to think about, okay, well, this person wants this thing and we're doing these projects and I have more control over the roadmap. I think having been in house for a little while, I think you have to think over a longer time horizon when you're thinking about people's careers. Because some of the projects are long and sometimes you have to do a few of them to get to somebody has to achieve them together where they want to go. And so biggest difference is you're thinking on longer time horizons than when you're consulting.
[00:26:31] Speaker B: Is that like with the more senior consult or with the more senior engineers? I imagine though they're also probably having to work on long time horizons to get promoted and build the case, build the skills needed to be at the next level as well.
[00:26:47] Speaker A: Yeah, I think the problem, not the problem, one of the challenges is that it was a small company and it was pretty flat. And so they didn't even have for a long time. For many it was companies around for like 20 years. They didn't even have like senior and junior or whatever. Everybody was just an engineer for many years.
[00:27:03] Speaker C: Yeah.
[00:27:04] Speaker A: And a lot of people that worked. It was a very lifestyle based company. So people worked there because they liked the changes, the change in technology and the change in projects. They liked the work, they liked the lifestyle. But there wasn't necessarily, if you were looking for like a lot of vertical growth, it probably wasn't the right place because it didn't allow for that because of the size of the company. I imagine if you were a larger company Like a pivotal. Yeah, that's more of a small company thing. I imagine if pivotal are like people who, who companies that have grown much larger, then there's room to like keep growing. But there were significant, there were enough projects where like you would show and I mean if you've on a project for six to eight months and there's a lot of complexity and then you're on another one for six to eight months, it's not that different from being in house.
[00:27:41] Speaker C: Yeah, yeah.
[00:27:42] Speaker A: I think if you're on like a lot of like two to three months then it gets harder. But we had enough variation where sometimes you're on a long project and then you're on a short project and then, and sometimes the short projects were really complicated technically. So it really.
[00:27:52] Speaker B: Or like intense.
[00:27:54] Speaker A: Yeah, so it doesn't. It's. So I think the biggest differences are like you have to build, you had to build trust really quickly. You had to deliver right fast to prove that you could do the thing and you were unblocked I think more easily.
[00:28:07] Speaker C: Yeah.
[00:28:08] Speaker A: I think sometimes we get in our own way.
[00:28:10] Speaker C: Yeah, yeah.
[00:28:11] Speaker A: And it's nobody's fault. It's a big organization, it's much harder. There's just more people and not it's one team is small, you can have a bird's eye view of what's going on, but in a big organization you don't know everything that's going on.
[00:28:22] Speaker B: And especially if you're trying to reconcile multiple multi year roadmaps together to try and figure out a potentially optimal solution, it can be difficult and no one wants to necessarily be the one that's just like we just built this for now and we'll revisit it later because then they're always worried about how that may reflect on like oh, can you not plan for the long term or like great, you're just writing tech debt for us later or something like that.
[00:28:48] Speaker A: But well, and I find it so interesting I think because so many things change. Like on one hand we want to be able to plan for the future.
[00:28:54] Speaker C: Yeah.
[00:28:54] Speaker A: On the other hand this is separate from the consulting competition but on the other hand so much changes year to year and so we can come up with a three year plan and it's probably good to have those guiding principles but then be able to adapt because yeah, things, the market changes or things change so quickly. But yeah, I do agree with you, it is a hard thing. Like I think being of like a high level executive at these companies I imagine is challenging because you are trying to Reconcile so many things, and you can't have everybody at the table because you would never get anything done.
[00:29:23] Speaker C: Yeah.
[00:29:23] Speaker B: What is something that you think would be helpful for, like, potential clients to understand about the world of consultants to have, like, a more successful engagement?
[00:29:35] Speaker A: That's a big question. Clients need to understand what they want to get out of the engagement, because sometimes that is a journey.
[00:29:41] Speaker B: What do you mean by that?
[00:29:42] Speaker A: Sometimes they're like. Well, we. They're like. They come in and they. Or they bring us in and they're like, we want to do this thing, but it's actually not the thing that they need to do. Once we start talking about process or get into the business, we're actually like, it sounds like this is your actual problem. Maybe we need to do this instead. So understanding your problem.
Having clear stakeholders for the engagement is helpful.
[00:30:03] Speaker C: Yeah.
[00:30:04] Speaker A: Because there were projects where we were bounced around and, like, somebody actually didn't have any power to make decisions, and that caused a whole lot of thrush.
[00:30:10] Speaker B: That's wild. That they could probably, like, sign the check but not make the decision.
[00:30:15] Speaker A: Exactly. And so we're not even sign the check. There's a stakeholder. The stakeholder for the project, not the one signing the check. And so we agree to something in a meeting and then go back to the meeting with other stakeholders, and then that person would backpedal, and we're like, well, we can't get anything done this way. This is not how it works. And making sure your stakeholders are aligned. I had several projects where the stakeholders were not talking to each other, and it was partially my job to get them to talk to each other so that they could realize what the issue was and align.
So I think mostly it's like making sure that you have a clear idea of a. Yeah. What the problem is and making sure that the people that are working on it are aligned on what you want to do. So, again, not rocket. None of these things. None of these things are rocket science. And yet we run into this stuff over and over and over again.
[00:30:57] Speaker B: I'm curious now because, like, for the main engagement that I got to work with Pivotal on, I know I was working with some really seasoned leaders that, like, had worked with them before. And now I'm curious. Or, like, actually, the company TaskRabbit was, like, started with Leah, I believe, like, Leah and Brian are the founders, like, working in Pivotal, like, there. And I'm curious how much of the success of the engagement I got to participate in was just because it's Pivotal's process, like, kind of their intake, you know, their application process or whatever, versus also just like Brian and Leah knowing, like we have to have all of these things buttoned up ahead of time to have a, you know, successful engagement. Exactly.
[00:31:43] Speaker A: I mean, I think you can have a very successful engagement without that. If the consulting is good, it might just take a little bit longer and cost you more money. So if you want to make sure that you're efficient with.
[00:31:51] Speaker B: When you have a shoestring budget.
[00:31:52] Speaker A: Yeah, if you have a shoestring budget.
[00:31:53] Speaker B: You really want to make sure you.
[00:31:55] Speaker A: Know what it is you're getting into.
[00:31:56] Speaker C: Yeah, yeah.
[00:31:57] Speaker A: And I think I learned a lot. Even like I think I learned a lot around process because similar to. I'm sure you did too. I like, I learned a lot around process that has been helpful in house. I think mostly about flexibility, ambiguity. Like how do you create necessary process around things that are hard to constrain.
[00:32:17] Speaker C: Yeah.
[00:32:19] Speaker A: And I think that has been really helpful. Like when things are ambiguous, how do you go about solving the problem? How do you start there? Where do you start? Because when things are clear, it's easy. It's hard when things aren't. And I think that's where a lot of the interesting stuff is. But also that's where the challenges are.
[00:32:33] Speaker C: Yeah.
[00:32:33] Speaker B: The devil's always in the details.
[00:32:35] Speaker A: I mean, I think like what do you think? I think, I think it's interesting that when big companies are hiring they are hesitant to hire consultants.
As someone who has been in house more than I have, why do you think that is?
[00:32:48] Speaker B: I think it is that like often in the conversations that I was involved with, there was a concern about like culturally, like they going to lose interest with us. Are we just going to end up hiring someone who will be around for six months and then are they going to be like, actually like this is too slow paced for me and I need to go back or are the problems maybe not the right kind that they are interested in? And so I think there is some higher confidence that you're able to have with people who have just been in full time, especially for a long time, to know that they can go through that. I think that a lot of the technical reservations are misplaced of are they just going to write bad code that we're going to have to redo later? It's like, no, no, no. Again, the consultants are often hired to clean up the mess. They have seen that mess. That's almost a worse situation where you're having to work on someone else's tech test.
[00:33:39] Speaker A: Oh yes.
[00:33:40] Speaker C: Yeah.
[00:33:40] Speaker B: And I think they just don't give enough credit to the consultants for having to quickly jump in, stay focused, provide value and all of that good stuff. I wonder how much of the people who are really concerned about hiring a consultant have actually hired consultants themselves for projects. Because I think once you have some firsthand experience of doing that and working with them, you kind of get the feeling of like, oh no, like these people are solid. Oftentimes they're people like some of the best engineers out there. Otherwise, like, I don't think the consultancy would exist for very long.
[00:34:19] Speaker A: Exactly right. That's the other thing is like, and again, there's lots of different consultancies out there, so you definitely need to do your research and like choose wisely. But I do think that it can be very valuable. And again, if you're early in your career and you're looking a way to like jump start it, I feel like it can be a very good option if those are the things that exist. Yeah, if their consultants exist kind of near where you are. I do think it's been an interesting, it's been challenging in the industry right now for consultancies. I think like the downturn has affected that too. So I think it just, it can just be a challenging business to run.
[00:34:49] Speaker B: Yeah, it's definitely a challenging environment for it right now. But it does feel like consultants often have to have a reliable process in order to produce consistent results, to maintain their reputation, to churn through projects on time and all that good stuff. And so I would totally agree that, you know, a good consultancy is an opportunity for someone early in their career to see things done right. And also that opportunity of like seeing multiple projects like running through lets you do some experiments and see what worked well, what didn't work well. Whereas at a full time job you would definitely have the opportunity to go deep. But you're going to have to live with your mistakes for a long time or you might not see the full consequences until years later and then you have to pay the piper. But maybe that's more of a philosophical kind of situation for someone based off of do they generally go for breadth or depth?
[00:35:43] Speaker A: What would you say given that you've worked also in both environments? What would you like if you could choose to do things differently in house than maybe you currently. The patterns that you currently often see, what would those things be?
[00:35:55] Speaker B: I think maybe it's going back to that, like how do we keep the teams unblocked and try and keep the priorities clear and alignment maintained? I think it's difficult inevitably for an in house team to have full explicit alignment with all priorities. But I think that is something where consultants are able. I think they have like a force magnifier through the clarity of the priority of their project. And that's something I would love to find a way to bring in house, at least for those mission critical projects. And I think we've started to see some situations where, you know, like for us at our company, like they're able to be like this is the top priority. Unambiguous, like this takes priority over everything and that's great. And how do you set all of the priorities in the different orgs and at the different levels and then help people reconcile those conflicts. Reasonable. Feels like that could be an opportunity for much faster decision making which would be fun and address maybe one of the major qualms against full time.
[00:37:05] Speaker A: Yeah, decision making. Faster decision making. We could probably do a whole episode on faster decision making.
[00:37:10] Speaker B: No doubt.
[00:37:12] Speaker A: I wonder, are we. Should we try and ground this ship? I feel like we've talked a little bit at length at both the opportunities and the disadvantages. I think given the opportunity, if I could find another environment like that, I would definitely.
[00:37:24] Speaker B: You've definitely sold me on it. It sounded lovely. Of course that is like, I guess like the Matrix thing still weirds me out a little bit, but yeah, I do love though the ability as a like full time in house employee to really like get cozy with a domain, with a project and to be like, this is my thing. Like I really, I do enjoy that, but it does, you know, I definitely respect a lot of the executional rigor kind of that you get from consultancy and maybe one day I'll have an opportunity to do it.
[00:38:02] Speaker A: Yeah, for sure. And I think maybe we should do another episode on a lot of the implicit stuff we talked about.
[00:38:07] Speaker B: Yeah, yeah. Implicit versus explicit.
[00:38:10] Speaker A: Stay tuned folks. See ya.
[00:38:12] Speaker B: Thank you.
