The Art of Organizational Change w/ Ahmad Fahmy

And around 2005, '06, the bank I was with at the time started realizing that the large technology deliveries weren't really delivering. Lots of money was being spent, lots of effort was being spent, lots of consultancy dollars were being spent, and ultimately, there wasn't much success. And so, they started looking at something at that time wasn't that popular as it is now, which was agile. What are agile ways of delivering products?

And that's the first I started working in this area, and just fell in love with the idea of attempting to change behavior at mass of an organization. And sometimes an exercise in futility, but still, it became something I'm really passionate about, because that's all this is ultimately at the abstract level, is changing behavior. And if you want to even be more abstract, changing culture.

AR:
So when you say they were adopting software, what exactly was the issue or challenge they were facing?

AF:
Yeah. If you think about a large institution, they decide there's a problem. There's one of two things that drive large capital investments. Either there's a problem, a burning platform, or there's a huge opportunity. And so, what ends up happening is, once one of the two are identified, so we need to get off a burning platform or we need to compete with X or we have an opportunity to enter Y markets, that kind of thing, then money is poured into it.

And back then, if you remember, the banks were flush with cash, so lots of money would be poured into these large product development efforts. And so, the standard playbook at the time, early 2000s, was what came later to becoming known as waterfall, which is, you do a lot of up-front... You do an initial business case. You get the money. You do up-front requirements, can take anywhere from three to six months. You do architecture and design, and then you hand it over to either an external development shop or an internal development capability, and then they start doing stuff, start building stuff for about two years.

And then come two, three years later, with the normal delays, that thing that was delivered is not the thing that either solved the problem, met the problem, because that's the nature of digital products. You think you want A, and then you deliver to the market, and the market says, "No, that's not what we want." Now, imagine if that time horizon is three years, four years. And so, even when you succeed, you failed. And so, got into agile ways of working, which is effectively, to oversimplify, allowing product people and businesspeople to change their mind very quickly to respond, to adapt to the market, external factors, internal factors, that kind of thing.

AR:
So the work that you do, is it primarily in terms of mentoring and coaching on the agile process? Because when you say behavior, I'm thinking beyond the development phase, or maybe it's in tangent or parallel to it.

AF:
Agile ways of working are a part of what I do. It's a set of behavioral patterns that impact business and technology, but what I do transcends that. It transcends just agile ways of working. So it really depends on the domain I'm in, the problem I'm looking to solve. But again, to oversimplify, what I do is change the behavior of an organization. Agile genuinely is a specific domain set or a specific domain where you're changing how developers behave, how product people behave, and, in some cases, even introducing roles such as product people.

AR:
So can you give us an example? Can you take us through a scenario? And it can be hypothetical or real. It depends on what you're allowed to speak about. But for example, a situation where you went in, there was a lot of cultural issues that was preventing certain type of growth, and then what exactly you and your team do that actually helped kind of bridge that gap?

AF:
Okay. So a standard pattern or example that I've seen many times is, let's say, for example, you take even the idea of a team. Just the idea of a team. You ask anyone, "Are you a part of a team?" And they'll say, "Yes, I'm part of a team." "Okay. So tell me about the team." They'll tell you who they work for. So they say, "I work for Aimann." So they'll identify their team based on the person they work for. That does not make a team. That just means a collection of people have a shared identity, and that shared identity comes from the fact that they work for Aimann.

But imagine if you go to any soccer team or any team, just take any team, you say, "Tell me about your team." They're not going to say, "Well, we work for X." So that's very normal. That's a standard way in which teams are organized. And I would argue that they're not teams, they're just a collection of people working for someone. It's like a hub and spoke.

AR:
And what are the consequences of that framework or that mental perspective?

AF:
In some cases, very good. In some cases, it's appropriate. So I'm not going to say anything is good or bad. It just depends on the context, but in the context, for example, of a group of highly motivated people that have an outcome. I just think about four or five or six people in a garage looking to deliver a product. Actually having a manager is a anti-pattern. It will be a bottleneck. It will be an information bottleneck.

