Increasingly CEOs of software organizations are hearing magical things about the powers of AI tools. When you hear that an AI can build a web app in seconds or rewrite git, it can understandably seem like software is now so cheap we can replace most developers. I think the reality is nuanced.

What is the Agent like?

Let's name our AI Hal. What is it like working with Hal?

Hal can generate boilerplate fast, entire functional (simple) applications. He does not make most of the typos humans do. He is an expert in languages and constructs that are widely repeated across the internet. This is true in every language, making him brilliant at porting code from one to another. He can read at superhuman speed, summarizing and pattern matching across massive swaths of code, making him an excellent research partner. He can read astoundingly dull output for patterns and find the important parts. He can do all this with a flurry of agent friends, affordably. His output rate gives an illusion of brilliance.

But on closer inspection, Hal's work fails in subtle ways. He seems to have no human common sense with requirements that are left unspecified. Sometimes he starts down a wrong solution path and gets so bogged down he can't recover. His solutions can be great-looking but fabulously wrong hallucinations, especially when using technology that's not highly cited across the internet.

It's critical to understand why he succeeds at some things and fails at others. Hal is like a coding buddy who has great focus on a very small context, and very broad human knowledge, but lacks everything in between. He doesn't remember what he worked on last week, which practically means, he's a bad long-term maintainer. After only an hour of work he loses his grip on the current task. For him to remember that task, his team, his company, his architectural goals, or his general mission, he has to be reminded over and over. Unlike a human, he is missing the layers of memory, context, relationships, and interactions with the real world that would make his work valuable. And while his knowledge is incredible, his lack of value judgments makes his hard for him to produce work with above-average quality.

(I should emphasize that these limitations are not hypothetical. I have developed features and programs with it and experienced these flaws.)

AI's limits

Another way to express the limits of AI is that its world is too small. And here I mean more than just "the context window is too small". The world a software engineer lives in is full of things that are hard or impossible for an AI to keep "in context":

• What value am I adding with this task? Knowing this guides many implementation decisions and trade-offs. AI can only make value judgements as good as its training data, and that often will be wrong for you.

• How does it fit with our architectural vision? This determines whether your complex product is robust to scale, change, and attack, or a Dr. Seuss architecture that falls apart in real life. The most subtle AI failures I see are architectural misunderstandings.

• What problems or possibilities exist in our product that require novel solutions or technology? AI struggles with problem never before seen on StackOverflow. And it will never champion novel product ideas based on expert knowledge, developers will.

• How can I trust that the results match our goals? The specifications that come from Product Management are never complete, developers make human assumptions and fill in the gaps all the time based on what they know of the people and the business.

• What about costs and failure modes? The AI has no wallet, and often does not know what errors to be afraid of and protect against.

All of these require awareness of people and the outside world. They also require wisdom. AI can identify bad solutions and offer pretty good ones, but without more information, it cannot wisely make the tradeoffs an expert needs to make. AI is not the total expert it seems; it is more like an expert at averageness.

Models and their tooling environment will continue to improve at some of the failures I've seen. Better models will help it not leak database connections (a bug I caught it making today). Sub-agents, web search, RAG/MCP (or whatever succeeds them), and model retraining have a long way to go and will give the models a bigger world. But it will never be big enough for everything I noted above.

The 3 Types of People

As we move into an AI-filled world I believe 3 types of software developers will emerge.

1. Those who refuse to use AI except for trivial things. Some can be good and effective for years to come, specifically those who work with architecture, novel technology (including systems sensitive to scale, cost, or security), and those who bridge the gap between product requirements and reality. Nonetheless, without taking full advantage of AI, these people are leaving great potential untapped. Some in this group that simply take specifications and implement them are, indeed, in danger of being replaced by AI.

2. Those who become over-reliant on AI. I believe this will be by far the largest group. Their skills will atrophy. Some of those skills may genuinely not be so critical anymore, like Bash or Terraform syntax fluency. Many will still be needed; AI will do it right 90% of the time, and the critical 10% when an expert human needs to understand it, they will be stuck or cause failures. These people will hold on to their roles for years to come because of apparent success, but will be unable to do that final 10% of what makes someone a truly senior technical player.

