Beyond Code: How Engineers Need to Evolve in the AI Era

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I’m sitting down with Ben Greene. Ben, welcome. Thanks for taking the time to talk to us today.

Ben Greene: Thanks for having me, Shane. This is awesome. Great to be here.

Shane Hastie: My normal starting point with these conversations is who’s Ben?

Introductions [01:17]

Ben Greene: Great question. I’m still trying to figure that out too. I am a multi-time founding CTO of startups. I’m currently building a new startup called Tessi.ai. We are using AI with geospatial imagery to help people get their homes fixed faster after they’re damaged by natural disasters. I’ve also been the co-founder of a couple of other companies. The last one was called Outcomes4Me. They are a consumer health tech company currently in Series B. I have been a CTO in residence at Techstars Boston for a few years, and I’ve also done some other mentoring and things of late. But Tessi is my new full-time gig.

Shane Hastie: What brought you to a serial founding CTO?

Ben Greene: I love solving problems. I’m attracted to big, hairy, terrible problems, and I think about them and I think about them and then I want to solve them. And so, one of the things I have learned is that it’s not enough to be able to see some part of the solution, but you need to be able to see the whole, because when you build a solution, you want the solution to last and grow and outlive you in your role. You don’t want to be the person who has to turn the crank, you want to be the one who can walk away and see it continue. And so, that has led me to tech entrepreneurship as a way of solving problems.

But I’m also impatient. And so, that impatience has driven me into environments that rewarded patience, startups, where you’re always late, no matter when you started and how far you’ve gone, which seems to fit pretty smoothly with my personality. Sometimes it’s a bit stressful, but I enjoy it. I always have something to do, and generally not a lot of red tape to get through to do it.

Shane Hastie: What’s the advice for the engineer thinking of moving into that startup environment?

Embracing Generative AI as the New Engineering Skill [03:07]

Ben Greene: Never been a better time. It’s so much fun. The mindset I would take as an engineer is the time of the artisanal software engineer is passing. Generative AI lets you be more productive than you ever thought possible if you are willing to embrace it. It is a similar skill to being able to manage other humans, being able to delegate problems. Really great individual engineers can have trouble delegating, because they’re worried that if they give a task to someone else that they haven’t figured out how to do completely themselves yet, that it won’t get done well enough. That is something that great engineers need to get over, and being able to manage engineering around imperfection is something that just has to be learned how to be done. So I think from the engineering standpoint, it’s a great time.

But I think the other thing is you need to think that you’re more than an engineer, you’re more than building a system out of zeros and ones and features. You’re building generally a business, or if it’s a nonprofit, you’re still building a system that has inputs and outputs, and if you don’t think about how what you’re building contributes to those and is affected by those, then you won’t build something sustainable.

Shane Hastie: The stereotypical engineer is not that interested in the bigger picture and the people stuff. We were chatting earlier and you said, “Slide the spec under the door and make sure I have pizza.” That doesn’t sound like it’s going to work.

Think Beyond Code to Business Outcomes [04:37]

Ben Greene: Yes. I think those days are over. I think that to be really valuable as a software engineer now, you need to understand the larger outcomes that you’re trying to deliver. And at a time when designers and product managers and salespeople and everybody else can start getting their hands into code with generative AI, a software engineer who doesn’t start expanding their own visibility into the larger business is going to look pretty simplistic. Now, it’s definitely true that tools like Cloud Code still aren’t great high-level engineering thinkers, but they’re going to improve, and when that happens, as an engineer, you want to be the person who understands not only how to get the most out of them, but also how to point out the things they’re not thinking about and to think higher level about the system.

I think about systems now as not just the software, but also the people around me, and those people aren’t just the people I work with, but also my partners and my customers. I’m still solving problems and I’m still building systems, I’m just doing it with more than code and APIs and managed services. Now, I’m dealing with the fuzziness of the whole world. But I still get to solve problems and software’s still a part of it, it’s just not the only thing.

Shane Hastie: We’ve looked over the decades at just increasing the layers of abstraction. Is this as simple as just another abstraction layer, or is there something else there?

Abstraction Layers and the Collapsing of Complexity [06:09]