And so, one of the standard practices that have become really popularized in the past 10 years is the idea of self-managing or self-governing teams or even self-designing teams. And so, if you imagine an organization where largely the organizational design consists of people being managed, strongly managed by a manager, and all of a sudden you want to introduce this notion of self-organizing team, or you can imagine the amount of behavior changes required from being heavily managed to self-managed, from being told something as simple as... You're used to going to your manager and saying, "Hey, I'm going to take Monday off. I'm not feeling well," to now telling your teammates, "I'm taking Monday off."

So even in that little, tiny, micro example, there is so many behavior changes that's required. And now, that's on the team side, things you have to learn and unlearn. Now, the manager who used to, on Monday, be successful by telling people what to do, on Tuesday, is now unsuccessful for telling people what to do. So there is a myriad of behavior changes required for the manager and the team, those who were formerly managed and those who are now managing. And so, that's just one of many, many different examples.

AR:
So what's the most common pushback you get when trying to change these behaviors? So from my experience, management doesn't like to step down, obviously, for obvious reasons, but does the role itself change? Does the responsibilities change? Do they become just part of the team as opposed to having a hierarchy? How do you see that play out?

AF:
Well, the first question is, where do you get pushback? And you get pushback from almost everyone at every level. It's not only the managers who have lost power. You get pushback from even the developers themselves. I remember a story of going to Jersey City on meeting a client, and there was a group of people in Jersey City who were mainframe developers for decades. And we were installing a new organizational design that will really give power to the people. It will put the locus of power into these CICS developers, these mainframe developers, as opposed to management and leadership.

And one gentleman, he's like, "Look, I'm going to go out on a smoking break. Come out with me, son." I was like, "Okay, Dad." And he took me out and he said, "Look, I don't want what you're selling. I want to come in at 7:00 AM, be told what to do, and leave at 3:00." And so, pushback doesn't always have to come from leadership or management. It can many times come from everyone, because you know the age-old adage, "Everyone wants change, but no one wants to change." And so, that's the first part of your question.

AR:
Right, because empowerment comes with responsibility and decision-making ability and things like that.

AF:
Exactly. And assumed risk. One of the things that a manager does for people is, they de-risk by taking the accountability onto themselves, or a project manager if you are from the PMI world. They're called the single wringable neck. They are a clearinghouse for lots of accountability. And so, when you remove these roles, then the accountability falls on people who were not accountable before, and that can be very uncomfortable.

AR:
So is the objective for modifying the organizational process and the culture in order to essentially work with the agile process, or is the culture kind of something that is outside of... It doesn't matter necessarily whether it's agile or not? Because the way you've defined the structure, it sounds like it's specific to agile, and if it was a different structure, then you would have to change culture in a different way, right?

AF:
Well, I mean, agile is just an industry buzzword that's almost become meaningless. Ultimately, it starts with, as you said, what's the problem the organization is looking to solve? An organization putting an agile process in places as useful as somebody starting keto or carnivore, it sounds interesting. People talk about it a lot. They get into it, but what's the goal? Are you optimizing for cognitive health, weight loss?

AR:
Weight loss or energy.

AF:
Yeah. Are you optimizing for mental acuity? Are you a sumo wrestler? Are you a triathlete? And so, a lot of times, people think about frameworks before thinking about what they're optimizing for, what the problem is. And so, agile itself is just a collection of values and principles, under which there's a lot of methodologies that seem to seek to actualize those principles and values, like scrum, kanban, LeSS, and a bunch of others, but they're just organizational diets.

AR:
Right. That makes sense. So then can you provide either a case study or high-level KPIs that illustrate your strategy? How do you know you're successful? When an organization brings you in and you have a client now and they say, "Ahmad, I have all these issues with our culture. People are not cooperating," how do you measure success in your experience?

AF:
Yeah. I mean, it's a really difficult question to answer and one that any consultant thinks about. How do you measure success? It's not as simple as... Measuring success in a marathon is easy. Did you finish the marathon in under the time you wanted to finish? There's a qualitative and quantitative aspect to what I do. But ultimately, like any product, I'm selling a product, which is myself, any consultant selling their product.

