Tricky Bits with Rob and PJ

Who Gets Hired, Fired, and Why?

February 28, 2024 Rob Wyatt and PJ McNerney Season 1 Episode 11
Who Gets Hired, Fired, and Why?
Tricky Bits with Rob and PJ
More Info
Tricky Bits with Rob and PJ
Who Gets Hired, Fired, and Why?
Feb 28, 2024 Season 1 Episode 11
Rob Wyatt and PJ McNerney

Enjoying the show? Hating the show? Want to let us know either way? Text us!

2024 and Tech Layoffs still continue...more than a headline; they're a wake-up call to evaluate the true resilience of our skills in an ever-changing industry. In this episode, we take on a tough subject to better understand the realities of job security, debunking the myth that exceptional programmers are safeguarded from the chopping block. 

We also challenge the notion of generalist vs. specialist and instead focus on the all important question of "what is the value delivered" and "what skills do you need to deliver that value."

Finally...we remind everyone... your self worth is not something that is defined by any company...you have value far and above your job.

Show Notes Transcript Chapter Markers

Enjoying the show? Hating the show? Want to let us know either way? Text us!

2024 and Tech Layoffs still continue...more than a headline; they're a wake-up call to evaluate the true resilience of our skills in an ever-changing industry. In this episode, we take on a tough subject to better understand the realities of job security, debunking the myth that exceptional programmers are safeguarded from the chopping block. 

We also challenge the notion of generalist vs. specialist and instead focus on the all important question of "what is the value delivered" and "what skills do you need to deliver that value."

Finally...we remind everyone... your self worth is not something that is defined by any company...you have value far and above your job.

Speaker 1:

Welcome back everybody Tricky bits with Rob and PJ For today's episode. We're going to tackle a subject that is front of mind for a lot of people, and we'll talk about one stat off the top, which is that we're at February 22nd right now 2024, and roughly 41,000 jobs have been turned down effectively in the tech sector. We're not even two months into the year at this point in time, and we've seen a huge slew of layoffs. The subject we really wanted to talk about today, because I think there's a lot of misconceptions out there, is who gets laid off, who gets hired and why does this stuff happen. There's a lot of things that sound right out there that are actually wrong and inactionable, or naive at the very least.

Speaker 1:

And so, rob, you sent me a video recently that claimed to contain the brutal truth about layoffs, and the points that were highlighted in the video were you know, if you're a good programmer, you were not laid off, which implies basically that if you were laid off, you weren't good, and this is a fairly common perception. I think that exists. The other points were that specialization is what caused people to get laid off, and that people should not look to get overly specialized and should learn some additional frameworks. And finally, there was this one last point which I think really put me over the top, which is that programming jobs are starting to pay the same as blue collar work, and it really carried this stigma that somehow that we've seen before about blue collar work not being as good as white collar work. So maybe we'll get to that one at the end, but regardless, the whole thing really got my goat. And then I was like, I think, spamming you over text effectively, of just why this thing like really ticked me off. That's why I sent it to you.

Speaker 2:

I do think while there may be some rhyme and reason to who gets hired or laid off, I still think it's way more random than any one person would like to admit. It's very difficult to get yourself into a position in a corporate structure where you're immune to this sort of thing, and I do agree with you that it's not necessarily the worst that get laid off. A lot of it comes down to need. Yeah, if your position is, if your division or your product or whatever you're selling to the end consumer is moving away or being contracted out, they simply no longer need you. So you could be the best there is, and now there's simply not a position for you, and maybe having a broader skill set, having those extra frameworks under your belt, is something that would keep you on if you wanted to stay.

Speaker 2:

The idea you can do that being a subject expert or want to do that, is something else that's up for debate. So I think that's where a lot of good people get laid off. Okay, you, and I think that point you just said is what goes back to the generalist point of like, if you're really good and you're really general, you can find a job in these big tech companies. If you're good enough, they'll keep you on, just so no one else hires you and they'll find something for you to do. I think the economics of that model is now what's changed and I agree I agree, being that wide generalist who just kind of fills in a gap wherever it may be those positions are going away. Maybe being more specialized is where you want to be today.

Speaker 1:

It goes to this, I think the value question I think we're heavily refuting that video at this point in time about if you were too specialized and obviously there are certain specialized positions that are over specialized If you were too specialized, you know that was the reason you got let go, rather than and if you got let go, you were somehow not good, rather than what we're saying, which is that you could have a very specialized set of skills like Liam Neeson. But if the company doesn't need that set of skills, even if you're the very best you know embedded systems programmer if you're no longer on a project or if there is no project at that company that uses embedded systems, you're not needed anymore.

Speaker 2:

Yeah, no, value is not good Are two completely different things.

Speaker 1:

Yes, your value to that company has gone down.

Speaker 2:

Your value as a whole hasn't gone down. It may have actually gone up, and I think that's where people get all of this fuzzy of like I got laid off there. I'm not very good. In reality, it's exactly what we just said.

Speaker 1:

Yes.

Speaker 2:

And sometimes it is because you're not good. That's fine. Being overly specialized to a point of ridiculousness, where in that video mentioned oh Snapchat, have a button, engineer. Why did you get yourself into that position when all I can now do is buttons in this application and that's all I can do, like what happened to the rest of your skills. Why are you not exercising those skills? It's almost complacency at this point of like. Oh well, I'll do buttons because I keep my job.

Speaker 1:

I think it's a really excellent point, and there's two sides of the equation, which is that that person likely did not invent their own job of button engineer.

Speaker 1:

That was probably crafted from the company of saying, hey, we're going to have a whole slew of people who are button engineers and we did that because it's good for someone's promotion packet as a manager. So there's an aspect here where it is the specialization is coming about by virtue of the company deciding we're going to collect these people into very specialized areas. I mean this, this happened at I've seen this happen a lot of places where it's like, hey, we're only going to have front and engineers over here and back and engineers over here and those your skill sets, and that's how we as a company are dividing this up. But to your point, rob, if you accept that situation, that is your complacency of saying I'm just going to be called a button engineer at this point in time because it's more convenient for me to stay at this company, and maybe it's because you're besting at that point in time, or whatever, rather than you know, go someplace where I can have a more expansive skill set.

Speaker 2:

And I think it's also plays into short term versus long term. Yep, I've like, I've been a button engineer. In fact I met you and, insomniac, you were doing the UI, I was doing the UI, I was helping you for the back end support. Yes, but it's temporary. I've like can you just make this work? Yes, I can, and it's within my skill set. That doesn't mean I want to do it permanently.

Speaker 1:

And one of the things actually I think that's really useful is when you can put yourself out of a job. I mean to take that example exactly, I was doing basically the UI, but the whole point of it was to get the framework up and running so that the artists could be doing this directly, the product people could be doing this directly, rather than having to have me go in and poke around and see plus, plus, like can they export assets and write some Lua code so that they can be the ones that are actually doing this. So I actually really like the idea of putting myself out of a job, because that means I've automated something away, which means that I then can go on and do cooler stuff.

Speaker 2:

And I think all of these factors play together. It's it's people get sucked in, whether you, like you said, whether it's because they want to vest for longer, or they're sticking out until some other project comes online and they don't quite make it, or simply company ones out of money, or whatever it may be. There's a lot of reasons why this happens, and I think a lot of people get themselves in that situation.

Speaker 1:

I agree it's a very seductive place, especially if you have a family and you're vesting like a lot of money or like your effect will be dependent upon that income. I get how people get themselves stuck in that, but that doesn't take away the fact that you're right that this creates a risk factor. And this is an actionable step people can take is to really recognize, like, how valuable am I to a company as a button engineer, versus trying to craft some new product that might have a chance of actually being sold and bringing value into the company.

Speaker 2:

Yeah, take a step back and ask why is there a button engineer? Why is this not a process and why can't I make this process? Can I put myself out of a job by managing a new process and or creating that new process? And I'm actually on the other side of the fence. I've let myself go from a handful of companies where it's like I'm not doing anything that's useful to me. Yeah, it's like I am now just a warm body fill in a slot that needs to get done and I can do it for a reason, but I can't do it because it's my job.

Speaker 2:

Right, I like to do the low level performance graphics things and I'm not really doing that. I'm just helping out and I won't hire to help. I was hired to do what I do and now I'm not doing it. So I've been on both sides of that coin and I think it's fairly obvious when you're in that position where it's like I'm not doing what I was hired to do, I'm doing this kind of ridiculous thing. You pay me a lot of money and it's like I'll just save you the money.

Speaker 1:

Yeah, I think it's a great, actually value set man. I mean to say like, hey, this isn't as valuable to me as Rob. It is really not a value add to the company, so let me go someplace else.

Speaker 2:

Yeah, or be a contractor or work part time or something that gets the job done but doesn't cost you as much as it costs in you, and there are more efficient, effective ways of doing what I'm doing, and maybe it's not me, maybe I train someone else and I'll come back in six months when you have a position for me, which is why I've always tended towards the contract workers. You tend to be hired for this and you do that and you move on. It doesn't give the company that opportunity of well, now we have these really good guys and nothing to do with them, and we don't want to be the higher fire company, but we have little choice.

Speaker 1:

I do think that organizations have this problem which I call incrementality, where they actually get increasingly risk averse to changing processes at large and, especially when the money is flowing in, they will opt to just hire a new person rather than to make a new process, Even though there is a huge advantage to actually like crafting a new process, it's actually just takes more than they're willing to put in. Have I ever told you my analogy with roundabouts and stoplights before? Nope, go for it Sweet. So when you look at like a four-way stop light versus a roundabout, in terms of things like safety and throughput and like almost really any factor, the roundabout is more efficient period. It is, hands down, just the right answer. But you have to make a very conscious choice to put that roundabout in at the beginning, when you're creating that road or creating that intersection, and there is a cost to it, and this might be a Europe versus US thing.

Speaker 1:

If I just had a single road and then later on decided to add in a new road as an intersection, the dead simplest thing for me to do is to put in two stop signs, not even four, just two, because I know that this existing road has more traffic to it, it's just the way it is.

Speaker 1:

And then later on oh well, now both roads get more traffic the next dead simplest thing for me to do is to put in two more stop signs. So now I have a four-way, and then after that, when there's enough traffic, the next dead simplest thing for me to do is for me to put a four-way stop light in there, and that four-way is going to be a lot less efficient than the roundabout would for the same job, but incrementally it was the cheapest option, even though I reached kind of a local maxima, if you will, of efficiency. I think organizations work in the same way. It's that, hey, we don't want to really redo a new process because that's going to take time and energy to rip out the stop signs and put in a roundabout. I'd rather just add another stop light and be done with it, because that's the dead simplest thing for me to do.

Speaker 2:

And it's a pretty good analogy as to how things get to how they are. Like if we had the hindsight of knowing what was going to happen, then we'd have done it differently in the first place, and that roundabout is a perfect example.

Speaker 2:

I think there's more analogies there too of the ongoing cost of a stop sign. You got there the cheapest incremental step, but now there's an ongoing cost. Where a roundabout has no ongoing cost except physical maintenance. There's no electricity to pay. There's also the upfront cost of well. A roundabout takes more room. So once we've built on all four corners, we can't ever pull off a real size roundabout. You can put the European mini roundabouts in, especially in American roads because they're so big. But yeah, that incrementalness has locked you into the future path. It's like you can't go back.

