Interna Talks Episode 1 - Fostering Culture, Addressing Tech Debt, and Organizational Change

In today's fast-paced world, businesses face many challenges in order to maintain efficiency and productivity. From how teams are structured to the technologies used, businesses must constantly adapt to stay ahead of the curve. In this fireside chat, we will examine some of the challenges that businesses face and how they can be addressed.

One of the most important considerations for businesses is the configuration of people in the office. A sense of culture and belonging can foster productivity and innovation. However, the modern office environment may not be conducive to productivity, which is why remote work has become increasingly popular. While remote work can increase productivity, it is important to create opportunities for people to get together in person and bond with the organization. The approach to remote work should be flexible and allow for autonomy for senior managers to do what allows people to collaborate effectively.

Tech debt is another challenge that businesses face. Tech debt refers to the burden of maintaining outdated and inefficient code, and it is a common problem in every organization. A complete rewrite of the code is usually not a practical solution. Instead, it is best to address tech debt incrementally by prioritizing fixes based on their potential impact and treating technology as a stakeholder in the development process. Flexibility in development methodology is also crucial to allow engineers to spontaneously address problems that arise while still adhering to best practices for code management.

Breaking large tech debt projects into smaller chunks can also be beneficial. This can provide more measurable progress and value rather than one large project that would take years to complete. Having a technical co-founder in startups is also important to avoid technical debt down the road.

Layoffs can be a difficult decision for businesses to make. Participants in a recent conversation shared different perspectives on whether Twitter's recent layoffs were a good or bad idea. While there is no clear answer, the conversation emphasized the importance of thoughtful communication during layoffs, even if the decision is a principled one.

Businesses face many challenges in order to maintain efficiency and productivity. However, by fostering a sense of culture and belonging, addressing tech debt incrementally, and breaking large projects into smaller chunks, businesses can stay ahead of the curve. Additionally, thoughtful communication during difficult decisions, such as layoffs, can help maintain trust and respect within the organization.

Transcript:

[00:00:01.050] - David

Fernando, you got your countdown. Looks like we're live. Okay. Hello, everybody. I am here with some of my colleagues from Interna, and we're going to do a little fireside chat today. We're going to talk about some of the common issues that we're seeing in product management and engineering across the industry with some of our clients and just have a general conversation and hopefully provide value to folks in the community. So we'll introduce ourselves for a moment. I'm David. Jeff. You want to just introduce yourself?

[00:00:36.410] - Jeff

Yeah. My name is Jeff. I've worked as a CTO for most of my career.

[00:00:43.310] - David

Mark.

[00:00:44.670] - Mark

Mark golden. Same here. Being a CTO for most of my.

[00:00:47.570] - Eddie

Career, I guess I'm the same as Eddie.

[00:00:54.130] - David

Okay, so I got a bunch of questions, and we're just going to have a conversation about them. So let's talk about remote versus hybrid for a minute. During the pandemic, everyone was forced to remote, and some companies had done it before and knew how to do it. Some companies had to rush into it. Now we're at this odd juncture where some companies want to stay being remote, some companies want to be hybrid, some companies want to shove people back in the office. What are you seeing with the various companies? What's working, what's not working? As far as working arrangements or conversations with employees about where they should be? What do you think is effective? Who'd like to start?

[00:01:47.490] - Jeff

Okay, go ahead.

[00:01:48.680] - Eddie

Okay, I'll start. I've seen it work both ways and not working both ways. I think a lot of it has to do with just the amount of consciousness management put into facilitating the conversation and the communication, whether they're in office or not. The worst thing you can do is have people show up in the office and they are on zoom in their cubes because half the team are remote or international. That's a problem that a lot of the companies that I work with have been growing through acquisitions. So by nature they are distributed. And with that, having the team in the office does not change the fact that they are still remote communicating with other people. So you just don't have that everybody in the same room kind of situation. But what I do see a lot is I think what works really well if it's a company that you have an office, is kind of a split three days a week, two days a week in the office. The key thing is just have to be very conscious, but on the days that are in the office right. Don't be there just for the purpose of being there and have your space seen.

[00:03:06.940] - Eddie

