George Jagodzinski (00:00):
Today we learned that a 170-year company can be more modern than expected. Sometimes the biggest unlock isn't just a new idea, it's someone stepping in to get executive buy-in and air cover for the ideas you already have. And we had a fun curveball learning. We learned how the humidity of a force can affect the quality of newspaper and how technology and insights are used to optimize that. I'm joined by Jason Sobel and Brian Hamman from the New York Times. Jason is the CTO of New York Times. He spent nearly two decades in Silicon Valley at Facebook and Airbnb, amongst others. Five years ago, Jason made the big jump to the 170-year-old news organization. Brian is the SVP of product engineering and leads messaging and publishing mission. He started in the newsroom almost 20 years ago as a journalist who coded and he's touched every corner of the engineering org since. It's a really cool story.
(00:48):
What makes this conversation different is what happens when you put these two in a room together. Jason's the outside, fresh perspective. Brian's the institutional memory. They compliment each other perfectly and their combo is where the interesting stories live. We dig into Conway's law and how a century of newsroom structure gets baked into the systems you build. The courage it takes for an engineering team to ask whether they are allowed to be world-class and why the right idea at the wrong time is a dead idea. But that same idea, with the right timing and a catalyst, changes everything. Please welcome Jason and Brian.
(01:20):
Welcome to Evolving Industry, a no BS podcast about business leaders who are successfully weaving technology into their company's DNA to forge a better path forward. If you're looking to actually move the ball forward rather than spinning around in a tornado of buzzwords, you're in the right place. I'm your host, George Jagodzinski. Jason and Brian, thanks so much for being here.
Jason Sobel (01:59):
Thanks for having us.
Brian Hamman (02:00):
Yeah, absolutely.
George Jagodzinski (02:01):
I'm really excited for this conversation because you guys are coming at the same problem from different directions, at least from my perspective, is you're at the New York Times. Brian, you made it from the newsroom to leading engineering to the role that you're in now over 20 years, which is impressive. And then Jason, a great career in Silicon Valley and then you make the move to this very old publisher and that's got to be an interesting challenge as well.
Brian Hamman (02:26):
Yeah.
George Jagodzinski (02:27):
I guess maybe first I'll start. Jason, we know is the new guy, but Brian, at an org like the New York Times, is 20 years a short-termer or does get respect over there?
Brian Hamman (02:36):
It depends what part of The Times you're talking about. In the newsroom, I'm still basically a baby. We've had people here in the newsroom or in parts of our printing plants and others who are literally multi-generational employees or people who've been here for 40 years. Certainly on the tech team, I am I think now the third most tenured employee. There's two people who've been here longer than me.
George Jagodzinski (02:58):
Nice. And then Jason, let's start with you. Going from Silicon Valley to New York Times, what drew you there? What made you make that jump and how'd you get there?
Jason Sobel (03:08):
Yeah, for sure. I basically started my career in the Valley in 2004. Got to work at some great companies like Facebook and Airbnb. Just learned a ton from those experiences both on the tech side and on the management side. I left Airbnb at the very beginning of 2021 and was just thinking about what I wanted to do next. And at the time I was getting a lot of reach outs from fintech companies or crypto and none of those were really grabbing me. And then I heard from a recruiter who was helping the Times look for a CTO and it just really jumped out at me as something really interesting and really different. And the mission, of course, is what draws most people to the Times, this mission to seek the truth and help people understand the world around them.
(03:54):
So that was a huge draw, just feeling like I could contribute to keeping journalism going in this country and around the world. That industry has really suffered and Brian saw a lot of that progression both down and then back up for us. And then the people, obviously I think that's such a huge part of any job. So as I got to meet a lot of the folks that were here, their stories and the work they were doing, it really drew me in.
George Jagodzinski (04:21):
That's fantastic. And how long are you in there now?
Jason Sobel (04:24):
Just about five years.
George Jagodzinski (04:25):
Five years. So from before you went in to now, five years in, what are the things that are the most different than you thought they were going to be going into it?
Jason Sobel (04:34):
I wasn't totally sure what to expect when I joined. Obviously I'd asked a lot of questions during the interviews. We were still in social distancing because of the pandemic, so most people were working from home. So you can only get so much of a feel from just meeting a few people and talking over video. I think probably the thing that surprised me the most was how familiar the Times Digital Operation looked to where I'd been before.
(05:01):
At the end of the day, The New York Times is building apps and websites to deliver amazing journalism and games and recipes and product recommendations to consumers. So we're building digital apps to deliver this amazing content to our audience, which is really not that different from what a lot of other tech companies are doing. So in hindsight, it may be unsurprising, but the way we're set up here is actually relatively similar to other places I'd been, with product managers and engineers and data scientists organized cross-functionality to tackle big problems. There're definitely differences, but they were a lot smaller than I thought they would be.
George Jagodzinski (05:36):
That's nice. You're not exactly walking into the Spider-Man newsroom where just paper's flying all over the place, but that brings me then to you, Brian. You've been there 20 years, newsroom to where you are now, that's a really interesting journey. Tell me a little bit about how that happened.
Brian Hamman (05:51):
So I spent the first six years here, in the newsroom and even then I was essentially leading a team of engineers in the newsroom. So the Times has had engineers even in our newsroom going back almost 20 years. This was back before the iPhone. This was really an attempt by us to do digital journalism and to do it in a way that we could bring it natively to the internet. So the Times has had a sense of innovation for a really long time. I left the newsroom and I actually went to journalism school, so I thought of myself as a real news developer.
(06:21):
Left the newsroom when we basically started to expand beyond the New York Times news to thinking about when we launched our cooking app, when we brought our crossword in house, it used to be a third party, so we could really drive that and be more innovative internally, and led engineering for that team. That was almost 12 years ago now. Basically have been going from that to just other parts of engineering until at this point I've basically either led or been involved in every part of engineering at one point or another.
Jason Sobel (06:50):
Yeah, Brian's done everything here.
Brian Hamman (06:52):
Yeah.
George Jagodzinski (06:52):
I love it. You're the guy-
Brian Hamman (06:53):
You could blame me for anything not working, basically.
George Jagodzinski (06:56):
Are you the guy that anytime something messy, they're like, "Hey, Brian, go fix this messy thing."
Brian Hamman (07:01):
Nobody asks me to fix anything anymore, but they will often ask me for the history of why it is the way it is. Yeah.
Jason Sobel (07:08):
Brian's being modest. We definitely point him at some of our harder problems. So for our elections, for example, he plays a big role just because he knows so much about our systems. He can be really helpful in identifying who needs to work together and what we should be more or less worried about.
George Jagodzinski (07:22):
Nice. Well, I know my Thanksgiving thanks you for the New York Times Cooking, for sure. Jason, I know you've talked a little bit about the way that you approach instead of blame, it's more with curiosity, asking why. And when you're coming into an organization that's been around for so long, I'm sure that there's systems that have been there forever. Some Frankensteins without a doubt, I mean, I'm a consultant. I've been under the hood of everywhere. There's always at least one Frankenstein. And tell me a little bit, how do you approach that and say, without calling Brian's baby ugly or without casting blame, how do you approach that?
Jason Sobel (07:57):
Yeah, I think the good news when I joined is that there was a lot of consensus already or alignment on some broad ideas of things we needed to tackle. One of the reasons I was hired was specifically to work on core tech and platforms and that had been a lot of my background in other companies. I didn't have to do a whole lot of getting people aligned on the high level problems to solve. So there was broad awareness that we had a lot of tech fragmentation. We had duplicate systems solving the same problems that teams had to be to full stack, that every team needed to understand AWS deployments all the way up to the very user-facing components of their app. There was a lot of alignment that we needed to find these common patterns and these wasted efforts and figure out how to really build the tech that would move those forward.
(08:51):
So one of the first big bets that I helped go from ideological alignment to actually executing on was what we call basically our DVSP, our delivery engineering shared platform. And the idea was how do we make all of our software engineers a lot more productive by taking away the common tasks, the shared toil like bringing up a Kubernetes cluster or running a CI process. These things that every team has to do, it's not that differentiated. There's probably not a lot of value in 10 teams having seven different approaches to it. And so how do we really consolidate a lot of those together?
(09:27):
And so that was one of the first things I got to do and it was relatively easy. I think a lot of it convincing was on some of the details and some of the stakeholder management because the story was, we're going to do this and it's going to take time from your roadmap and it's not going to immediately pay off in any metric that you, as a business leader, pay attention to. It's not going to lead to more subscribers. It's not going to lead to a bigger audience, but it's going to give leverage to all our engineers so that, going forward, they can do a lot more in that space. And that was probably one of the harder things to really land with the broader team.
George Jagodzinski (09:57):
That's a tough sell. And it's huge having the alignment before, as you step in. But I don't know, Brian, I'm curious from you, when I step into organizations, I find also there's usually alignment from the team. Here are the things that we need to fix, but for whatever reason they haven't been able to. It hasn't been prioritized. They haven't been given the space. Talk me through that a little bit, because I'm sure you've probably been hitting your head against the wall a little bit to get some of this stuff done.
Brian Hamman (10:21):
Yeah. I would say, to now give Jason credit, the idea of building a developer platform was by no means new at The Times. This is something that we have attempted to do several times, that we have built pieces of over the years. There's historically been a feeling that are we a real engineering team? Do we really deserve a real platform? Is this hubris that we think we could build it? We're not Facebook, we're not Google. Do we need this or should we be thinking more simply? And so I think we both had the idea and we had some steps in the right direction, but we didn't have the full conviction or even necessarily the belief that we could build it and it would be good, not that we could build it and it would actually turn out to be something that wouldn't be useful or wouldn't make us faster.
(11:06):
And so I think having Jason come in who has built this, who has seen this at other organizations and be able to say, "What you guys are doing makes sense. This can work and it can work in an organization this size," I think helped tip us over the edge to then going and doing it. And then the execution, making sure we're actually delivering on that over the next couple of years to the point where now it's a point of pride within the engineering team. We're very happy with that platform and we're now building on top of that platform and seeing what other platforms we can bring into the organization. So I mean, I think it's a good example. There's a lot of ideas that have been at The Times even before I got here that we just haven't been able to pull the trigger on or put into production or decide that we deserve to build and it takes a catalyst to come in and make that happen.
George Jagodzinski (11:52):
I love it. It's a little bit of that you're not crazy perspective. Have an interior designer come in and be like, "No, you should move the couch over the air. You're not crazy." And you're like, "Oh, okay. Am I cool enough to pull over this style?" And you're like, "Yes, you're cool enough to pull off this style." One thing that you talked about there, Brian, and this will be a tossball to either one of you, is you started to dig into what is the identity of the engineering team. And that matters in a lot of your decisions and it flows all the way through. I'm curious, how do you guys define your engineering team's identity? And then just broadly, how do you go about even approaching how you define where you land on what the identity is?
Brian Hamman (12:28):
It's a complicated story of The Times. I mean, The New York Times is a news organization. That is front and center of what we do. And we've often had this debate of, are we a tech company or are we not a tech company? And I think we've honestly, we've moved past that. That was a real identity crisis for us for a while. The reality is the identity of the engineering team is we strive for excellence. We often say we want our technology and our products to match the quality of our journalism. Team takes very seriously that our technology needs to be there when it's most important to deliver the journalism. It really attracts mission-driven people who are striving for that. You can see this in the organization. We've been a tech company since print.
(13:10):
One of my favorite memories of the Times is when we launched our website and we were merging the digital and print engineering teams together, we used to have two different organizations. We were still at that point pretty early on in our digital journey and I was meeting with some of our print engineers and they were able to basically know if the paper ripped at a certain point in the printing plant, they could trace it back to where was that harvested, in what forest and what temperature and what dew point humidity and know that if they harvested paper in the rainy season, it was most likely to rip. And so they completely renegotiated their paper contracts about when they were harvesting things. That's a level of technology and sophistication-
George Jagodzinski (13:51):
That's cool.
Brian Hamman (13:51):
In print that just has carried through to what we're doing now.
Jason Sobel (13:54):
I think what Brian said about a really mission-driven organization is spot on. Like I mentioned about what drew me in, I think draws most people in is this idea of contributing to the mission and keeping journalism going in a really challenging time for the industry. And I do think one of the changes that I've seen in my time here is just helping this organization buy into the idea that we are a strong tech organization. We are not that different from what's happening out in the valley. Like what I said surprised me a little bit.
(14:24):
I think there was some real question and some real doubt there because historically the Times tech team had been a little more insular, a little more media-oriented, hadn't had as many outside perspectives and more senior roles. And so there were just a lot of open questions about, are we doing this right? Can we build this level of complexity in a project, et cetera? I didn't necessarily change that much, but I just said yes to a lot of those things. No, we're doing this very similarly. The talent here is good. The work we do is good. And I think that has really helped people get a little more comfortable that we can really do and deliver work, just like any other tech organization.
George Jagodzinski (15:05):
That's great. I want to dig into that stakeholder buy-in and air cover that you're able to get for the team because I'm sure there are a ton of engineering leaders listening right now that they also have those three things that they want to do, but it doesn't have clear, quick ROI. It's the typical, we need to move slow to move fast argument, which is very hard for people to buy into, especially now. How did you get buy-in there and alignment there?
Jason Sobel (15:30):
Yeah, I think the good news was there had been a lot of discussion on these topics before I joined, even outside of the engineering team. So during the interview process, Meredith, our CEO, Alex, our chief product officer, they were both telling me about some of the opportunities that they'd heard and they, of course, wanted my opinion, but this had been in the water supply so it wasn't starting from zero. That really helped. I do think this is a tough problem and every organization is different. I think fundamentally, it's based on trust. And if you're a trusted leader and you have trusted partnerships, that's probably 80% of the battle right there. And I think trust tends to be built up over time.
(16:09):
So as a new person, I maybe didn't have as much trust, but I did have a little bit of runway because I was new. So I do think that helped. The other thing that helped was we did some qualitative surveys of our engineering team. So one of the questions we asked was just how much time do you spend on undifferentiated work, was the term we came up with? So work that doesn't really directly add value to the business or the product experience. And in some teams, we were getting numbers like 60, 70, 80% of their time. And so I was able to show that to stakeholders and say, "Look, this team over here that you want growing the subscriber base or making Cooking a lot better, they're only spending 20% of their time on those problems. They're spending 80% of their time on this technical work and we can take that 80 and make that 50, 40, 20, depending on the team." And so that was a really compelling argument as well that helped make the case.
George Jagodzinski (17:05):
Nice. Some objective data. Yeah. And then you could probably show how that nets out over the next couple years. It actually is an acceleration rather than "a slowdown," right?
Jason Sobel (17:14):
Exactly.
George Jagodzinski (17:15):
So let's talk about ideas and the timing of them and human resistance to changing and all that. So Brian, over to you, perhaps, is we talked, there's plenty of ideas that you've had in the past and you guys have been talking about a few of them that you were able to make happen, but were there ones, some examples where the timing wasn't right? And there's always the classic thing, as a consultant, I go in and I suggest an idea and the immediate response is, "Yeah, we tried that. It didn't work." And was that a timing thing? Was it an execution thing? I'd love you to just dig deep in your brain for one of those examples.
Brian Hamman (17:53):
Yeah, I mean, I can think of probably several examples. I mean, having been here at The Times for 20 years, at a certain point you probably have a document with every idea that anybody new comes in with that either you've had or somebody else has had while they've been here and it could create a real allergic reaction sometimes in the organization, like we already had that idea. We already tried it and we didn't get anywhere. And I think my personal pet version of that is community. We have a comment section at the Times that really has many different personalities and different parts of The Times, Cooking versus games and the news. And over the years, everybody has had ideas about how we could take that and build upon it and think about it differently.
(18:35):
It's been a struggle to do that and to get that working, but we are now embarking on another version of that. We have some teams working on that and have launched a few things online. If you're a close reader of the Times, you will have seen evolution in our comments section recently that's been really exciting to see, especially for somebody like me who's really wanted this, over the years, to see that a team is running with this and really starting to drive for it. But it's a risk in an organization where people feel like that's their idea that they should have been able to drive, but they were maybe 10 years too early or just missed the mark in some way and you have to be patient in order to see things grow and get the right timing.
George Jagodzinski (19:10):
Yeah. And you also run the risk of, if you keep trying to push the same idea, it's like, "Hey, Brian, stop trying to make community a thing. It's never going to happen." And you have to persevere if you truly believe in it.
Brian Hamman (19:21):
Absolutely.
George Jagodzinski (19:22):
And then Jason, I'm curious, were there any ideas that you brought in where they're like, "No, this isn't going to work," and you're like, "Actually you're right," once you dig into it? Or just something, an interesting idea there.
Jason Sobel (19:37):
I do think the question of timing is a really important one. When is the right time for something? It's often hard for people to really invest a lot in something if the pain isn't very acute, which is unfortunate because ideally we're getting ahead of problems and it's like this preventative medicine idea. The best time to build that system is before it's acute, but then no one ever really, innately understands the value in quite the same way if you wait for the problem to be acute, because now it's much easier to make the case. So I think that's a pattern that's come up a lot over my career.
(20:14):
The counterpoint to that, however, is trying to think around corners and see steps ahead, there's more risk in those projects. The more you're doing something speculatively, the riskier it is. And I do think The Times is an organization that doesn't run with a ton of slack. Other organizations I'd been just had more people and could take more risks. We could try more things. We could have a broader portfolio and if something didn't pan out, that was okay because we had three or four other teams working in the same space and we could de-risk the work across that portfolio. Whereas at The Times, we tend to have a smaller number of people working on any single problem, so you have to be really confident in a bet or trying to see around a corner to justify taking it. And I think that's been a big factor here as well.
George Jagodzinski (21:01):
Interesting. Yeah. It gets back to that identity of an engineering team or of an organization. One organization might say, "We're going to fail a ton. We're going to fail so much. We can fail 90% of the time. As long as we succeed 10% of the time, we're fine." But others might be much less, like you're talking about there. So let's talk about the organization a little bit. Conway's law, it talks about how any system you design is a reflection of the communication frameworks or the organization behind that. And with the history there at the New York Times, you've got news desks, you've got all those silos that have built up, those must manifest themselves into the systems that you design and build. And then you guys, it's probably your job to reorganize that. And I'm curious, what's your approach there, some examples and do you find yourselves not just reorganizing it on the technology side, but just into the broader organization, having to find different organization frameworks?
Jason Sobel (21:57):
The first thing that jumps to mind for me is, and then I can segue over to Brian, is around publishing. So we have one of the biggest, most sophisticated, we think the best newsroom in the world. If you look across all of our products between Cooking and games, news, the athletic with sports, Wirecutter, we have thousands and thousands of journalists. They were all using relatively different tools for how they publish and create their content because of some of those organizational structures and silos. And I think Brian, with a bunch of other folks on his team have created a whole organization around solving that problem. And Brian, maybe you can just talk a bit more about publishing, what we're doing there.
Brian Hamman (22:43):
Yeah. I mean, this comes, it's very much the history of the New York Times organizational structure has been built into our publishing systems. Our current CMS was built at the moment when we were going from a print-first production, so taking our paper and putting it online to flipping that to basically producing for digital journalism and then distilling it into print, and that workflow is baked into the system, but it's still primarily an article-based, let's get some text into a document that we're going to ship out and to people's front doors. And what we wanted to be able to do is have much more innovation in digital journalism and to scale that across the entire newsroom. So it wasn't just innovation in small pockets of people who can essentially hack around the CMS and either create a new workflow or deal with tools that are a little bit janky and unsafe so that they can get that out there.
(23:40):
And so we've been building that into our CMS in a way that the newsroom can use, but also, in our case, multiple newsrooms now can use between New York Times Newsroom, Wirecutter, Cooking, The Athletic and others. And so it's very much thinking about the organization, thinking about the workflow. I would say a lot of it is the Conway's law. It's also, it's just like the workflow. What is the thing you're trying to produce and what is the workflow that you're trying to build around that I think really guides a lot of our technology choices here because we are such a journalism workflow-based company that that workflow is embedded into all of our systems.
George Jagodzinski (24:16):
Yeah. Just getting down to those jobs to be done, right?
Jason Sobel (24:19):
Yeah. One thing I would add to what Brian said is when you are shipping the org chart and you find opportunities where you want to create commonality, that's where, in my history, we've often just brought together a team. And at the New York Times, we call them platform teams. And so Brian, one of Brian's jobs is leading what we call our publishing mission. And so we actually created a whole cross-functional team around publishing and their mandate is to build out these shared tools and to make sure that their customers, who are internal editors and journalists, are adopting those tools. And so that helps a little bit counteract some of the forces of shipping the org chart, if you actually create something on the org chart whose whole purpose is to break down some of the silos.
Brian Hamman (25:06):
I would say a tension there and a challenge that we're always wrestling with is the more you break down the silos and centralize things, the more you can also stifle innovation because innovation often happens in silos and places that are protected within the organization. And so we're trying to be very thoughtful about how can we standardize centralized to both raise the water level for everybody, but do it in a way that doesn't create so much lock-in, that people are going to try to escape in order to innovate and do things outside of the system. As long as I've been here, that's been a trade-off in tension we've long been moving the needle on back and forth.
George Jagodzinski (25:42):
I'm curious what you guys take on that, because I always see the same thing, that it ends up being a pendulum that you have to embrace the fact it's going to keep moving back and forth. And it depends on the organization, but some we talk to, they instill a principle within the company that, "Hey, we should be comfortable with some pretty significant org changes every one and a half to two years," or something like that. And I'm curious, do you guys have anything, any similar principles or approaches to that?
Jason Sobel (26:07):
Yeah, I feel very similarly. I do think it's really hard to be perfectly balanced on any spectrum, that essentially all your decisions are spectrums and you're almost never going to be perfectly balanced. And even if you are, it's unlikely to last. So you are always oscillating around that perfect point and that can feel really confusing and disruptive to people that are like, "Why do we keep changing? Why can't we just get it right?"
(26:31):
And so I think being able to explain that it's hard to be perfect and so we are going to probably overcorrect in one direction or the other and eventually that's going to get significant enough that we're going to have to make some changes, so we start swinging back the other way. I wouldn't say there's a hard and fast timeline on all these things, but yeah, generally I feel like if you can come up with an org structure that lasts 18 to 24 months, you've done a good job. And if you're starting to get past that and you're not thinking about any changes, you should probably take a closer look and see if maybe there's something you're missing.
George Jagodzinski (27:01):
Makes a lot of sense. And so now looking forward, there's a lot of changes going on. We are 27 minutes in. We haven't said AI once. I love it.
Jason Sobel (27:10):
There we go.
George Jagodzinski (27:11):
All right.
Jason Sobel (27:12):
We did it.
George Jagodzinski (27:12):
But now I'll say it. AI, AI. I'm curious, what are you guys embracing now that you're able to talk about that you're changing the way that you work?
Jason Sobel (27:21):
I would say we're thinking about this very similarly to a lot of other organizations I've talked to. We have three broad areas of exploration. One is on just the user facing side. So how can we use these new AI tools and capabilities to create better experiences for our audience? We've been pretty thoughtful on that. I do think there's a lot of consumer products that have just thrown AI, in some way, to see what happens. I think we've been more purposeful in how we've approached it. So we've shipped a relatively smaller number of features there because we want to make sure, one, that they're meeting our editorial standards. We're never going to have AI writing journalism or making editorial decisions. That's something that has to be human-led. And also because, again, we want to build things that actually matter to our users. Like I said earlier about waste, we don't want to build a bunch of things only for them to just totally flop.
(28:19):
We have shifted a few things in there around Cooking. We help with metric conversion. We've shifted some advertising products that help our advertisers. So we do have some real work there that's made progress. The second piece is all around the internal just technology capabilities. So what do we need to build to make sure that all of our teams can harvest these new tools as effectively as possible? And again, we're trying to start small there. We're not going to try to think around too many corners, but we have built some systems that centralize the way you interact with an LLM so we can monitor it and we can do routing, if necessary. We've brought in capabilities around evals, which are really important to make sure that once you ship an AI feature, it actually stays good and continues to work the way you want it to.
(29:06):
And then the third piece is all around just internal productivity. How do we make our people and our teams better and faster? And so we've brought in a bunch of tools that help people build their own little mini agents, even if they're not software engineers. And then we've rolled out Cursor and Claude Code and we've looked at Codex and we've looked at all the coding tools for our technical folks that are making a lot of progress on those as well.
George Jagodzinski (29:29):
And then Brian, I know you and I talked a little bit about this before, but when I'm waving my magic wand as far as the persona that I'm looking for, even on my own teams when we're leading AI efforts, that hybrid journalist/engineer persona, to me, seems like such a great combination when you're leveraging these various tools. And I'm curious, how much are you leveraging your journalism background in driving these things forward?
Brian Hamman (29:56):
Yeah. I mean, we have a number of people in the organization who Have hybrid backgrounds of some sort, journalism engineer, journalism designer, designer, engineer. The Times tends to attract multidisciplinary folks and they're certainly pushing some of the boundaries on AI. We have a team in the newsroom that is thinking about this, working very closely with our engineering and design team and has been exploring a lot of different things. I think what AI has unlocked for some of these people is basically within a person, being able to take something from start to finish in a way that honestly reminds me to the early days of the internet when ...
George Jagodzinski (30:34):
Big time.
Brian Hamman (30:34):
Somebody armed with jQuery could basically build an entire website very quickly and get it from start to finish. As everything's gotten much more complex, that's much harder for a single individual to really launch and build something that's large in scale. And now somebody can sit down with Claude and go really far. If you can understand the whole problem, not just the technical parts of it, but the journalistic, the design, the business, for a small number of people, it really has unleashed them.
George Jagodzinski (31:04):
Yeah. It's funny to talk about the early days. I wish I had a laundry list of all the problems we ran into then because I feel like they're all the same right now. Even data retrieval, the way some of the AI frameworks are retrieving data, it's reminiscent of early data frameworks or just, let's retrieve one row at a time, let's retrieve one field at a time or all of it. And it's just the same thing is the same thing again, huh?
Jason Sobel (31:28):
Yeah. We just keep running into the same problems over and over.
Brian Hamman (31:32):
Eventually everybody finds out the database has to scale.
Jason Sobel (31:34):
Has to, oh, yeah.
Brian Hamman (31:35):
They always run into that problem eventually.
George Jagodzinski (31:38):
We'll have to learn sometime. Guys, I could do this all day. I like to finish on a fun question, which is, in life and your career, what's the best advice you've ever received? Brian, we'll start with you.
Brian Hamman (31:50):
The best advice that I got was if you see something that needs to be done and it's not anybody else's job, it's your job. Go do it, solve the problem. And if nobody tells you to stop, that's now your job. And I think that at organizations like The Times that changed so much, I think that that's been great advice. Organizations can't adapt fast enough to all the work that needs to happen and the gaps that get created. And so it's been super useful for me to always just jump into things.
George Jagodzinski (32:23):
That's a great one. Yeah. I mean, the flip side to that is if you open your mouth, you're going to be the one that gets a new task on your plate.
Brian Hamman (32:29):
It is a double-edged sword, absolutely.
George Jagodzinski (32:32):
I love it. Jason?
Jason Sobel (32:33):
Yeah. One of the most pivotal things for me was learning about the fundamental attribution error. Brian's heard me talk about this before and I'll probably butcher the definition a little bit, but the high level idea is that we give ourselves a lot of slack and a lot of credit for our own behavior because we know what our intent is. We know our inner monologue, we know our whole story. With other people, all we know is how their actions make us feel and what impact they have on us. And so we tend to judge them based on how their actions affect us.
(33:06):
And so this wasn't necessarily advice, but it was someone who really helped me see how I was making that error a lot in my own role and how to just change the way I thought about both myself and the way and other people and the decisions I was making and the decisions they were making and how I reacted to them. So I still have work to do. Not quite in perfect balance on that one, but I do find that realizing that everyone, on the inside, thinks they're doing the right thing has been really powerful for me.
George Jagodzinski (33:38):
That's a fantastic one. What's interesting about that one is there's a selfish one to that too, that it allows you to operate in the world in a better way. At least for myself, I get less frustrated with things. I get less stressed about things when you can just have that empathy and that curiosity as to why someone's being where they are versus just, screw this guy kind of a mentality.
Jason Sobel (34:00):
That's right. Yeah, I would love to say I'm perfect at it, but I still do have screw that guy at moments that I'm working on.
George Jagodzinski (34:06):
Hey, none of us are perfect, but guys, I really enjoy what you're doing and I enjoyed the chat. Thank you so much.
Jason Sobel (34:12):
Thank you for having us.
Brian Hamman (34:13):
[inaudible 00:34:13], George.
George Jagodzinski (34:15):
Thanks for listening to Evolving Industry. For more, subscribe and follow us on your favorite podcast platform and pretty please, drop us a review. We'd really appreciate it. If you're watching or listening on YouTube, hit that subscribe button and smash the bell button for notifications. If you know someone who's pushing the limits to evolve their business, reach out to the show at evolvingindustry@intevity.com. Reach out to me, George Jagodzinski, on LinkedIn. I love speaking with people getting the hard work done. The business environment's always changing and you're either keeping up or going extinct. We'll catch you next time and until then, keep evolving.