3. Those who use AI effectively. They will multiply their effectiveness. Their key feature will be the discipline of understanding what the AI is doing for them, learning from it, taking ownership over what it generates, and knowing when not to use it. It's a matter of discipline because trusting result from AI is an incredible temptation that must be fought.

Takeaways

My message to executives would be this. If you are satisfied with software that has a polished look but is internally clunky and fails in unexpected ways, and the software you want is simple anyway, go ahead and have AI be the expert for you. If you want quality software, if you want to avoid security holes and support issues, if you want to be able to pivot and add features without a quagmire of broken changes, and if you want a team that scales up and adds value for you autonomously, then you need software engineers.

For executives, ask yourself:

• When I hear claims of massive productivity ("AI did this 1 week task in 1 hour!"), is it really about changes in our core product that offer long-term value?

• Are large features and architectural initiatives really being completed so much faster, or is momentum being slowed by complexity? What do my most trusted technical people have to say about the quality of work coming out of AI?

• Am I encouraging and training my people to be effective, but not over-reliant, on AI?

For technical people, ask yourself:

• Am I learning to use AI effectively?

• Am I learning to add value to my organization in ways the AI fundamentally can't? How can I move toward this?

This story came to mind that I think captures elements of communication that technical leaders frequently miss. Let me tell it then explain.

The Parable

On a river flowing through a forest there lived Beaver. One day while swimming he notices a concerning sulfur-like smell. He realizes water flow has been slow lately, so he heads upstream to investigate. Sure enough he finds that fallen debris has created a stagnant section of the river.

As an ecological expert, Beaver recognizes what's happening. The water is now stratified into thermal layers and no longer mixing. Oxygen isn't reaching the bottom, causing a change in bacteria make-up and the smell of hydrogen sulfide. He knows that if nothing changes, nutrients trapped in the sediment will no longer stay there. In a single night it all could be released, causing an algae bloom that will kill the animals.

The debris needs to be cleared, but it's too much to remove by himself. Beaver concludes he'll find help in the forest.

He first comes across Deer.

Beaver: "Deer, there's debris in the river that needs clearing! Can you help me?"
Deer: "Why does it need to be cleared?"
Beaver: "It's causing hypoxia! If the low-oxygen state continues and nutrients get released, the algae bloom will be massive."
Deer: "Okay... that's too bad, but I'm busy, sorry."

And Deer prances off.

Next Beaver finds Bear.

Beaver: "Bear! There's debris blocking part of the river, I need your help!"
Bear: "Uh oh, so is there flooding? Could that flood my den?"
Beaver: "No, there's no flooding, but it's causing hypoxia in the lower layers and a potential algae bloom. The animals might experience phycotoxicoses!"
Bear: "Oh. Sorry to hear about the phyco... whatever that is. Anyway, that river is pretty far from here. Is there someone closer who can help?"
Beaver: "Not so far."
Bear: "Well, if you REALLY need me, let me know, but I'm still finishing my lunch."

Bear lumbers back into his den, and Beaver is becoming frustrated that no one will listen.

Finally Beaver has traveled so far he hits another small river and encounters Otter.

Beaver: "Hey Otter, I'm not sure if you can help but I don't know who else to ask. Can you help me clear debris from the river a mile that way?"
Otter: "I'm happy to help Beaver, but if you can't clear it, then I probably can't. Did you ask the bigger animals for help?"
Beaver: "Yes... nobody seems to care! I explain the problem but no one seems motivated to help me."
Otter: "Hm, what is the problem?"
Beaver: "Well, hypoxia is going to lead to a huge algae bloom."
Otter: "Okay... so what?"
Beaver: "What do you mean so what? Phycotoxicoses is what."
Otter: "Which means...?"
Beaver: "What do you mean? Algae will make the water undrinkable, that's what I mean."

Otter now recognizes why Beaver hasn't been able to persuade the animals to help him.

