Vox

Leitura de 48 min

Product Mindset w/ Jessica Hall (Part 1)

Summary

In this episode of Developer Tea, host Jonathan Cuttrell interviews Jessica Hall, co-author of “The Product Mindset,” about how developers can thrive in an era of increasing automation and global competition. Jessica argues that simply writing quality code is no longer enough to remain valuable; developers must expand their impact by understanding business goals, collaborating across functions, and helping make technology decisions with customer and business context in mind.

Jessica explains that the most sought-after developers are those who elevate the productivity and impact of those around them, work effectively with QA, DevOps, UX, product, and marketing teams, and help business leaders make informed technology decisions. She emphasizes that skills like understanding trade-offs, sequencing work, managing technical debt, and interpreting customer needs are much harder to automate and will remain in high demand.

The conversation explores practical advice for junior developers who want to adopt this mindset, including understanding how their company makes money, talking to product managers and UX designers, listening to user research, and asking questions about how their work contributes to business outcomes. Jessica stresses the importance of leadership creating environments where this kind of inquiry is encouraged through psychological safety and clear communication of goals.

Finally, Jessica and Jonathan discuss how to view automation not as a threat but as an opportunity. By focusing on what becomes newly available when routine tasks are automated—particularly time for higher-value work—developers can position themselves for continued growth. They emphasize that learning should be viewed as developing transferable thinking skills rather than just mastering specific technologies, making individuals more adaptable to change.

Recommendations

Books

  • The Product Mindset — Jessica Hall’s upcoming book (mentioned as coming out in under a month) about helping companies, engineers, UX designers, and product managers succeed in the digital economy.

People

  • Sip — Jessica’s friend who consistently provided context before meetings by explaining objectives and why they mattered, making collaborations more effective.

Research

  • Google’s research on team effectiveness — Referenced research on what makes good teams and managers, particularly the concept of psychological safety where team members feel safe to speak up.
  • Forrester survey of product leaders — Survey of 154 product leaders where 84% said their work is integral to growing revenue, highlighting the business impact of product-focused work.

Topic Timeline

  • 00:00:00 — Introduction to automation concerns and career growth — Jonathan introduces the episode’s focus on automation threatening jobs and helping junior developers grow into senior roles. He introduces guest Jessica Hall, co-author of “The Product Mindset,” and explains her background in engineering, design, and product management. Jessica describes her current work helping companies and individuals succeed in the digital economy by expanding their value proposition.
  • 00:03:04 — How developers can avoid becoming obsolete — Jonathan asks how developers can protect themselves from obsolescence without becoming bottlenecks. Jessica explains that while quality code delivery was once sufficient, top performers now bring more: they collaborate across functions, elevate team impact, and help make technology decisions with business and customer context. She notes that automation handles deployment and testing, but the “people part”—decision-making, trade-offs, and navigation—remains valuable and hard to replace.
  • 00:08:47 — Connecting work to business revenue and impact — Jessica shares research showing 84% of product leaders say their work is integral to growing revenue. She illustrates with an example of a team building a new product line without considering revenue potential, emphasizing that developers should understand how their work contributes to business outcomes. She contrasts high-value engineers who think about market impact with those who just follow requirements, stating the latter approach is becoming replaceable.
  • 00:12:46 — Advice for junior engineers adopting product mindset — Jessica offers practical advice for junior engineers: understand what the company does, who its customers are, and how it makes money. Talk to product managers and UX designers, listen to user research occasionally, and ask questions about how work connects to broader goals. She shares an anecdote about an engineer who resolved months of debate after hearing user feedback directly, highlighting the power of context.
  • 00:17:51 — Leadership’s role in empowering teams — Jonathan and Jessica discuss how leaders must empower junior engineers by providing context and psychological safety. Jessica notes that people often underinvest in context, leading to misalignment. She emphasizes the importance of clearly communicating goals, why they matter, and how each person contributes. Without this foundation, attempts at initiative may be punished, creating a culture where people retreat or leave.
  • 00:28:43 — Viewing automation as opportunity rather than threat — Returning to the theme of automation, Jessica encourages seeing change as opening new possibilities. Instead of fearing loss, ask: “What is now available that wasn’t yesterday?” This mindset shift allows developers to focus on increasing impact and value. She acknowledges the fear but suggests embracing change, taking risks, and continuous learning as paths to growth and new opportunities.
  • 00:35:32 — Transferable skills and hiring for aptitude — Jonathan and Jessica discuss how learning should focus on transferable thinking skills rather than specific technologies. Jessica criticizes hiring managers who overly focus on checking boxes for specific technologies or domain experience, arguing that problem-solving ability and learning agility are more important. She shares an example of a successful hire who had been a stay-at-home parent for seven years, highlighting that core competencies endure.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-09-13T09:00:00Z
  • Duration: 00:43:23

References

Podcast Info

Transcript

[00:00:00] if you’ve worried about the coming revolution in automation that is supposed to take all of

[00:00:10] our jobs away well today’s episode might be just for you and also if you are a junior developer

[00:00:17] and you’re trying to figure out a way to grow into your senior role your future senior role

[00:00:23] and how to set yourself up for success today’s episode is for you as well

[00:00:28] interestingly today’s episode isn’t with a senior engineer it’s not with a manager it’s with someone

[00:00:34] who thinks more about product today’s guest is jessica hall she is the co-author of the product

[00:00:42] mindset book that is coming out in under a month we’ll talk more about the book during the episode

[00:00:48] my name is jonathan cuttrell you’re listening to developer t and my goal on this show is to

[00:00:52] help driven developers find clarity perspective and purpose in their careers let’s get

[00:00:58] started

[00:00:58] straight into the interview with jessica hall jessica welcome to the show thank you for having

[00:01:05] me so we were talking before about whether you want to be called jessica or jess i might end up

[00:01:10] using those interchangeably but uh instead of uh letting me speak for you i’d love for you to kind

[00:01:17] of introduce yourself and explain the things that you’re most interested in right now in your career

