The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/Leadership/Leman Tech Leadership Podcast
Leman Tech Leadership Podcast artwork

#166 | Staff Engineering in the Age of AI How Engineering Teams, Roles, and Expectations Are Being Redefined w: Jordan Cutler @Pinterest

Leman Tech Leadership Podcast · 2026-06-04 · 1h 0m

0:00--:--

Key moments - from our scoring

Substance score

67 / 100

Five dimensions, 20 points each

Insight Density14 / 20
Originality12 / 20
Guest Caliber16 / 20
Specificity & Evidence13 / 20
Conversational Craft12 / 20

Jordan Cutler shares his experience navigating the transformation of engineering teams in the age of AI, where traditional role hierarchies are being compressed and skill expectations are rising across all levels. At Pinterest, where he leads 3-5 engineers directly while supporting 200+ web engineers on the web platform team, Cutler emphasizes that the shift isn't just about adopting new tools - it's about fundamental mindset changes in how engineers approach problems, delegate to AI systems strategically, and communicate value. He highlights the psychological resistance senior engineers face when their identity becomes threatened by AI disruption, and addresses the challenge of gracefully onboarding experienced engineers to new ways of working. Cutler's practical examples - from using AI to write PR descriptions with Mermaid diagrams to establishing an "how I AI" channel for knowledge sharing - illustrate how to build organizational capability without attacking people's sense of competence. The conversation explores how junior engineers can now accomplish what previously required mid-level expertise through AI, mid-level engineers step into senior responsibilities, and staff engineers expand scope beyond single-team leadership to influence architecture and standards across multiple teams and company-wide initiatives like Pinterest's AI pathfinders group.

Key takeaways

  • →Expectations are rising at every engineering level - junior engineers now expected to solve problems independently with AI, compressing traditional role progression by one level.
  • →The mindset shift from fearing AI to strategically wielding it (managing quality, knowing when slop is acceptable, and prompting for higher-quality outputs) is as critical as learning new tools.
  • →Staff engineers differ from seniors by expanding impact beyond their team to coordinate cross-functional initiatives, set company-wide standards, and influence architecture decisions across multiple teams.
  • →Psychological resistance from experienced engineers stems from identity threats, requiring leaders to communicate AI's value without attacking their competence - a challenge that needs a clear playbook.
  • →Building organizational AI adoption requires making it easy and fun (guild sessions, shared channels) rather than forcing it, while teaching engineers to think about process improvements before tool selection.

Guests

Jordan Cutler

Topics in this episode

Staff engineer roles and responsibilitiesAI-assisted code generation and PR descriptionsMermaid diagram rendering in GitHubDeveloper experience and internal tooling at scaleAI guilds and knowledge-sharing channelsJira MCP integration for AI contextWeb platform team structure at PinterestRole compression and shifting expectationsPsychological resistance to AI adoptionPerformance optimization across multiple teams

Questions this episode answers

What is the main difference between a senior engineer and a staff engineer role?