Otter: "Okay, Beaver, I have an idea. Take me to the animals you spoke to."

Beaver agrees. Together they return to Bear's den.

Otter: "Hey Bear, I've got some news you might be interested in."
Bear: "What's up Otter?"
Otter: "I learned the fish you eat out of that nearby river will be dead soon. You might have to walk almost an extra mile to go fishing. Did you hear about that?"
Bear: "What!? No. But that would be horrible, I hate walking. How do you know this?"
Otter: "Beaver told me. If the debris blocking the river doesn't get cleared, it'll eventually poison the water and kill all the fish."
Bear: "Well let's go clear it!"

And off they went. On the way they encountered Deer once again.

Otter: "Hey Deer, I heard there's a new danger for the fawns around here."
Deer: "What? Nobody told me that."
Otter: "Yeah, it's a little scary. The river water may be poisoned soon if we don't clear the debris. I just hope none of the little ones accidentally think it's safe and drink from it."
Deer: "Goodness, no! Can I help?"
Otter: "Why, yes! We're off to do that now."

And with help from both Bear and Deer, the debris was quickly cleared.

When the job was done, Beaver spoke with Otter.

Beaver: "I don't understand, Otter. Why wouldn't they listen to me?"
Otter: "Well, for one, you were cursed."
Beaver: "What!?"
Otter: "Haha, I mean, you were cursed with knowledge. You knew what this debris would cause, down to a science, and how it would impact everyone. You knew it so well you forgot what it was like not to know. So when you spoke to those creatures, you acted like they knew too. It's a common expert's mistake."
Beaver: "Wow. So how did you overcome that?"
Otter: "I won't say it's easy, but the important thing was to put myself in their position. They don't care about algae blooms; they care about fish and drinkable water. Instead of forcing them to do the interpretive work to know why my information matters, I did the work for them. That's how you communicate so people will listen."

Application to Technical Leaders

The Curse of Knowledge is a well-studied phenomenon I find critical for technical leaders. To lead you must communicate well. I find technical people fail to communicate most often because of this curse, much like Beaver.

Here are 3 tips for avoiding this problem.

1) Keep it simple

Suppose you are explaining to a stakeholder why your system causes weird behavior for users. You pull up architecture diagrams with many arrows highlighting the historical reasons certain users lack some piece of metadata. 20 minutes later your stakeholder is mystified, because you gave them too much information.

Experts often care too much about accuracy. When we try to communicate nuances and exceptions to an audience that will not understand them, we need to recognize it really does detract. In these situations, less is more. Keep it simple.

(As anyone who has drawn software architecture diagrams knows, they are all inaccurate. The key is not to fix that, but to be accurate in the right ways.)

2) Be concrete

It is tempting to say things like the following: "My change will reduce latency for low-bandwidth users. It will scale horizontally. And the design decouples the components." To a fellow expert these abstract terms might be fine. But almost all of the time you should say the following instead: "With my change, people in rural areas will experience pages loading in 200ms instead of 500ms. It will stay fast even if users quadruple. And it's structure so a junior engineer could make further improvements." This is concrete.

3) Find out what your audience cares about

When we communicate we usually do only half the work, figuring out what we want to say but not what others want to hear. It's like trying to find the overlap in a Venn Diagram without discovering where one of the circles is.

Everyone cares about something different. Engineers care about what will help them build. Project Managers care about who else needs to know something. Executives care about why they should spend any time to care. Product Managers care about what something will do for users. Finance people care about financial impact. Sales people care about whether something can give them leverage with a customer.

Whether you're writing an email, a ticket, a code comment, or giving a presentation, ask yourself:

• How can I make this shorter and simpler?

• What abstract ideas can I replace with concrete examples?

• Who is the audience, and what do they care about?

• How can I do the interpretive work for others?

For further reading see Chip and Dan Heath's book Made to Stick.

Leaders are constantly challenged with the extent of supervision to exercise over junior people. We all recognize that micro-management is bad, but so is having low standards and tolerating poor performance. When we try to follow simplistic advice about rewards and punishments, we tend err on one side or the other. So what do we do in order not to micro-manage, but to have a high-performing team?