[00:01:24] oh gosh that’s uh such a big question

[00:01:28] um i came up through the world of technology first as an engineer then a designer ux designer

[00:01:37] product manager and now i help a lot of companies decide what to build how to build how to structure

[00:01:43] their organizations and i work at a place called three pillar global and we just wrote a book

[00:01:48] called the product mindset and that’s all about helping companies engineers ux designers product

[00:01:54] managers succeed in the digital economy so what i’m trying to do now is i’m trying to do a lot of

[00:01:58] is help people expand the value that they’re creating help people who are looking at things

[00:02:06] like a highly competitive global talent market and the increase of automation and say how can i

[00:02:12] be different how can i distinguish myself how can i broaden that value proposition to continue to

[00:02:18] grow my career and how do i get support within my leadership team in order to do that and that’s

[00:02:24] kind of the area that i’ve been focused on for let’s say the last two years i’ve been focused on

[00:02:28] is we’ve been doing the research and writing for the book that’s uh such an interesting area to

[00:02:33] discuss and i’ll go ahead and point out that i and many other developers i’ve been concerned about my

[00:02:39] job becoming obsolete at some point in the future you know what i do as a developer we’re always

[00:02:46] abstracting these these concepts right and so you know it’s very possible that everything that i do

[00:02:52] today is going to be very different in as short as a couple of years so i’d love to know you know

[00:02:58] has some of that research taught you about protecting yourself from becoming obsolete

[00:03:04] and i’m going to add a qualifier here because i think there’s uh there’s kind of a a bad way to do

[00:03:10] this the which is obvious where you create kind of the stranglehold by making yourself the the

[00:03:17] bottleneck or you know withholding information and that’s something that i’m going to kind of

[00:03:22] rule out that’s not something that i want to do so what is kind of the the right way the good way

[00:03:28] to uh to avoid becoming obsolete in a in a job like developers have yeah i think you know a couple

[00:03:35] years ago what a successful developer looked like is someone who was regularly deliver delivering

[00:03:42] code that was secure performance compliant reliable maintainable deployable scalable

[00:03:48] if you were delivering quality code with some consistent velocity you were doing pretty well

[00:03:58] in the market it is a global market uh all over the world there are engineers and and schools

[00:04:04] turning out new engineers um we’re seeing things like low code no code environments where a lot

[00:04:10] more is being distributed towards people with less technical skills um you know the rise of

[00:04:17] automation devops containers um continue you know automated testing that’s kind of changing

[00:04:26] things where you know a lot of teams used to have

[00:04:28] a lot of manual testers well you don’t see as many manual testers as much you don’t have as many of

[00:04:35] those one systems engineer who if they left the company would you know everything would uh go to

[00:04:41] a halt so they just gave them lots of spot bonuses i worked at a place where they had

[00:04:44] one of those engineers because they didn’t have continuous integration or continuous deployment

[00:04:49] and now those things are are possible so you’ve seen a lot more and and you know how much of this

[00:04:55] is hyperbole how much of this is real i’m not quite sure i’m not quite sure i’m not quite sure

[00:04:58] but i definitely know this that the top performers the most sought after talent

[00:05:05] they’re bringing more to the table than i could just write code consistently with high quality

[00:05:10] they’re great at collaboration they’re working with qa devops ux product marketing they’re

[00:05:19] elevating the productivity and the impact of those people around them they’re helping business

[00:05:25] leaders and their organization make decisions about what technology they’re using and what

[00:05:28] technology to use how do we sequence things how can we scale when do we decide to acquire

[00:05:34] technical debt how do we pay that down there’s certainly some top uh performers out there who

[00:05:40] are distinguishing themselves by helping people make technology decisions with the business

[00:05:46] content with a customer context and i think those are the things if you look at some of the

[00:05:51] research around automation those are going to be harder to replace because can cncd that’s

[00:05:56] but up deployment i didn’t and

[00:05:58] I used to have to be woken up at 3 a.m. one weekend a month for user acceptance testing.

[00:06:03] That hasn’t happened for a long time.

[00:06:06] UA automation is sped up testing.

[00:06:08] Now we’re speeding up development.

[00:06:10] But you know what?

[00:06:10] The people part never got any faster.

[00:06:12] That’s true.

[00:06:13] And it sure as heck doesn’t seem to have gotten any easier.

[00:06:16] But people who can help make decisions, trade-offs, alternatives, understand how to go from one place to another, I think those people will always be in demand.

[00:06:27] And those people will offer a greater value and a multiplier that is going to be really, really hard to replace by automation.

[00:06:36] Yeah, I think that makes sense.

[00:06:38] I think that as we see these abstractions kind of wrap what used to be a lot of what a developer might do on the day-to-day basis, an abstraction kind of wraps around it.

[00:06:51] It still makes sense that a developer like myself or the people listening.

[00:06:57] They might need to know how those abstractions interact and how to compare the different abstractions.

[00:07:04] In the same way that as we’ve seen abstractions change, for example, the languages that we use.

[00:07:13] Instead of using a lower-level language, we might be able to use a more expressive high-level language.

[00:07:19] And so those different abstractions still have trade-offs.

[00:07:22] And those evaluations, like you’re saying, makes total sense to me.

[00:07:26] That it’s all about.

[00:07:27] The context of that automation or of that decision.

[00:07:32] It’s not just about plugging in the system and pressing go.

[00:07:37] There’s more to the puzzle than that.

[00:07:39] Yeah, and people, business leaders are trying to keep up in a world where customers have more choice than ever.

[00:07:46] There’s constantly changing demands from customers, from technology, outside forces like GDPR and the California Privacy Act.

[00:07:55] And so there’s always this world where things change.

[00:07:57] There’s such a demand for change.

[00:07:58] And there’s always this demand for change.

[00:08:00] And companies are going to have to get decided.

[00:08:01] Well, who’s going to decide?

[00:08:03] Who’s going to decide whether we use this technology or that technology, when we make a replacement?