Just be mindful about scheduling time to do things that can only be done or more effectively done in person.

[00:03:20.450] - David

Maybe I'll pose this one to Mark. Do you find certain configurations of people being in the office matter? Like in this geography? Do you want to have certain people in the same office on certain kinds of projects or you don't care. Do you find that there's a configuration to who sits in the office, with whom? Is that important?

[00:03:48.650] - Mark

So I worked for a large software company right before the Pandemic and we had started to go remote several years before and so we were very, very prepared. Most people were in the office, to be fair, but we had many distributed teams and so we had a lot of experience working cross borders, cross teams, and within teams we had allowed people that wanted to the opportunity to work remote. And so I would say the consideration is more about being able to foster a sense of culture and belonging. To me that's the most important thing. People can be productive. We have all of the tools. We are knowledge workers and we're just talking about product engineering. We're knowledge workers who need to collaborate from time to time. And the modern office environment is not conducive to productivity. The Open Office was a disaster in my opinion. Microsoft had it right back in the days when they could still afford to scale away. Giving every programmer either a private office or an office share with one other person, that was the ideal in my opinion. But when CFOs discovered they could save tremendous amounts of money by going Open plan, it all went to hell in a handbasket.

[00:04:52.070] - Mark

So we're giving engineers and product people the opportunity to work from home in my opinion. You're increasing productivity, but you've got to consciously create opportunities for people to get together in person, to share experiences and to bond with the organization. If you've worked for a company for a long time, going remote isn't a big deal. You know everybody, you already feel connected. You may have a strong sense of loyalty, but coming into a company new, that is a different challenge altogether. And so I don't think there's one size fits all and going three days a week like some people are doing, that may or may not work. It depends on the organization, depends on the circumstance. I think the important touchstone is to be flexible, to give senior managers some autonomy in this regard and to do what allows people to collaborate to be effective, but also create an opportunity for those that need to work from home, who want to work from home. The means to do that as a retention tool, franklin as an attraction to a lot of us don't want to work in a traditional office environment anymore anyway.

[00:05:53.170] - Eddie

Another interesting point to note is my observation is some people work can work effectively remote and some people don't. Some people are just too easily distracted for whatever reason. And it's something that management really need to pay a lot of attention to. In terms of I'm not a big fan of making sure someone click the keyboard every 45 seconds to make sure someone's in front of the screen that's not how that's not how knowledge work most effectively. But you do have to make sure to monitor and work with the team from a productivity perspective. Some people just does not work well dealing with in front of a TV or 10ft away from the microwave.

[00:06:45.180] - Jeff

All this all screaming kids.

[00:06:47.490] - Eddie

Screaming kids, really.

[00:06:55.110] - David

I had a conversation with another CTO a week or so ago. We're going to publish the conversation about having remote teams all working on the same product, all working in the you know, serving the same customer. I thought, for me that made a bunch of sense, but your mileage may vary. I'll throw it to you. Jeff, do you have an opinion about locating teams?

[00:07:21.070] - Jeff

I've had a lot of experience with that model, even pre pandemic where there's maybe an offshore team or it could even be onshore that works on a particular initiative. But they work in a location together and so they have good interfaces built with the rest of the organization and the advantages of being in the same place with each other. And that does work very well. More broadly, I think a lot of people see the upsides, but it's worth mentioning some of the upsides. One of the things I think a lot of people I've worked with have discovered is that people get a lot less frivolous distraction from their coworkers and from their business environment when they're working at home. It forces people to kind of go through scheduled meetings and things like that rather than walking over to people's desk and disrupting their line of thought. And that could be a big advantage in just going home. And that extends to a lot of other things. But one of the things I think we don't know yet is how much expense we're suffering from just the kind of human bonding that comes from being in a room together.

[00:08:29.890] - Jeff

