#7

Managing Software Teams in the Post-AI Era with Fabrizio Romano

From lean organizations and AI tools to Gen Z teams, the software team manager’s job has changed. Here’s how to lead without losing touch and decide whether you want to move into management.

Workshop: Unpack OWASP Top 10 LLMs with Snyk

deep-engineering-7-managing-software-teams-in-the-post-ai-era-with-fabrizio-romano-img-2

Join Snyk and OWASP Leader Vandana Verma Sehgal on Tuesday, July 15 at 11:00AM ET for a live session covering:

✓ The top LLM vulnerabilities
✓ Proven best practices for securing AI-generated code
✓ Snyk’s AI-powered tools automate and scale secure dev.

See live demos plus earn 1 CPE credit!

Register today

Welcome to the seventh issue of Deep Engineering.

The software manager’s role is being remade—less by choice than by necessity. The old playbook, where managers translated product priorities into sprints and stayed one layer removed from the code, no longer holds. In 2025, development managers are navigating leaner organizations, AI-assisted teams, hybrid work models, and a workforce increasingly shaped by Gen Z expectations.

To understand this shift and glean best practices, we spoke with Fabrizio Romano, author of Learn Python Programming and development manager at Sohonet. We also examine what the transition from senior engineer to manager really entails—and how to know if that’s the right move for you. Throughout, we draw on Romano’s experience, alongside insights from other engineering leaders like Gergely Orosz, Mirek Stanek, Nick Centino, and Vladimir Klepov, to unpack the changing traits, tensions, and tradeoffs of modern development management.

You can watch Romano’s complete interview which covers both his experiences with Python and as an engineering manager and read the transcript here, or read on for an engineering management focussed deep dive.

deep-engineering-7-managing-software-teams-in-the-post-ai-era-with-fabrizio-romano-img-3

Sign Up |Advertise

Leading Software Teams in Changing Times with Fabrizio Romano

While a desire to nurture growth in others is crucial to success in management, the evolving landscape of software development today brings a set of external challenges that shape how development managers must lead. As Romano suggests, becoming a development manager isn’t just about mastering technical skills, but about understanding and adapting to the broader trends reshaping the industry—particularly in a post-AI world. The role has become more complex and dynamic than ever, influenced by forces like leaner organizations and teams, more millennials and Gen Zs in the workforce, remote-first work, and AI-powered development tools, and an increasing focus on efficiency over expansion. These shifts have led to new expectations for managers, testing their ability to balance people development with technical leadership.

The Current State of Development Management

The post-COVID world is seeing significant changes in how development teams are structured, with many organizations flattening their hierarchies to reduce layers of management. This shift to leaner teams, combined with the increasing use of AI tools like GitHub Copilot, Cursor, and others, has led to new challenges for development managers.

Leaner Organizations

As Mirek Stanek, PL Engineering Site Lead at Papaya Global points out, one of the most profound changes in development management is the trend towards fewer managers and a greater emphasis on individual contributors (ICs). In organizations where budget cuts and performance metrics dominate, managers are now expected to maximize the productivity of their teams with fewer resources. This is in line with Amazon's directive shared in a letter from CEO, Andy Jassy, to employees in September 2024, to increase the ratio of ICs to managers by 15% by Q1 2025. This shift reflects a broader trend where leadership roles are being scrutinized more heavily, and managers must justify their position by demonstrating tangible value to the organization.

The hands-on expectations of development managers have therefore increased. In previous decades, a manager could expect to focus on strategy, vision, and team alignment, while ICs handled the bulk of coding tasks. Today, however, many engineering managers (Ems) are expected to stay deeply involved in the technical aspects of development. As Vladimir Klepov, EM at Ozon Bank, discusses in his reflections, a manager who is disconnected from the technical work risks losing touch with the challenges their team faces on the ground. Therefore, hands-on leadership—being embedded in the development process—is now a critical competency for effective development managers.

Managing Gen-Z, Millennials, and the New Workforce Expectations

Another change reshaping development management is the increasing presence of Gen-Z and Millenials in the workforce. According to Elizabeth Faber, Deloitte Global Chief People & Purpose Officer,

“Projected to make up roughly two-thirds of the labor force within the next few years, Gen Zs and millennials are likely to be a defining force in the future of work—one that looks less like a ladder and more like an interconnected web of growth, values, and reinvention.”

Stanek also points out how Gen-Z values work-life balance, professional growth opportunities, and authentic leadership.

Concluding from the 14th Deloitte Global Gen Z and Millennial Survey, Faber writes that, for Gen Z and millennial workers to feel truly supported and fulfilled, managers must be empowered to support employee well-being by:

Addressing team stressors
Promoting work/life balance
Recognizing contributions
Enabling growth
Facilitating access to mental health resources

For development managers, this means adapting leadership styles to align with these expectations. Managers must be more emotionally intelligent, open to feedback, and flexible in how they structure their teams.

This also reflects the broader trend of remote and hybrid work models. While some companies, like Amazon, are pushing for a return to the office, many development managers will need to navigate the challenges of managing a distributed, remote-first workforce while ensuring cohesion and a sense of purpose within their teams.

Working with Distributed and Diverse Teams

Managing teams split across cities or continents adds its own set of challenges – and opportunities. Stanek writes,

“The pandemic showed us how teams can function effectively remotely, but it also highlighted the limitations of remote work, such as the lack of nonverbal communication cues and the blurring of work-life boundaries.”

Nataliia Peterheria, Operations Manager, Django Stars, recommends the following practices to overcome dissonance in remote and hybrid team setups:

Choose one primary communication channel (e.g., Slack, Google Hangouts) and stick to it to reduce information loss. Supplement with one or two backups only when necessary. Every team member should maintain a complete profile—with a real photo, job title, contact number, and bio—so others can quickly understand roles and reach out when needed.
Set up a single “source of truth” for documentation and decisions—like Confluence or a shared wiki—structured simply (no more than three nested levels). Keep specs, requirements, and changes in one place, and annotate directly on the relevant topic pages to avoid fragmentation.
Create a structured work schedule with overlapping hours for live collaboration. Use this shared window for time-sensitive interactions like team calls or joint problem-solving. Schedule overlapping meetings in advance, prioritize ruthlessly, and stay consistent to avoid drifting into 24/7 work mode.
Use daily checklists to track questions, progress, and blockers. Organize them by project and link them to your source of truth or project repo. Checklists help ensure timely answers and keep asynchronous work from stalling.
Standardize request communication to prevent missed inputs. Assign a single person (often the PM) to collect product owner requests, or reserve regular meeting slots to introduce new requirements to the full team.
Require approval for all logic changes or scope updates, no matter how minor. Even well-intentioned “improvements” by developers must be signed off by business stakeholders to prevent misalignment or scope creep.
Define escalation paths clearly. Publish a diagram showing who is responsible for what and who to contact when something goes wrong. Team members should know exactly how to escalate unresolved issues—internally or with the client.
Align on a common task tracking and documentation toolset before kickoff. Avoid fragmented tracking (e.g., team members using their own spreadsheets). Centralize around one system, even if it means switching from a personal favorite.
Codify remote technical workflows. Set clear guidelines for pull request handling, commit hygiene, and review expectations. Include code style guides to prevent inconsistency and ensure maintainability when multiple people contribute to the same codebase.
Assess technical readiness before the project starts. Identify gaps in tooling knowledge, run onboarding sessions where needed, and provide up-to-date guides for any systems that require self-service support.

In addition to these, there is the human side to management. Romano describes watching body language and Slack message tones for signs of stress in his team. If a developer seems off or tensions are brewing, he takes time to talk one-on-one and understand the issue. In some cases, he even teaches simple meditation or mindfulness techniques to help his engineers re-center under pressure. “When you’re upset, frustrated, or angry… it triggers a fight-or-flight response… If you keep stimulating that state… it becomes a health risk,” he explains, drawing from his experience in martial arts that a “relaxed mind is a creative mind.” By coaching his team in emotional intelligence and stress management, he not only cares for their well-being but also ensures they stay productive and collaborative. This kind of empathetic leadership – once rare in engineering circles – is increasingly recognized as key to maintaining high-performing teams.

AI Tools: A Double-Edged Sword for Development Managers

In addition to managing shifting workforce dynamics, AI is becoming an integral tool for development teams. AI-driven tools like GitHub Copilot are no longer just productivity boosters but are changing how software is developed at a fundamental level. For example, Gergely Orosz, author of The Software Engineer’s Guidebook, in The Pragmatic Engineer reports that,

“90% of the code for Claude Code is written by Claude Code(!).”

The rise of AI coding assistants and automation is one of the defining trends reshaping development management. Tools like GitHub Copilot, ChatGPT, and other AI pair programmers are rapidly becoming part of daily software engineering workflows.

Gitlab’s 2024 Global DevSecOps Report found that 39% of software professionals are already using AI in development, up 16 percentage points from the year prior. Moreover, 60% say implementing AI is now essential to avoid falling behind competitively.

Development managers now face the challenge of integrating AI effectively into their team's workflow while also ensuring that these tools don’t hinder creativity or lead to over-reliance.

“We have to use AI. I think a developer who refuses to embrace AI today is probably going to be obsolete very soon,” says Romano, underscoring the urgency of adaptation. He adds: “At Sohonet, in my role, I got everyone on my team set up with GitHub Copilot. I wanted them to start using it, get familiar with it, and understand how to leverage what it can offer.”

By equipping his engineers with Copilot, he aimed to help them embrace AI-assisted development rather than fear it. Romano notes,

“Copilot is especially helpful for menial or repetitive tasks—like hardcoding different test cases. It’s really good at predicting what the next test case might be.” “Even when it's just acting like a better IntelliSense, it’s still useful… instead of rewriting a line yourself, you just hit Tab and it’s done,” Romano says

For development managers, the benefit of such tools is twofold: they boost team productivity and free up human developers for more complex, creative work.

According to Infragistics’ Reveal 2024 survey report, the top reasons developers leverage generative AI are to increase productivity (49%), eliminate repetitive tasks (38%), and speed up development cycles (36%).

Managers who proactively introduce approved AI tools can thus accelerate output and improve developer satisfaction. Romano mentions that his team continually experiments with new AI aides (from code editors like Cursor to AI pair-programming prototypes) to stay on the cutting edge. This reflects a broader best practice: staying up to date with emerging tools and evaluating their potential.

However, Romano also points out that over-relying on AI tools can stunt problem-solving skills, as developers might bypass critical thinking or creative solutions in favor of quick, AI-generated responses. 55% of Gitlab’s survey respondents also felt that introducing AI into the software development lifecycle is risky.

Effective development management in the AI era means finding a balance between leveraging AI and honing human skill. Romano emphasizes that developers shouldn’t offload all problem-solving to machines:

“Part of the job… was to smash my brain against a problem now and then. That’s really beneficial for your thinking… It keeps your mental muscles in shape.” “Relying too much on AI to… figure out the next step… that’s risky. I still want to ‘go to the gym’ up here,” he quips, referring to exercising one’s own mental faculties. Romano encourages each developer to “find the right balance—using AI as a tool, but still keeping their minds fit and challenged.”

This balanced approach ensures that while AI accelerates routine coding, it doesn’t “dumb down” the team’s critical thinking. “If you stop challenging the [AI’s] recommendations, they run the risk of dumbing down the reasoning. The true risk is in placing naive faith in quick fixes,” cautions Sammi Li, co-founder and CEO of JuCoin, noting that AI can expedite work but must not replace understanding. It falls on the EM to ensure this balance is maintained both for the team’s and the business’ benefit.

What the Shift to Engineering Management Really Looks Like

The move from senior engineer to EM is often misunderstood—frequently treated as a natural promotion rather than a deliberate change in function. But this is not a bigger version of the same job. It’s a transition into a fundamentally different role, with a new definition of success and a new center of gravity. Here is what development and EMs say about their shift from development to management felt like.

You stop being measured by what you ship. Engineers derive a tangible sense of accomplishment from writing code and seeing it run in production. That feedback loop is fast and direct. Management breaks that loop. “As an EM, you’re not the one building the things,” says Nick Centino, Principal Engineering Manager at Microsoft. “You’re helping empower others to build the things more effectively”. This shift—away from hands-on output and toward enabling others—can take years to internalize. Centino himself spent nearly eight years in a dual role before realizing his highest leverage was no longer in the code.
You have to redefine what ‘impact’ means. Orosz writes: “As an engineering manager, you’ll need to put company first, team second, and your team members third. And I would also add: yourself as fourth”. That’s a reversal from the individual contributor mindset, where engineers focus on executing their own tasks and helping teammates as needed. The EM role requires strategic alignment across teams—not just personal productivity.
You stop optimizing for technical challenges. Engineers advance by solving complex problems. Managers progress by preventing them. As Klepov writes, “Of all the possible career moves a seasoned engineer can make, switching to management gives you the most new challenges...without hitting your salary”. But these challenges are rarely technical. They involve process alignment, team dynamics, emotional management, and cross-functional friction. As Romano puts it: “Most of what we do is fairly routine...The real challenges lie in everything around the code”.
Your working memory breaks down. Many new managers underestimate the cognitive overhead of managing a team. Orosz notes that while ICs can often track all their tasks in their head, managers can't: “As a manager, I have far more things to pay attention to…Keeping all of this in my head doesn’t work well for me—so I’ve started to write things down”. Time and task management become not just useful, but essential.
You spend less time writing code—and often none at all. The drop is not optional; it’s structural. According to Centino, once you manage five or six people, meaningful individual contribution becomes unsustainable without either cutting corners or burning out. Even if you retain technical context, your job is no longer to build—it’s to coach, unblock, coordinate, and align. “If you feel like you have time to code,” Centino warns, “you’re either working long hours or not spending enough time with your team”.
You enter the domain of slow, uncertain feedback. ICs can validate ideas quickly: deploy a fix, measure a metric, refactor a function. Managers don’t get that immediacy. Feedback loops are long and ambiguous. “Very few of your actions produce a visible result in under a month,” Klepov notes. “Even the right changes can make things get worse before they get better”.
You have to manage people, not just lead them. This distinction matters. Leadership is about vision and influence. Management is about one-on-ones, reviews, process hygiene, and psychological safety. “There’s a lot of peopling involved,” Centino says. “You need to be listening to people, understand them, spend time with them”. For many introverted engineers, that’s emotionally exhausting—but non-negotiable. Skipping the people work results in burnout, distrust, and attrition.
You give up control, but remain accountable. Orosz captures the paradox: as a tech lead, you can write code and drive decisions. As a manager, you may do neither—but you’re still responsible for outcomes. That means learning to influence without coding, to steer without micromanaging, and to delegate without detaching.

None of this means the shift is a demotion of technical skill. If anything, it requires expanding your judgment from systems to humans. As Romano puts it, “The skills we learn as developers aren’t confined to software. They transfer to life”. But it is a shift. And for those unprepared, it can be jarring. As Centino warns, “Engineering management and individual contribution are completely different roles”.

Is Moving into Management Right for you?

A move into management is often seen as the natural career progression after senior developer or tech lead. However, not everyone is suited to be a development manager – and that’s okay.

“Managing people is a completely different skill set,” Romano candidly remarks. “If you’re someone who’s drawn to logic, machines, and technical problems—and you’re not interested in helping people grow—then you probably shouldn’t go down the management path.”

Strong coding ability alone does not guarantee success in leadership. The core of the development manager role, Romano says, comes down to a genuine desire to care for people:

“That’s what this job is really about: doing your best to help the people you manage become healthier, happier, more skilled professionals – and hopefully better human beings too.”

If that mission excites you more than writing code yourself, it’s a sign you might find the management path rewarding.

Despite the persistent narrative that “eventually you’re going to become an engineering manager,” Centino points out: engineering management and individual contribution are “completely different roles” with different success criteria, daily rhythms, and reward systems. The most common trap is assuming that strong technical performance qualifies someone to lead people. As Romano puts it,

“In our industry, we often promote people into management roles just because they’re technically strong. But managing people is a completely different skill set”. For those drawn to logic, systems, and clean abstractions, people management may feel frustrating and opaque. “People aren’t logical like machines,” Romano warns. “Managing them requires effort, empathy, and patience”.

The core question isn’t whether you can manage—it’s whether you want to. “I do think it’s important to have a solid foundation in software development before stepping into this role,” Romano says. But that’s table stakes. What distinguishes successful managers is not technical depth, but a “genuine desire to care for people”.

Centino echoes this point:

“As an engineering manager, I like to focus most of my attention and effort into growing individuals on the team… If I can align that with the direction the business is heading, then I think we have a great recipe”.

But if that alignment never comes—if writing code is still your deepest source of satisfaction—management may not be the right move.

Self-awareness, not seniority, should drive the decision.

“This type of thing will change over time,” Centino notes. “I found myself in a dual role for eight years and didn’t really know until the end… what I really felt would motivate me most”.

Regular reflection, honest conversations with your manager, and exposure to the demands of the role are more reliable indicators than promotion ladders or external expectations.

As Romano says, “If you’re only doing it because it’s your next step, or because someone handed you the role, it can be tough”. But if helping others grow feels like a worthwhile use of your time—and you’re willing to trade code for conversations, and systems for people, you may be ready to step into the role.

Making the Move: Traits of Successful EMs

If you feel you fit the bill and are ready to take on the challenges that come with managing software teams today, start by building a foundation of both technical and leadership experience:

Learn to manage time and context switching deliberately: Orosz emphasizes that time management shifts from “maker schedule” to “manager schedule.” Future EMs should practice structuring recurring meetings, protect deep work time, and use lightweight systems, for e.g., Getting Things Done (GTD), to track tasks across people and priorities—not just their own.
Get fluent in setting and supporting growth goals—for others and yourself: As a manager, you won’t just pursue your own goals—you’ll guide others in theirs. Orosz suggests practicing this by helping peers articulate growth goals, using role frameworks where available. Future EMs must also apply the same discipline to their own goal-setting, or risk drift.
Seek and learn from mentors before the transition: Orosz didn’t wait until he was fully in the role—he proactively asked his management chain to connect him with internal mentors who understood the company’s management expectations. Engineers eyeing management should do the same, asking for guidance and observation opportunities ahead of time.
Develop the habit of reflection, not just execution: Romano and Orosz both stress the importance of stepping back. Engineers often optimize for output; future managers must learn to observe team dynamics, reflect on what’s working, and adapt. Orosz models this by reading, writing, attending conferences, and running lightweight experiments with how he works.
Strengthen emotional awareness and communication range: Romano explicitly notes that successful managers listen closely, pick up non-verbal cues, and adjust their communication style to fit each team member. Aspiring EMs should build this muscle early by observing tone, response patterns, and interpersonal signals on their teams.
Practice coaching and teaching—not just explaining: Romano compares great management to good teaching: if one explanation fails, try another. Aspiring EMs should practice helping others understand by adapting to their learning style—not defaulting to their own.
Clarify your own motivation: Denis D., Software Engineering Manager at PaySaaS Technology and Romano both warn that without intrinsic interest in people and leadership, the transition becomes painful. Future EMs should reflect early: do they enjoy unblocking others? Does seeing someone else grow feel like progress? If not, they should reconsider the path.
Build a low-friction system to stay tech-adjacent: Denis maintains a Notion glossary, logs unknown terms, and watches short tutorials to stay grounded in the tech domain even after moving into management. Aspiring EMs can adopt this habit early to prevent drift and preserve confidence in technical discussions.

On the technical side, credibility matters: working several years as an engineer, shipping projects, and understanding the software development lifecycle from firsthand experience will make you a more empathetic and effective leader. As Romano notes, having been “under deadline pressure” or stuck on a stubborn bug helps you relate to the struggles your team faces – “that empathy makes you more effective as a manager.”

Ex software development manager and author of Coding in Delphi, Nick Hodges’ words sum up the job of a software development team manager nicely,

“Sometimes being a manager is hard—even impossible. Sometimes you have to give up being right and put the needs of the entire organization over yourself. Sometimes you have to balance protecting your people with being a loyal member of the management team. Sometimes you have to manage up as well as you manage down. Being right isn’t enough—being effective matters more.”

deep-engineering-7-managing-software-teams-in-the-post-ai-era-with-fabrizio-romano-img-5

If Romano’s reflections on team dynamics and career growth sparked your interest, his book Learn Python Programming offers a different kind of guidance, focused on building solid, modern Python skills. Now in its fourth edition, the book covers everything from core syntax and idioms to web APIs, CLI tools, and competitive programming techniques.

Get the Book

🛠️Tool of the Week⚒️

Backstage: Open-Source Developer Portal

Backstage provides a central Software Catalog, project templates, and “docs-as-code” infrastructure (TechDocs) so teams can standardize their architecture, onboarding and documentation. For engineering managers, this means you can enforce coding standards and best practices (via templates and catalogs), keep architecture and ownership information up-to-date, and give developers self-service access to resources.

Learn more about Backstage

📰 Tech Briefs

Building Strategic Influence as a Staff Engineer or Engineering Manager by Mark Allen, Engineering Leader & Technical Co-Founder @ Isometric: Outlines how staff engineers and engineering managers can build strategic influence by identifying business priorities, acting with curiosity beyond their role, cultivating cross-functional relationships, shaping their internal brand, and selectively saying yes to high-impact opportunities to grow their organizational visibility and impact.
How Staff+ Engineers Can Develop Strategic Thinking by Shweta Saraf, Director of Network and Infra Management @Netflix: Explains how to odevelop strategic thinking by diagnosing organizational needs, aligning technical decisions with business goals, influencing cross-functional stakeholders, and balancing innovation with risk—emphasizing that strategic impact stems as much from mindset and relationship-building as from technical expertise.
The AI productivity paradox in software engineering: Balancing efficiency and human skill retention: AI adoption in software engineering is creating a productivity paradox—delivering short-term task efficiency while eroding system performance, cognitive skills, and governance, unless teams integrate AI responsibly with oversight, skill development, and systemic alignment.

That’s all for today. Thank you for reading this issue of Deep Engineering. We’re just getting started, and your feedback will help shape what comes next.

Take a moment to fill out this short survey we run monthly—as a thank-you, we’ll add one Packt credit to your account, redeemable for any book of your choice.

We’ll be back next week with more expert-led content.

Stay awesome,
Divya Anne Selvaraj
Editor-in-Chief, Deep Engineering

Take the Survey, Get a Packt Credit!

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.