The answer is instilling personal discipline. In the essay "Discipline: Creating the Foundations for an Initiative-Based Organization", Christopher Kolenda defines Disciple as: "to understand the difference between right and wrong in terms of performance and behavior, and to do what is right in the absence of supervision." There are numerous benefits when a team of people are disciplined in this way. Leaders have bandwidth freed from micro-managing. The team can handle situations "on the ground" dynamically, with solutions more fitting and effective than those that might be dictated from on high. Good decision-makers are trained up rather than stifled. The organization's effectiveness is multiplied. Everyone is happier.

So how do you get there?

A Concrete Example: Code Review

Imagine you lead a team of software engineers. As you consider how things might go without supervision, you recognize code quality as inconsistent. You have a practice for code review in place, but bugs are occurring that should have been caught in code review, and some review requests receive no comments for days, so people move on without it. You recognize that without leadership, this will not change.

You decide to discuss expectations. Should we expect code to be well-documented to make reviews easier? Should we expect frequent comments? Should reviews be done generally within 24 hours? Knowing the answers should be "yes", you have already been taking the first step of any servant leader by doing these yourself. You earn respect and trust for doing so even before others reciprocate. When it comes to asking for them to do the same, they will know it is no less than what you are doing. So in your team meeting you raise the discussion, listen opinions and reactions, and declare expected standards the team members can generally get on board with.

In team meetings (particularly retrospectives), you deliberately share praise when someone has reviewed code quickly or left thorough comments. In a meeting setting you keep negative comments general (making an example of someone is not the point), but you are still honest, expressing that you would like to see this area improve and ask others for their thoughts. Maybe you get little response, but it is on their radar, a small step in the right direction.

One team member in particular gives you frequent trouble. When others request improvements on their work, they argue. They state, "what I wrote works, that's what really matters, all this review stuff is a big waste of time." As the leader who  has convictions about your standards of professionalism, you meet with them and reiterate that these reviews are the standard for behavior. You ask what would help them, knowing that they may have reasons and are not simply a rebel. You listen, trying to persuade even as you stay firm. You ask for their compliance and for them to trust that your intentions are good.

Though it takes time and reminders, code review standards are increasing. Thoroughness of the comments and responsiveness to them are becoming normal.

As the years pass, your team grows, taking on more projects and people. For these team members who have demonstrated the fundamentals, you can now trust them to lead and make decisions. You show them how you did it. You observe their own choices to instill discipline, giving them feedback. But most importantly, you let them lead. Ingrained with the high standards you demonstrated and persuaded them to value, your collective effectiveness multiplies.

How to Instill Discipline

If you want to instill  this kind of discipline in your own organization, here is what it takes.

Maturity Assessment

First, assess the current maturity of your team vis-a-vis discipline. Ask yourself:

• How well would the team function if the leaders were removed?

• How much is the team driven by high morale and a sense of professionalism rather than externally-imposed discipline?

• Are the standards of performance for behavior clear to team members?

• Are those standards consistently followed when leaders are absent?

The answers here will indicate how much change is needed, how long the road to change is, and how quickly you can move through the remaining steps.

Defining Performance Standards

Before even trying to communicate or enforce standards with your team, you need a picture of what "right" performance and behavior is. What do your high performers do that others do not? Which of those behaviors should be considered standard for the role? Rather than write long documents and descriptions, focus on a few key behaviors and how they are not universally performed by the team.

Enforcing Standards With Persuasion

You are now trying one of the hardest and most fundamental tasks of leadership: shaping culture.

It can often go wrong. Some leaders set goals for their people that those people have not taken ownership of, which technical people are specially good at accomplishing with minimal effort. This is why improving productivity among engineers merely by measuring metrics like lines of code or pull requests fail; they know how to game it.

Some leaders emphasize punishments and put people in performance improvement plans, often causing unhappiness, adversarial feelings, or attrition. Others emphasize positive rewards but still tolerate underperformance, with little effect.