[00:08:07] How do we do this?

[00:08:08] How do we integrate these things together?

[00:08:10] What’s a smart trade-off?

[00:08:11] Somebody’s going to have to help make that decision.

[00:08:13] And business leaders, they can’t do it.

[00:08:15] And they just want to know how much is it going to cost when I’m out in the data?

[00:08:20] Somebody has to help navigate that.

[00:08:22] And I think the people in those roles.

[00:08:25] The people with that expertise.

[00:08:27] With that ability to understand that.

[00:08:27] And that’s just a new example of what’s going on.

[00:08:27] Yeah.

[00:08:27] So it’s that process. Yeah.

[00:08:27] the needs, um, interpret, help people navigate are going to be, uh, specifically, you know,

[00:08:34] high value. Um, you know, we did some research with a Forrester. We surveyed about 154 product

[00:08:40] leaders. 84% said the work that they do is integral to growing revenue. So the work that we

[00:08:47] do, you know, as someone who came up, like I did in UX or product, you know, I might be writing

[00:08:52] stories or I might be making a comp or a wireframe or you might be writing code, but all of us have

[00:08:58] a key role to play in generating new revenue for the businesses that they work at. And what we’re

[00:09:05] seeing is in a lot of cases, people don’t even think about that. I was working with an engineering

[00:09:10] team, um, and they were creating a new product line. And it was interesting about this new product

[00:09:16] line was that it was going to open up new markets. There was a whole category of people that they

[00:09:21] couldn’t sell to.

[00:09:22] Because the way they deployed and implemented their solution, um, wasn’t going to work for

[00:09:28] them. And so this new team was stood up entirely separate from all the other teams to build this.

[00:09:35] And I did some math and I’m like, guys, my guess is you burned over a million and a half dollars,

[00:09:41] like easy calculation. You’ve been working on this for nine or 10 months. This is a team about

[00:09:46] eight people. It’s got product. It’s got this other thing. Okay. Okay. I’m going to guess

[00:09:52] this is a team of about eight people. It’s got product. It’s got this other thing. Okay. I’m

[00:09:52] going to guess this is at least a million and a half dollars. So how much revenue do you think

[00:09:56] you’re going to do in the first year? And it was like crickets. Sure. Do you guys, do we understand

[00:10:02] what we’re trying to do here? Do you understand the kind of bet, the kind of sacrifice the rest

[00:10:07] of the business is making to make this possible? And are we contributing to that? Do we think

[00:10:12] about, well, you know, if we architect it this way, or we use this kind of tool or use this

[00:10:17] kind of approach, we could probably ship something smaller, faster, and then we could start doing

[00:10:21] more.

[00:10:22] So I think it’s a good idea to think about these requirements with customers and doing

[00:10:23] betas or proofs of concept and be able to onboard some new customers earlier or get some

[00:10:29] new revenue in the door or learn about something that was risky. If we approached it differently,

[00:10:33] if we took the mindset that this was a new product line that could open up a new market,

[00:10:37] what was the best way to get after it? That’s the difference in mindset. I think you see

[00:10:42] from a high value kind of future-proof engineer, then someone says, okay, well, give me the

[00:10:47] requirements and I’m going to write some bang in code. I’m not, I’m not even thinking

[00:10:51] about those other things. That’s product’s job. That’s UX’s job. And if they get it wrong,

[00:10:57] that’s their fault. I’m just going to go over here and do this stuff. Well, I’m sorry. That’s

[00:11:00] not good enough anymore. That’s replaceable. That’s, that makes total sense because,

[00:11:05] you know, great code is, uh, something that we can study and, uh, but what makes it actually

[00:11:13] good? This is something that we’ve talked about a lot on this show. What makes code actually good?

[00:11:18] Well, there’s multiple dimensions for that. You can, uh, kind of,

[00:11:21] judge it at the code level itself. Uh, you can judge it from that subjective experience level

[00:11:26] as a, as a secondary developer that’s coming in with your knowledge set. You can judge it from

[00:11:32] the team level. Is this maintainable by this team? But perhaps the most, uh, profound way to

[00:11:38] judge this is, is this doing the thing in the world that you wanted it to do? And this is the

[00:11:44] way that the market will judge it. This is the way that you are going to earn or lose a job. And so

[00:11:51] what you’re saying makes total sense. There’s this burning question that this brings up though.

[00:11:57] And that is for all of the people who are listening to this there, uh, that are in school,

[00:12:03] or maybe they’re thinking about becoming a developer and they know that this big

[00:12:06] technical hurdle is in front of them of learning how to code, learning how to implement these

[00:12:10] systems. This job that you’re describing sounds a lot like what I’ve heard people describe for

[00:12:17] kind of senior developers or even staff level engineers.

[00:12:21] How can we encourage the junior engineers that are coming onto a team to be thinking

[00:12:29] in this influential way, rather than thinking about their job in terms of, okay, I’m getting

[00:12:36] a card, you know, off of my, uh, Asana or Jira board or whatever, and I’m doing whatever the

[00:12:41] card says, how could a junior engineer start thinking more in this product mindset?

[00:12:46] I absolutely love that question. I think it’s a great one. Um, so,

[00:12:51] you’ve joined a new team or you’ve joined a new company. What does that company do? Who is their

[00:12:59] customer? How do they make money? What are we trying to achieve? Having some fundamentals of

[00:13:04] what the organization is trying to do, spending some time, talk to your product manager, talk to

[00:13:09] your UX designer, try and get a sense of who the customer is and what we’re trying, getting those

[00:13:14] kinds of that kind of background, that kind of information. So we have that, you pick up that

[00:13:19] card and you’re like, okay, I can see how,

[00:13:21] what this is doing contributes to everything else around me. And so the work, Hey, that gives your

[00:13:27] work more meaning and purpose, right? You’re not just banging out a ticket. You’re, you’re

[00:13:32] contributing to the value and say, you know what, I’m not quite sure how this connects or, you know,