Ben Greene: I think it is both another level of abstraction, but also a collapsing of the abstractions, because in some ways, from a PL perspective, we are always just translating from one language to another. I don’t even know, I’ve lost count of how many translations we do in a browser interpreted language down to processor instructions in the back, it’s probably seven or eight, maybe 12. I don’t know, I’ve lost count. But from a higher level perspective, it’s not critically necessary to understand all those layers anymore. I don’t understand the V8 engine or whatever engine we have now in Chrome, and I don’t want to, I’m glad it works.

I really want to solve the problems that I’m focused on, particularly in startups, but I think in a lot of open source development-driven shops, we’re always trying to stand on the shoulders of giants. So what does it matter if now we’re doing that at a level of description where it’s not even code? Now, it’s English. But I think what that does to software in the grand scheme is it means that you’re not going to be able to deliver as much value with just pure software. You need to actually have a connection to the real world, because moving bits around, moving zeros and ones just isn’t as unique and special as it used to seem.

Shane Hastie: So that’s a very different role for the software engineer. It’s also something that if I think of most of the engineering training, it’s not there.

The Forward Deployed Engineer Model [07:41]

Ben Greene: So one of the things that’s interesting, this trend of the forward deployed engineer, I don’t know if you’ve seen this, but a lot of companies are now hiring engineers to go sit in the office of their customer, and they’re an expert in their own company’s platform, but they also become an expert in the customer’s platform and the customer’s problem, and they’re right there embedded. And I love that model, because that is how you learn to apply technology directly to a problem, you are there with the person who has the problem.

This is what we’ve been telling product managers to do for years. Don’t just interview them, go to their office and sit with them and watch what they do, watch how they interact with your product. Now, we’re sending the engineers to do it, which I love, because engineers should stop thinking, “I just type on a keyboard. I do go out and I talk to people and I empathize with them.” And so, that skill of empathy, that maybe software engineers have not been practicing and utilizing to a full degree, is now becoming very critical. And I, for one, am excited about a world where more people spend more time empathizing with others. I think that’ll be a net positive.

Shane Hastie: How do we engender that culture in our organization?

Building Customer Empathy in Engineering Culture [08:58]

Ben Greene: I wish I had a perfect answer for this. I’m definitely still working on it. But I think that it’s important to talk about your customer, to spend time with your customer. I mean, it’s not enough to just stay behind the desk, you have to go out. You have to go see them doing their job, help them do their job. You have to make sure that you engender a belief within the company that what your customer is doing matters and that your customers as people matter.

One of our partners right now is a volunteer organization that does relief work after disasters, and it is really awesome, but also probably really easy, if I’m being honest, to love them and love what they do. But I think no matter who it is, you have to understand that your customer, for instance, in a B2B software state, you may be selling an analytics platform, but really, there is a person over there and they need your software to help them get a promotion. So if you don’t understand how your software is going to help them succeed in their life, then you don’t really understand what they’re in it for. You need to help them at a human level and you need to think about the human level of everything. Easier on consumer than business, but business people want promotions, they want success, and they deserve it and you should help them.

Shane Hastie: That’s a very different perspective than what, in my experience, most software engineers come into the industry with. You made the point earlier on that product managers, salespeople, everybody codes.

Ben Greene: With quotation marks for now.

Shane Hastie: Absolutely. With that in mind, how do I, as an engineer, really show the value of my skill and what I bring to it? What is the unique engineer competitive advantage?

The Engineer’s Competitive Advantage: Systems Thinking [10:57]

Ben Greene: Software engineers are incredible systems thinkers. We go into a meeting, someone describes a feature, and we can tell them immediately all the things that can go wrong because they didn’t think through every corner case. That’s an incredibly valuable skill that, frankly, we should be bringing outside of the creation of software and into the creation of the larger system of businesses and organizations. What happens when the person who calls our call centre can’t understand the person at the call centre, they don’t speak the same language? Software engineers will think of these problems immediately, and we can help everyone else in an organization bulletproof and improve the integrity of everything they’re doing because we’re so experienced building systems.

