Embracing AI: Transforming Engineering Management for the Future

AI is coming for us. Three to five years from now, software engineering will be radically transformed. Code monkeys – i.e. engineers who merely pound out one task after another – will be less valuable as Copilot and its ilk get ever better at generating complete functions and classes. Instead, the more experienced engineers will see their productivity increased tenfold as they learn to leverage the AI’s strengths and fill in for the weaknesses. The brunt of human work will shift more to system design and stakeholder interaction, i.e. translating ambiguous requirements into working software.

We’re already seeing prompt-driven engineering become increasingly prevalent. Numerous devs on LinkedIn have talked about shifting away from from-scratch coding to prompt-assisted coding, and studies by Microsoft have shown that devs already see a major increase in productivity when coding this way. 

Software Development as we old-timers have known it is going the way of the dodo. 

All this creates some interesting challenges for the Engineering Manager. How do you motivate your engineers with this Sword of Damocles hanging over their jobs? How do you set them up for success in this looming future?

This article is not about technology. It’s about values. Tech is ephemeral and will only get more ephemeral as coding assistants get more powerful. But no matter what happens with the actual tech, jobs are still primarily about people, and people value… values.

Ownership

As an EM, this is a primary value you should instill in your team. Ownership is the difference between caring and not caring about the outcome of your work. It’s the difference between an inventor and a code monkey. It’s the difference between having a job five years from now, and being laid off in the Great AI Purge.

Ownership also has a great way of separating the rock-star engineers from your average ones. Rock-stars will exhibit ownership through a consistent cycle of idea-drive-execution and will frequently find ways of upleveling your product in a way others hadn’t thought of. AI isn’t good at those things, and given the amount of ambiguity involved, isn’t likely to get good at them anytime soon. As one engineer put it: customers themselves don’t know what they want. How’s AI going to solve that?

Ownership begins with empowerment. Your directs cannot feel a sense of ownership if they don’t feel like they have a voice in your product’s development strategy. So the first thing you need to do to promote ownership on your teams is make sure your team members feel empowered to change things they see as going astray.

This can come in many forms. Tech debt is one of the most obvious: when an engineer comes to you with a suggestion for tech debt reduction, take them seriously. Work with them to find a way forward for their idea and give that engineer ample credit in public.

The same applies to working cross-discipline. The more often your engineers collaborate (not merely interact!) with PM, the more understanding they have of the business drivers for your product, the more informed the suggestions they bring forward will be. This isn’t just great for their future job security; it also brings immediate value to your company.

Finally, delegation is a terrific tool to promote ownership on your teams. For any story that lands in my team’s backlog, I have one engineer be the “story owner.” It’s their job to collaborate with PMs to define the story to the degree needed for execution. It’s their job to take the initial pass at system design for the story, to get that design reviewed with the team, and to make any changes necessary. It’s their job to then thin-slice that design into small, 8-hour long tasks, identify parallelization opportunities, and then drive the team to execute on the story.

All those tasks have typically fallen to EMs or to tech leads. I make it a point to make sure every developer on my team, no matter the seniority level, acts as a story owner at least a couple times a year. The rest of the time, they’re part of a swarm on someone else’s story. 

Getting this experience has done wonders for instilling a sense of ownership amongst my team members. It will do the same for your team, too. 

Being Proactive

Going hand-in-hand with ownership is the value of proactivity. This is about doing things without being explicitly told to, about reaching out beyond the scope of the immediate team, of looking to make an impact beyond the core role expectations. 

This approach to work doesn’t happen by accident. Just like ownership, it must be developed through constant prompting. On my teams, I’ve asked my devs to allocate blocks of time (usually 5-10% a week) for doing things they are not expected to do, and just say, in the next day’s standup, that they were doing above-level work. Not everyone takes advantage of this, but those who do learn the value of proactivity as they engage in it. This, then, translates into proactivity throughout the week, which is precisely the mindset I’m trying to encourage. 

Why is being proactive so important in the age of AI? Because being proactive is one of the things AI isn’t great at. At least for now, the technology is primarily reactive. It gets prompted and produces a result. Even as it’s able to handle prompts of increasing complexity, AI will still struggle with consistent, everyday proactivity. But without proactive individuals driving your business forward, it will wither. So, the need for those individuals will remain as great as ever, even as AI absorbs other part of their jobs.

Being Curious

This one goes without saying. Those who stick their head in the sand, pretending the tectonic shift in the nature of our work isn’t happening, are going to be buried in sand. Like it or not, change is here, and all we can do is embrace it.

Encourage your ICs to get curious about AI, to experiment with it. Find and recommend classes they can take. Look for ways to integrate AI into your team’s workflow. (Though be careful about protecting your company’s IP if you’re going to be using a 3^rd party coding tool; at the very least check with your IT department about what’s allowed.) 

At my current workplace, we’ve organized a multi-day Hackathon focused on Gen-AI technology and encouraged the engineers to take classes beforehand and to participate. The experiment produced multiple compelling prototypes that will be working their way through our product pipeline.

These conversations should be happening at all levels in your organization. They should be happening between you and your directs, between you and your manager, between the technical teams, and so on. Jumping on the AI bandwagon is a strategy, not a tactic, and as such, it needs to be coordinated across the organization. But it all starts with being curious.

Conclusion

The AI revolution is here, and it’s up to us managers to ensure that it benefits our teams instead of demoralizing them. I hope that cultivating the values I’ve described above will be useful for your directs, not just in the realm of AI but for general career growth.

What about you? How does your org plan to leverage AI? What sort of disruptions to your engineering workforce have you already seen, or are planning? Join the discussion!

Check out our new free Engineering Manager Priorities eBook!