To enforce standards properly, do it relationally and play the long game. The relational trust others have with you will allow you to bring small changes. Show team members that you care first and you have their interests in mind. Make one change at a time, enforce it, praise good performance, and yes, use punitive measures. Explain the reason improvements are needed, and even better, share the performance gaps with the team and involve them in solving it. When the desired behavior change is established, be consistent about it. Show the team that yes, you meant it, but also that you understand where they are at. Reward progress in the right direction, showing that you value willingness and grace.

The end goal is persuasion, not coercion. Coercion may be required for people lacking any sense of the fundamentals, like a conscript army. But instilling discipline requires persuasion, so that people hold to the higher standard out of their own sense of professionalism.

Why is it not done this way more? Because persuasion takes more time, work and sacrifice. It's a high-cost, high-reward investment.

Grant Increasing Decision-Making Freedoms

For team members who demonstrate fundamental competency, you must give real decision-making freedoms. While it might begin with decisions that are easy to revert, it cannot continuously be "fake" decisions where leader approval is required before action is taken. Consequences are necessary for real learning. While those consequences may seem bad, forever shielding people from decision consequences is worse.

When teaching someone a skill it can be hard to know how to escalate the level of freedom. Usually we err by continuing to micro-manage or by throwing people into the fire too quickly. So when teaching someone a skill I find it helpful to deliberately move through the following stages:

• I do, you watch

• I do, you help

• You do, I help

• You do, I watch

• You do, and the chips fall where they may

On this final stage it is important that someone making a decision in good faith feel supported, even if that decision turns out to be wrong. This should be expected, it is how they will learn. If you are a leader it may help to remember that this is how you learned, too.

A Final Note

Even if you have no formal leadership position or title, you can seed the change for discipline in your team. You can demonstrate it, earn the respect even of more senior people, and raise the bar. As you demonstrate discipline and earn decision-making freedom, you will be a leader.

In The 21 Irrefutable Laws of Leadership, John Maxwell says,

“Anyone can steer the ship, but it takes a leader to chart the course.” What does this course-charting navigation look like for technical leaders? The core is seeing more than others do.

Bigger Vision

We once had a situation with our class and assignment listing page that required bigger vision to solve properly. Three teams were involved in showing the list: a front-end team (FE) making the request and rendering it; a back-end team (BE1) with responsibility for listing the assignments in the class; and another back-end team (BE2) owning some important display statistics like "user submissions per assignment". One day FE found that the submission statistics were not taking user enrollments into account (owned by BE1), and so they requested BE2 fix it. It would have been possible, but we paused to look at the bigger picture. It took vision to see the fact that BE1 is already responsible for a separate page that combines user and submission data together into a list. If we wanted to save ourselves from future inconsistencies, the logic to list and count those submissions should be in one place.

When working with a team it is so easy and natural to focus our solution space down our team's available options. Navigators take the time to understand what neighboring teams are doing. They ask, "Has this been solved elsewhere? How do this component or feature fit in with our product as a whole? What does our team provide that others should be aware of?"

This occurred once with a service our team had developed. It was a highly-scalable Redis-backed rate-limiting system, used at first for rate-limiting specific actions that could be attempted at many thousands per second. We built it for our need, not over-engineering, but had it use an HTTP API we could build upon. Years later in technical meetings I heard about a team trying to prevent password-cracking attempts on their login page. Typical Captcha-like solutions were looking very expensive. I threw this service into the ring as a candidate for the throttling we needed, and it ended up working well for them.

To many people, knowing where the tech department is going, much less the whole company, feels not worth the time. But being aware of the bigger picture has great value for alignment. Navigators know this.

Some may also say this is someone else's responsibility. That is likely true, for now. But if you want to be that person someday, your effort to grasp the bigger picture has to start now.

Farther Vision

Software leaders know that code is read far more than it is written. An engineer may focus on the value that code provides in this moment, by the feature it implements. The leader sees into the future, how that code will support future work, or detract because it is obscure, poorly documented, or error prone. Navigators see far into the future.

