The Limits of Influence: Expertise, Growth, and Career Evolution
NOTE: Early draft.
How much influence can one person have? We all know there are limits. This affects how we should organize work, especially in software engineering. Let’s explore these implications.
Influence is shaped by several factors, such as authority, trust, empathy, and the people we surround ourselves with. However, for this discussion, I will focus primarily on expertise as the key driver of influence and its implications. To simplify things, consider that the ability to gain and maintain these other factors, whether or not explicitly mentioned, can also be viewed as a form of expertise essential for having influence.
Domain of Expertise
To me, expertise goes beyond raw knowledge and memorization of accepted, dry facts. It extends to awareness of boundaries, edge cases, applicability, alternatives and their differences, etc. It also includes the ability to make conclusions and situational decisions and to independently act quickly, without relying on any help from others for anything within a domain of expertise. That normally comes from experience.
We’re not done yet; there’s more. Much of what we do in software engineering is continuously and rapidly evolving. While many fundamental computer science facts remain true, new ones are constantly being created within existing domains. Some truths inevitably become less relevant while others gain importance. Because of this, being a domain expert at one time doesn’t guarantee that status in the future, even if we never forget anything. It is rare for someone to care about a “has been” expert – contemporary expertise is what’s sought after.
Natural Limits
We can’t break the laws of nature. While details may vary, we are all individually constrained by how quickly we learn and how much time we have to do the learning. The time constraint is particularly ruthless:
-
We can’t spend infinite time just learning, never starting to work. Would you wait, for example, until you’re 65 before your very first job?
-
We have limited daily/weekly time budget, a fraction of time, that we can dedicate to “work”.
-
A chunk of that work time will be allocated to things completely unrelated to the target domain.
-
Another chunk of that time will be used on practicing the existing expertise, not evolving it.
Only what remains, minus any context switching overhead and likely with reduced effectiveness due to exhaustion, will be available to actually evolve our expertise. This includes both foundational learning and subsequent “maintenance” to keep up with discoveries and external advancements. Even if we had unlimited memory and years for education, there is a boundary we can’t cross. In a sufficiently large domain, the time needed to keep up with its rapid evolution can exceed the remaining maintenance time budget we have available. It’s a bit like having a real-estate property size limited due to property taxes and maintenance fees exceeding available income and becoming unsustainable. If you’re a Physics fan, this is also a bit like the Schwarzschild radius – the extent of space (expertise?) at whose boundary the speed of light isn’t sufficient to escape gravity due to the mass of the object at the centre.
Skill Progression
How does one’s expertise evolve over time? In the initial stages, with young and eager minds that have ample room for learning, our expertise can take root and grow quickly. However, as our expertise expands, the “taxes and maintenance fees” we must pay increase, and the rate of growth slows down. At this point, we face a choice: maintain our current domain of expertise or sacrifice parts of it to make “room” (time) for something new. The following charts illustrate these effects.
- Figure 1 (left) depicts someone who retains all their skills, eventually reaching a limit.
- Figure 2 (middle) includes recognition that some expertise becomes obsolete and enables learning other things.
- Figure 3 (right) presents the effects of deliberate sacrifices of some past expertise, letting it rot. This opens up even faster acquisition of new skills, at some cost of raw magnitude of relevant knowledge at any one time.
Learning rate also changes over time due to changes in time we have available and our exposure to new learning opportunities. Accounting for that the reality is probably closer to:
There are at least three distinct phases:
- Initial expertise growth before much of it starts becoming irrelevant or obsolete.
- Continued maintenance & growth, while trying to retain all expertise that’s still relevant.
- Focused growth with delegation, after realizing that one “can do anything, but not everything” and willingly giving up on maintaining some expertise and leaving it to others.
These stages aren’t mandatory, except that for any particular domain, earlier stages are prerequisites for the later ones. Anyone can stop at any point, but can’t skip them.
Career Journeys
As previously mentioned, an intriguing decision arises before the third phase: one must determine whether to relinquish maintaining a particular area of expertise and allow others to take the lead. For individual contributors in software engineering, the options might look something like this:
- Continue investing time in maintaining current and relevant expertise, even though the risk of it becoming irrelevant grows.
- Decide to relinquish some areas of expertise to focus on others, while continuing to contribute individually.
- Leverage acquired work skills to attempt to increase one’s own productivity by guiding and leading others.
In my opinion this aligns well with my observations of career paths. The names I will use here may differ in your experience but, please, allow me some “artistic freedom” and, for this post, accept my terminology:
- Engineers, who aspire to every hidden corner of the technologies and code they own, all the way to the lowest layers of their tech stack.
- Architects trade some of the expertise in the lowest layers to focus on interactions between stacks managed by different engineers. They can’t let go of all their expertise, as that would impede their understanding of the tech stacks and the human labor involved in maintaining them. Since they consciously or unconsciously relinquish some expertise, they must rely on those who have the time to cover their blind spots. Architects must design solutions that work for both technology and the people who build it. Remember, “architects” who can’t code are impostors - either they can code, or they’re not really architects.
- Managers, Directors, and other people leaders exchange their technical expertise for the skills needed to organize and inspire people. Like architects, they can’t abandon technical knowledge entirely, but they must spend significantly more time developing and practicing non-technical skills. As a result, they must rely on their team to handle the technical and architectural work more effectively. This delegation allows them to focus on guiding the larger vision and fostering a collaborative environment.
Let’s (over)simplify things a bit to allow us to illustrate something. While anyone’s expertise requires uncountable number of dimensions to represent correctly, we’ll pretend that there are only two orthogonal categories of these and that each can be represented as single linear (one-dimensional) spectrums: the spectrum of technical skills and the spectrum of leadership skills.
These are not value axis. Having a skill further away from the origin doesn’t imply having those closer to the origin. We get a two-dimensional area of expertise that can be had at any one time. We get a can of paint to paint a section we’d like to have. That can isn’t infinite and there are no refills at all, free or otherwise. How is your piece of art going to look like?
Below is a hypothetical example of what an engineer, a beginner architect and manager may paint. Each of them has something they know better than others and they all have some common knowledge, too.
What I didn’t mention yet is that to acquire a specific new skill, one must have its prerequisite skills – you can’t just jump into a subject matter area and learn it well. Interestingly, while those prerequisites are needed to acquire new skills, their importance fades as we advance our attention further. We must travel roads to get from A to B, but we don’t care about the roads we’re done with. Firm foundations are beneficial, so it’s useful to think of these “roads” as being made entirely of bridges. Destroying one end of a bridge can very well destroy it all, so we have to keep them in good condition until we’re completely done with them.
Influence
Each of the two dimensions of expertise implies its own kind of potential influence, one over technology and the other over organizing people. To make that influence real and effective it is not sufficient, however, to only have skills in one of those dimensions – both are required. Again, an architect can’t be good without understanding people organization and processes and managers can’t be good if they don’t understand the realities of engineering. Bringing them together and applying constraints we can observe that the direct influence must remain more or less constant and indirect influence grows the more higher-level expertise we have on either technical or leadership dimension (or both).
That, too, aligns well with my observations of career paths people followed. Most aimed to increasing their influence over time. Very often their paths are categorized into one-dimensional technical and management “ladders” as if they are entirely distinct, though experience suggests they are not: they appear to have similar beginnings and endings. This requires more than one dimension to accurately represent. Here’s a rough illustration of my observations:
That observation aligns well with my observations of typical career paths. Individuals often aim to increase their influence over time, and while career trajectories are frequently categorized into distinct technical and management “ladders,” they are more connected than that model suggests. These paths share common origins and destinations, necessitating a multidimensional representation to capture their complexities. Here’s a rough illustration of the beaten paths I observed using the same 2D simplification:
Parting words
You may be familiar with different role titles and organizational structures. For instance, some modern perspectives question the necessity of architects, while others uphold their importance. Similarly, some organizations prefer managers to be more technically skilled than their reports, whereas others take the opposite approach. It’s essential to adopt a balanced perspective that acknowledges human limitations. As people progress in their careers, they inevitably delegate tasks, even those they once excelled in, because others have more time to stay current. Teachers must help their students surpass them, growing their influence indirectly through their teachings. Embrace and nurture this concept for a more effective and collaborative environment. With the tremendous advancements in AI that we are witnessing, it is crucial to understand how to leverage these new tools and organize ourselves effectively.
Other posts dealing with similar topics