[00:13:38] I think maybe I could probably implement it this way. And then you could just ping, um, someone on

[00:13:43] the team say, how about this? I was, I was kind of thinking about it this way, or maybe we could

[00:13:47] sequence this way. Uh, we had a team, um, working

[00:13:51] with a big client, a big insurance organization and the way this insurance organization, um,

[00:14:00] measures everyone and how that affects their, their raises and their bonuses and things.

[00:14:07] It’s about how much self-service they can drive. So it means that if you can keep somebody from

[00:14:12] off the phone, from calling a support representative, we want you to do that.

[00:14:17] And that’s the goal. And so the team actually spent some time.

[00:14:21] And everybody on the team brainstorming ways to improve performance. And so they found that by

[00:14:26] tweaking, uh, one of their algorithms, they could speed up the way to return some results

[00:14:32] to customers by like 10%. And in this game, 10% actually counts for a lot. I mean, that could mean

[00:14:39] the chance of definitely, you know, could improve the amount of conversion that they would get.

[00:14:43] And so everybody on the team said it came up with some ideas to say, you know, if I did this,

[00:14:48] we could get it a little bit faster or,

[00:14:51] you know, we could make it easier for this customer or, you know, so being, you know,

[00:14:55] suggesting ideas, thinking about the impact, asking a lot of questions and making sure you

[00:15:02] understand, uh, how you contribute to the team. And those types of things are great for junior

[00:15:08] engineers to do occasionally listening on some user research, whether that’s a recording or

[00:15:14] some of it lives, you have a notion of who is this person. I love getting engineers to listen

[00:15:19] to user research, not to say you’re going to do it all.

[00:15:21] Because you’ve got stuff to do and everybody’s got a ton of meetings, too many, but occasionally

[00:15:26] hearing a human being’s voice and knowing that what you do is make their lives easier

[00:15:31] and understanding them is great. We were doing something with a big media company, huge one.

[00:15:38] And, uh, one of the folks on the team was doing user research and an engineer was next to her,

[00:15:45] like scribbling in a notebook, writing things down very furiously. And she gets the end. She’s like,

[00:15:50] what’s going on?

[00:15:51] And he’s like, we’ve been arguing about how to implement this feature for months. And I finally

[00:15:56] understand what they need. And I know exactly what I need to build. And if I just known this

[00:16:00] a couple of months ago, if I just ask a question or thought a little bit more about what I was

[00:16:04] trying to keep, I could have saved weeks of debate. So one little extra question, one little,

[00:16:11] uh, interpretation, one willingness to be able to step out and say, Hey, I was thinking about this.

[00:16:16] And hopefully you’re at an organization that supports and encourages this behavior.

[00:16:21] I sure hope that’s the case. I know that’s not everywhere. Um, but those types of things are

[00:16:27] that little bit of investigation, that little bit of extra understanding that little bit of

[00:16:33] extra initiative is such a great thing for a junior developer to come in and right from the

[00:16:38] get-go start adding more. Yeah. Yeah. You mentioned something that I think is so important,

[00:16:44] uh, for, for managers who are listening to this and certainly for product owners and, uh, anybody

[00:16:51] who’s in any kind of leadership position, the more that you can empower those junior engineers,

[00:16:58] because we’re talking to the junior engineer a moment ago and you said, you know, I hope you’re

[00:17:02] in an organization that supports us. The people who are empowering the younger engineers should

[00:17:10] be doing so in this direction, in, in the direction of saying, Hey, you know what? I want you to

[00:17:16] understand thoroughly the whole kind of product chain.

[00:17:21] From the user and their requests and their needs all the way to whatever that piece of code is that

[00:17:28] you’re writing. And you may not be the one that’s going to perform that research. You may not know

[00:17:34] all of the, you know, statistical models that are used to decide between one feature or another,

[00:17:39] but if you have some exposure as a, as a, whether you’re a junior engineer or any level engineer,

[00:17:47] it’s important for leadership to support these efforts because,

[00:17:51] because what most junior engineers are not likely to do on their own is to stop the work that they’re

[00:17:57] doing and say, Hey, you know what, is this even the right thing to do? That’s a really dangerous

[00:18:02] and scary thing as a junior engineer, that would be a really dangerous and scary thing to do

[00:18:08] because who are you, right? You haven’t really proven yourself. And there’s a lot of kind of

[00:18:13] social pressure for you to kind of, you know, do the thing that you know is going to impress

[00:18:19] the most people in the company, right?

[00:18:21] But that’s most likely not the thing that is, that is going to prove long-term successful for

[00:18:27] your career necessarily. Um, and certainly not long-term successful for that product.

[00:18:33] So that’s kind of a call to leadership to support those efforts.

[00:18:38] Absolutely. You’ve reframed that so beautifully. Um, what I’ve learned of eight years of working

[00:18:43] with global teams is that people under invest in context. Um, so isn’t that true everywhere?

[00:18:50] So,

[00:18:51] so true. Like people do not, uh, they don’t take the time to say, um, I love my friend Sip. He did

[00:18:59] this in every meeting that we went to when we were building this, the first mobile app, the company

[00:19:03] we worked at. Every time we sat down with someone, he would spend a good five to seven minutes

[00:19:08] explaining the whole context, what we were doing, what we’re trying to do, what we’re trying to get

[00:19:12] done today. Here’s the lay of the land. Here’s the objective. And I’m like dying inside cause I

[00:19:17] super ADD, but he was so right because that extra,

[00:19:21] context that he put into every big, important interaction, just framing up. Here’s what we’re

[00:19:27] trying to do. Here’s why it matters. Here’s what we need for you. Here’s how you’re going to help

[00:19:31] us contribute to this thing that is important for our company’s future. Like he just did that

[00:19:35] before every major meeting we had and everyone was like, okay, everything got easier. Yeah.

[00:19:40] Yeah. Um, so even though I would, my desire was to jump right in and get started that context,