Ultimately, the measure of success, is the person or organization buying the product happy with the product? Now, that's my success. Are they happy with the product? Right? And then I have some other KPIs. Are they happy with what I've done? But then when I engage with a client, I ask them, "What problem are you looking to solve? And how can you quantifiably show me that problem?" Right? And so, for example, if they feel that their problem is lack of delivery, do they have any data to demonstrate, really demonstrate that they're not delivering? Or if it's quality, do they have data to demonstrate that they have lack of quality?

Then we can benchmark it at some point in the future. So if you agree that success looks like lead time is going down from six months to three months, do we have the mechanisms and the benchmarks to check in the future? But a lot of times, when you ask, especially in large organizations, they'll give you the symptom of the problem. So they'll tell you, "Well, our problem is, our developers are not efficient enough," or "Our quality is not high enough."

And through some sort of Socratic questioning, you can find out really what the problem is. And sometimes the problem is, the internal business are just not happy with the technology delivery. And so, the measure comes in after a year. You can ask them, "Are you happy?" It can sometimes be that simple.

AR:
That makes sense. So what is the typical, I guess, timeline for working with a client on behavioral change? And do you work at a department level? How do you kind of organize the way you go about it?

AF:
It depends on the client. Most of the clients I work with are either very, very small, startups, or the size of nation-states. They're very, very big. And so, in both cases, it generally starts with the problem I'm trying to solve, but most likely, I'm working with a specific division. And the approach I generally like to take is, I don't try to change the entire division or organization I'm working with. I try to take a specific product group and work with them, establish, like we talked about before, what does success look like?

AR:
So almost like a proof of concept?

AF:
Almost like a proof... Because what you're trying to do is, you're trying to introduce a positive virus into the organization. You're trying to create a viral reaction-

AR:
I like that.

AF:
... in such a way that it infects the rest of the organization positively, because a stable system does not want to change. If you look into systems thinking or any of the works of Peter Senge or Russ Ackoff, these are stable systems. They do not want to change despite what they say, despite what the leadership says. And so, when you want to change an organization, there's a rule in systems thinking. Peter in The Fifth Discipline says, "The organization, the pushback to change is commensurate to the amount of change we introduce."

So if you're going to introduce a Jobsian level of change, like he did when the organization was six months away from bankruptcy, A, you better have a serious, real purpose and a leader that can handle the blowback from that much change. There's not that many Steve Jobs out there. So in their case, yes, they had an extreme sense of urgency. They were going to run out of cash. But then they also have Steve Jobs, who decided to cancel every product line, barring four.

And so, because those are not the circumstance I usually work in, I try to introduce change into a small set of the organization such that that particular leader can handle the blowback. But then what happens when it's a successful change, the rest of the organization gets organizational FOMO, like, "Oh, that looks really interesting. I'll have some of that."

Now, if you come heavy-handed and try to change the entire organization, try to change the religion of the organization, then there'll be lots of pushback. And then not to get too religious and trying to introduce any religion into any place, always, you get three things: the true believers, those who disbelieve to your face, and those who are hypocrites. Regardless of the religion, you get those three classes of people. Right? And so, same thing apply to introducing any large-scale change. So I prefer to start with a division, create success, create that positive momentum such that you introduce this positive virus into the organization.

AR:
In terms of leadership, obviously there's a ton of things changing in the industry. AI is one of those things that is disrupting a lot of work and processes in the workplace, removing manual labor. How do you see leadership evolving over time, especially in the way that you see self-organizing teams? There still has to be some sort of leadership above those teams, I'm assuming.

AF:
Of course.

AR:
How do you feel like that looks like in the future, or how is it evolving today?

AF:
With regards to technology or with regards to new ways of working?

AR:
Both. I think they're kind of married sometimes, but maybe in your experience, they kind of run separately.

AF:
Well, you have to empathize. To do this kind of work, you have to empathize with every level. And I'm talking about senior leaders, not just managers of teams, hear lots of noise. So imagine you're running an organization that's 100,000 people, a technology organization that's 100,000 people. That's like governing a state. You have lots of drama and problems and COVID and this shutting down, all this kind of stuff there. And then you hear lots of noise. Y2K, if you remember that, NFTs, blockchain, blockchain is going to change the world.