I think we see some of it and we see it with some of the new players, new employees. But a lot of the companies that are doing remote have employees that used to work in the same place and already established those relationships. So we're only starting to see the first companies that are doing this from scratch. And I wonder to what extent we're going to fail to develop the kind of relationships where we'll run through walls for each other when we don't get that kind of bonding. So interestingly. It's kind of a counterpoint to what Mark said. If you get them together occasionally, or maybe it was Eddie, I'm sorry, it was one of you. If you schedule that time very rigorously and they have business objectives to accomplish because they're together, you may miss on the opportunity to have them bond that and get the thing done functionally. Whereas the big thing I'm concerned about is standing around a coffee pot or going to lunch together or whatever it is, where they actually start to care about each other's people because I think that's important.

[00:09:29.910] - David

I'm going to transition to something that is 180 degrees opposite. I'm in the middle of writing this article about tech debt. And the thesis of the article is why did Siri not do what OpenAI is doing? Why does siri not have chat GPT? And the basis of the thought was several articles that I read about the tech debt that Siri has and to make any significant change in code, it takes them a year. So the thesis of the article is tech debt can be a strategic impediment. So that's all great. And I'll write that article and people can read it and hopefully they like it. But I want to talk about something about tech debt that I think is hard. We can talk about ways to not create tech debt, to refactor a little all the time. There's a bunch of good things we can talk about. But the thing I want to talk about is a hard problem is now you already have tech debt and it's impeding you in a significant way in the company from being competitive. It's obvious to everybody that software development is slower. The engineering group is slower because this tech debt, now we have a problem that we have to address.

[00:10:51.890] - David

We can stop doing everything and refactor everything and wait for four or five months to do it. CEOs usually just say no to that with good reason, in my opinion. We can just keep accruing tech debt and be slower and slower, or we can try to be thoughtful about how we address the tech debt, how we pay it off, if you will. Let's talk about that case. How do you think it's the best way to think about that and to address the tech debt engineering team while simultaneously creating new product features that the market wants? It's a hard problem.

[00:11:41.330] - Mark

Should I run with that one?

[00:11:43.030] - David

Sure.

[00:11:43.480] - Jeff

Opinion? Okay. There's two things that I think are important. First of all, the big rewrite it thing. I'm one of the CTOs that almost always thinks that's a bad idea. I won't say why. I think most of our audience probably knows, and you can address it since you're writing the article if you want to. But I think that one of the things that's important, and it's important for other reasons other than tech date tech debt is to make sure that technology is viewed as a stakeholder in building out roadmaps and in planning work that's to be done. And one of the things that the technology organization should be representing is the management of TechNet in those kinds of discussions. And I've worked in several environments where that worked fairly well, where those were things that were built out as ethics or stories or whatever. The costs or the benefits to be gained were well explained and those things could be prioritized. And most organizations, in my experience, even if some of the decision makers don't even really completely understand it. They feel like they should give engineering something what I want. So some of that stuff gets in and gets done.

[00:12:53.820] - Jeff

So treating that as important and as kind of a first order consideration, I think is one of the things you have to do. And the other thing is at the other end of the spectrum, which is when engineers encounter a problem and they want to just fix something and it can be done in small enough parts to not be disruptive to everything that's happening, that should be a good thing, not a bad thing. And a lot of organizations fail have mechanisms in place that kind of make it harder. For instance, every commit having to be associated with some kind of ticket, which means if you're just fixing an algorithm that someone has introduced that's introducing a lot of delay in some step that you've seen, you've noticed you've got a better solution. It's a small bit of code. In the old days, you could just commit that no one has ever seen. We're in a better place now where that's not true and that shouldn't be true. It should be visible and it should be checked, et cetera, et cetera. But engineers need to be feel free to do that fairly spontaneously because engineers by and large really care about that kind of thing.

[00:14:00.270] - Jeff

And unless they feel like they're going to be criticized for doing it, they will do it very naturally. So I think it's important to allow it to build that flexibility into your development methodology.

[00:14:12.190] - David

I agree with that, but go ahead, Mark. I was going to just call on you. I was just going to call on you. Go ahead.

[00:14:18.290] - Mark