Speaker 1:

And to me, this is how we get a button engineer.

Speaker 2:

You start off as an engineer, you become a UI engineer, then you become a button engineer. That's literally the steps. How? Why did you allow it to happen to yourself? Yeah, because you know a button engineer is not a thing in the grand scheme of things. If you're doing a job that has no value to somebody else, you have to think it has no value to your co-employer, and probably to you either.

Speaker 1:

This value proposition is. One of the big sins of Big Tech for me is that there has been such a divorce between the value to the company that any given project will give and its cost People will make careers out of, effectively, you know, building up their teams to be something huge, because they need to be a certain size to get to director or vice president or whatever, and so they're like looking at headcount rather than saying, hey, what is this division actually doing to bring in value against the cost of that headcount? And this is the equation, like you talked about earlier, that is changing, which is now they are scrutinizing and looking at what is the cost of this stuff versus the value that it's actually bringing me in. And I think that's one of the reasons why we're saying you know what, the cost of these button engineers isn't worth it.

Speaker 2:

So do you specialize or do you not specialize as an actionable item?

Speaker 1:

I think that this is. It's actually the wrong question in my mind, because the right question is hey, what are the valuable problems that people are willing to pay me for? What are the things that we actually are trying to solve in the world? And we're trying to solve it with technology, okay, great. What are then the skills I need to go after to solve those problems? Could they be generalists? Maybe could they be specialized? Maybe the core value proposition really isn't like do I specialize or do I go general? It's what's the shit I wanna solve? What do I need to go to figure out and go solve it? What is someone gonna pay?

Speaker 2:

me to go. Do I agree with that? I also think it goes further back than where you are in the workforce. I think this all starts high school college of I'm gonna be a software guy, I'm gonna be a hardware guy, and then you kind of stay on that path and take my own experience. I'm technically a hardware engineer, like I have a degree in electronics and a master's degree in micro-projects.

Speaker 1:

Yeah.

Speaker 2:

But all the things I do are kind of related. I do a lot of, I don't do much hardware. I do a lot of firmware and it's obviously low level hardware based programming. The architecture and the electronics fit in there. I do a lot of graphics which came from that in the old days hardware and consoles and graphics and audio were all the same thing.

Speaker 2:

But that hardware background although I'm doing pure software at this point is just how data flows, how DMA works, just general bandwidth and things that you think about in a hardware sense, like you don't necessarily think about in a software sense. So although I went for hardware and now mostly do software, it's all kind of related, even if I ticked a bunch of boxes and said, okay, technically on paper I'm kind of a generalist. I can do high level code, I can do level code, I can do software, I can do hardware, I can do graphics, I can audio, I can do gameplay, I can do a bit of web stuff and all that. So I tick a lot of boxes. But which am I good at and which do I want to do? I think comes back to the question of what you just said, of what problems can I solve?

Speaker 1:

Right, and what problems do you want to solve? I mean you probably are not thrilled at the notion of hey, I wanna write JavaScript in SQL, right? I mean that probably would not be something that you'd really go after. I know you'd do it if you had to in a certain situation, but I can't imagine that's something that you would gravitate to.

Speaker 2:

naturally, and I think that also is the point of like do it because you want to learn something new, right, and it's completely out of your comfort zone. Like web stuff to me is foreign as it gets, yeah, but I like to tinker with it. And what point does the tinkering become? Another box you check of something you can do or want to do. And is that making you a generalist? Because you have a broad knowledge and you've experimented and played with a bunch of different technologies? I'm technically still a specialist, like I do these things and I can fix things over there if I need to, and some areas are never enough to be dangerous and it should keep me away.

Speaker 2:

But I think a lot of people call themselves generalists when they really not. It's making you better at what you do to see how other people and other environments have solved similar or even the same problem. And this comes back in hardware all the time. You'll look at like how all eight bit micros, the Amiga, the consoles, all the different computers we've had to get to where we are A lot of what's old is new again applies in hardware too. I've like oh, we used to do it like this and then it kind of went out of vogue for a while and then now it's back doing it kind of the same way, but in a more modern version. So there's no harm in broadening your knowledge base. You've just got to be careful how general you interleave at all and at some point you become this Uber generalist who can kind of jack of all trades, master of none. That's where you don't want to be.

Speaker 1:

This is why I take a lot of umbridge with the generalist versus specialist term. I think a lot of it comes from big tech, where there was this mantra that came out my favorite company in the world, Google where they espoused the notion that we want to hire a whole bunch of generalists. Well, the idea that once you have these sort of smart people, generally you can stick them anywhere. But it would lead to these tropes, these memes that we'd have internally. We have people who got their doctorates, who are moving proto buffs from one proto buff to another. So it'd be like your API proto buff versus your storage proto buff and that, basically, is their job and it's like, okay, that might be the job that's valuable to the company. Again to your point, why not automate it? But it's not necessarily like the right use of those folks' skills. And I know what happens at other companies where the right person for the job isn't necessarily the one who's in that job. They're stuck somewhere else because the politics of the situation.

Speaker 2:

Apple. I've seen the two wrong people for the two jobs working side by side. They should literally have just switched positions and it would have been way more efficient. We got a math guy who's doing embedded systems and we have an embedded guy who's doing math on AR type stuff and it's like you should switch and then be like he's good at that, let him do it. And again, it's politics or headcount of team members. I'm sure that one could have been resolved because the teams work pretty close together, but there was no need, there was no impetus. We need to switch these two people, which I think the big tech versus the startup mentality is very different. Like in the startup, those two people would have been switched in a heartbeat of like you need to do the embedded stuff because we need it done now. We need it done by someone who knows what they're doing, no time to go learn this stuff Right, and the same the other way around.

Speaker 1:

But anyways, thanks a bunch. The value equation still works. It just works more efficiently there, which is that, hey, we have an existential threat to our company If we don't get out this product as a startup, we're going to die. So there's a huge amount of value to switching those folks, especially relative to their cost, because they're trying to get that thing out into the market right. So in many ways, the lack of money creates that efficiency that needs to be there simply for survival.

Speaker 2:

Yeah, so it just comes back to that original point of not necessarily the best or worst of the ones who get fired. It's what value do you, do you bring? And I think it's just more obvious in the startup, where every dollar counts, where, if you had Google, it's every billion dollar counts.

Speaker 1:

I'm going to deliver Rob a very rare compliment to Google at this point in time to help illustrate these points. I know I know you probably thought it would never happen.

Speaker 2:

I've never heard it before, so go for it.

Speaker 1:

I think Google Stadia is actually a pretty good example of something where it was a huge product area of the company. It had a lot of great programmers people that you and I had worked with in the past that got hired over there.

Speaker 2:

I'm going to disagree with it. I'll let you finish first.

Speaker 1:

Okay, all right, I'd love to dive into that, but they were highly specialized and they worked on the internal studios or done Stadia. Ultimately, google decided that it wanted to shut Stadia down as a whole product area, and this is where I give them credit that they made a choice effectively to shut down a product area, and then they had opportunities to say hey, if you want to try and stay at Google, try and find another position, otherwise go elsewhere. So I do think that this is where the company said this product area is not valuable to us anymore and even though there are lots of people that could be good here, we're not going to keep them.

Speaker 2:

Okay, my turn.

Speaker 1:

Your turn. Bring it on. I want to hear this.

Speaker 2:

I think Stadia hired all the wrong people to begin with. They didn't hire good game engineers. They hired producers and managers who'd worked on good games. They had a name for themselves. Those people without the team that made the game are useless, and that's what Stadia showed. They decided we're going to make this new division, we need specialists, we're going to go hire people from the game space. They hired lots of high level managers, lots of producer level people, not that many actual game engineers, not many gameplay engineers, not many audio engineers, not many graphics engineers. They didn't go in poetry or from Epic, for example, or Naughty Dog. They had a very high level team of people who think they know how to make games but don't have the staff to make the game, which was the first mistake. And then a lot of stuff gets contracted out and that's the second mistake.

Speaker 2:

I think you have to have an in-house team to drive the technology. Epic have in-house games to drive the Unreal and without that in-house content and that direct feedback as to how the product works, you never really get that feedback. And from there it's a slippery slope and it just went downhill. So, yes, they did lay off the team and they did hire the team for all the wrong reasons. You need actual content, people who can drive the content forwards, people who can get the result that you need. We need to show how to do a high-performance game in this, and that all got contracted out to Ubisoft and the third parties who they worked with. Blah, blah, blah. There was no real direct feedback from the guys doing the network architecture of these server boxes that were going to stream games. There was no one in-house to hammer on that and give them direct feedback. It was just kind of a test code and then they'd send it out to developers who'd be like no, that kind of works, and that's the kind of feedback they would get. They didn't have anyone in-house who was like, let's re-architect how a game latency works, how a game updates and things like that. Because if we do, if we can get this to be the new norm, we have a much better platform than what's ever existed before. And none of that existed. They didn't have the technical people In this case, very specialist people to solve very specific problems and again, when that went away, they were not needed.

Speaker 2:

Fine, get rid of them. They went into it as a specialist, knowing that that's what it is Again. Contractors would be good here, and none of that existed. It was a bunch of high level Phil Harrison type people who can't make games without the massive amount of brilliant engineers and artists and whatnot behind them, and you take them out of that position and now they don't have that team to lead. And if you take the good guy from here and the good guy from there and this person from over there put them together, yes, they were good, but it's the team that makes good games, not necessarily the skills of the individuals on the team. And Google failed all of that because they applied big tech mentality to something that isn't yet big tech. Even the big companies don't run like big tech.

Speaker 1:

You mean the big game companies.

Speaker 2:

Don't run like big tech, the big game companies the good media, the big media companies too, and I think a lot of people have struggled with this. I think Amazon have tried to get into games and the video have tried, and Google obviously tried multiple times and they always fail. And they fail for this exact reason. They'll put out a press release of we hired this person. So fucking wild. What's he going to do by himself? He's going to make a whole new game. He didn't hire the team, don't forget. He ran the team, but he didn't hire that team. He got put in the position, or she to run this team, which happened to make a brilliant game. They probably had a lot of say in making that brilliant game, but I think they overestimate the dynamic of how they got there and think they could do it again. In reality, that team was hired organically. It was never put together. A put together team has never worked in games or media. Even if it's a dream team, it's never worked.

Speaker 1:

I'm going to use a rare sports analogy like this difference between a team that really is working together versus like an all star team, where it's like an exhibition game. You pick out the best players from each team and hope they're going to play together well, and it's never as good as like the teams that actually are like practicing and playing together. Yep.

Speaker 2:

And I think Google hired people from the game space. They went there, but they hired the wrong people. And I think they hired the wrong people because they didn't know any better. And I agree with you, they did let the team go. In the end, we shut the division down. Like you said, find a new job in Google or go somewhere else. That's fine too. It's a good example of specialists not being needed anymore. As we talked about earlier, I think Stadia is a glaring blemish on the history of gaming.

Speaker 1:

I think it's an important example because you know to your point where it's like, hey, we can acquire this talent. Maybe this talent is sort of considered you know good or is sort of famous. But the difference between like acquiring individual pieces of talent and the value that they're going to bring versus their costs, versus like what you see actual studios do, like like what not studios you see Sony purchase entire studios. You see Microsoft purchase entire studios because they know that team is going to be the thing that matters, not the individual players.