AR:
Right. There's always a new kid on the block.

AF:
Yeah. SOA, service-oriented architecture, in the early 2000s, TQM. There's always something that's going to disrupt. So eventually, you gain a level of cynicism, because otherwise, you can get whiplash. There's going to be a new disruptive technology sold by the internet every... Now, of course, as you know, some of them do end up disrupting. We just really don't know which. And so, NFTs, everyone talked about NFTs, or VR, and Facebook is now Meta, although they're giving away their goggles free now, apparently.

AR:
Oh, okay.

AF:
Yeah. And now it's these large language models and machine learning, and is that genuinely going to be a disruptive technology? So the first thing is, there's a lot of cynicism, and I don't blame them. I don't blame them for being... I would probably be the same way if I ran a 300,000-person org, and every once in a while, someone on LinkedIn screamed about how disruptive this technology is.

Now, having said that, I've seen a couple of genuinely disruptive technologies in my career, which started in the '90s, like the web, and then the app economy in 2008. I feel like that really genuinely changed things. And I think blockchain is interesting, but still similar to VR. Not really.

AR:
Right. I think people are still finding use cases for it.

AF:
Exactly. Still finding use cases for blockchain, all those tons of accelerators and things like that. But AI, I feel like there's something there. When I play with ChatGPT, I don't just play with it, I use it in what I do. I feel like this is the first real killer app for artificial intelligence, which has been around as an idea since my career started.

And so, now back to your question, how that's going to impact leaders, I think probably the way they're thinking, at least what they're telling me is, how is it impacting their workforce? So, for example, you have Copilot, which developers seemingly love, and you have ChatGPT where you can give it a prompt and it can produce complex code for you. Of course it's not perfect, and I'll never argue it's perfect, but I know-

AR:
Saving significant time.

AF:
It's saving significant time. And so, they're thinking a lot of times, "What does that mean for the bottom line?" Because publicly traded companies, people forget they are many times optimized, but they'll never say that for the stock price doing this, quarter after quarter. And either you can have a significant new product that's just printing money, like Google AdSense did for years, but eventually not so much, although it's still a cash cow. Banks were printing money for years. Well, that's a different conversation.

But their margins were so high, they didn't have to worry that much about efficiencies. Eventually, your margins get squeezed, just like it's happening now with Google and AdSense. It's still making a lot of money, but then where do you get the growth? You get the growth by cutting cost. And so, I think many senior leaders, when they hear about AI, and they're thinking, "Okay. What efficiencies can be gained from our developers using something like that? Is it almost like some sort of cyborg developer now where one developer can do what 10 did before?"

So it's almost like the way development... And I don't even know what the consequences of this was. If you remember, the early 2000s was all about offshoring. Okay. So an onshore developer might cost you 200,000 or, back then, 160 or something like that. But you can get four of them as if they were replaceable widgets, ditchdiggers as some would call them. And they'll say, "Okay. So we need to move to offshore."

Now, are they thinking in much of the same way, which is one developer plus, "Let's train them up on how to prompt these things. That way, one developer can equal four"? And so, their problem, if I know, in the back of their mind thinking, "What are the efficiencies to be gained that ultimately allow a developer to deliver the same amount of value with less developers?"

AR:
So, Ahmad, we briefly touched on emerging technologies such as AI, NFTs, blockchain, VR, and how leaders are understandably skeptical and they have to make the right decision so that they're not making massive disruption for no reason. I want to take a step back and touch on emotional intelligence in terms of behavioral change, because I think a lot of managers talk about how a lot of what they do is not simply quantitative. A lot of it has to do with... There's a joke about how managers need to be therapists as well. So I'm wondering what your thoughts are on that and how empathy and emotional intelligence kind of factors into creating a wide-scale change.

AF:
Yeah. I mean, look, I touched earlier on even you have to be empathetic with a senior leader, and they're generally people you're not very empathetic with, because they're the senior leaders, the ones with the big bonuses. And if you're going to be empathetic with them, it behooves that you have to be empathetic with almost every rung.