First of all, I agree with everything Jeff said. There's no company that doesn't suffer from this to a greater or lesser extent. Somebody wise once said to me, code is legacy as soon as you ship it. Unfortunately, the longer you wait to address it, the worse off it's going to be. You can reach a point where you're just saddled with tech debt and it's almost impossible to move and everything takes five times longer. And who hasn't heard the CEO complain that it used to take us so much less time when we just started off? Why has the team gotten so slow? The reason is we've built up more processes, more people, more tech debt, and it's very hard to move. One thing I would add to what Jeff said is I think tech should be given the opportunity to prioritize things that are important to tech. But if you can possibly partner with a product team in order to do that, make them your partners. Take the time to educate them and have them understand some of the challenges and some of the benefits of prioritizing these tech debt stories, you'll be so much better off because you'll have the product team as your advocates and it's not just tech talking about the same problems.

[00:15:17.820] - Mark

But if you don't set aside time to go back and refactor and fix what's broken or it's hard to maintain, the problem is just going to get worse.

[00:15:28.070] - David

I buy all that, but I'll give a second. But let's just be in a case where I'm a new CTO, I've parachuted into a company. There's a lot of tech debt there for whatever reason, and it's impeding. And I need to have the conversation about we need to address this tech debt and it's not incremental small things to do one at a time. How do we think about the right way to address the tech debt? Not just have the conversation, but what's in the interest of engineering, what's the interest of the whole company? Eddie, looks like you got something to say about that.

[00:16:04.490] - Eddie

Yeah, absolutely no disagreement with what Jeff and Mark is saying about tech. That's a given in the life of an engineering team. One thing I want to touch on a little bit is maybe a little bit of a counterpoint is a lot of times engineering teams are hesitant. Even if given the opportunity to fix a tech DAP or components that need to be improved, they're hesitant to do because they don't know that risk averse. They don't want to risk breaking anything, especially when the original developers of the code is gone. It's fairly typical, especially in companies that have high turnover. When you have this piece of code that is working, I don't want to touch it, even though we can never improve on it either. So when you're in the situation where you describe David, where someone is new, as in the CTO role of EP, engineering role in a company, and you're seeing basically no velocity, very minimal velocity, because engineering is saying, hey, it's hard to do, to change anything, the first question to ask is why is it hard to change anything? Is it because it's just so complex or it's just the lack of understanding of how the system works?

[00:17:29.330] - Eddie

The system works, but do we know why and how risk averse is the team in actually trying to break things and make it work in a new way? And from there, you have to eat the elephant one by the time right. Start with breaking things down into smaller and smaller pieces so they can start chewing off the lake.

[00:17:57.530] - Mark

Can I add something to that, please? I think let's say you're the CTO of parachuting in. So granted this tech debt, I want to know what exactly are we talking about? Have we done the work to identify those opportunities? Let's talk about the risk. Let's talk about the opportunities. What can I improve by doing the work? Let's rank them in order of priority and on return on investment, I don't want to just allocate 20%, for example, for random stuff. I want to know exactly what we're going to work on, what benefit I'm going to get and I want to be able to track back to that afterwards to see if it was true. That's how I build up confidence that the team knows what it's doing and can actually make progress. Treat it like user stories, honestly.

[00:18:46.070] - Jeff

Sorry David.

[00:18:46.800] - David

Yes, go ahead.

[00:18:49.110] - Jeff

Time horizons is often an important thing. To add to that, if it's going to take two weeks, it's going to take a sprint for the whole team to dive in and address an issue. Will you get more or less out of the two weeks if we don't do it? But you get less because we'll be focusing on this. Four weeks probably still worse. By six weeks, we'll be producing things faster not to make more at the end of six weeks than you would have if we hadn't spent the first sprint doing this, or whatever it is. So in addition to everything Mark said is straight out of my playbook. But then understanding kind of painting a picture of what the quarter is going to look like if we do this versus if we don't often makes the addressing of the technician issue a lot more powerful.

[00:19:32.530] - Eddie

Yeah. Mark mentioned brought up a concept that I think some teams adopt is they allocate a certain percentage of time to work on technical tasks. Maybe they may not be tech dep is technical tasks that may not be feature related. I'm not a huge fan of that, especially if you have major tech debt that you want to pay off. Spreading it out over a long period of time is not necessarily the best thing to do because there are other things changing at the same time or there are other dependency being built on the stuff that you are replacing or improving a lot of time. You really just need a considered effort. To Mark's point, I think a better way to do is to treat any activity related to paying tech debt in a general sense as just another story and prioritize accordingly with that demand manager buy in. Understand what that means as well.