We once had a scaling challenge with particular metadata our product team wanted to display. It would be a big lift to make it queryable at the granularity they wanted. When they heard the costs involved, they dropped the request. Years down the road we had a new product need that would have required this metadata. Beyond that I recognized a third more technical use for it: we were relying on unscalable proxying to request it already, and it would simplify our architecture. I wrote a proposal to present to the rest of the architects, gathered buy-in, and we launched the project, which I can say is now essential to our newer products while simplifying our architecture.

Navigation is like looking several moves ahead in a 4D chess game being played by multiple disparate teams. It takes far sight to recognize points of convergence and obstacles, to build systems that will be ready on arrival rather than hold everyone up.

Navigator's Priorities

One way this kind of strategic, navigational thinking plays out is in order of delivery.

A common example is rebuilding legacy components. Often the focus is, should this thing be rebuilt or left untouched? I believe it is just as important to ask: How can it be rebuilt in a way that incrementally adds the value along the way?

Joel Spolsky is known for calling rewrites from scratch the "single worst strategic mistake that any software company can make". I think that's often true, if only because software engineers are terribly optimistic at time estimation. But I think the real critical mistake in that kind of rewrite is that until the new version is done and rolled out, there is zero value added for customers. Agility is lost, and any efforts to improve the old thing are wasted. The opportunity lost could be fatal, as it was with Netscape.

But the reality is, software (or hardware, research, whatever you work with) must be revamped eventually. Except for the thumbtack, nothing stays valuable as it is. Everything must change to keep providing value and compete. So how should it be done?

Years ago we had a document similarity viewer service that was core to our business, but was quite old. It was in C++, had no tests, and had to be treated with care. We all hoped to rewrite it. That day came when I recognized some new product requests coming down to us for a new way to view the data this service currently handled. It would have been possible to do in that service, but brittle and somewhat costly. I recognized two things about these requests: 1) they required only a small subset of what the current viewer did; 2) eventually this new way might overtake the old way we view the data. So we started building a fresh viewer in Go, well-tested and with a better API, but able to read the same underlying on-disk data as the old viewer. Because the new product capabilities were still a work in progress with UX, it bought us time to build this new thing. We were able to stay ahead, powering new features with our new viewer even as the old one continued providing value. Eventually it completely replaced the old viewer.

Stories like this make the decision sound obvious. But in reality, building a new thing was going to be quite a bit more work. They key was seeing into the future, knowing where we are going, and recognizing that now is the time to do it in a way that provides incremental value along the way.

Ask yourself:

• Is your understanding of the bigger picture and the future growing?

• Do you have a large project that you could realize value from mid-stream rather than at the end?

Every job comes with a description of responsibilities, and it becomes easy to think of that as what your job is. This post is a reminder that your job is always, ultimately, one thing: adding value.

By this I don't just mean making money for the company or increasing stock value. I mean adding value to people. Your job description is intended to identify the way you'll do this in your organization, but we focus on that alone, we lose sight of the forest for the trees.

How Experts Lose Track

Consider a software engineer who gets into a rhythm of completing tickets, producing features and fixing bugs. By themselves, those add no value. The value comes from those features actually being useful to humans, who in turn value the product more. No matter how elegant a feature or advanced a research breakthrough, if something is not valued by people, it is not a job anyone will pay for.

This particularly applies to technical people who want to advance by just being amazing individual contributors and avoid working with people. At junior levels that can work, because someone else is doing all the work to determine what you can do that will be valuable to someone. As they move up they'll quickly face ambiguity and be expected to do more defining and prioritization themselves, all based on what will add value to others. I have seen many individual contributors whose performance ceiling is not their technical skills, but their willingness to work with people, which requires communication, documentation, collaboration, compromises, and sensitivity to non-technical needs.

This also applies to the ongoing AI revolution. AI models can implement tickets quite well. What value will the human add? It will be in understanding not just the larger context of the system (still a challenge for the models), but in understanding what about this work adds value to people and the business, and what implementation will be strategic for adding value later.

