Scaling Tech Teams Without Writing Code

Discussion with Manny Gatlin

With more than three decades of leadership in software engineering, systems design, and organizational transformation, Manny Gatlin has consistently delivered results at scale. He has held senior roles at companies such as Intel, Biamp, SmartRG, and Construx Software. Across industries and team sizes, he has driven improvements in release predictability, team velocity, and cross-functional collaboration, often in high-compliance, high-stakes environments. In this article, Manny shares hard-earned insights from leading global engineering teams, implementing delivery frameworks, and reshaping software organizations from the inside out.  

Why Engineering Managers Should Stop Coding and Start Leading

A common myth in software is that the best managers keep coding. Manny Gatlin firmly rejects this notion, not due to a lack of technical ability, but because experience has taught him that leadership success stems from stepping back, not coding in parallel.

“When a manager insists on writing code, they're not leading the team. They're competing with the team”, Manny says. This creates a dynamic of mistrust and dependency, stifling growth and autonomy. Instead of empowering the team to solve problems, these managers often become inadvertent bottlenecks, limiting scale and slowing progress.

Manny’s principle is direct: “Make or manage. Don’t do both”. Effective engineering leadership, he argues, means clearing roadblocks, aligning strategic priorities, and creating conditions where teams can excel. “Your job is to basically deal with the other things that prevent them from doing their job”, he explains. Organizations that blur the line between management and technical contribution risk fragmented workflows, blurred accountability, and stalled team development.

How to Transition from Developer to Engineering Manager

Many companies conflate technical excellence with leadership potential, assuming that great engineers will naturally make great managers. Manny challenges this assumption. “Leadership is not a promotion. It's a different job”, he adds, “it has different skill sets”. Transitioning from individual contributor to manager, he argues, should be a deliberate choice, not a reward for seniority.

Manny advocates for two respected growth tracks: one focused on technical mastery and another on organizational leadership. Each requires tailored training, benchmarks, and recognition. Without this structure, companies often push skilled engineers into ill-fitting roles, leading to underperformance, frustration, and attrition.

Manny’s own trajectory benefited from intentional investment. “I was fortunate that when I became a manager, I was directed to go to a management training program”, he recalls. “And I learned a lot during that training program that I thought I already knew, but I didn't really know”. He believes this kind of structured, early-stage training is rare but indispensable. Successful leadership goes beyond technical skill, requiring humility, constant feedback, and a shift from solving problems to enabling the team.

Staying Technical Without Coding

The transition to management doesn’t mean losing technical relevance, it means redefining what technical engagement looks like. Manny sustains his engineering fluency not by inserting himself into daily coding, but by staying embedded in the ecosystem where decisions are made.“My own philosophy is that you have to be engaged technically to understand what's going on”, Manny explains. 

This isn’t micromanagement. Manny stays current through low-risk strategies like sandbox experiments, testing SDKs, and joining architecture reviews.“I can make changes myself to see what would happen but never affect production code”, he notes. This hands-on curiosity allows him to retain context without interfering with execution.

He sees design and code reviews not as inspection points, but as moments for inquiry. “It’s not that you're telling them how to do the job, you're asking them how they’re going to do the job”. Shifting from direction to dialogue helps leaders build trust, align on architecture, and catch risks early. For Manny, credibility lies not in writing code but in understanding its impact on scalability, maintainability, and business value.

Scaling Engineering Teams with Communication and Clarity

As engineering teams expand, aligning priorities, people, and progress grows increasingly complex. Manny believes sustainable scale rests on three pillars working in tandem: strong communication systems, well-defined role expectations, and consistent, visible delivery.

“When you're dealing with a large organization, your communications have to scale”, he explains. Manny built bidirectional feedback loops, so information moves not just downward but laterally and upward. This system helps leaders catch early signals, correct misalignments quickly, and give teams the autonomy to act.

However, communication alone isn’t enough. Manny stresses the need to showcase results, so teams know their work is valued. Demonstrating tangible progress builds trust and ensures that work doesn't go unnoticed. His teams implemented a cadence of recurring demo forums, hybrid events where even small product increments were presented to cross-functional stakeholders. “We had a regularly scheduled event or forum in which the expectation was set in advance: we will demonstrate what we have done to this date”.

These forums served a strategic purpose: to foster accountability, acknowledge team wins, reduce stakeholder ambiguity, and reinforce shared ownership across departments. By institutionalizing this rhythm, Manny ensured that alignment was not an afterthought but an operational constant.

Why Software Projects Fail and How to Break the Cycle

Manny is clear on why many software projects fail: organizations get stuck in a loop of repeating flawed delivery practices without ever questioning their effectiveness. "I would question that they actually know what really works", he says, likening these repeated missteps to addiction cycles.

A key issue, Manny notes, is equating working code with quality engineering. Speed takes priority over durability and scalability, a problem rooted in the lack of formal training in software engineering principles.

For Manny, software failures are rarely technical. Instead, they stem from broken upstream processes: vague requirements, superficial user engagement, and incentive structures that reward speed over value. "If you ship something quickly, but nobody wants it, what's the point?", he asks. Across industries, from automotive to fintech to aerospace, the same truth holds: the barriers to successful engineering are more cultural than technological

Key Engineering Metrics for Software Quality

In an age of AI-generated code and obsession with velocity, Manny urges engineering leaders to rethink what success looks like. His approach to metrics is pragmatic: “You only measure what actually drives meaningful results”.

He rejects vanity metrics like lines of code, instead focusing on rework rate as a litmus test for software quality. “If you're delivering 20 stories in a sprint, but you have to fix 10 of them in the next one, you're only delivering actually 10 stories”. Rework, he argues, is a silent productivity killer, and often ignored.

The rise of AI has only intensified this. “It’s generating a bunch of garbage, and it takes an engineer to go in and fix that garbage”, he warns. Without rigorous tracking of what gets reworked versus what works on first delivery, teams risk overestimating their productivity and underestimating technical debt. “Rework is actually one of the most underutilized metrics as far as I'm concerned”.

Leading Engineering Teams with AI and DevOps

The rise of AI and the widespread adoption of DevOps have transformed software delivery timelines, but Manny maintains that core leadership responsibilities remain unchanged. "Technical leadership still means owning architecture, design decisions, and delivery", he says. "What’s changed is the environment in which these responsibilities operate".

Manny cautions against getting swept up in technological hype. While AI can accelerate development, it doesn't absolve leaders from exercising judgment, upholding accountability, or ensuring software craftsmanship. "AI isn’t some magical eight-ball, it’s pattern matching at scale", he says. "It lacks the context to determine what’s best for users or sustainable for teams".

In this new environment, the role of engineering leaders is more, not less, critical. They must think critically, ask the right questions, and reinforce teamwide accountability. Just as DevOps challenged the inefficiency of siloed workflows, AI now demands an even greater degree of thoughtful oversight. "Delivering faster is only a win if you’re delivering something that works, that lasts, and that people want", Manny concludes.

Key Takeaways for Executive Leaders

• Managers Should Enable, Not Code: Leaders create more value by clearing blockers and guiding teams than by writing code. Coding distracts from key duties like alignment and delivery support.
• Lead with Vision, Not Hands-On Code: Knowing how to code is different from doing it. Leaders add value by helping teams solve the right problems and scale, not by doing the work themselves.
• ‍Fix Culture, Not Code: Most failures are caused by communication gaps and poor alignment, not bugs. Teams succeed when they're aligned with user needs and strategic priorities.