Speaker 2:

Yep, it's the old star it's. They went hired individuals. They should have found a company who was doing very good streaming and started there. Put Google's resources and Google's network behind them and let them do it differently, or just done it differently to start with. But they can't, because then people won't use it. The way you solve streaming games to make them like flawless isn't to use an existing game that runs as is on a PC. There's a lot of things you could do differently. They knew these problems existed, but again, they didn't hire the right people. It was just more of a PR hire of like oh we got Phil House and what does he actually do?

Speaker 1:

This is a really important point generally, though, about the appreciation, or lack thereof, of teams versus individuals in big tech, because, again, what they they have done as in a cultural sense, has really fed this notion that if we hire you, you must be good as a almost a cache. And then the cultures exist, like we've talked about before, where it is about individual achievement, individual leadership, individual impact and action, rather than what are we as a team or a product area? What is the value that we are bringing to the table? Not necessarily like. Is my individual piece? Am I necessarily the best button engineer in the world? Doesn't matter. Is our division actually like bringing value back in? And are we doing that as a team, rather than you know what is the sort of individual, all-star characteristics that are there? And I would actually say that I think maybe that is the problem with the specialization. It becomes too much about the self and individual achievement and how good am I looking Versus like? How are we doing well as a team? How are we doing well as a division? How are we doing well as a product area so that we're actually able to create a valuable economic story?

Speaker 1:

I agree, a lot of people, I think, focused for a long time or continue to focus at this point in time, that all these sins came about because of the zero interest rate era, meaning that no one really looked at bottom line costs. No one was looking at profitability. Everyone was looking at top line growth and maybe revenue at that point in time, and I think there's a lot of people that blame effectively, like, zero interest rates for this, and I don't actually think that's true. I think there's a lot of blame to be had on the VCs for this one. Vcs were very fundamentally focused on growth at all costs, without any worry about profitability.

Speaker 2:

Yeah, and I think that's definitely biased. A lot of smaller companies who run like big companies because of the VC funded.

Speaker 1:

I agree. And then a lot of divisions within big companies that effectively got run in the same way, but instead of VC money, it's basically just whatever ad money that's coming in to effectively fuel these product divisions that are not making money. It's bad patterns. I got put in for not looking at self-sustainability and profitability. Now people are looking at costs more heavily and that's when they're starting to look at these employees.

Speaker 2:

Yep, but I do think they should look more at the team level and not the individual level. I still think open management at tech companies is like we'll take this person out of the team. Maybe they were the person who held the team together, but on paper they're not the best. Maybe the rest of the team suffers because that person's gone. I think it'd be best if they just did it team by team, product by product, instead of you're gonna move to this unrelated team because we perceive you have value and you're gonna get fired because we don't perceive you as having any value, where in reality could be the opposite.

Speaker 2:

As far as the team structure and the contributions to the end user product are concerned, yes, but that's never measured. It's a non-tangible thing as to like, what do you contribute to the end product? Yes, and that could be anything from comic relief to being the person who made it all work. It could be anything in the middle, and without either one of them it's not going to work. You can't eliminate the social structure of these teams and I think that's where managers and corporate cold bloodedly just go. You yes, you no, and you just decimated the team. The team now won't produce because you've destroyed the social dynamic. You've took it from the sports team. That places the team to the all-star team and you've decided who has value and who doesn't. That's not really how it works. We're not AIs, we're humans, and the social side is incredibly important, and managers don't give a shit.

Speaker 1:

I want to tease this one apart, rob, because I think this is actually a really interesting balance point, because I think you bring up a really important point about the social dynamics, the social structures of teams that make them more effective, and I think that's not talked about as much. I think what is talked about is the shitty term that you love to hate which I hate as well is when people call companies families but I do think it's worthwhile to talk about the positive side, about the social dynamics that make teams effective and how that doesn't always translate into something of individual achievement.

Speaker 2:

It doesn't always translate into things that a company likes Like you have these team-building days, which is supposed to be social. It's like you shouldn't need them. They should just be going to have a day off and do something fun, not have these stupid exercises to try and get you to mingle. By this point, you've already picked who you're going to mingle with and who you're not going to mingle with. You've been having a beer with them in the pub, you've been on vacation with them, you've been hiking with them. It's if you haven't done it yet, you're not going to do it because somebody put you in some stupid situation that and now you have to do it. Like team-building days are ridiculous. It's just give them a day off and I'm going to do something fun and let them pick it.

Speaker 2:

And again, it's corporate. Everywhere they always forget the social side. These people hang out after work, they talk after work. They might be neighbors God forbid. They might be dating, but that's a big no-no and it's like we're humans. The social side is incredibly important. Things will get decided outside of the office. If you'd like it or not, accept that, because that's the reality and it's always going to be the reality.

Speaker 1:

Well, it's either going to happen or you're not going to get that cohesive social structure that makes teams better.

Speaker 2:

Yeah, I mean, some of the guys I've worked, I've been friends with at work in the past, are still some of my best friends and you're meant at work. You don't really get that. It's almost like you're trained to be a robot from the day you get the big tech of like you do this, you don't talk to anybody else, you talk outside of work and it's like nobody wants to go in social life. It's like, oh, I got to work late, I've got to go home to my family Both reasonable excuses, but when there isn't not much of an excuse, there's not much dynamic to get you to know each other to. It's almost like corporate's avoiding it.

Speaker 2:

And if you're the one, I think you're putting yourself out for HR management to notice. If you are the social one, that is true it's like it's another. It's almost a red flag of like oh well, fire him first because he's gonna cause trouble. Without defining it, I'm just like oh, it's, it's different to the others, he's, she's different to the others, she hangs out with him, can't have them on the same team.

Speaker 1:

It's risk aversion at that point in time it's absolutely risk aversion.

Speaker 2:

It's like trying to avoid as much, avoid humans being human and and trial a pigeonhole everything and everybody into their own little slots, because if they could keep your pigeonhole it's easier to manage you. When you step outside that pigeonhole, they don't know what to do with you. What did that be? Technical, social? It's easy to be like. Well, get rid of him first.

Speaker 1:

It's fascinating because you know that now that we're talking about the pigeonholing, that brings us back to the button engineer right when it's like, hey, if we can just isolate these folks, specialize them, you know, not be part of the broader picture of like solving the product, but just be solving this one little thing. It's like, yeah, maybe you'll get along with the other button engineers, maybe you won't, but you're not looking at holistically.

Speaker 2:

It's the cog in the machine. Yeah, you are. Now you are the button cog, right. You are no different to say and I need a this type of coil on an engine or I need this type of fuel injection. It's like it's a part. It's a part of a bigger machine and you're part of it, right, and that's just big tech.

Speaker 2:

If you were generalist and you're all over the place or a specialist with general knowledge, then you Can't be pigeonhole so easily and they don't really know what to do with you, which is kind of why they didn't go down that path. If we need four button engineers, we need a UI engineer to manage the button engineers, and they literally just design it as if you're building up like a Lego set of like oh we need four red blocks and we need these big blocks over here, and it's literally the same thing of like this is what we need, this is what each of them will do, this is what they will cost. This is what the project will cost, yes or no when it gets to the top. There's no holistic thinking in corporate management higher in and fire.

Speaker 1:

What I think is fascinating is that and we see this in big tech a lot when we have effectively these cogs in the machine that have been created, but then they've tried to artificially then layer on a social structure. And this goes back to hey, we're a company, we're a big family to try and effectively seduce folks into this kind of non-organic social structure Effectively to have them work longer hours and that's been admitted by many people in the past is, you know, craft all these baubles effectively to make them want to be there longer.

Speaker 2:

We'll provide lunch of like. Right everywhere I've been that provides lunch. People tend to get lunch. Go eat at the desk. If you suggest like, oh, let's go out and have lunch or, god forbid, I've a beer at noon a British, for God's sake Then you like some weird, almost alien creature that showed up of like well, you're gonna leave the premises, the a this free food and you're gonna leave and buy food.

Speaker 1:

I'll never be a damn right I am so in the lack of basically these organic Experiences where it's like, hey, I'm gonna go to the pub with my teammates and let's talk about this, maybe a few beers in we're gonna solve the problem, we have, in many ways, regimented fun we have. These are the, the lanes you can operate in, and then we still want you to develop an emotional connection to it so you can work longer and You're still just a cog in the machine though at the end of the day.

Speaker 2:

Oh yeah, I mean the and they corporate Team building exercise days are just proving the point that you're a car in the machine. Yeah, and I second it all fits into the everyone gets a medal mentality too, which I'm not really into of, like, some people might be really good as we might be really bad, and that's not a good team dynamic at that point. But that's the world we're living and that's also teams really good engineers.

Speaker 2:

Some people are really bad engineers, but you bring something else to the table. We're all have to be good at the same things, right? And I think the way that HR Management higher and fire, like I said, it's very different to what the team actually needs, right? They look at it as black and white of like we need one of these and one of those and we don't have one, so we'll hire one, and then we don't need them, so we'll fire them where, in reality, teams need all of this social support and we don't need team building days, because we should be social as a team, right, making our own plans, doing our own thing, paying for it ourselves too. We don't need the company to pay for it.

Speaker 2:

If you have that team dynamic, it's much easier for that team to work because you can depend on people like you know what. Can you just do this for me? So I've got to finish this, or I'm not in today and this needs to get done. Can you take care of it? It's much easier To treat them as almost. Like says that this is where the family mentality in corporate comes from. Of Years ago, teams were very family-like. It's like some of your best friends are there, right, you'll do anything for them. And then that got corporatized and Now it's these little robots that go sit in a cubicle all day. And that's not our family, but it isn't no.

Speaker 2:

No, and again, this all fits into the higher and firing thing and it's also why HR hates me.

Speaker 1:

That's all right, rob. People hate people that Tell the truth, and that's what you just call it out, oh.

Speaker 2:

I call it to her face because you you call this place a family to my face and you're gonna have a whole Regret, a whole list of regrets of like you shouldn't probably said that, but they're allowed to say that. But I'm not allowed to question why they say that from their standpoint.

Speaker 1:

They're doing it effectively to Craft an emotional bond and there's a lot of people, especially those who you know have come up after us, who buy into it. You know, there's some people who only worked in big tech and that was their whole identity and now, effectively, as they get fired and they realize that, oh, this is a company Like it's, this is just business, this is just the way it works.

Speaker 2:

It's a hundred percent business. That's why I will never let you Call it a family. Yeah, I mean family stand behind you mostly at the time, no matter whatever you do right.

Speaker 2:

Like you do something, you go to jail. Your family will probably stand behind you. You get divorced and all things like that. Or you do you become a drug addict and you get fixed and your family stands behind you. It's none of that would be stood behind by corporate. It's like a best. They'll be like oh, you having problems, you see your work stats have gone down or you're struggling somewhere. Let's get you a therapist, like fuck off.

Speaker 1:

That's, that is it. I mean it. And it comes back to that equation Are you more valuable to the company than your costs? That's, that's fundamentally it. And you know, because part of those part of the cost really is like it's actually very hard to fire someone when it's not layoffs. You know you have to build up a whole body of Documentation, you have to have given the performance improvement plans. You've have to done all this stuff. During layoffs it's relatively easy because it's just somewhat, you know, a Course at that point in time. But to your point earlier, you Decimate teams that way because you destroy the social structure, you destroy the morale and you're not necessarily putting people into the right spot For those teams to succeed.