[00:20:34.970] - David

So I'm going to argue with that for a moment and I'm going to talk about a real world example of one of our clients right now. So I'm a proponent of giving engineers a certain percentage of time to always sharpen the saw, not to take on a big tech debt project. Tech debt project for the reasons Eddie you just said because it should be a large tech debt project. Should be, as Mark said, well thought out, understood what you're doing and the value of creating it. But I like the idea of having engineers, when they're in a bit of code, clean the code for the current purpose. Because of the legacy code thing that Mark said, I say it slightly differently. All paint on my house is future peeling paint. All code is future tech debt. We know that. So I like them to be able to repaint a little bit all the time in this big tech debt picture, then I'm much more akin to what Mark said. We have a client right now who has this large legacy data structure, data infrastructure, and every time the rest of the engineering team, which is pretty sizable, has to do anything, they have to go to this monolith and stop for the data engineering team.

[00:21:50.050] - David

For the data engineering team, too. So my recommendation was just in this case, was, you need to refactor this. And the company came back, the data engineering said, great, we'll take a year to refactor it and it'll pay off in three years. And I said stop. No one's going to approve that. I wouldn't approve it. And so in this case, we're directing the team to have smaller chunks, each of which is measurable when it's done, each of it providing value, which means that it might take longer to refactor all the tech debt than if you did it all at once. But I'm holding that. That is, as Mark would say, a much more transparent way of looking at the big tech debt. Or as Eddie was saying, eating the elephant. What do you think of that? Would you have advised it differently? I'm going to pick on Mark because I know Mark's got something to say about this.

[00:23:00.110] - Mark

No, I think that's the right approach. It reminds me of another thought I wanted to share. I understand there's probably multiple audiences for this little Fireside chat, but if you're a startup entrepreneur, I can't stress enough the value and importance of having a technical co founder because you see a major distinction. I mean, it's not always true, but I think if you just go out and hire yourself a tech team, they'll just do what you'll tell them to do and they'll rarely push back, and they're not really able to. And if they do push back, it's not going to be hard enough. But if you have a true technical co founder, you will avoid a huge amount of hurt down the road. That's a quick plug for getting it right from the get go, because it's just so much harder to fix afterwards. You and I are the same, David. I'm a huge fan of breaking things into chunks, and I just attest large multi year projects because they usually fail. And even if they succeed, they take two or three times longer than you told your CEO that they would, which time you're probably gone.

[00:23:56.500] - Mark

So it's okay, but you're leaving somebody else with a really horrible burden that they have to take care of after the fact.

[00:24:05.270] - Eddie

How many of us have been that's a great transition.

[00:24:08.050] - David

Yeah, that's a great transition to the next question. What are some misconceptions that non technology executives have about engineering, how engineering is run, the engineering team? What are some things that you think that they should know? Frankly, some of the things that we tell them when we're engaged with companies. Who wants to start this off?

[00:24:37.690] - Eddie

I'll start. I think I had conversation recently with the sales leader in two different companies that come with very different perceptions and misconceptions about engineering. One has the old, how hard can it be? I can just hire a bunch of people to do this. And then on the other hand, there's this reference to, oh, wow, this stuff is hard, I can't even imagine how to do this. And I think they are both not quite entirely true. There is obviously some art to software development, a lot of art in terms of software development. But at the same time, there is also a lot of science to it in terms of how to do it right. I don't know how much you guys see one versus the other, but I think they're both definitely misconceptions about how software is done. It's not easy. At the same time, our life depends on it, so it can be done.

[00:25:48.610] - Jeff