[00:19:46] that, that foundation about here’s what we’re trying to do. Here’s why it matters.

[00:19:50] And a lot of people don’t do that. And I’ve run into many product leaders that I’ve coached

[00:19:56] in the last year and they just, they don’t understand why their teams don’t know what’s

[00:20:00] going on. They just like, they’re, they’re kind of, they don’t, you know, cause I’ll walk around

[00:20:05] the thing I, they do to test this real simple. What are the three most important goals for the

[00:20:11] next three months? And I’ll ask like 20 people. How many times do you get different answers?

[00:20:16] Uh, I get, the only answer I get the same as, I don’t know.

[00:20:19] Yep.

[00:20:20] Yep. So, um, and you, you find a lot that, that people have said things once and they put it in a

[00:20:28] PowerPoint deck or it’s not simple. It’s not clear. It’s not going to hammered in. This is what we’re

[00:20:32] trying to do. This is why it matters. This is how we have, this is how you fit in this. And so I

[00:20:37] think people really under invest in that. And then they, then when somebody tries to take an

[00:20:44] interpretive leap and step out of the balance of the card, they get smacked on the hand because

[00:20:50] they didn’t interpret it in the right way. And so then they, you know, and because they got smacked,

[00:20:56] they now receive, they do, you know, they have all the anxiety you discussed. And now,

[00:21:00] now they’re like, they stepped out of line and they got smacked for it. So I’m like,

[00:21:03] I’m going to step out of line again. And then that’s the, that’s the leader who calls me later

[00:21:06] and says, well, why do people not feel empowered? That’s exactly why you tell them. Um, but you

[00:21:13] didn’t spend the time to say, here’s the mountain we’re climbing. Here’s why we’re climbing. Here’s

[00:21:17] what success looks like. Here’s how I need you to.

[00:21:20] Tribute. You can figure stuff out on your own. And as long as we have some way of measuring that

[00:21:24] we’re going in the right direction, it’s okay. When you get it wrong, you’ll get it right. You

[00:21:29] know, you’ll figure it out and then we’ll, we’ll get there together. People just don’t invest in

[00:21:33] that. And if you don’t, if you’re on a team and you don’t understand, you’re not quite sure what

[00:21:39] we’re doing. You gotta ask somebody, don’t just put it on product or UX to be responsible for,

[00:21:46] or sales or marketing, ask questions.

[00:21:50] Um, try to report it. And you know, you may hit the wall at a certain point. You may be like,

[00:21:53] you know what, just shut up and do your job. And my sense is that’s probably not a place

[00:21:57] you want to be long-term. It’s probably just not, you’re probably going to hit a wall pretty fast,

[00:22:03] or maybe they don’t stay in business or they get acquired or something else happens.

[00:22:08] That was, that was, you know, one of the pieces of advice. Uh, and you mentioned before we started

[00:22:12] recording the, that, uh, this was one of the episodes that you would listen to at this show.

[00:22:16] One of the pieces of advice that I gave myself is, you know, don’t,

[00:22:20] uh, don’t stay loyal to something that goes against your values. That’s essentially what I

[00:22:26] was, what I was saying. And that’s true. If you, if you’re stuck in a company where you can’t think

[00:22:31] this way, where you’re not allowed to access this, this higher level vision, or you’re not

[00:22:36] allowed to even ask questions about it without feeling, and maybe it’s not a written rule that

[00:22:41] you’re not allowed to, but rather it’s not normalized. It’s not something that, uh,

[00:22:45] culturally is acceptable. And you know that because when you tried, when you tried to

[00:22:50] do it, or, uh, when someone else tried to do it, they obviously got shot down in some way.

[00:22:54] You know, this is a major failure of leadership because this should be normalized. This should

[00:23:02] be something that, and when I say should, I mean, if you want to succeed as a company and be a

[00:23:08] long-term company, then it’s likely that this is a way that you should operate. Not just because,

[00:23:14] you know, people like to be empowered and connected, but because this is necessary to,

[00:23:19] to maintain.

[00:23:20] Uh, this, I’m sorry, this is necessary to stay competitive, like you said, in a global market.

[00:23:27] And so if you’re, if you’re just, you know, pushing people into their boxes and whenever

[00:23:32] somebody pipes up and says, Hey, you know, what about this big idea? If they feel a sense that,

[00:23:38] you know, they’ve stepped out of line or somehow this is inaccessible to them,

[00:23:43] there’s probably something wrong there. Right. Would you agree with that?

[00:23:46] Mm-hmm. Yeah. A couple of things are going to happen.

[00:23:50] One is people are just going to retreat. They’re just going to do what they’re told.

[00:23:55] And you, you watch these organizations and you’re like, how did something

[00:23:59] happen in these big scandals? It’s because they retreated or, um, they’re going to leave or,

[00:24:05] uh, there’s going to be drama. They’re going to go rogue.

[00:24:07] Or all three, right? Maybe all three.

[00:24:09] Or all three. I mean, I, I’ve certainly seen it, um, many times. We have a chapter in the book

[00:24:15] about culture. Uh, and we talk a lot about what is the kind of culture that’s enabled. And it,

[00:24:19] the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the,

[00:24:20] the culture is exactly the one you described. The culture that is open, um, that is accessible,

[00:24:25] that values questions, that values asking, um, pushing things forward. Um, one of the things

[00:24:32] I tell clients sometimes, and it’s a little like salty language, I’ll just warn you in advance.

[00:24:37] It’s like, okay, I know what it is. Sometimes you just need something and it maybe isn’t the

[00:24:42] best idea, but you just got to get it done. Like your, your boss is all over you. Your board is

[00:24:47] all over you. You just had to make this thing. You do. You got to make it. You got to make it.

[00:24:49] Go away. Like, that’s okay. I understand that that’s necessary. I’m going to give you two of

[00:24:54] those a year. And I call it the JFDI, which is just effing do it. It’s like, oh, is it the JFDI?