Speaker 2:

Yeah, and a lot of the people making the decisions have never had that family connection in a corporate world where it's genuine family, like your best friends, right and and it. They've never had that, so they don't feel the need to sustain it and so it's easy for they go. Okay, you get fired, you get moved, the rest of you are Gonna stay poor and the rest of the state poor. Or they get someone new of like he replaced him or she replaced her, and Now the dynamics different and everyone starts drop. Now the end user product suffers, right, which is kind of. Most of these teams are so far removed from what they're actually making hundred percent you can't even measure your own impact on the end product Exactly.

Speaker 1:

There's been such a divorce to that end user value. You don't know what it is that.

Speaker 2:

Anything that you do, it matters and you don't even know the metrics. They measure in you against, because they don't know what matters.

Speaker 1:

Exactly, it's turtles all the way down. Everyone has crafted basically these structures that really come down to how much headcount do I have so I can get to the next promotion, rather than what is the value of this team? How is this team actually making this product better for this end user?

Speaker 2:

What can we do to make the team function better. We don't need a new person, we need the bonding of the team to be better and you can't force that. It has to happen naturally. And all the products that get made that are groundbreaking games, hardware products, software products, whatever they may be always tend to have this team addition in there of they did something called and then others try to copy it. It happens for individual pieces of IP, it happens for entire products of entire games. I've like, oh well, these people got really good at making mobile games, so now EA steps in and starts making corporate mobile games because they were successful, so therefore will be successful. All these managers really that stupid that they just look at it black and white like that? I mean, really someone call me and tell me like you're a manager, a big company. Are you a fucking idiot or not? I think yes is the answer.

Speaker 2:

They'll never admit it, but yes, yeah, they're like ultra, ultra idiots to think that's how the world works. I've like, really, my teenage daughter can tell you that that's not how the world works. They had a good product for them. Is it like? Analyze it Like is it what made it good? How did they get there? Just to assume that we can do it in a corporate way and get the same result is just ultra ridiculousness. But it's kind of me to feel being left out of like oh no, they're going this way and again you do get the whole Microsoft mission mobile result if you're not careful. But this is a much smaller scale. This is a team scale thing, Like this team did well by being a team and made something cool, and then they want to replicate the result without replicating the structure.

Speaker 1:

Let's compare back with Stadia versus Xbox. I mean, you've mentioned in the past how Xbox operated as this little startup inside of Microsoft. It was a team that had a dedicated vision. It was doing something innovative, which is making a console out of PC parts at that point in time, and they stuck with it. It took Microsoft seven years before Xbox became profitable. Stadia operated as the corporate let's bring in like just pick out all the people we think are all stars, kind of toss them together, not make any changes. You know, keep it within the corporate structure and that thing gets shut down. So I think there's a huge amount here of having that vision, having that team being able to understand that value, even if, like, not everyone looks the same, not everyone is operating on the same axes, like everyone's bringing something different to the table, which is important.

Speaker 2:

It's hard to quantify some of the human elements that make a team work. It's much easier for a manager to look black and white of like metrics yes, no, you go, you stay, and that's how a lot of people get hired and fired. And in the non-layoff world, in the layoff world, it's a whole different thing. The idea of the button engineer you must know when you're in head, at some point you're going to get laid off because they're not going to need buttons anymore. We're going to go to something completely different. Or they have all the buttons that could possibly ever want. And again, where is that back of your head? Thought of like I should automate this.

Speaker 1:

I think this does take us back to the actionable stuff we talked about earlier, which is, instead of trying to answer this question of generalized or specialized which I still think is a BS question that got invented by big tech Look at the problems that need to be solved. Look at the technologies you want to go after. Look for teams that you get along well with, like. Find the people that you want to be in the shit with when stuff's going wrong. Find the visions that actually matter. Find the things that actually get you going and go after that. Don't basically try to re-plug yourself into some corporate structure that calls you a family and your value is tied up, basically, in your identity as being a part of that company.

Speaker 1:

Your self-worth has nothing to do with the company.

Speaker 2:

I 100% agree with everything you just said. Find a team where you can be yourself and be most productive in the contributing to the end users product not necessarily contributing to the metric that some team artificially put there that you have to hit which means nothing at the end product level and ask questions of like. This needs to be x% better by this date. Why Is it affecting the end product Of like. Can't we do something more productive by fixing A, b or C, which are far more important? But the team from the top down has been told to fix this and ask questions, although, if you want to keep your job, don't ask questions.

Speaker 1:

No, a really good point, man. If you're at a place where you can't ask questions, you can't ask why you can't get to the bottom, for why something is important, that's a huge red flag. That's a signal that says that, hey, this place might not be interested in doing the right things or is focusing in on the wrong things.

Speaker 2:

That's all big tech, though I mean you can't ask questions in big tech. You'll just get told it's the way it is, or it's 10 layers of viewing management, and you can't really go email that guy directly. Well, again.

Speaker 1:

This is how you get stuck into some like backwater team at that point in time.

Speaker 2:

You've got to stand up for yourself in a lot of cases and it might mean failing a few times. You might get let go because you're told you're not a team player, because you don't play in the team by the same rules as everybody else does. For me personally, I've always been like I'm going to be who I am and I like to be on teams that are super social and do things out of work and again, we've been on vacation with people who I have worked with. It's ultimately a better team. If I can't do that, I'm not really interested in working for you. Even if it's a great product or a great position or great pay or great stock or whatever, it is Not really interested. I'd rather just be who I need to be and not be pigeonholed by somebody who doesn't know me.

Speaker 1:

My experience thus far has been I've never gotten pulled aside and said I wasn't a team player for asking questions. I have more gotten frustrated at the fact that it seemed like nothing I was asking, even though I felt like it mattered. It mattered to anyone else. So typically I would end up leaving teams effectively when I found out that I was just spinning my own wheel.

Speaker 2:

To be a corporate player today. You've got to just spin your wheels. I don't think they want people who want to ask the hard questions Again. They want three-button engineers and a UI manager to manage them. They're building it like they're building a physical device. They build a team like they're building a hardware product. We need ten of these, one of these, six of these. That's how they build teams, because that's how they can manage it, because then there's metrics they can use. But they forget these people are human.

Speaker 1:

I think you're going a little overboard in thinking that there's always metrics there. I think the metric that they put on most of the time is headcount how big is my team?

Speaker 2:

No, I mean metrics of performance, of, like, how do you measure performance of a button engineer? I mean, I'd like to know the answers to that question. If anyone knows, send us an email and I'm like yeah, what is it? Who makes these metrics up? Are they known metrics? Are they just kind of like, made upon the fly for performance review reasons? How do you rank somebody if, like, are you doing a good job or are you not doing a good job? Did you make buttons? Did you not make buttons?

Speaker 1:

So this was a perennial problem that we actually had back when I was the front-end manager or one of the front-end managers on Google Drive, because a lot of the back-end engineers would produce metrics effectively for, okay, I made this system faster, that system faster, and there needed to be a UI for the feature we're producing. But it might not have been like the most complex thing in the world, but the way that Google had structured the teams there was a front-end team and a back-end team and the front-end team would often just get frustrated by the fact that their careers couldn't advance Because it was really hard to measure, like what the impact was going to be, or try to, versus what should have happened, which is to have full-stack engineers, because, quite frankly, even the back-end engineering metrics didn't matter. Next to, is this producing user value? It's like, oh, I spun up all these queries and I launched all these servers.

Speaker 1:

Great, does it matter? Did it sell more units? Did it do anything? And the bias here, basically, was that one side could come up with cool graphs. The other side could not. Neither side really mattered, and that's actually the thing is that there's this biasing function that occurs based on what the company can measure or look at or value, and it doesn't necessarily mean that any of it is valuable. Next to is this actually impacting some user's life in a positive way?

Speaker 2:

Yep, all that is completely true, but I think action of items for people to do don't get pigeonholed, is what I would say, because it may be hard to find another pigeonhole for you to fit in.

Speaker 1:

Yeah, work on a shit that's valuable and figure out the skills you need to solve those problems and then find teams where you want to be there and working with those folks to solve great problems.

Speaker 2:

Yep. So I want to bring up the point we made earlier of blue-collared workers versus what we perceive programmers to be, white-collar workers. And it's interesting that the blue-collar workers that we call blue-collar workers tend to be a more socially interactive group. You've got a bunch of plumbers that'll go on vacation together, they'll go to pub together, they'll just basically, they'll become really good buddhists. Yes, that doesn't happen so much in the white-collar work. It's always like oh, we're friends because we both bought expensive cars or things like that, but you're not true friends. And I think programming becoming more of a blue-collar job is actually a good thing.

Speaker 1:

Oh, I 100% agree.

Speaker 2:

It makes it more acceptable in society. It makes it a more required thing and potentially get paid more. I know plumbers who earned way more than a programmer could ever earn.

Speaker 1:

I think this comparison that was used at the end part of the reason it pissed me off so hard was one it speaks to this like classism that has been built in I don't know if it's everywhere, but at least in the US between blue-collar work is kind of crappy work to do and white-collar work is this sort of awesome stuff. And then programming, especially, got really hoity-toity for a very long time of people loving the fact they could do their big-o notations and it's like you know what. Everyone needs to have electricity coming up to their home. Everyone needs to be able to flush their toilet. These are essential things that are here. Like I want to be able to frame out my basement. It's essential to have the right skill set for that, and we demonized the trades, at least in the US, for decades.

Speaker 2:

The irony is, programming has become one of those trades.

Speaker 1:

Yeah, I think the other side of it is that it is not so much that programming has fallen in terms of like people saying, oh, the compensation isn't as good. There has been a severe lack of people in the trades for decades. This is a supply and demand problem. Demand has stayed the same or gone up. Supply of good electricians, contractors, plumbers, name it has gone down. So this is just supply and demand. Salaries are going to go up for folks in the trades.

Speaker 2:

Like I said, programmers it's becoming one of them because the demand is there but the market is fully saturated with programmers now of all sorts. There's a point where we have button engineers, so it's just a big equalization. But it's interesting how, just while I said that the social side just plays better in the blue collar side, I'd like to see programming just become a normal job. It's not a hoity-toity tech job, it's just programmer whatever Shit needs to get programmed, Just like toilets need to flush.

Speaker 1:

I think you put it best in our text thread, which is that all of these are jobs where it's like I need to connect point A to point B, and whether that's just electrical line, whether it's a plumbing pipe, or whether it's effectively like I need to go from pin G10 to pin G6. Like I need to do something in between there. They're all about just connecting shit together.

Speaker 2:

Yep and programming is the same. This function connects to that function something up in the middle and it is basically as simple as that.

Speaker 1:

Yeah, maybe folks basically in the tech industry should get off their high horses a bit and just kind of realize like, look, there's no job you can do, that is, whether it's front end, back end or whatever that's you're above. Just go figure out the problems you want to solve, figure out that basement you want to frame, figure out the skills you need to go do it and make it happen.

Navigating Tech Layoffs and Specialization
Incremental Efficiency and Value Assessment
Specialization vs Generalization in Tech
Case Study:Stadia
Team Dynamics in Big Tech
Corporate Family vs Team Dynamics
Equalizing the Perception of Trades