I think you see both. I think you see people who see the engineering group as their magicians, and you hope to keep the magicians in good humor, so they'll execute their magic in your favor. And there are others who envision you like an offshore manufacturing facility where you give them precise descriptions of a little plastic widget that you're going to crank out, and then their job is to crank them out. And neither of those are reflective of what engineers actually do. I think that I always try to encourage organizations to regard engineering as part of the creative and business driving process, because the possibilities, the potentialities for the product, they may not be the source of even most of the best ideas, but they will certainly be the source of some good ideas that other parts of the organization might miss because they understand the potentialities of the technologies they're using and the things that they're working on. If you give them a precise spec, which almost everyone has stopped doing, thankfully, they can probably generate doing that what it does, doing what that says. But 20% of that effort, well, 60% of that effort and 20% of that value may be wasted because that was really hard and not that important.

[00:27:05.400] - Jeff

And opportunities might be missed because you miss hearing what the engineers see. That's possible. That wouldn't tend to be visible to less technical people approaching your technical organization as a partner where you're trying to figure out together how to improve the business yields a lot of benefits.

[00:27:33.510] - David

I agree. And you guys have all heard me talk about merging product management engineering with a combined goal of shipping a product that creates value for companies and using that as alignment mechanism. But Eddie, I'll pass to you. But then, Mark, I have a question for you on this because I know you.

[00:27:51.020] - Eddie

Yeah, that's what Jeff was saying. Another misconception about engineering or engineers in general. Right. These are nerds who want to be not to be disturbed. They are introverts. While there is truth for a lot of people, there are also incredible amount of very business savvy, client centric engineers that have a lot of really good ideas, but that are not necessarily heard in the law development organizations. To David's point, I think there are a lot of companies can benefit from having engineers more engaged, more involved in the whole product process, instead of thinking of them as the machine that builds something that's designed.

[00:28:41.850] - David

Mark, you've run particularly large teams. Do you have any thoughts of what you've seen and you've seen different you've bought different companies or been part of purchasing different companies and merging in different teams, then had CEOs change?

[00:28:59.390] - Mark

Yeah.

[00:29:00.300] - David

What have you seen about go ahead.

[00:29:04.660] - Mark

A lot of common misconceptions, I think. A software is your main business. If your business is making software, your cloud company, you're a software as a service company, some kind of consumer software company, then the most important people in your organization are probably the software engineers. So treat them as such. That's not always the case. If your main business is doing something different and software is just there to support it, okay. But I think a lot of people, they look at engineers as, first of all, kind of cookie cutter. Right? I'll get five engineers, I'll get ten engineers. If I get ten, I'll double my productivity. Well, we know that's not true. Right. And though this is maybe less of a mystery than it used to be, once upon a time, we're all very familiar with the ten Xers, or sometimes it's even a 50 XR. Your most productive engineers are just so much more productive than the least productive. And being able to identify them and use them appropriately, there really are some silver bullets inside the tech team. The second thing is, I think there's the thought that if you're not coding, you're not working.

[00:30:04.070] - Mark

And so we're not giving engineers time to think or plan or research right. Really do true development. So if you haven't started coding yet, you're not working. I find that's a very common misconception. And people get irritated if they don't see people typing furiously on the keyboard. And then thirdly, and somebody kind of said this already, software people. It's a mixture. I think it's a mixture of art and science. There's a tremendous amount of creative latitude in software, which is why you find these differences in productivity. There are just better ways to do things. Some people can do things in ten lines of code that somebody else could do in two. Right. And so giving people that opportunity to think, to be creative, to get that quiet time to operate, I think is so important. It's up to the tech leader to use these tools in the most appropriate manner. CEOs and CTOs, too, I think, will over index and communication skills. If somebody's very well spoken, we'll put a lot of store by that we'll say, well, that person must be really good. Now, I value a very communicative engineer, of course I do.

[00:31:03.720] - Mark

But that doesn't necessarily mean that person is the smartest or the best technical person. They may just be the best at talking to customers or explaining what they're doing, understanding what's in your toolbox and using that appropriately. That, I think, is the tech leader's challenge and opportunity.

[00:31:20.270] - David

Great.

[00:31:21.180] - Mark

Okay.

[00:31:21.550] - David

I want to transition to something controversial.

[00:31:24.510] - Jeff

Good.

[00:31:24.980] - David

Elon Musk. Because why not.

[00:31:30.450] - Mark