There will still be complex things to do as well that other people aren’t going to think of to do, but they’re going to be more innovative. They’re not going to be the rogue repetition of building the same SaaS features we’ve seen everywhere. That can be done with generative AI, and frankly, isn’t that good? Do we really want to keep doing that stuff ourselves? Let us work on the really maybe new problems that no one has ever solved before, bringing new theoretical ideas into software engineering, and let the more boilerplate stuff be taken care of.

Shane Hastie: So circling around to your experience as that serial founding CTO, how do you, or do you, design the culture of a new startup organization?

Designing Culture and Structure in Startups [12:35]

Ben Greene: There are a couple of things that I have found that have worked for me. There are a few laws that I like to refer to when I’m designing things. So from a structural standpoint, I think about Conway’s law and that systems will mirror the structure of the organization. So I work backwards and I think about what I want the system to look like and where I want those interfaces to be and what needs to scale independently and what can be loosely coupled so they can grow independently, and then I try and design my organization to mirror that. That’s from a structure standpoint.

From a culture and interaction and how do people work together, I try to figure out what I can model myself, because I’m generally the first person on the engineering team and I need to start demonstrating how I want people to interact. Culture is really just the result of communication. It’s the artifacts that result from interaction. And so, one of the things that I figured out at Outcomes4Me was that one of my priorities is always high code quality, particularly the readability, the legibility of code.

Prioritizing Code Readability and Psychological Safety [13:43]

That’s so important to me, because when you are going zero to one, looking for product market fit, you’re going to have to make a lot of changes on the way, and if you don’t understand what you did and why you did it, you have no ability to change that code the way you want to. And so, what that winds up doing is leaving these sort of mines in the middle of your code that people route around. And so, that’s, I think, the situation that happens when somebody comes and asks you to do a simple-sounding feature and you say it’ll take three months, because you have to walk on eggshells around the code you don’t understand. How do I prevent that? In code review, I say the rule is, after correctness, think always of the reader. If the reviewer says, “I don’t understand this code,” they’re right. It has to be changed until the reviewer understands it easily, going for as low cognitive load as possible at all times.

There’s only one challenge left. Engineers hate to admit when they don’t understand something. We’re all struggling with imposter syndrome, nobody wants to look dumb. How can I fix this in my culture? I don’t mind looking dumb. I can act dumb all the time. Most of the time, I’m not even acting. So I can pretend or just say that I don’t understand something, and by modelling that behaviour, well, if the CTO doesn’t understand something, it’s okay if I don’t understand something. Now, everyone can do that. And it creates a culture of acceptance of it’s okay not to understand something, it’s okay to have it explained, it’s okay to try and ask for it to be simpler.

Shane Hastie: As startups grow, you’re bringing on new people. One of the statements that we’ve heard a fair amount lately is the gap and the challenge for newly graduated engineers finding roles even. How do we, in this rapidly changing, evolving environment, at all of these different layers of abstraction, how do we bring new people into the industry effectively?

Hiring for AI Orchestration Over Traditional Coding [15:44]

Ben Greene: I think it starts with changing our idea of what are we hiring them to do in the first place. I’m not hiring software engineers to come in and write code anymore. I’m hiring software engineers to come in and get things built. If I hire a 10-year experienced engineer who wants to come in and write all the code, I’m not hiring them. If I’m looking for someone to build stuff and someone new at a college has mastered having agents direct other agents, I’m bending over backwards to get them to join. That’s hard, and if they’ve figured out how to do that in a consistent way that produces consistent results, we just have to understand that it’s a new skillset. AI orchestration is the skill that we really should be looking for now, not just writing code. Now, there is an understanding of code that’s critically important, but I’m always looking for the velocity. In startups, there’s so much we don’t know about the problems we’re solving, about the technology we want to use, so I’m not looking for someone who knows everything. I mean, it’s great to find someone who knows what I think we’re going to use, but the reality is we’re going to use new things that we haven’t thought of. So I need someone who, first and foremost, likes to learn, is unafraid of learning, and is going to be aggressive about it. And there’s a lot of people straight out of college who are going to have that mindset, I hope.

Shane Hastie: What’s the important trend in the software engineering space that we’re not aware of yet?

Managing AI Agent Reliability Expectations [17:16]

