A recent Sudo Make Me a CTO community call sparked a debate that I haven’t been able to stop thinking about.

The topic for the deep dive session was how the role of engineering leaders should evolve in the age of post-ZIRP and AI hype?

One specific aspect of the discussion is what piqued my curiosity the most.

It’s a hiring conundrum that every engineering leader is, or soon will be, facing.

Let's start with a true story that was shared in the call.

Bob (not the real name), a senior leader at a fast-moving scaleup, is hiring for a software engineering role. When reviewing the take-home assignment with two candidates, he notices they seem to be at the opposite end of an imaginary continuum:

• Candidate A has completed all the mandatory parts of the test but not the optional ones. During the walk-through interview, he displays a deep level of knowledge and expertise. The candidate can explain the choices made in the code, can reason about alternative solutions, and discuss explicit tradeoffs. In essence: a solid and competent software engineer. This candidate has developed the solution completely on their own, without any AI assistance.

• Candidate B completed all the optional parts of the test, in addition to the required ones. They leveraged AI throughout the whole work, which made them perform better from the narrow perspective of the take-home assignment: they got more done in a shorter amount of time. During the walk-through interview, though, they show a complete lack of understanding about fundamental concepts. They're unable to reason about the pros and cons of their approach (or the AI's approach) and seem unable to come up with alternative takes on the problem at hand.

Bob ended up not hiring either of the two for reasons that go beyond the scope of this article but was left wondering about the dilemma:

Who do you hire? The seasoned expert with deep domain knowledge who is hesitant about AI, or the junior, AI-native enthusiast who may lack fundamental skills but churns out code at an impressive speed?

This question sparked a rich conversation in the group, covering many diverging views.

One member noted they wouldn't hire someone who outright refuses to use AI, framing it as a red flag for a stagnant mindset.

Another pointed out that more code equals more problems, or in other words, code is a liability. A lot of engineering excellence lies in simplifying systems and removing complexity. Adding to it is the easy part.

Someone else brought up the question of individual vs. mandated choices when it comes to productivity: the same logic that some seem to apply to AI-assisted coding tools today used to apply to the choice of editor or IDE a few years back. Should we mandate everyone to use the same tool (VSCode, IntelliJ, Borland C++, or whatever), including those 2-3 people who are extremely productive with their heavily customized Vim or Emacs setup? Or should we leave it up to each individual person to select the setup that makes them more productive?

This led to the endless question of how to even measure the productivity of individual software engineers. A problem that is currently not solved, despite the claims from various vendors. What's more, the jury is still out on the real impact of AI on software engineering productivity. The most recent DORA report on the subject is a good read for anyone willing to educate themselves on the subject.

What the latest DORA report says about GenAI and Software Development Sergio Visinoni · Apr 23 Read full story

Like Bob, I've been thinking a lot about the hiring dilemma he recently faced.

It's one of those cases for which it depends seems like a sensible answer.

Yet, if I had to make a decision based on the limited information I have on the case, I'd have a clear default answer: hire the hesitant expert rather than the incompetent enthusiast.

The only major exception to that would be the case where the expert shows reluctance to learn anything new, lacks a growth mindset, and refuses anything new by design.

But let's break down the thinking behind the suggested default approach.

High uncertainty around AI tools

If you have enough brain to read beyond the overly enthusiastic claims from vendors, LinkedIn influencers, and true believers, the reality is that almost 3 years after the first launch of ChatGPT, the jury is still out on whether AI-assisted coding tools are a net positive, neutral, or even net-negative contributing factor to the murky world of engineering productivity.

It's the realm of vanity metrics and anecdotal experiences at best.

What can help immensely on prototyping new ideas could cause more harm than good in massive legacy codebases. There are still security, privacy, and legal concerns that remain unresolved.

All major Gen-AI vendors are operating at a loss. We've already seen price increases lately, and we can only expect these to become even bigger in the months to come, as investor pressure will push more vendors to aim for profitability. Most companies will probably run out of money before they get there and will be acquired or shut down as a consequence¹.

Ultimately, there is no real first-mover advantage in tech.

Combining all of the above - unproven results, price volatility, potential high churn among vendors, and lack of first-mover advantage - it feels at least a bit too premature² to stop hiring people with solid fundamentals and skills that have always been at the core of the industry and replace them with entirely new skills that might or might not turn out to be as relevant as some would like you to believe.

Impacts on motivation

If you have been reading this newsletter for a while, you should know about self-determination theory and the work of Daniel Pink on intrinsic vs. extrinsic motivation.

Mastering Team Autonomy: A CTO's Dilemma Sergio Visinoni · March 13, 2024 Read full story

Two of the three known drivers for intrinsic motivation are mastery and autonomy (the third being purpose). Mandating the use of certain tools, no matter what they are, is an effective way to reduce the perceived autonomy of a software engineer. While there is benefit in standardization as a means to make interactions and collaboration more effective, there is less evidence that the same applies to individual productivity. As mentioned earlier, forcing everyone to use the same IDE might not have a significant impact on productivity, but it will likely make a few people feel disempowered. Even more so if they were recognized as highly productive with their own setup.

Mastery is another potential challenge.

We don't have enough distance to be able to observe long-term effects, but there has been plenty of research coming out lately on the negative effects on cognitive abilities linked to over-reliance on AI tools³. As the software engineer becomes more of a specs writer and serial code reviewer, how will that impact their ability to develop deep expertise in certain areas? And how will that impact their motivation as professionals?

Pragmatism

Finally, not all skills are born equal. Or rather, some skills are easier to learn than others.

Given the abundance of self-proclaimed AI-coding or vibe-coding experts taking up valuable real estate on the LinkedIn feed, it's safe to assume that learning such skills isn't that hard.

It's likely easier for a seasoned software engineer to proficiently learn how to leverage AI-coding assistants in their workflow than it is for a very inexperienced AI-coding practitioner to learn and use programming fundamentals and principles of software engineering.

The upskilling cost in the two scenarios is simply not comparable, assuming both persons show the same willingness to learn, of course.

I assume that all readers are smart enough to understand the difference between a default rule and a rule you apply in every single case. There are definitely situations in which I would instead hire the scrappy AI-driven developer who doesn't know what a syscall is, but those would be obviously exceptions to the default rule.

Come and share your views in the community!

Help the newsletter remain free!

Engaging with my professional services is a great way to ensure I can continue dedicating many hours each week to producing what I hope to be high-quality content.

Those services revolve around three legs:

1. Fractional CTO or Advisory roles for startups, scaleups, and established tech companies. Find out more on this page.

2. Individual Mentoring and Coaching for Engineering Leaders. Find out more on this page.

3. A paid Community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.