Used to be my favorite Twitter.

[00:31:32.540] - Jeff

Probably even controversial in the group.

[00:31:35.410] - David

Yes. So he goes into Twitter, and I'm going to now not have the statistics. Correct. But I think he said, I think I read yesterday he had 1500 people in the company were 7500. He laid off like 80% of the engineers. A common thought was, oh my God, that is the worst idea ever. Everything is going to break. It's going to be terrible. A secondary thought was, yes, everything is going to break, but there'll be latency because it takes a while for code to rot to address that tech debt. A third way of thinking about it, and I'm going to present this, was that's a very innovative way of realigning.org design and rethinking if you have too many people and seeing where the pain really exists. I think that we don't have the historical record to know which is true, but there's some reason to believe that it wasn't a terrible idea. What do you think?

[00:32:39.350] - Mark

I'll jump in. Correct. It really troubles me to acknowledge that Elon might be right, because I don't want him to be right. I think the way he went about doing it was awful and inhumane and probably not the best approach. He could have taken a better approach. He could almost have achieved the same thing, but had done less damage while doing it. That's what I think. There's definitely something to be said for stripping away layers of people. Those companies do just like you're accumulating tech debt, you're also accumulating organizational debt. And for sure a company that's been around that long with a reputation for complacency must have had a lot of organizational debt. And there are ways to figure that out and to strip away some of those layers and some of that dead skin. And you can see who copied him. Didn't take long for mark Zuckerberg is essentially following the Elon Musk playbook. He almost said as much without quoting Elon Musk by name. Other tech leaders have cottoned onto this, and you're right, this story is not over yet. We need more time, but it may well have been an inspired move.

[00:33:41.720] - Mark

On the other hand, didn't he also say he lost $20 billion in value or something?

[00:33:47.050] - David

Well, there's that small matter.

[00:33:48.830] - Jeff

Well, that was from a purchase and that's perceived value at the time, not because of the organizational change.

[00:33:56.030] - Eddie

I largely agree with what Mark is saying, I think is the fundamental thesis of what he's trying to do to reduce Bloat, to reduce a lot of the hierarchy or inactivity at Twitter, like any large organization, I like Mark's word of organizational debt. There's just a lot of hierarchy at some point where people are just not producing the level to what they're supposed to essentially stress test the organization and then obviously they're backfilling people where things truly break. Right. They're bringing some people back on contract and whatnot even actually I think I heard offering more money than before people were making before. They laugh. And then you realize, well, we really do need some of these people. I wouldn't recommend it for every company because I think there is some recommendational pool working at the Twitter when they, despite all the horrible thing, horrible stories, they were hurt about how he botched how to do it. Not the what. There are still plenty of people who are willing to work there, right? But if it's not a company with that kind of kind of gravitational pool for people who want to work there, definitely don't try the same thing.

[00:35:14.200] - Eddie

At least do the delay offs and the restructuring a lot more thoughtfully than that. But yeah, definitely at this point recognize that a lot of our biggest companies forever, always for those long Bloat that can definitely use some drastic organizational rethinking.

[00:35:37.960] - Mark

There are some things that made it possible for Twitter that just wouldn't be possible elsewhere. Number one, elon Musk. Right. He's kind of a unique character. Number two, it's a private company wholly owned by one person, so he could afford to take that risk and do the things that he did. Not a lot of companies can do what he did in that way. I bet they'd like to.

[00:36:01.350] - Jeff

You guys said a lot of the things that I think about it.

[00:36:07.270] - Mark

The.

[00:36:07.610] - Jeff

One thing I don't want to die on the Hill if it wasn't inhumane, because it certainly wasn't done with love of kindness and thoughtful communication that I would have felt comfortable with if I had been involved. But one of the things I actually sort of like about the fashion in which he did it was that it was a principled and open kind of decision. Decisions along the lines of, no, you're going to come into the office and be prepared to work really hard, or really leave now and take the severance, is a statement of we're going to change this culture. We're going to change it dramatically, we're going to change it now. If that excites you, you have a place here. If you don't, you're self select against it. I think that's admirable. And I've even now said it better than he said it and trying to repeat what he did. So it was even worse than that. And I think you could do better than how I just said it and.