Senior engineers own work from start to finish with informal team leadership, while staff engineers expand scope across multiple teams, coordinate cross-functional initiatives, and influence company-wide standards and architecture decisions (e.g., Jordan's role coordinating performance improvements across teams and setting up AI fundamentals at Pinterest).

How are AI tools changing what junior engineers are expected to accomplish?

Junior engineers are now expected to solve problems independently with AI assistance, completing 80% of work with AI support before requiring senior oversight, versus historically needing hands-on mentorship from the beginning - effectively raising junior-level expectations to match previous mid-level capabilities.

How can leaders help experienced engineers adapt to AI without threatening their identity?

Jordan recommends creating safe learning channels like AI guilds and 'how I AI' internal channels where engineers naturally discover improvements, focusing on communication and ease of adoption rather than forcing change, while avoiding messaging that attacks engineers' sense of competence.

What is an example of shipping AI output at higher quality instead of accepting AI slop?

Jordan has AI write PR descriptions while guiding it with context (e.g., 'add Mermaid diagrams' for architecture changes with color-coding), resulting in faster, higher-quality output than he would write manually, versus other use cases where minor slop is acceptable risk.

How can engineering teams build AI adoption systematically?

Jordan's approach includes establishing learning sessions where engineers share how they use AI, creating dedicated channels for sharing techniques, and emphasizing the importance of clear communication about when and how to use tools (like connecting AI to Jira through MCPs for better context) over just dumping technical implementation details.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

14 / 20

The episode contains substantial practical insights about AI-driven engineering transformation, role redefinition (junior/mid/senior/staff), and concrete adoption strategies (AI guild, 'How I AI' channel, Claude for PR descriptions). However, it includes considerable conversational filler, throat-clearing, and repetitive points that dilute density. The core insights about rising expectations, delegating to juniors at 80% completion, and building 'software factories' are valuable but not consistently packed.

I haven't written any of the code by hand for me, you know, probably in the last couple of months. Every once in a while, you know, you need to do like a couple of line change here or there, but it should generally be able to do most of it for you nowadays.
the expectations of the junior engineer are going to become the mid level engineer. Mid level engineers are going to be expected to perform at senior engineer's senior as staff and so on.

Originality

12 / 20

While the episode addresses genuine shifts in engineering work (role compression, AI integration, identity threats), the core frameworks are largely extensions of existing discourse rather than contrarian or first-principles thinking. The 'racing off a cliff' metaphor and 'software factory' concepts are present but not deeply novel. The psychological/identity angle is more original than the technical commentary.

engineers are racing to run off the cliff of essentially, you know, their job security, which is essentially like they are constantly adding more and more automation to make them as part like part of the process less.
the expectations are now going to be raised, and you, you know, as leaders, I think should be able to expect a lot more from your engineers.

Guest Caliber

16 / 20

Jordan Cutler is a credible practitioner: staff engineer at Pinterest managing 3-5 engineers directly, leading 200+ web engineers on platform team, with proven career progression (Gusto → Qualified/Salesforce → Pinterest). He has shipped meaningful initiatives (AI guild, migration platform), held visible speaking engagements, and operates at sufficient seniority to guide organizational transformation. However, he is not a C-suite operator or builder of breakout companies, limiting top-tier caliber.

I am a staff engineer at Pinterest on the web platform team. I am generally leading directly like around three to five engineers at any given time
we support over two hundred web engineers on the web platform team and we just ensure that everything is as smooth as possible experience for them

Specificity & Evidence

13 / 20

The episode includes concrete examples (Jira MCP integration, PR descriptions with Mermaid diagrams, Claude newsletter digests, migration platform, 'How I AI' channel) and specific metrics ('80/20' split on task completion, '10x' growth of internal channel, '15 minutes' for proposal doc). However, much of the discussion remains framework-level or anecdotal. Missing: quantified impact metrics, failure cases, timeline specifics, and measurable business outcomes from described initiatives.

I'm guiding it into what is the story that I wanted to communicate now also telling it, Hey, add mermaid diagrams because GitHub can like rend natively render mermaid diagrams
I can quickly spin up either like a proposal doc in you know, maybe like fifteen minutes now with Claude

Conversational Craft

12 / 20

The host asks reasonable thematic questions and creates space for guest responses, but rarely pushes back, challenges claims, or explores contradictions. Questions are often long, multi-part, and somewhat repetitive. There is minimal productive disagreement or sharp follow-ups. The host validates rather than interrogates, missing opportunities to probe the junior hiring contradiction, sustainability of 'software factory' acceleration, or risks of over-automation.

What is the worst leadershould behavior that you've ever experienced?
what is something that you may be read recently or it can be a book, it can be an article, can be a report

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

different50engineer28engineers25mentioned20perspective18love17team17junior17learn17level16senior15sure15engineering14teams14couple14code14

Episode notes

▶︎ #166 | Staff Engineering in the Age of AI: How Engineering Teams, Roles, and Expectations Are Being Redefined w/ Jordan Cutler @Pinterest In this episode of the Leman Tech Leadership Podcast, Alex welcomes Jordan Cutler: Staff Engineer at Pinterest, where he leads web platform initiatives supporting over 200 engineers. Jordan's career moved from junior to senior in just two years at Gusto, then through Qualified (recently acquired by Salesforce), and into the kind of cross-functional, multi-team leadership that defines the Staff Engineer role today: a role many leaders still don't fully understand. What makes this conversation stand out is Jordan's unflinching clarity about how AI is not just changing what engineers do, but raising the bar at every level of the career ladder. The mid-level engineer is now expected to do what seniors did three years ago. Juniors entering the market face a job board that has shrunk to under 10% of all engineering listings.

Full transcript

1h 0m

Transcribed and scored by The B2B Podcast Index.

Welcome to the Lemon Tech Leadership Podcast. My name is Alexander Leaminskam. I'm a former violinist turned management engineer, turned organizational psychologist, speaker and PCM leadership mentor and facilitator. In this space, everyone is invited to the table where we have real eye opening conversations about tech leadership.

Two keywords utility and real life implementation. Knowledge tools, frameworks, ways of working, dos and don'ts. Taking from my personal experiences as a leader in the experiences of others is what you are going to get from every single episode. This is the Lemon Tech Leadership Podcast.

Okay, so let's go and take some action. Oh yeah, and we are live with another episode of Lemontech Leadership Podcast. Today, I have very very special guests. General Jordan is with me today, Hydrogen.

Thank you for joining. Hey, so happy to be here. Yeah long Tino. See, so finally we get a jest to have this conversation.

So I really appreciate it, Jaran, I will do. I would love to for you to give us a snek peak of who you are, so for everybody who doesn't know you yet, if you can tell us about your career story where everything started for you, what happened over the I and where are you now? Yeah? So right now, I am a staff engineer at Pinterest on the web platform team.

I am generally leading directly like around three to five engineers at any given time, and then I'm also leading a bunch of cross functional initiatives having to do a developer experience, a lot of AI usage nowadays, but also kind of within the context of how we can improve things for web engineers. So we support over two hundred web engineers on the web platform and we just ensure that everything is as smooth as possible experience for them all their development flows, and that the entire website Pinterest is running performantly as well.

And then in terms of my career journey. I started at Gusto and I was there as a junior engineer and ended up growing pretty quickly to senior engineer after just two years. Then I wanted to join a bit of a smaller company for a bit more ownership, so I ended up joining Qualified, which recently just got acquired by Salesforce, So that was nice to see that they're heading, you know, some good success there. And after Qualified is where I landed on Pinterest.

So I've been at pinterest now for two years, so been really enjoying it here. My team is awesome, and it's. A great opportunity for just a ton of you know, impact, both for pinteasers and you know internally because I'm supporting a lot of internal users, so many engineers there. I would love to dig deeper into, I mean, your role right now.

But also something that I saw with any of presentation that you delivered last year and the infra Share conference that we we had a chance to meet, and you were talking about transformation of engineering teams, and so I remember because I talk about it all the time and I get inspired by you. So thank you for that how them we need to transform engineering teams regarding what is happening right now and more and maybe not right now per se, but it started a couple of years ago and right now we're in this transformation transition mode when we need to like get into the the change with how teams in engineering in engineering are are created.

So what kind of structure engineering team? And I remember the slide when you were saying that it was a junior meat and senior an orchid science and right now taking into constitution in your current for as you mentioned your stuff in right now, you show that the junior the junior, the meat is an old junior, and senior is old meat, and the staffing engineer is an old senior. So it'd love to dig deeper into into in this one because it is a super important thing, especially for people who are leading development teams, uh leading startups.

As you mentioned during a smaller organization, how to build those those teams that are adequate, I would say to what is happening from the tech perspective, from the job market perspective, and organization development perspective as well. So I would love to ask you what kind of changes do you you see as you're in the market as a developer for a couple of years now, I would say, And when you start as a junior, the world looked differently as right now when you're a staff engineer.

It'd be interested. So I would love for you to share with us what kind of change in a world do you see over these years and what kind of the second question is what kind of structure the engineering team needs to have right now to be efficient and to use their time, the tech stock, everything they have. And then the develop great products successfully what they need you to look like. So this is the opening.

Yeah, yeah, so I can I can speak to a little bit more about what I meant on that side, and also the structure of that I think would help. So for that side, really what I meant is that the expectations are now going to be raised, and you, you know, as leaders, I think should be able to expect a lot more from your engineers. There's going to be a lot more output per engineer that you hire, and not only the raw output, but the type of output I think is going to change too. So, you know, for my case, right like, I am currently sort of managing you know, people at different levels, like an apprentice who has just converted to full time and mid level as well soon coming onto the team, and my expectations of them three years ago would have been very different than they are today.

You know, I'm having some of those people lead things that I would have previously expected people you know, two levels above them to be doing, but now they're able to do at their current level with much less oversight from my end too, because I can also delegate and say, hey, you know, instead of you, you can still ask me things but here's the process that I would like you to, you know, use when you decide to bring it to me. First, you know, check with AI. See if that helps you, you know, figure out the solution yourself.

If it doesn't. Now you're able to give me a even more distilled, like high quality question than you previously would have, because you were able to at least get further or at least say, hey, this is what you know AI thought, I don't really think it's right here, so I feel like I need your help for these types of things. So overall, I think, you know, and leaders should be able to just expect more from their engineers and make sure that they aren't saying, oh, you know, you know AI is not really useful.

Things like that, Like figure out a way to make it useful, because there's a lot of ways. There's a lot of times where it will not be useful right now now, But if you're able to like maybe connect it to the thing that it needs, well, then yes, it will be much more useful. You know, Like if it doesn't have access to your GIRA and that's why it's it doesn't have this context that you needed to hook up the Gurra MCP you know, and then like it is so much more valuable, and then you know, you could kind of just keep on building these abstractions to sort of turn it into like a software factory of sorts where you know, most of the time the engineer is not really writing any of the code by hand, Like I haven't written any of the code by hand for me, you know, probably in the last couple of months.

Every once in a while, you know, you need to do like a couple of line change here or there, but it should generally be able to do most of it for you nowadays. So yeah, I'll start with that. Does that how does that resonate? Yeah?

I think it is. It is super interesting how you how you put it, because we can talk about how the situation connected to TAG you mentioned a couple of fine is influencing how teams are working, especially engineering teams are working right now, and how different I expectations to what they should create as a value of their work is shifting, right, So this is this is this is how you you create a team to build that kind of skills at mindset and toolset so people are able to you know, to raise to those expectations that you mentioned.

I so I can actually expect for people to use different tool sets to create a different, different result and to come to me with different type as I mentioned, the type of questions, or be prepared in a different way to start a conversation. And I think this is this is an important important part because I hear a lot of people are saying only about the skills, right, So this is this is how I use a certain tool, how I in what kind of context I use this, uh, this piece of tech or this piece of tech, And you'd say something more that I can expect something different from those people, not only from the skilled skills is perspective, but also from the mindset perspective, thinking differently and a different and decide having better decision making mindset and skills supquirted right, So the muscle of decision making should be different, but I think that it is not there yet many cases.

And before we hit record, we talked a little bit about how people still are threatened by that change, the tech change that is that is happening. Why do you think they they're scared of what is happening right now because it is strictly connected to the changes that we started to talk about, who are going to come back to them in a sec. But why do you think is happening in people's brains? I mean, I.

Think it is an incredibly fundamental shift to the way you have been doing things for so long. And I mean I'm sure I think you've probably done, like, you know, some psychology reading and things that like, you know, like people are just resistant to change naturally, and it's understandable, like it's something new you have to learn, and you know, you probably thought that your next couple of years would look a certain way, you know, maybe a couple of years ago or or maybe right now, and it's now sort of being forced upon you that it's going to look very different.

And I think it is kind of annoying too, you know, like I feel it, Like I it was kind of annoyed, Like I was telling you, you know, I just came back from like a couple of week break, and I just see there is an insane amount of problem bress that has been made across so many different initiatives. It feels overwhelming, you know, in a way. Because like there's just so much that's happening all the time, both like at your company and outside your company, and so I think it's kind of like an adjustment that people probably didn't really expect, but the reality is that it's here to stay.

So you have to pretty much adapt or you know, you're you're going to fall behind and those the expectations that we're just talking about are going to come and you won't be ready for them. And so you have to be, you know, staying on top of things and making sure you're you know, grinding your acts so to speak, and you know, improving your system your own systems and processes so that way you can become more efficient. And that's one other thing that I want to talk about too with AI is like I think a lot of people talk about like AI slop and it is a reality, but it's that's part of the mindset shift that you need to adapt to avoid.

I'm sort of constantly like thinking to myself, Okay, how can I make sure that this doesn't come out to be slop? Or if it is some level of slop, like where on the slider am I allowing it to land because I'm okay with it because for some reason like that is the pragmatic choice. Like let's say it's some piece of code that nobody is ever going to look at or it's like super easy to delete or something like that. I'm totally happy like with you know, shipping stop in that case of it if it proves value for the company and there's like very little risk in it being that slop.

But then at the same time, like there's so many opportunities that you can apply to ship something faster at higher quality as well. Like for example, nowadays I almost always have AI write my PR descriptions, but I'm guiding it into what is the story that I wanted to communicate now also telling it, Hey, add mermaid diagrams because GitHub can like rend natively render mermaid diagrams and add diagrams for like how it how the how the architecture changed, and then like color the parts that are different than they were before.

So that way it's really easy to see, you know. And it's like the Mermaid is super complicated in the PR description, but you know, no one cares about what the Mermaid like looks like. They just look at the actual image and it like looks so much better. And I would have never written it myself.

I would have maybe like described something. But that's like an example where you can, you know, ship something faster at higher quality. It would it took me, you know, longer just to write the pr description myself than it was to like prompt it and get like this insanely better output. So you have to make sure that you know all the people that you're working with, and you know the engineers that work for you as a leader are also adopting like similar mindsets to that.

Yeah, And from from the psychological perspective, it is it is also connected with the personality board. And I see it a lot of being being scared, sometimes not outlouds of course, people don't want to admit that they're they are scared or threatened. Sometimes they're they're talking about it openly, but most of the time because they want to feel competent in their job. And I see it especially people who have more years of experience in the area, and they, as you mentioned, they thought that the next couple of years or a decade will be quite the same.

So I put some automations, I know some you know, some languages, I'm good to with scripting with something, and it's going to be enough because it always has been enough. And right now that their identity is under under a huge threat because this is part of who I am and how I delivered my job. And for people who I see that, for people who weren't very close to what was happening for the last like three to five years, and right now they have it in front of their faces and they are, as I mentioned, they're pushed to change, to shift, to transform themselves.

It is extremely hard because they lose their part of themselves, part of their identity. So it is it is something that I see, and I think from that psychological but also from the organization perspective, leadership perspective as well, this is something that we need to address because without that, people are going to be lost. And hey, let's let's let's be honest here. If you are if you are fifty and you are thinking about getting retired and to you're web developer who was working for like thirty or thirty five years, in a certain way, it is it is hard to make that kind of a shift, right.

So this is this is this is what I see as one What do you think? Yeah, yeah, I absolutely agree. I think one of the challenges which I'm not sure I have the answer for, but I'm sure for you know, something that they're going to need to think about is how to communicate the value of AI while not attacking you know, that identity shift that they will be you know, they will have to make, and just making sure people can come along for the ride gracefully rather than sort of feeling, you know, so resistant to it.

So I don't I personally that's something I have not you know, needed to explore, because you know, there's plenty of leaders at my company that are kind of doing that. But I think that that would be something to have a playbook for if you could. I think you're doing it because you know, you're an educator as well. Right you mentioned that you work, and we're going to dig deeper into the stuff engineer world because this is new for people, and I would love for all of the listeners so to have some you know, some you mentioned briefly what you're doing right now, but in overall, whatever the difference is between the levels.

Right now as we are talking, we are recording it in the middle of May twenty twenty six, what is a new definition of a new meet senior staff engineer and where is the junior in all the all the puzzle because there are a lot of different discussions about engineers and how how they should go into the job market and how how big of a difference is their possibility to even enter or pivots to that to the market, and we're going to talk about it during the conversation as well. So this is this is what you're doing.

You mentioned that you're improving the web engineer's mindset, skills and the toolset, and so so I think you're doing it maybe you know and consciously from from from this perspective, but as you mentioned, the playbook will be will be quite useful to how to use different tools and think about because the tools, you know, you can always have more tools. More important is to see from my perspective, I'm super curious about yours, to see the process and seeing you to zoom out zooming and them out to see.

Okay, so I'm doing this. It takes me x amount of time and I need to shrink it to ony amount of time. How can I do it to from more from the process and the product perspective than from the tool perspective itself. What do you think how it can be helpful?

Yeah, yeah, I agree. I mean I think looking back on the experiences where I've sort of adopted different things that other people are doing. A lot of it is coming from learning sessions where you know, we have something like an AI guild now and people are sort of presenting every week and sharing, Hey, this is what I'm doing. I set up actually a channel at our company called how I AI, so I you know, sort of follow that and you know, people can contribute to that and say, hey, this is how I use AI to help me, and you know, making it kind of like a like a fun thing where people can just naturally stumble upon like little improvements that they can make, and then also just trying to make it like as easy as possible to adopt.

I definitely have seen sort of a like. Dichotomy between the engineers who have really good communication skills on sort of like the selling aspect and the ones who maybe they have those skills but they aren't really giving it as much effort. Let's say, so. You know, cases where someone will give you like a like a one line command to just automatically like you know, improve all the things that they're trying to sell to you basically, versus someone who kind of just like leads a lot with all the like technical implementation details and doesn't really make it easy to figure out, like how is this going to be useful you know, to me?

And like when would I actually use it? So I think trying to make sure that you're following those principles is going to be really helpful. And speaking about principles, what do you see is the new definition of the junior need, senior and staff engineer as you as you mention about yourself, taking into consideration everything that we talk so far about them, different possibilities, different tech stock, different options we have on the table right now to choose from who and connected with the expectations that you mentioned, who should be a person on all of those levels to be as efficient, as successful, as satisfied, as engaged as possible to deliver great results to the clients, to the organization, to themselves.

Yeah, I mean, I think what we're going to see is that the same that shift that I was talking about, where you know, the requirements of the junior engineer are going to become the mid level engineer. Mid level engineers are going to be expected to perform at senior engineer's senior as staff and so on. I think in general there's just going to be more expected at every level. I think it's possible that the expectations, like the the the high level identity is still the same and maybe you just expect more output.

Like for example, the way that I would frame like what a junior engineer role is that they require hands on mentorship and you know, in order to solve problems. But the difference at mid level engineer is that they can solve problems independently. Now, the question is is, like, will the requirements of junior engineer be that they can solve problems independently now because they have the access to AI, which can you know, significantly help them with that, or would it be that they can just solve more problems, not independently.

And so for me, I think it's going to be that, you know, the identity is going to sort of ladder up to the next one where you're going to see junior engineer's expectation be that they can solve problems independently because they have access you know, to AI. So but I could be wrong, but I mean, at least in my boat, that's kind of. My expectations for I am. I am, I'm still expecting that they will need some help, but a lot less help.

Maybe at the on the finish line. Right, so they can do a lot of work from the very beginning to the middle of the eighty percent of the on the job with AI, but then the twenty the last twenty thirty percent of the before the finish line is going to be more supervised, more consolid, et cetera. And the higher you are, the smaller than the last percentage from the finish line is maybe this is going to be more and more visible. And what is the most significant difference between senior and staff engineer from your experience because you've you've made it through the change, or what it should look like to see because I hear the people are not very familiar with the staff engineer role yet very much.

So I would love for all of those people who are not familiar with with the with the differences between because we we were talking for there's a senior and vendor's technic, right so, but right now there's this layer of staff engineer. So what is the main difference between both skill set? Mindset, tool set? Again?

Right, so, senior engineers, at least in the past historically, you know their job has been to take a problem from the beginning all the way to the end. Ship manager should generally not really need, you know, to check in on you. And then not only that, but I would say that you're a leader within the team, but your impact is mostly scoped to the work that your team does. At staff engineer, it changes to many teams, so you could kind of be working within like multiple sister teams pause different things like that.

You could be sort of outsourced to like a different initiative that is really important at the company. Like for me, for example. I ended up getting resourced to a sort of AI a pathfinders group where you know, company is realizing AI is going to be really important to figure out we need to set up some like fundamentals and I'm you know, having some knowledge shipping some things around the AI space. So I got you know, pulled in to help with that, set up some standards things like that.

So that is like an example of where a staff engineer might you know, come into play. Another thing that was helpful in me getting promoted, for example, was I identified that there was like these performance opportunities within the web app and they we needed to coordinate across multiple teams because you know, different ownership across all these different performance opportunities. So reaching out to those managers, getting resourcing for those initiatives, and overseeing and advising the engineers on those teams that ended up working on them to make sure that it goes smoothly.

So ultimately it boils down to expanding your scope outside of your team. Does that did I answer your question? Yeah? Yeah, yeah, thank you for sharing that.

And as you mentioned, a senior is a leader within the team. I would love to add that it is informal leadership, right, is not connected with being our team lead, but most of the time is a mentor. Was a mentor, right, So this is a person who can answer a lot of questions because of the expertise level and such trend as staff engineers and a senior at scale, I would say working with them different different teams can be a point of contact for different development teams or going into being a part of the initiative organization initiative for example, the project team.

They have different roles, et cetera. So it's more more complex than the senior itself. What about the juniors because we talk with different leaders. I talk with different leaders a lot and I also see what is happening on the market that if we take a look on the job offers, the juniors are shrinking month after month, and there's for the last two years it is more than it is less than ten percent the job offers.

That for engineers that are on the job market globally. Of course it differs from market to market, but most of the time I see there's something between six and nine percent of all job offers. Development engineering is for juniors. And there are a lot of different publications that, hey, juniors are deads, we are only going to recruit meets and above.

And there are a lot of old conversations about how on earth young people or people who want to pivot their careers should start in tech. So I would love to have your thoughts on this one. How if I would right now, I would love to change my career, stop being who I am and start being a developer. What I should do to start such a career, and what those young people after college, out of school, fresh but super eager to learn to be them in the in the engineering world, what should they do or what do you see in the market that is actually happening from the insight perspective.

Yeah, I mean, I definitely see a lot of the same trends that you're mentioning. I've seen some stories about it where you know, we're talking about like team like companies are going to suffer down the line or maybe the industry as a whole if we don't really have sort of that junior base that we're building up to become the next set of seniors. So it's going to be interesting to see how it plays out, and I really hope that it doesn't go that way. I personally do feel like companies should be hiring at the junior level, at least at the same level as before, if not more, because I think nowadays there is a lot of.

There's a lot of time where. You as a you know, someone in a senior position are able to make a lot more impact through AI because you're able to get something about eighty percent of the way there. But then there's kind of that the last twenty percent, which really takes like eighty percent of the time, which is all the like valid and kind of like manual like QAG effort and you know sort of like checking different edge cases and things like that, and like running all these things on your on your actual machine versus just like shipping the code.

Because like for me, and let's say my role, I can see a lot of the you know, the whole system, right, and I can see, okay, these are where the bottlenecks are. These are where we need to like ship the improvements. I can quickly spin up either like a proposal doc in you know, maybe like fifteen minutes now with Claude that sort of shows like what's the high level, like, Okay, here's the problem, here's the solution, here's what we need to do, or maybe even ship like a proof of concept pr in about the same amount of time, and it's like a working you know, working UI air quotes working.

But the thing is like, you know, then you need to kind of like go through all the normal engineering stuff that you would do to make sure that it's working correctly and all that. And so for me, what I've found is that it's really nice to have that opportunity to delegate at that one pager or proof of concept level and say like, hey, here's the proof of concept, here's the general idea. Now like let's expand this to all these different systems and now like replicate this process and then you know, you go through some of those manual like engineering basic engineering skill steps, but it takes a lot of time from someone who you know has done that, you know, thousands of times before and can now move on to the next like really high impact area.

So that's why I think, you know, we should still continue to hire juniors in terms of what a junior engineer should do. Now, I. The thing that comes to mind for me is showing that you have the skills to you know, just sort of hit the ground running and not need as much guidance as you previously would have a couple of years ago. Because that's my guess on why these companies are not really hiring juniors as much is that they're assuming, oh, like, if I hire a junior, I'm going to have to guide it to you know, guide them too much, and it's just going to take up too much time.

So you want to do everything in your power to you know, influence their thought to that being like not the case that you you will be fine if you just you know, hire me, give me a problem to solve, and I will figure out, you know, how to do it. And so one of the ways that comes to mind for doing that is basically building stuff yourself. Nowadays with especially with AI, you know, gives you the capabilities to do that, whether it's like web app or you know, mobile app or something like that.

Showing proof that you can do that and you did it on your own. If you're able to get users, that would be awesome. Another final point that I'll give is that I might not be the best person to answer it because I am like super far removed, you know, from that situation, and so I would recommend reaching out to people that you can find who are junior engineers at some of the companies that you want to work at, or mid level engineers and ask them that question what did they do, because maybe it's you know, something that I just I'm not really going to be able to think of in my position at this point, and I think you would probably get some pretty good advice there too.

I agree from the leadership perspective, when I'm thinking about my team and how I recruit, it is being self sufficient, I would say, and thinking actually using your brain. This is the most important thing for me, because if you are thinking logically and you can use your brain, you can think in a critical way. You can start looking for solutions and not bother quote unquote me as a leader in super simple questions that actually any AI whatsoever can answer you. You are my person, right, so we can we can, I can teach you anything.

You can learn any anything, but that this part of mindset, it is critical for me. Right. So this is as as you mentioned, you need to learn on your own. This is the world.

But we can be frustrated about it, we can be angry about it, but this is the life right now. So if you want to be in this industry, you just need to do a lot of things on your own. And and this is this is just the reality. And if you are not graveto to do it, it's maybe it's not the industry for you.

Because there is no not a short another shortcut we can we can give you. Right, So you need to do projects on your own, being in different initiatives, doing doing some maybe community work like the startup communities that are all anund the world that you can be a part of it. Build something with different people from scratch, probono. Hey, but this is the this is the beginning of the job.

They are not internship in organization anymore. Not a lot of them. But this is the internship outside of the organization that you are getting with the practice and skill that you mentioned, that you actually can show, you know, take conversation in organization in the recruitment process, that you can actually build something and it works and you know where to look at you to make it work if it doesn't work right now, So yeah. Yeah, absolutely, those are all really great tips.

Totally agree. Yeah, look at both of us. Weekn Actually my display book that you mentioned before, I would switch I would like to switch gears a little bit into what you said about education because as as we've met and you you were talking about how you you love to teach others how to use AI to to to increase productivity and actually increase productivity, not a buzzword that AI will save us all from unproductive time, et cetera. And and you mentioned about your role right now that you're doing that part of your job is to improving web web engineers in their skill set, ways of working, how they can be more productive and actually create great products on their own.

So what would you advise for engineers right now? And it is connected with leadership as well, because it is what leaders should do for their engineers, so they have an environment that they can actually use to learn and be the best version of themselves. What those engineers should use, should you do? Should learn?

Should think about to make the biggest progress, to build the best pieces of software products, to create a great experience for clients. What we should do right now or in the next couple of weeks, months, or a year to be that kind of engineer that is not going to get worried about their jobs and who they are from the identity perspective. So I think, so I heard the funny kind of phrase or like analogy. I'll give credit to eat the Evans for it.

But it's like, right now, engineers are racing to run off the cliff of essentially, you know, their job security, which is essentially like they are constantly adding more and more automation to make them as part like part of the process less. Right. So if you are, if you are like very far behind in that race, what that looks like is you're still writing like all the code you know by hand type of thing. If you are like very close to the cliff where you have you know, almost fully automated yourself away, then you know you might be doing something like I don't know, you have like a Gira taskboard set up or something like that or linear and you just like add tasks to it and you have like the full workflow set up where you can be like fully confident that claud is just going to like pull tickets from that queue and.

You you know it's it's gonna do it correctly. It's gonna ship the PR, it's gonna you know, there's gonna be like a code review agent that reviews the PR. There's like a QA process that happens either like in the CLI or in CI or something like that, you know, of whatever the change is, it has like a really good PR description all that stuff. Maybe you know, like is even writing like one pagers for this.

And and like reaching out to stakeholders for you or something like that. You know. But uh, that's that's the part I think where like AI is going to have a lot harder time replacing is kind of like this initial idea of like what to do and what is like importan what's high ROI. So I think if you're able to like build that skill of okay, I can like recognize these opportunities and then the implementation part I can just have my system set up in a way where as soon as I know what the idea is and I've got an alignment on it with the right people and I know that it's a good idea, then I can pretty much have it chipped, like not almost since you know, not instantly, but like like ten times faster than you would have before, and then you can move on to the next idea and then you just you know, repeat the process versus you know, don't do like where you're still spending like all that time like handwriting all the code and all that stuff.

Your job as an engineer is definitely changing now. Before you know it was it was still a lot of like talking to people and it was probably like equal parts coding, maybe more coding. But now I think that ratio is going to shift. And so you know, follow along all the you know, top newsletters, maybe a couple of people that you really like on LinkedIn that really you know, you feel like you actually learn something from You get like actionable tips from things like that.

Incorporate those things in your workflow, Identify things where you find yourself like constantly repeating yourself as well, and then try to figure out. Some way to automate it. A lot of the like AI tools nowadays, they give you tons of ways to basically just ask it, you know, to automate this thing for me, so the next time, like I'm good. You know, there's like cloud hook, skills, agents, files, you know, linters, ci checks like all those types of things you can add so that way, your your whole like system gets compounded and improves over time.

Yeah, and I think what is and what I see from my perspective as well. You know, I'm no web developer. I'm an engineer from my first degree, so I'm in the backet as well. But what I see from my perspective of using AI is that you need to have a great base for it.

And don't be mad that it gives you crappy results when it comes to your your prompt because it needs to learn and it needs to have a great base infrastructure to learn from. So it gives you those results that you're talking about during our conversation, because you're talking about high quality outputs that it gives you, and it's it is not you know from the air. It needs to have great database sources of truth, access to the secured access to to the to the files that you that you put put in there, or if it uses different different tools that they and that's it's it's it takes data from It is important for for for the prepared.

I think it's super super important for us to say it out loud that it is not going to work from day one because it is a toddler from at the very beginning. It needs to it needs to learn how to how to crawl, and then how to work and how to run so it gives you the results that you're talking about a different end. Yeah, absolutely, Yeah. I mean I've been doing a lot more like side project development than I have in the past.

I typically like would not really do any coding outside work before AI came along because I'm just like, so, you know, exhausted from like how much you know, energy I put into work that day. I'm like, I can't look at code anymore un till tomorrow. But nowadays, like you know, I don't have to look at the code. But at the same time, like I will say, there has been so much that I have that I have had to set up over the course of the last four to six weeks now where I've kind of been doing a lot more side project stuff.

So yeah, you definitely, I totally agree. You can't expect it to give you perfection initially, but it is a skill to I think, keep figuring out where is it getting things wrong? And how can I improve the you know, the software factory, so to speak. What is the right place to put the thing to make sure that this never happens again?

And do I put it in you know this one place? Do I put it in multiple places? How do I optimize you know, the context window, all those types of things? And you know, once you get it going, then it's insane, you know, like how much you can ship.

Like I had this idea for like a you know, an app, and I was able to basically put together like an. MVP and just. You know, a couple hours because it had all these other really great apps already set up architecturally where it could just copy a lot of those you know, same things and the foundations over and you know, it works smoothly because it has really a really good base to follow. Yeah.

True, And talking about identity that that we we we've took about, I think this is connected with the skills as well, as you mentioned, and you mentioned the ideation and face. That's uh it is. It is not writing the code manually anymore. It is more about figuring out recognizing the patterns or where a certain piece of software, for example, can help for users clients.

It's internally. Externally it's whatever you're working on. But you need to have a different piece of a new different piece of skills at the mindset connected with the creative creativity, critical thinking, process, thinking, the dooming, zooming out to see more in using different lengths. And I think it is not going to be for everybody because this is harder learn than learning how to code.

What do you think? Yeah, I mean it's definitely a difficult skill, but it is I feel like it is learnable, and I think it should be. Applicable to almost all career. Not almost all careers, but I think a lot of other careers, especially like knowledge worker careers.

So if you've you know, if you are in some other kind of knowledge work and then you want to transfer over to engineering and you have built that skill, you know you should be able to like transfer it pretty easily. Like for example, I think more than half of my ideas come from seeing people complain about something, and it's like that's the easiest, you know way to just like ship more things that are high impact. It's like you literally see people are complaining. Yeah, you're just solving real problems, right.

Yeah, exactly right. And so you know, if you just like focus on those types of things, you're pretty much half of the way, which is like, you know, that's not much of a skill that you need to to build past that. But then you know, of course there's there's things that are kind of hidden under the surface, and you know you need to make like different connections here. They're oh, okay, what if we piece this thing together to this thing together to solve some problem that they don't even know that they have, or you know, something like that.

But the other aspect of it I would I would say, is like what are people doing that they might not be complaining about, and where are the bottlenecks? You know, in that process, a lot of people might be used to some thing that they're doing taking a certain amount of time, like ten minutes, and you know, meanwhile, there could be some sort of solution out there because you read, you know, some article from Adios MONI, you saw some Google doc from your VP, and you use the tool five years ago, and you realize that all three could be combined to cut that ten minutes down into three minutes.

You know, Like so if you're able to like make those types of connections, that's that's the heart. That's definitely in the harder range. But you know, you have to realize to be looking out for. It constantly solving as a examples, to actually listen to what people are whiting about and then solve those problems.

But it requires that the problem solving skill as well and actually listening to people and it will here you go with the people's skills and business skills. And this is quite different, right from from the role where you just get the the the list of things that you need to implement or develop within a code. And this is pretty So I just wanted to compare the all to the new that uh and the beliefs that people have about the engineering job that it is not about as you mentioned about the colde and only the colde anymore.

It is about the code, but there's so much around the code that it actually becomes a different role. So it is interesting times we live and to observe how it's going to shift as well. Yeah, absolutely, yeah, I would also say, like something that I think I didn't realize for a while in my career, and I think probably a lot of people feel this way too, is that you often just do sort of like what you're handed you know, to do. But if you think about like the context of the whole company, right you are in you know, a team, there are many teams, and then there's like you know, multiple kind of like levels above that, and like every single level has goals, and so you could theoretically just keep yourself scoped to whatever it is that your team or your manager or your tech lead is like assigning to you, or you can like you know, gain a third eye and you can you know, look outward either to the side or above, you know, above your team.

What are what are those goals? Like what are the opportunities in those areas? Are there areas that you're interested in that you could explore more? That you could ask your manager, Hey, I saw that there's you know, this was a priority, and I have this really good idea that could be like really huge impact.

What do you think and like if. You're able to get that done because you saw like certain connection, you know something over here, some tool that could be incorporated or something like that. You're able to ship that that makes your manager look good, you know, so they're going to be you know, on board with that, even if it's not necessarily like what they what they had planned might not happen immediately, but you know, oftentimes I'll have situations like that, I'll be you know incorporated in the next quarter or something like that, and that that type of thing can be the case for your promotion because you're going out of your way to find what's the next best thing that we could do, maybe even better than what we thought that was, you know, was the best thing.

Well, the thinking, I would say, so people who don't like to think and the words just makes me you super hard for them starting right. Now, Yeah, definitely, Jordan. I have a couple of questions within the light in front for you. Ready, yeah, I'm ready.

Okay, what is the worst leadershould behavior that you've ever experienced? No names, but the behavior that you you would like to you know, for all of the engineers in the world to avoid, to be prepared for, to have a shield over their heads, to not to not even you know, need to think about it. So this would be like kind of like a manager doing this or like a tech leader or something like that. Yeah, yeah, yeah, oh okay.

I mean I don't think I would have anything like super drastic. I mean, you know, there could be like a little bit of micromanaging here or there, you know, something like that. So I mean I would probably just go outside of my own experiences to like what i've seen, you know, kind of like in the just out there in the industry. Or one thing that I think leaders I've seen happen recently is they are optimizing for the wrong metric.

So every metric often has like an input and an output, or every goal kind of has like an input and an output metric, you know, like right now, what I'm seeing be a problem is that leaders are optimizing for things like which engineers are using more tokens, you know, to see like how how is AI adoption coming along? Or like are which engineers are the best engineers because they're using more tokens. And then I'm sure you've seen like you know, uh, Facebook or Meta, they they had people literally spending like tens of thousands of dollars on like infinite loops basically with AI while they're sleeping or something like that.

Just to hit the top of the leader board because you know, they like they tried to optimize for the wrong metric. So you know, making sure that you're trying to connect these things to the right outputs that you actually want to see, because people will optimize whatever it is that you make as their incentive, so you know, make sure you have something that doesn't cause stuff like that. I think it's probably a big one. Yeah, I agree, yes, And I'm laughing because I see all the time when people start to learn how to use different KPIs or different metrics and they measure something and they don't think about.

What kind of value actually it actually brings to the table. And I see when, especially when people start using ok rs, they the key results are, for example, the number of books that they read or the number of trainings that the participate in. And I'm like, okay, so what So it was like it is one of the word but it has a number, Alex, and I'm like, hey, yes, it has a number, but it doesn't it doesn't really show you what kind of progress you've done because you can read a hundreds of books and implement nothing, so nothing changes exactly.

So yeah, I'm with you. On this one. Yeah, what is what is the one thing that you wished you knew at the verb beginning of your engine and joy? Let's see.

So something that I've been doing recently that I wish I knew more like to do more of is try and create like the foundations where it sort of grows by itself and lives on and like constantly like compounds to create impact because you created some sort of like platform or foundational level thing and you know, this could be like this could be a technical thing, but it doesn't have to be a technical thing. Like for example, like one non technical thing that I did recently was that that channel, like the HOWII channel.

You know, I saw there was a trend of like people doing like lots of AI stuff. There wasn't a place to put you know, how is everyone using it? How can we all learn from each other? And then I made that channel and then like it grew ten x to now like one of the most popular channels at the company, and like you know, people are constantly sharing it and now it like runs on its own.

And then like from a technical perspective, I try to do the same thing now. So I'll try to like notice a problem and then see how can I make it so like I can set up some sort of foundation that like people can hook into and then it just sort of naturally just keeps making more impacts. So I made this like platform where people can kind of set up like their configuration parameters to like auto run and migration. And then you know, now like people are just shipping you know, tons of prs and then like you know, different initiatives or finding out about this.

All I have to do is basically say, hey, did you know that there's this tool that exists? And you know, then I can like get attribute like insane impact because now they can use this tool that you know basically just automatically does their migration for them. So I think it's just like a way to make lots of impact, whether technical or non technical. What is the source of knowledge for you?

Where do you learn? What is something that you may be read recently or it can be a book, it can be an article, can be a report, or maybe just a source of truth that you're using in daily basis. We're talking about learning a lot during your conversation, So I would love for you to share with the audience the sources of knowledge for you, how how you learn? What's what do you do for your own learning?

Because this is what we talk about today. Yeah, So if I were to name one book book that has been insanely helpful, I would say Radical Candor for me, because before that I didn't really know how to give feedback effectively and I felt and I feel like after reading it, it just made it so much less awkward, like I could just I realized that I could just kind of say what I'm thinking, but do it in a respectful way and people appreciate that versus before I think I would have just constantly like danced around it and like feedback sandwich shit and all that stuff, and you know, it's it's a lot better of an experience now.

And then regularly how I learn is I have I'm just subscribed to like a lot of different newsletters. Then I also set up this recent I set up this workflow with Claude where reads my you know, emails for the week and then gives me like a nice little like digest of all the key insights and things like that. So I've been using that. So I don't really even have like this this you know, particular newsletter because its kind of just like condensing everything for me.

And then you know, telling me about like all the different tools. But I will say that that workflow of having newsletters that I subscribe to gain some insights figure out oh there's just like you know, a thing that we could use at the company, that has definitely like been a huge factor in my career growth because like my knowledge source has not just been scope to what is happening at the company. It is what is happening at the company, what is happening outside the company, And then can any of that stuff that's happening outside the company be brought in to the company, and then like if I'm the vehicle to make that happen, that is impact and that you know, impact basically.

Drives your career growth. So you know that that has just been a huge part of that and I think I'm gonna keep doing that for the rest there was of my career. I love it. I love the insight about Claude condensing the insights from the gess letters because I have so many newsletters that I love, but I my brain is sometimes not very able to do it.

I'm you know, I would love for it to have a skill to condense the video as well, because I have a lot of different webinars that are recorded and you know they are in my inbox in you in a special folder to watch and uh and maybe this is something that they can. Also to do it. It'll it'll figure out a way. Yeah, yeah, yeah, totally totally.

Jordan. I love the conversation. Thank you, Thank you very much for joining me. And for those people who would like to connect with you to ask you maybe some additional questions to to send you a d M.

What is the best best place to to to find you? Yeah, LinkedIn would be the best. I think it is Jordan culor one, but you could probably just search Jordan color and should show up there. We are going to put linked to or linked in the show notes so everybody can just click and connect with you.

So think it was fun. It was great to have you show. Yeah, thanks so much, Alex is so much fun. Really appreciate it.

Thank you and the caureful listening. We hope that the conversation was insightful, interesting and useful. This is the most important thing for us always to give you and give you something that you can use on a daily basis. So everything that we both shared just to take away and use in the real life.

This is the world that we are living and we are going to live in and for for for a long time. I would say so thank you for listening, uh and share the link with somebody who might use it.

More from Leman Tech Leadership Podcast

All episodes →
  • #174 | A-Players, Task Monkeys, and the AI Reckoning w: Francis Brero (VP AI Strategy @HG Insights)69 / 100
  • #173 | Tech Leadership Q&A: How Do I Get My Team to Just Do Their Job Without Checking on Them Constantly?46 / 100
  • #172 | What Silicon Valley Taught a Tech Analyst About Marketing, Authority, and Never Burning Bridges w/ Mark Vena73 / 100
  • #171 | Tech Leadership Q&A: Am I Actually Good at This… or Did I Just Get Lucky?47 / 100
  • #170 | From Startup Garage to Microsoft MVP: How Continuous Learning Builds Unbreakable Tech Leaders w/ Amit Chandak, @ex-Oracle, @Kinerika74 / 100
Explore the best B2B Leadership podcasts →
All Leman Tech Leadership Podcast episodes →