Like, for example, in this new current wave to self-managing teams and basically bringing the power back into the teams, I have a massive amount of empathy to managers, the managers of those, what were called human resources. And if you think about it, you used to be rewarded for years by running, quote, "a tight ship" and all these sort of military metaphors that were cool.

And now, if you're a senior QA leader with hundreds of quality assurance people in India and in the US and Poland, and all of a sudden, A, becoming a manager is uncool and the idea of offshore testing is uncool. And so, what do you do? I mean, I have lots of empathy. I mean, so there are people who fashion themselves like Elon or Sergey. And in the early 2000s, Sergey and Larry did something called the Disorg, where they said, "We've hired the best engineers. Why do we need to have managers?"

So they just fired them all, and they called it a Disorg. And that type of thinking, that engineering way of thinking is still prevalent until today. Of course they were wrong and they rehired managers about a year later. But this lack of empathy that leads people to say, "Okay. So now teams are self-managing. We've now instituted something that looks like scrum, so therefore we can fire managers."

And you know what? Facebook has done it, and they've fired X percent. It's such a naive way of thinking about things, both naive and lacks empathy. Naive in that there is a ton of information inside this manager's head on how this system works itself, how to get stuff done in this organizational system. But then there's a genuine lack of empathy or looking at people as humans, because empathy, like safety, like all these other buzzwords, are used so much to the point of them losing all real, effective meaning.

And so, I'm reminded when I think about empathy of something Dale Carnegie... Basically the thesis of his book, his 100-year book. It's almost 100 years old now, How to Win Friends and Influence People. Of course there's nothing in it... It's fantastic, but what's his thesis? People are motivated by the need to feel important. And sometimes people act in ways during organizational changes that make people feel unimportant. And by doing so, what's the cost of doing that? What's the cost of, quote, unquote, "lack of empathy" as you've weaponized them against you?

And if we circle back to the conversation I had before, the three types of personas, the true believers, the true disbelievers, and the hypocrites, you weaponize a lot of people. And it's a silent sort of people who we'll commonly call the grin effers, like, "Oh, yeah. We love this idea. We love what you're saying," but in the back are incredibly toxic. Right? It's easy to just say... I even empathize with them, because many times, leadership have created them by basically put them into some sort of purgatory. They put them into purgatory, organizational purgatory, and they took-

AR:
They didn't provide a safe space for them.

AF:
Exactly. More than a safe space, they didn't give them a sense of purpose. And so, imagine your purpose was to tell 15 people what to do, and now those 15 people are telling each other what to do. And this person is a hard worker, wants to earn. You've taken away a sense of purpose without replacing with another sense of purpose, then you're confused when that class of people are weaponized against the change. No. You've done that. It's like, Russ Ackoff said, "Every dysfunction can be mapped back to a management decision," whereas it's much easier to blame the teams, the individual, the manager.

AR:
So how do you resolve all of this? Where do you start, and how do you know where the problem might be? I mean, obviously, you ask a lot of questions and you do one-on-one interviews with these individual resources and try to understand where the problems are, but how do you actually tackle them?

AF:
It's such a big question. Let me try to tackle it. But generally, where the problems are in an organization generally will be solved somewhere else in the organization. This is what Russ Ackoff calls fundamental attribution error. So, for example, a common analogy I use is lower back pain. So you suffer from lower back pain. The cause is generally somewhere else, tight hip flexors most likely from sitting down all day. So the solution is not to buy a Theragun and just point it at your lower back and just saw your lower back with the Theragun.

It's probably reduced the inflammation, and yoga, and stretch your hip flexors. Same thing with the organization. When there's an acute problem, it's generally almost always solved somewhere else in the organization. The trick is finding that equivalent to the hip flexor. Like, for example, I was with a client recently, and they had asked me to help improve developer productivity, which is always a symptom to me.

I said, "Okay," but that's almost like the trigger for where I begin. And you dig deep into developer productivity. And in this case, it had nothing to do with developer productivity. It had to do with the fact that there was no single point of prioritization. No one was prioritizing the work. So you imagine you have all of these stakeholders asking things, and because you don't have a product owner or product manager that's saying, "No, that's not priority. That's the priority," it was all falling into the lap of the developing organization, and they were not senior enough to say no to anything.