[00:25:03] Yeah. Okay. I’m not, we’re not going to talk about it anymore. We’re just going to knock it out

[00:25:07] because we’ve accepted that like, sometimes you just got to do what you got to do, but

[00:25:11] every other time, no, let’s have a conversation about it. Let’s, let’s be willing to debate it.

[00:25:16] Um, let’s, let’s be willing to, you know,

[00:25:19] entertain it and, and have, you know, push things forward. And if you look at

[00:25:23] the work that Google has done, they’ve done a lot of really, um, expansive research on what

[00:25:30] makes for a good team and what makes for a good manager talking about things like psychological

[00:25:34] safety, um, which doesn’t mean that everybody is nice and fuzzy. It means that you feel safe saying,

[00:25:41] yeah, that was dumb. Like, I don’t get it. Or I think we should do something else or this isn’t

[00:25:47] working. And so environments where those,

[00:25:49] those things are healthy and safe and open and welcomed are environments where I think

[00:25:54] engineers are going to be able to succeed. Um, and all the people around it, because

[00:25:59] it feels, uh, one of my, uh, colleagues told me once, he’s like, we don’t need agile so much

[00:26:05] as ways to work together because the, the complexity of the modern development team

[00:26:10] is so far beyond just engineers. Now we’ve got QA out of engineers, we’ve got data engineers,

[00:26:15] got data scientists, we’ve got, um, DevOps, we’ve got,

[00:26:19] you know, product marketing, we’ve got product management, we’ve got user experience,

[00:26:23] we’ve got information, we’ve got all these people, we all have to figure out how to work together.

[00:26:27] And the best way to do that is in an open collaborative workplace with a very clear,

[00:26:32] like that’s the mountain gang. We’re all going together.

[00:26:35] Yeah. I mean, that’s, that’s what all of the research in this area shows, right? Is, is if

[00:26:41] you can have a shared, a shared goal, then your particular flavor of, of working and whatever

[00:26:47] ceremonies you have, if you can have a shared goal, then you’re going to be able to do that.

[00:26:49] If you can have a shared goal and if you develop clarity around that, but you also, uh, have a

[00:26:56] sense of, like you said, psychological safety, you know, if you have someone who cares about

[00:27:01] your wellbeing at work, these things seem like common sense, but unfortunately, a lot of the

[00:27:06] time, what we ended up seeing in companies that don’t, you know, actively manage these various

[00:27:12] points that we’re talking about, we see companies that, uh, that, you know, elevate only one of

[00:27:19] these things, right? They’ll elevate psychological safety, but you don’t have the clarity that you

[00:27:24] need or you don’t have a shared goal. And so everybody feels, you know, like they can work

[00:27:29] with their, with the people around them decently well, but nobody knows what they’re doing or why

[00:27:33] they’re doing it. Right. Uh, so it’s safe, but it’s not really progressing anywhere.

[00:27:39] Yeah. I, I definitely, I think you’ve expressed it where I, I, my, one of my favorite clients of all

[00:27:44] time, totally collaborative, highly,

[00:27:49] invested in, in content and context, really traveled the world, spent a lot of time or super

[00:27:55] open about what they were trying to do. The problem was that they just moved too slow and

[00:28:01] they took, you know, years to develop their new product, which would open up a new market. Well,

[00:28:06] other people beat them to market. So you can be a great working environment that everybody loves

[00:28:12] and still not be making any money and just completely fail. And so, you know, it’s a,

[00:28:19] it’s a battle.

[00:28:19] It’s a balance of all these things. And, and it, you know, there are times where

[00:28:23] certain, they’re going to have to trade certain things off. It’s never, it’s never easy. It’s

[00:28:28] messy. It’s hard. Um, but I think if you take the attitude, we’re all in this together, then you’re,

[00:28:34] you’re more likely to, um, come out of that on the other side and, and be successful.

[00:28:39] I think on one hand, you could say to go back to our theme of automation,

[00:28:43] um, that this is a scary time to be an engineer and a time where maybe

[00:28:48] off you scale, you’re going to have to, you know, you’re going to have to, you know,

[00:28:49] and entrenchment and putting your head in the sand is the right play.

[00:28:55] And what I think is it’s the absolute wrong play. Yeah. It’s automation is coming for a lot of

[00:29:01] people, but it does, you know, open up a lot of possibility that maybe you’re not even thinking

[00:29:08] about whenever there’s change in an organization and gosh, isn’t there change in organizations

[00:29:12] like all the time I try to say to myself, what is now available? That wasn’t yesterday.

[00:29:18] How have the pieces on the board changed in a way that maybe I can chase a new opportunity

[00:29:24] or learn something new or take on a new challenge. Maybe I can hire a different kind of person in a

[00:29:30] different kind of place and learn a, take on a new project or, or develop the skill that I know

[00:29:35] I’m lacking in chain. If you take the mindset as changes opportunity, like when something is

[00:29:42] different and maybe that’s something opens up a possibility. So if you can just like

[00:29:47] gulp, like, I don’t know, I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t

[00:29:48] know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t

[00:29:48] know that fear for a second and say like, now what is available to me today? What is it available to

[00:29:54] worldwide could spend less time doing this like task that I don’t like. What could I fill that

[00:30:00] time with? What could, how could I increase my impact? How could I increase my value? How could

[00:30:06] I do something different today that I’m not doing because I have to spend my time on this.

[00:30:11] If you kind of shift your focus that way, then I think you can get to a potentially

[00:30:17] better place.

[00:30:18] place. I know it’s scary. I know you don’t want to do it. I don’t want to do it. I have two

[00:30:24] children. The automation thing scares the living crap out of me. But then I take a deep breath and

[00:30:30] say, okay, something is now available to me that wasn’t yesterday. What is it? And do I want to

[00:30:37] chase that? Is that worth making a bet on? Amongst the many things that technology is

[00:30:42] drastically changing in our everyday lives, fintech might be at the top of that list.

[00:30:48] And Barclays is helping lead that change. Barclays has an award-winning group of developers

