Unveiling the Hidden Side of Org Charts at the NYTimes

**David Yee** (0:00)
Every organizational leader has sat down at some point, to think about two things.
One, should I re-org? And two, what are the values and principles of my organization? When we do that, we often ask ourselves what we're optimizing for. That's a very reasonable question. What we don't ask is, what do we do with the things that we're repressing?
About like, how are we going to reconcile with that? How are we going to acknowledge, like, I'm putting this to the side?

**Conor Bronsdon** (0:26)
What's the impact of AI-generated code? How can you measure it? Join LinearB and ThoughtWorks Global Head of AI Software Delivery as we explore the metrics that measure the impact GenAI has on the software delivery process in its first-of-its-kind workshop.
We'll share new data insights from our GenAI Impact Report, case studies into how teams are successfully leveraging GenAI, impact measurements including adoption, benefits and risk metrics, plus a live demo of how you can measure the impact of your GenAI Initiative today. Register at linearb.io/events and join us January 25th, January 30th or on demand to start measuring the ROI of your GenAI Initiative today. Welcome back to Dev Interrupted. I'm your host, Conor Bronsdon, and today I'm joined by David Yee, VP of Engineering at this little company called The New York Times.

**David Yee** (1:18)
We're gonna make it someday.

**Conor Bronsdon** (1:19)
Yeah, I believe in you. This regional paper is scrappy.
The amazing thing about your career, David, is you've scaled both small organizations and frankly enormous ones in the world of journalism, music and art. And you have an emphasis on product-oriented engineering and humane management, as I've heard described. And that diverse perspective has led you to identify something that you think is that organizations all have a shadow. Can you define what that means?

**David Yee** (1:48)
Yeah, so what's interesting about talking about organizations is we sort of define what they look like. So if you think about the values that an organization has or its org chart, these are all things that you see.
But the thing that I've been obsessed with is this idea that every organization is bigger than that and the parts that you don't talk about still operate and they are excluded for a reason. So it's those bits that are left on the side that are still operating that show up in ways that kind of can irritate an organization. And so the things that I've been thinking about is how you bring that together.

**Conor Bronsdon** (2:19)
What are those bits?

**David Yee** (2:20)
It depends on the organization.
So usually these things are either in conflict with the way you operate. So you could say like, all right, well, we're the kind of organization that makes like really crisp decisions, and everybody owns their decisions, something like that. But there's always gonna be a class of decision where people are like, oh, well, I really need to ask a bunch of people or we need to agree on this. That might not be in your org values. It might not be the way you identify as an organization, but it's still something you need to do. And so if you're going around trying to make sharp decisions about things that need consensus, everyone's going to get just annoyed.
And so that's an example, but it shows up in all sorts of different ways.

**Conor Bronsdon** (2:57)
What are the impacts of the shadow? I mean, you mentioned one, but it seems like there would be a variety of ways this would impact different organizations.

**David Yee** (3:05)
Yeah, generally speaking, the thing it tends to do is like cause dysfunction, slow you down. And it's not the shadow does that. It's the fact that you have, that you're not sort of engaging with it meaningfully. You're not really acknowledging that this is happening. The thing that I was, the example I was giving at lunch was, I was talking to somebody, I was, you know, when you think of an organization, I had this debate a couple of years ago with my product partner, where I said, we really have to be, we have to make sound technical decisions. And my product partner was like, we need to move fast. We don't have time to make sound technical decisions. And so like we worked this out, just the two of us were working this out, debating back and forth for a long time. Finally, I said, okay, like, you know, we make, we have to move quickly while aiming for sort of technical consistency.
Now the result of that debate between two people means that there's still this question that the engineers would ask about, and this is an interment organization, about like, where do we value? Show me where we value technical consistency. But I do value it. It's just that when it shows up, it tends to fly in the face of the missable, or values say that we're supposed to move quickly. Why would we do this?