So the solution would have been to just put someone to prioritize the work, understand their capacity and prioritize the work. Instead, they'll say, "Okay. How can we improve their productivity? They're not delivering fast enough." So your question in terms of, how do you know where the problem is? I mean, you should start by knowing, wherever the symptom is, the solution is somewhere else. And then there are a myriad of ways to figuring out what the root cause and solution for that is.

Now, that's one of your questions. The other thing is, where do you start in the organizational change? Like I said before, you don't want to start, unless you're Steve Jobs and you're about to go out of business very, very quickly, and even Elon. Everyone loves to talk about Elon. Right? And he did what he did in Twitter because he had no choice. He wasn't flush with cash. He bought this thing for 42 billion and advertisers jumped and he was going to lose the company.

And so, that's one of the major reasons he fired, I don't know what is it, 75%. And so, unless you're one of those, you have those two circumstances of an extreme sense of urgency and a Musk or a Jobs that's willing to take the blowback, you start small within the organization, and second thing is, you must change the organizational structure. You cannot leave the hierarchy as is. Those are just two things to think about.

AR:
Do you find that top-down versus bottom-up is the wrong way to think about it?

AF:
Yes, absolutely.

AR:
Because I think everyone needs to be on board, right?

AF:
There is no top-down versus bottom-up. It's both, because you have top-down, which you need. You need senior leadership. You need senior leadership to provide you with purpose and urgency and priority, and you want to ensure that they're there for a long enough time to get you through the J-curve. But then you need bottom-up, and you get there through educating everyone, creating a common language, in some cases, having to exit certain people after a certain period. And so, you definitely need both, bottom-up and top-down.

AR:
Yeah. So I have just one more question here, and it talks about emerging technology again. So I always like to ask my guests, "What do you see the future of work?" And I want your predictions to be as wild as possible, really get the juices flowing. So I'm curious to know, have you thought about what the future of work might look like?

Obviously, with COVID, we are doing a lot more remote work and there's been a lot of experiments, successes and failures around that. Have you thought about where leadership is heading in terms of the future and how we work together?

AF:
How far into the future?

AR:
Let's say 10 years. But if you have a 20-year prediction with some interesting potential changes, I would love to hear it.

AF:
Yeah. Okay. Let's stick with 10 years. I think in 10 years, a lot of the industry will largely look the same, and some of the industry will look radically different. 10 years, I'm reminded, and maybe because I'm just getting older, most banks... I think banks are the perfect sort of example to illustrate what I'm trying to say. Most banks and even most planes are running on 40-year-old code.

AR:
That's true.

AF:
They talk about all these blockchain and this and Level 2 and Ethereum and all this kind of stuff, and blockchain for everything. But still, the Western world, actually, the global banking is still running on SWIFT and running on mainframes and still there. And despite all the attempts to move some of the core banking and payments, and some of them have been migrated, IBM and mainframes are still alive and kicking 40, 50 years later.

I mean, there's code in banks that are older than me, which is crazy. So in 10 years, I think there's going to be a lot of this stuff still there, and there's going to be an entire world of maintaining these systems that will... And so, the maintenance of these systems will have organizational designs and paradigms similar to what exists today, because sometimes putting something that looks like scrum or these product development methodologies on top of the maintenance of these decades-old systems is actually really bad.

And so, I think there's going to be a lot of the same, and I think there's going to be... Similar to the front office of a bank where it's really bleeding edge, I think it's going to be really interesting, especially in the development world, the coding world. I wanted to write a script and a script that would've taken me... So I still code on the side, because I think it's interesting.

And it just occurred to me, "Let me ask ChatGPT to produce the script." I was like, "There's no way." There's no way it could actually write what I wanted. 99%, it did it. And so, it's almost, the limitation is going to be, in the future, how well you can write these prompts. And it's almost like the writers and the philosophers are the ones who are going to be the most effective.

AR:
Yeah. I always talk about storytelling, coming back to the forefront, because I feel like humans, natively, we evolved to be storytellers, and we kind of lost that art because we're in the mundane, everyday tasks. But when we have technology, it allows us to kind of get back to the storytelling.