[00:30:54] and the passion, resources, and tools necessary to actually do something innovative in this space.

[00:31:02] And they’re hiring. Go and find your next position at home.barclays.com. That’s home.barclays.com.

[00:31:12] B-A-R-C-L-A-Y-S slash developers. At Barclays, developers are always developing.

[00:31:21] This is, we can’t really predict the future very well. And so when people are asked what’s going

[00:31:27] to make them happy, they often say something that they think will make them happy. And then

[00:31:31] they’re asked, you know, once they have that thing, if it made them happy, it turns out it

[00:31:36] doesn’t for much of the things that we expect that it would. And, you know, a large number of people

[00:31:42] say, well, I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I

[00:31:42] don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t know. I don’t know.

[00:31:42] The reason for this is because the way that we predict or the way that we imagine an alternative

[00:31:47] reality, in this case, you know, a future where automation has replaced a lot of our current tasks

[00:31:54] is incomplete, right? So we aren’t thinking about, you know, what will we replace that work with?

[00:32:02] We don’t really think about that. Instead, we think about purely just the loss, right? We have

[00:32:07] this massive loss aversion. So we’re really concerned about,

[00:32:11] oh, no, you know, all the skills that I’ve spent my career honing are suddenly obsolete.

[00:32:19] And now I’ve lost this major thing. But what you’re saying is exactly right. This is how we

[00:32:25] should be thinking about the future. Specifically, what have I gained? Not just what have I lost,

[00:32:31] but what have I gained? What is new on the table? What’s available now that previously wasn’t? And

[00:32:37] one of those things, perhaps the most important one is time.

[00:32:40] Now you have a wide open field to replace the thing that you were doing with perhaps something

[00:32:48] more valuable.

[00:32:49] Yeah, I think that, you know, loss aversion is a powerful, powerful thing. And I love all the

[00:32:56] research on those aspects of, you know, I read something recently that I’m sorry, I can’t recall

[00:33:04] where, but it said, when you imagine your future past a certain point, it’s a different person.

[00:33:10] Yeah.

[00:33:10] Not you. It’s like somebody else. And so the idea of like, one year, five year plans are

[00:33:17] like, you’re imagining a company that doesn’t like even exist. So you tend not to because it’s not

[00:33:24] you, you aren’t thinking about some of these long term changes in your life. But if you go back

[00:33:30] from a couple years, I worked at the museum. Well, there’s no more typesetters in the world.

[00:33:36] There’s no more telephone operators. There’s no more

[00:33:40] a few printing presses for certain things. But people are doing something else, like some other

[00:33:46] things have emerged. And but you do have to, you know, the hard part is you have to kind of lean

[00:33:52] into the change, embrace the change, take some risks, continue to learn. You did a podcast about,

[00:34:01] you know, the advice you would have given to 10 years ago that you wouldn’t have learned,

[00:34:05] listened to, sorry. And you said, you know, spend a lot of time, learn a lesson,

[00:34:10] you know,

[00:34:10] learn a language really deeply, because so many things are more applicable when you truly have

[00:34:14] more mastery of it. That’s a great example of like, things, things are things are different.

[00:34:19] I went to journalism school, and I work in technology. I but yet so much of what I learned

[00:34:25] in journalism school, asking questions, digging for the story, trying to figure out what the most

[00:34:30] important parts are being able to communicate to people in a crisp, clear, short way. Gosh,

[00:34:36] I you in, you know, doing research, you know, I use,

[00:34:40] all those skills today that I spent time building on, but I just use them in a way that I would have

[00:34:45] never thought about in the past. So it’s not as bad as you think, hey, you know, who the heck

[00:34:51] knows how it’s all going to play out. But, you know, I would come back to take that mindset,

[00:34:58] that kind of growth mindset of, I’m going to learn, I’m going to impact my company,

[00:35:02] I’m going to continue to provide value and value at an ever broader, higher level. And if that’s

[00:35:10] you take as an engineer, it can take you many, many places. And you know, it can take you up to

[00:35:17] the CTO level, it can take you up to being a CEO, or, you know, a leader, a thought leader. I mean,

[00:35:23] there’s so many possibilities. And I don’t even know what the next set are. But there’s there’s

[00:35:27] definitely a lot out there. Yeah, well, the cool thing about what you’re saying, and I think this

[00:35:32] is true for developers, a lot of the skills that we think we are learning, a lot of the things that

[00:35:38] we think are,

[00:35:40] you know, going to last us a lifetime. When I said to learn a language deeply,

[00:35:46] it’s not because you’re learning the language. That’s the thing that’s kind of the trick,

[00:35:50] right? We think we’re learning the language. And when we learn math, we think we’re learning,

[00:35:56] you know, algebra so that we can get an A on the test, right? But actually, we’re learning this

[00:36:02] whole other skill set that is entirely transferable. It’s not just one kind of blanket skill set,

[00:36:10] so that we can learn the language.

[00:36:10] When automation arrives, suddenly you have to toss that thing out the door. Instead, if you look at all

[00:36:17] of your learning processes as this integrated thing, right? All of the learning that you do

[00:36:23] can apply in multiple ways. Your brain doesn’t really know how to package up your math knowledge

[00:36:31] and, and remove it from your language knowledge, right? To your brain, it’s all the same stuff.

[00:36:37] And so if you can imagine that the learning that you,

[00:36:40] have spent so much of your career investing in is not, you know, just this, this bucket that can

[00:36:49] easily be thrown out, but instead it’s deeply integrated into all that circuitry in your brain.

[00:36:55] Now it becomes more valuable. And in fact, actually becomes incredibly valuable when change occurs,

[00:37:03] because now you have this deep set of knowledge to draw on. You have all these models in your mind

[00:37:08] that perhaps the next person, you know, you’re going to be able to use. And so, you know,

[00:37:10] the next person, the next, uh, worker that’s, uh, that didn’t have all that experience,

[00:37:15] they may not have the same information that you have in your head.

