# Redefining Engineering Value in the AI Era

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-02-13

## Transcript

If you're the kind of senior engineer, architect, or technical leader who people look to for what's next.
QCon London is probably already on your radar.
Join us in London from March 16 to 19, where we go deep on the topics that matter, like the architectures you've always wondered about, engineering productivity, and applying AI in the real world.
This isn't about trends for their own sake.
It's about getting practical insights from senior practitioners to help you make smarter calls on where to invest your time and tech.
With software changing fast.
Learn more at QCon London.com.
This is Shane Hasty for the Infinite Cube Engineering Culture Podcast.
Today I'm sitting down with Ben Green.
Ben, welcome.
Thanks for taking the time to talk to us today.
Thanks for having me, Shane.
This is awesome.
Great to be here.
My normal starting point with these conversations is who's Ben?
Great question.
I'm still trying to figure that out too.
I am a multi-time founding CTO of startups.
I am currently building a new startup called Tessie.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 uh co-founder of a couple other companies.
Last one was called Outcomes for Me.
They are a consumer health tech company currently in Series B.
I've been a CTO on residence at TechSarce Boston for a few years and also done some other mentoring and things of weight.
But Tassie is my new full-time gig.
What bought you to a serial sounding CTO?
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.
Do it.
What's the advice for the engineer thinking of moving into that startup environment?
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.
Genitive 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.
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.
We were chatting earlier, and you said, you know, slide the spec under the door and make sure I have pizza.
That doesn't sound like it's gonna work.
Yeah, 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 in the 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 is 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 manned services.
Now I'm dealing with the fuzziness of the whole world.
Is this as simple as just another abstraction layer, and software is still a part of it.
It's just not the only thing.
I think it is both another level of abstraction, but also a collapsing of the abstractions.
Because, you know, in some ways, from a PL perspective, right?
We are always just translating from one language to another.
And I don't even know.
I've lost count of how many translations we do in a browser interpreted language down to processor instructions and back.
It's probably seven or eight, maybe twelve.
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 engine, the V8 engine or whatever engine we have now in Chrome.
And I don't want to.
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's a very different role to deliver as much value with just pure software engineer.
It's also something that if I think of most of the real world because moving bits around, moving zeros and ones just isn't as unique and special as it used to seem.
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.
How do we engender that culture in our organization?
I wish I had a like 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, right?
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 a 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 B2D 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.
Easier on consumer than business, but business people want promotions.
They want success and they deserve it.
And you should help them.
That's a very differ on that product managers, salespective than what in my experience, most software engineers come into the industry with.
With quotation marks for now.
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?
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 center can't understand the person at the call center?
They don't speak the same language, right?
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, right?
They're not going to be the road 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 meaty 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.
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?
There are a couple 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, you know, 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 sort of 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 outcomes for me was that one of my priorities is always high code quality, particularly the readability, the legibility of code.
That's so important to me because when you are going zero to one looking for product market fit, you're gonna 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 lines 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 modeling that behavior, 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.
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 environments at all of these different layers of abstraction?
How do we bring new people into the industry effectively?
I think it starts with changing the 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 out of college has mastered having agents direct other agents, I'm begging over backwards to get them to join.
That's hard.
And if they figured out how to do that in a consistent way that produces consistent results, we just have to understand that it's a new skill set.
AI orchestration is the skill that we really should be looking for now.
Not just writing code.
Now, there is an understanding of code, it's critically important, but I'm always looking for the velocity.
You know, 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.
What's the important trend in the software engineering space that we're not aware of yet?
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 of 95% reliability.
But there are so many engineering problems to which 95% is it 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 sort of overrun by the marketing spiel, but we need to be more involved in this.
What's your advice for the mid-career professional looking at where do they go next?
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, right?
And this is partly because it's startups and because they're grueling.
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 we can 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, you know, the rest will take care of itself.
What's the important question I haven't asked you that you would like to get through to this audience?
I think the lesson that I want people to take from the way the 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 in communication.
We need to get off our butts and start working on that.
Where do we start?
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.
You know, something that I heard uh decades ago is that everyone you interact with at work, on a city street, you know, 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 I think really all software engineers are problem solvers at heart, and you go out in 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.
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?
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 to.
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 them up and we'll go grab a drink.
So I'm available.
I'm out of here.
Cool.
Ben, thanks so much for taking the time to talk to us today.
Thank you so much for having me.