AF:
That's exactly right. So it's kind of almost elevating the liberal arts because... And of course, this is in the application, the usage of these things, not in the creation of them. I'm sure in OpenAI and Neuralink and all these places, you have some MIT PhDs who are thinking about drawing things Beautiful Mind style on some glass windows, but I'm talking about in the actual utilization of these things.

I think development is, it was commoditized in the late '90s, early 2000s as something like a commodity, and then they're like, "No, no, this is wrong." This is a deep skill. The offshore movement didn't work, and these are real craftspeople. But now I'm thinking-

AR:
Maybe the opposite now.

AF:
Yeah. Maybe it is a commodity again. And instead of being commoditized by low-cost labor in offshore locations, it's being commoditized by language models that have analyzed every bit of code on GitHub.

AR:
Right. I feel like, yeah, the gap between an idea and actually delivering value is the execution. And I think that AI and technology really... I mean, it makes the execution part almost trivial. In 10 years, I imagine anyone who doesn't even know how to code can write an app just by saying, "Okay. This is what I want." And if they can conceive of it and they can find a market for it, then they're in business. And that's extremely powerful.

AF:
It's extremely powerful and it's going to be extremely noisy, because, I mean, anyone who can conceive of a podcast can create a podcast now.

AR:
Right. That's true.

AF:
And the barrier to entry is so low. And so, I think the same thing is going to exist. I remember when I first started developing, you'd have to buy hosting space, and it was just a barrier to entry. It was-

AR:
Yeah. You'd have to pull a thousand levers before you can see "Hello, World!"

AF:
Yeah. Exactly. So I think it's going to be a lot of the same and some really incredible use cases that I can't fully imagine. Are the developers going to be almost like... I'm talking about the common developers in the firm. Are they going to go by almost like Kodak film? Almost unnecessary, because there used to be this dream that a businessperson can write some business requirements and autogenerate the code, and there were some POCs. IBM had it, and then all of a sudden, autogenerate the code, but never worked.

But I believe in the next couple of years, it's going to work. Forget even ChatGPT. You'll be able to almost... Because ChatGPT is natural language. So what's the next evolution? They just tell the thing, "Hey, do this thing for me."

AR:
Right.

AF:
And so, the traders in the front office of a bank are very, very intelligent people, and they have these models and they'll go to their developers generally sitting on the desk, and they'll say, "Hey, I have this idea for a model. Do this for me so I can test the model." And they'll go. They'll do some things. They'll change the object. They'll do this and they'll compile and whatever. And maybe a week later, the trader will test the model against the market. I can foresee all of that going away.

AR:
Yeah. The momentum would be completely different.

AF:
The momentum and the speed will be completely different. It's just really, really interesting. And of course, depending on how down the rabbit hole, what are the implications to... Forget the software development. What are the implications to lawyers?

AR:
All knowledge-based work. Right.

AF:
All knowledge-based work. Exactly. Management consultant, what we do.

AR:
Yeah. A running joke with me is I think that in 20 years, everyone's going to learn how to juggle, because that's the only job that you can't automate.

AF:
Like I said, I think there's going to be a lot... 80% will be the same, and then 20% will be really, really different.

AR:
Yeah.

AF:
I say in 10 years. I don't know what 50 years will look like.

AR:
I don't even want to think about 50 years.

AF:
Yeah. But all the singularity stuff is just over my head, and part of me doesn't believe in it anyway.

AR:
Right. Well, I appreciate the insight. I think we're aligned on what the future might hold. I'm curious to see how that will affect behavior in the workplace and obviously how people work with each other with all these new tools and all of this new surveillance. But thank you so much for coming on. Where can people find you if they want to hear more?

AF:
So I have a website, which is my blog. It's my first name and last name dot com, ahmadfahmy.com. And my company is zone2consulting.com. It's Zone, the number 2, Consulting dot com.

AR:
Great. Well, thank you so much again, and hopefully we can talk to you again in 10 years and see how things have changed and how robots have taken over.

AF:
My pleasure.

^{Transcribed by Rev.com}