[00:37:18] Yeah. I would also say, gosh, I wish every hiring manager who’s listening to that podcast would

[00:37:23] consider what you just said. Um, because a lot of them get focused on, do you, you know, this

[00:37:29] technology at this skill? Can you check this box? Do you have this subject, you know, subject

[00:37:33] matters? You do have this assistance, like, whoa, whoa, whoa, timeout that person. They can,

[00:37:38] there’s nothing that they need to know that they can’t learn quickly by spending some time on the

[00:37:44] internet. But I’ve definitely seen, I don’t know if this happens to engineers as much as I’ve

[00:37:49] absolutely seen it’s product in UX to say like, oh, but you’ve never worked on a healthcare

[00:37:54] product. So you probably can’t do this. I’m like, no, that, that all of that experience,

[00:38:03] that knowledge you’re bringing in practices from different industries. That’s where innovation lives.

[00:38:08] Um, you have a broad set of skills. So when the next time a technology stack needs to change,

[00:38:14] you can adapt more easily. I think sometimes hiring, um, H you know, talent or HR teams

[00:38:21] or managers are looking to check, uh, tick off boxes when they’re hiring, as opposed to looking

[00:38:29] for people who can learn and who can think and who can solve problems because they’ll solve

[00:38:33] whatever they need to solve. The, one of the best hires I ever made as a product leader,

[00:38:37] she had been,

[00:38:38] a stay at home mom for seven years. Like you went back and looked at it and they’re like,

[00:38:42] this person’s a bad-ass. Like they did these amazing projects, but they took seven years

[00:38:46] off to raise kids. That’s a, that is a product exercise in and of itself. That’s for sure.

[00:38:52] Oh my Lord. Yes. As a working mother of two. Uh, yeah, I can logistics anything,

[00:38:59] but one of the best hires I ever made because all of the things that are really important,

[00:39:06] she never lost them. Okay.

[00:39:08] Needed to get up to speed on some technology stuff and some process stuff and some other stuff. But

[00:39:14] yeah, she had that done in like three weeks.

[00:39:17] It’s like driving a new car, right? You have so much of these fundamental concepts in your mind.

[00:39:22] I would say, you know, there are a lot of companies that actually already understand

[00:39:26] this, especially, and I’ve noticed this for developers, the companies that have

[00:39:31] elected an esoteric language to use for, uh, for their stack, uh, like Elixir or something, right?

[00:39:38] So this is, this is, this is not a, uh, a common language. And for that reason,

[00:39:43] what they’ve done is they’ve hired a lot of people who didn’t know it.

[00:39:48] And so what they’ve realized in that process is, wait a second, these people are, are getting up

[00:39:54] to speed fast enough to be productive. Maybe we don’t have to restrict to, you know, just people

[00:40:01] who have experience in the stack, but instead we look for thinking skills rather than doing skills.

[00:40:08] And that has been such an interesting factor in the way that these companies hire, because

[00:40:13] they end up hiring people who tend to have skills in a broad array of languages rather than,

[00:40:20] you know, only focusing in on that one esoteric language.

[00:40:24] That is so interesting because most of the time when they’re choosing,

[00:40:28] I know a lot of people who, when they choose stacks, they’re like, okay, where’s the talent?

[00:40:32] Don’t go with Java. Cause I know I can find Java.

[00:40:38] And, uh, you know, I may pick something a little bit more exotic and the rest of the stack,

[00:40:44] but I gotta have a couple, I, you know, like I definitely know people who will pick stacks based

[00:40:48] on, you know, looking at their talent supply, but the idea of intentionally choosing something

[00:40:53] that’s a little more off the range, that’s just blows my mind. I think it’s fantastic.

[00:40:58] Yeah. Well, and, and it’s not necessarily, it’s not necessarily because they want to recruit that

[00:41:04] way. You know, they may have someone that does have experience with it and they,

[00:41:08] know that it gives them a competitive advantage in a particular area, but rather they’ve learned

[00:41:14] that recruiting, they kind of can break the rules because they’ve had to, because this language

[00:41:21] doesn’t have as much of a talent pool. Well, now they have to start considering talent separated

[00:41:27] from the language and look at aptitude as, uh, as a different way of seeing the same outcome.

[00:41:35] Yeah. I think people are way too attached to languages. Um,

[00:41:38] languages come and go every, you know, three to four years, your people are re-architecting

[00:41:43] and making changes. A lot of people are committing their organizations to a path

[00:41:49] without knowing how hard it’s going to be to change as opposed to saying, this is what we’re

[00:41:54] solving for today with tomorrow in mind. We think we know that things might shift and change over

[00:42:00] time because everybody has had to re-architect and in many cases, multiple times. Yeah.

[00:42:08] Yeah, absolutely. Change is the only thing that we can rely on. And that’s kind of the fundamental

[00:42:14] concept of this episode, right? It’s, you know, we’re really seeing our jobs in, in light of the,

[00:42:22] uh, maybe a more advanced way of thinking and integrated approach to our work rather than,

[00:42:30] you know, trying to turn everyone into a component that we can plug in.

[00:42:34] Instead, we have components in our machines. And so the human,

[00:42:38] the brain is so good at integrating concepts. So let’s take advantage of that.

[00:42:45] Thank you so much for listening to today’s episode of Developer Tea. If you enjoyed this first part

[00:42:49] of my interview with Jessica Hall, make sure you subscribe in whatever podcasting app you use

[00:42:54] so you don’t miss out on the next part on Monday. Thank you again to today’s sponsor,

[00:43:00] Barclays. Barclays developers are always developing. Go check out the openings they

[00:43:05] have available in New Jersey, as well.

[00:43:08] As all over the UK, head over to home.barclays, that’s home.b-a-r-c-l-a-y-s to check out the open

[00:43:17] jobs today. Thank you so much for listening. My name is Jonathan Cottrell. And until next time,

[00:43:21] enjoy your tea.

Visão de gráfico