[00:37:06.750] - Eddie

How you communicate it.

[00:37:08.440] - Jeff

I think he felt stressed by being kind of on a public stage about what he was going to do with this company and he had a certain agenda and it was driving him in that direction. But I don't know this. I know you guys know our audience doesn't. I know some of the founding engineers at Twitter Twitter and know a lot of the insider stuff there. One of the things I don't know yet is what's happened since. What is that culture looking like? The signs Eddie points out, like they're discovering some of those people really were valuable. They're offering money, they're bringing them back. Sounds like the right kinds of things are happening. But it'll be interesting to see, as the evidence becomes clear what the impact of that was. I'm not sure it'll be terrible. I'm not even sure it'll be bad.

[00:37:52.330] - David

It might be okay. So let's go to the new hotness. Everything's Generative AI OpenAI is going to cure the world. Chat GPT is beautiful. It does everything. Now, we know that's not true, but we also know it's interesting. How are you seeing it affect engineering teams and product management teams today? What are those effects? Do you see are good? Which do you think are overblown? And where do you think it's going to go in the future? How is it going to change our world in terms of how do we think about managing engineering teams in the future? How do we think about managing product teams? What do we need to learn? I'm going to throw it to Eddie.

[00:38:39.540] - Eddie

First because, you know, I have strong opinion about this. To me, what this means is this is the next level of abstraction to how people do things right. And the interesting thing with Generative AI is I think the best analogy I've heard about it is like talking to a party, talking we don't know that sounds super confident about something. But when he talks about something in a topic that he happens to know, you realize that the person doesn't know anything. He just sounds super confident. That sounds perfectly reasonable, but officers don't know what they're talking about. And that's really how Generative AI works. It's statistically built things that statistically plausible. Just like I know David. You have done exercise where you ask to generate your own profile. It comes up with a profile that, yeah, it's possible some of David's prepared could be doing or could have done, but definitely not what you have actually done. And that's generative AI works. And with that said, what that means is, I think the future worker, it's not going away. It's here. It will be here. And I think what that really calls for is certain soft skills, critical thinking, the ability to make sense of things.

[00:40:05.480] - Eddie

And it becomes super critical in the future. Being able to code is not going to be as important anymore, but the ability to make sense of the stuff that gets generated in the cloud becomes super, super critical. So actually I have a friend asked me about, hey, my son is interested in doing studying computer science. I actually told me I have a PhD in computer science, so I'm biased, but I actually told him it may not be the best idea if your son has other interests, even if in philosophy. Going to school to study computer science not going to make a break if you want a career in the table anymore. Not anymore.

[00:40:52.450] - David

So I'm going to argue with you. I'm going to argue with you for a moment. One of our clients is a low code company, and they're thinking obviously about generative AI and doing things like copilot things like that. And the interesting conversation is it's good at generating code or it might be good at generating code, but it's not good at generating architectures, at least not yet. And so my argument would be it's not replacing programmers, but you better get really good at code review, and you better get higher level skills to understand how to put components together. You arguing with that? You agreeing or disagreeing?

[00:41:35.000] - Eddie

I absolutely agree. I absolutely agree. That comes from the whole critical thinking, the larger the next level thinking, right. What was next level is going to shift as we go, right? Like chas becomes not a thing anymore. Now Go has been conquered, right? So what's the next level? It's going to continue to evolve, but it's absolutely agree with you.

[00:42:01.450] - Jeff

One caution I would throw in everyone in this discussion is old enough to have seen any generations of your business is about whatever it is, plus blogging or user generated content. Your business is about whatever it's about, plus social. There's a real danger at this particular moment in history of your business is about whatever it's about. Plus the use of various machine learning and artificial intelligence techniques, because those are sexy. Those help with fundraising. If you're talking about those things when you go through them, and it's often a square peg for Round hall. It's ill thought out how it's being brought in. I think that what's certain is that the state that uses the two you're describing is going to be where we are in ten years. Somebody's going to make the innovations and figure out how the broad swath of internet companies or software companies can use these technologies effectivel