Ben Greene: I think we need to get better at communicating what sort of problems should be solved with agent-based reasoning and what sort of problems still need to be solved with code, because there are a lot of companies selling AI agent reasoning solutions boasting 95% reliability, but there are so many engineering problems to which 95% is abysmal failure. And I don’t think that in the rush for everyone to adopt generative AI and AI reasoning and AI agents, and in the rush for engineers to still stay relevant and to understand those tools, that we are managing the conversation around when are these things appropriate and when are they not and how do you use them responsibly. And I think maybe this comes from the fact that we just generally don’t like to own these conversations, we get overrun by the marketing spiel, but we need to be more involved in this.

Shane Hastie: What’s your advice for the mid-career professional looking at where do they go next?

Finding Passion to Sustain Mid-Career Energy [18:29]

Ben Greene: I don’t know that I have advice for that. I guess that’s me. I just find something that feels to me that I’m going to have lots of energy in the tank to pursue, I do it by feel, and this is partly because it’s startups and because they’re gruelling, I have a sense for is this going to motivate me enough to dive into this and commit myself for years? And I think that if you can find something to which you want to devote yourself, then you’re going to find the energy to conquer whatever problems are on the way.

But software engineering is supposed to be a creative discipline. We are literally creating new worlds and forces and dimensions out of thin air, and we need to keep thinking of it that way, and we need to think about how can we apply those skills to whole new worlds and whole new problems. I’m not going to shed a tear if I never have to write CSS or HTML again, I don’t care about that. But the idea that I can build better solutions to solve the problems that people previously were just unable to afford the solutions they needed to do better jobs and affect lives better is so exciting. So find passion, pursue it, and hopefully the rest will take care of itself.

Shane Hastie: What’s the important question I haven’t asked you that you would like to get through to this audience?

Improving Person-to-Person Communication as Technology Advances [19:59]

Ben Greene: I think the lesson that I want people to take from the way that technology is going and also the way that society is going, because they’re very strongly connected, is that we need to put more value and priority on the skills and the need to interact. Person-to-person interaction is critically important, being able to communicate effectively with a person, now being able to communicate effectively with an AI agent, being able to communicate effectively with a computer through code. These are different types, but all equally valid and equally important, because we are all, at the end of the day, part of one big system, and the ability for us to communicate effectively between those nodes in that system is the singularly most important thing affecting the performance of that system. And if we think about how we’re doing with technology-to-technology, computer-to-computer communication versus person-to-person, computer-to-computer keeps getting better and better. The weak link now in society is the person-to-person communication. We need to get off our butts and start working on that.

Shane Hastie: Where do we start?

Start with Empathy [21:13]

Ben Greene: I think it’s empathy, it’s sympathetic understanding. It’s just trying to understand who the person is on the other side of the table and what is it that they are dealing with. Something that I heard decades ago is that everyone you interact with at work, on a city street, at the store, has some problem in their life that you know nothing about. You don’t know how bad it is, it could be a tragedy, it could be an annoyance, but there is something going on inside their head that is making their life harder than you realize. And if you assume that and if you think about that, you are going to be so much more kind and considerate and sympathetic when you interact with people.

And if you are a problem solver, and I think really all software engineers are problem solvers at heart, and you go out into the world thinking everyone has a problem to solve, then it really opens your eyes to all the impact you can make. There are still so many things that software and technology computers can do to make the world a better place and to make businesses more effective and society run smoother and to help democracy, there are so many things we can do, but we do have to care, or else we’re not going to even see them.

Shane Hastie: We have to care. Ben, that’s a great place for us to end. But before we do, if people want to continue the conversation, where do they find you?

Ben Greene: LinkedIn’s probably the best place. I respond to messages. I do request, if folks send me a connection request, just send me a message too. I really do not connect with anyone that I haven’t spoken to live, but if someone reaches out and says, “Hey, I want to chat,” then I connect with them after the chat. I love it. In fact, someone from QCon that I didn’t get a chance to speak with after my talk connected with me on LinkedIn, we got on a call the day after American Thanksgiving and it was super fun, and hopefully next time I get to Germany, I’ll look him up and we’ll go grab a drink. So I’m available, I’m out here.

Shane Hastie: Ben, thanks so much for taking the time to talk to us today.

Ben Greene: Thank you so much for having me.

Mentioned: