The Architecture of Meaning

In the paradigm shift that AI is bringing, managers may have a leg up in the new era.

The Tech Leader’s Superpower

Any seasoned developer-turned-manager has a story in which they learned to shift their focus from the coding system to the people system. Of course, it’s not a binary shift and the degree of focus is based on the level and scale of the organization. But make no mistake – every single technology leader has come face-to-face with the reality that the next level of scale and velocity comes not from coding faster but in investing in the right people who invest in software systems.

Leadership is fundamentally the skill of aligning of group of people toward a common objective in such a way that their individuality is enhanced in the shared mission.

Or, more bluntly, delegation.

Good delegation is a skill and it takes years of practice to develop the right people judgment, instincts, communication style, and fluid range to effectively build alignment – and course correct.

Delegation itself is not uniform. There are degrees and levels of delegated authority based on situation, seniority, and confidence in the person. I personally have relied on the 5 levels of delegation model as a structured way to handoff work:

• Do as I say. Task-oriented. Do exactly this task and tell me when you have done it
• Research and Report. Look into options and come back with a summary
• Research and Recommend. Look into options and provide your POV
• Decide and Inform. Look into options, make a decision, and let me know
• Act Independently. Full ownership, no need to report back

This model itself is not static. A static model would be pinning a person to a given delegation model across all time. Person A is at level 1 while person B is level 3; person’s b’s promotion to senior makes them level 4. It’s not exactly that linear. Rather, the model is situational. The senior engineer who has been working in backend pipelines rather autonomously will need a smaller scope delegation strategy when making front-end decisions governing react code.

There’s a lot to this model we can unpack. However, the point here is that delegation is more nuanced and complex than binary: did you delegate? yes / no. It has a shape and each person and situation requires judgment and re-calibration.

Agentic AI and Letting Go

I remember the first time I went YOLO with Agentic programming and handed a task over to an AI-agent. Not assistant, not advisor … full agentic. I stared at my prompt for a minute looking for any possible wording or misreading that could happen. I hit enter, reminding myself that I had VCS and was on a branch. I watched it start to work and quite literally gripped my desk I was so nervous.

Why was I nervous? In some ways it doesn’t make sense. I was sitting on a branch, I could revert the code at any point, it would go through a review. So why was I scared?

To understand this, we need to consider what development is. Development is not banging out a lot of code: “type faster!” as the old adage goes. Rather, development is fundamentally about mental models.

Most of software engineering happens inside the developer’s mind

The work of development starts with having a mental model of the structure and composition of the software system. New feature requests require developers to build mapping functions that project a new state onto the current system. In other words, the code changes – systemically – is a function that, given the input of the system, produces a new system that includes the new features.

With that in mind, we can return to my first foray into agentic programming. My fears were born, not out of a sense that the agent was going to take down the production system (that would have been impossible because I hadn’t hooked up the tooling); my fear was that it was making changes that would remove my mental model of the structure of the code.

Let that sink in. If a developer doesn’t intuit the code they are responsible for … how can work proceed?

The agentic iteration completed and – given my ai tooling stack – I scanned the code changes. OK. That made sense. A couple tweaks were needed. But generally the direction I was going for.

There was something more fundamental taking place than simply running an agent against my code: I was practicing delegation.

Management and AI

This brings me to my fundamental assertion: agentic ai is at its core a delegation strategy. The tools of delegation are applied in this instance to a machine, not a human. But the model is the same. Steve Yegge notes something similar in his AI maturity model. As trust increases in the agent’s ability to increase a task, the developer’s delegation strategy matures. It moves from advisor to assistant to agent to empowered actor(s).

Two implications emerge.

1. Managers and senior engineers already understand how to prompt AI. The AI is a new developer being allowed to touch the codebase. That developer needs a ramp up plan that includes: understanding the code base, making small improvements or bug fixes, getting enough context to make larger changes, and not being given a responsibility greater than their skillset and ability to reason allow. If ai is a developer with general expertise, onboarding requires training in local styles and approaches*
2. Managers have a greater responsibility than ever before to coach developers in the skill of delegation. Previous to the AI era, a developer could be very good and have a high growth ceiling without needing to let go of control. Delegation is a skill reserved to those wishing to go into leadership: managerial or technical. However, with AI, even the junior developer needs to understand how to communicate and delegate a task with clarity in delivery expectations.

* Note. Onboarding is designed to bring a developer into the style. A historical challenge (albeit short) of ai is its proclivity to remain aloof to localized specialization. This is where skills, context, and system prompting, and chaining help avoid the forever aloof AI-developer. Modern agentic models have gotten very good at this and I predict will keep improving local enterprise training quickly.

Managers are the New IC

It’s possible to imagine a world in which those in technical management – given the advances of ai – are called back into the rank-and-file of the Individual Contributor (IC). Technically aloof leaders are obsolete; gone are the days of middle management!

This notion, as tantalizing as it may seem, is misleading. To be sure, I believe

1) every technical leader must remain technically conversant. This doesn’t mean top coder in an organization; it also doesn’t mean no-coder. Some lingering familiarity with the craft must stay or distance and time will lead to fractured connections between the primary workforce – the cross functional team – and the leader.

2) Every technical leader must become conversant in AI. Why? Simply because unless that leader stepped of out an IC role last month, no one in leadership understands the field. They weren’t trained in it, they didn’t grow up in it, and they haven’t learned deeply a workflow that optimizes productivity and safety.

So the leader must remain grounded in the practice of software engineering.

However, if the role of management is to align a group of people toward a common objective in such a way that their individuality is enhanced in the shared mission, and if AI has the potential to accelerate individuals working together toward that mission, and if a major aspect of AI adoption is delegation strategies, then it follows that the manager’s role and work is to build the skillset in a safe environment for developers to practice and hone ai delegation.

We have thus returned to the state we started. Managers align and accelerate. AI helps accelerate but requires additional soft-skills. This is the work of the modern technology leader. I hope many technology leaders will see that their role – while shifting in its focus – hasn’t fundamentally shifted.