This makes existing, running-in-production "legacy" code have far more value than people give it credit for. So often we want to throw legacy stuff out, rebuilding or replacing it. (Often we should, carefully over time.) But we must all appreciate that no matter its technical flaws, this legacy thing is providing most of the value to users right now, and it needs to be taken seriously until that is no longer true. In practice that means: expect that system to last quite a while, and learn in exacting detail what it's doing for people before expecting it to go away.

These things are the work of technical leaders, who understand that in the end it's all about adding value.

Ask yourself:

• How does my work add value to people?

• How can I excel in skills that add value to people?

Technical leadership is the intersection between technical expertise and leadership. I feel that combining the two is generally undervalued today, and by the end I hope it will be clear why.

Technical expertise is skill in a domain. It is effectiveness of a software engineer at building systems or an electrical engineer at designing circuits. Early in your career much of your growth is in this area.

As John Maxwell says, “Leadership is influence.” When an architect gets buy-in from teams to implement his plan, a QA person raises the quality bar with their team, or a scientist teaches others in his lab who follow his example, they are leading, regardless of what their title might be.

The Technical Expert Vs. the Technical Leader

Consider a hypothetical example. You work on a web service and trying to prevent users from abusing your login page; they are trying to steal passwords and take you down.

As a good engineer you recognize, we should at least use an IP-based blocking solution. You survey options. Can a CDN do this? Can we built it internally? What will each cost in effort or money, both now an into the future? Perhaps you pick an internal build with a data storage option that's robust, well-tested, and satisfied your current needs. You find that balance between costs, future needs, and scale. That's technical expertise.

How about technical leadership?

First, likely you noticed the problem in the first place. You built the monitoring dashboards and noticed the unusual traffic patterns. Rather than let those sit, you investigated, weighing the impact on your database, and tracking down the cause. That's initiative.

Then, you spoke with stakeholders like the Product Manager to explain why this should be solved. You explained the problem, potential solutions (like firewalls and captchas) and their costs in terms a less technical person could understand. That's connection.

You also asked, has anyone else here solved this? What can I learn from them? Can we share? You learn that another team at the company has built a Redis-backed rate-limiting solution that can solve this problem in a cost-effective way. That's seeing bigger.

The catch is, it has no API to be shared like this. You feel tempted toward the fastest solution, building your own similar thing. But knowing the long-term benefits of well-designed shared components, you reach out to work with the team that owns the service. You persuade this team of the mutual benefit of making this shared component a distinct API service. That's getting buy-in.

All of these are just a part of what goes into influencing your organization through people.

In the end, perhaps some else builds it. It's a well-defined piece of work non-leaders can do. You move on to other tough problems that can only be solved by technical leaders.

Why Leadership and Technical Expertise Multiply

Here is how I often see this process fall flat when technical leadership is undervalued.

Apart from leadership, technical experts will choose solutions that optimize the exercise of their craft. Engineers will solve the problem by building something with a preferred tool. Operators or IT people will find something to buy. Scientists will create novel inventions. Most will ignore the breadth of possible options, not just because those options are outside their field, but because they lack the context of business value and trade-offs which should ultimately decide what an organization does.

Apart from technical expertise, leaders cannot allocate resources in properly. They cannot properly train and rate their people. They miss industry signals the require domain knowledge to recognize. They are unaware of optimal solutions to their organizational goals, choosing instead to copy what friends or competitors are doing.

In practice, of course, good leaders work closely with technical people to overcome these gaps together. No human is perfect at either (or perfect at all). I am not advocating for individualistic super-humans. We need teams.

Still, it is rare to find a leader and expert who are both skilled, both aligned, and trust each other. In practice I see the failures I mentioned earlier happening regularly.

Ask yourself:

• Do the leaders at my company have reasonable understanding of how their products function?

• Am I giving technical experts opportunities to grow and exercise leadership even if they are not managers by title?

• Am I appropriately valuing "player managers", those with leadership who still engage in their craft?

• Does every one of my leaders have domain training in the field they supervise? Or is there an expert close to them who understand their people, their projects, and can advise them?