The Technical Competence Spiral Theory
The Technical Competence Spiral states this:
An organization’s continuing ability to hire and retain senior, competent, technical leadership for each of its IT domains, dictates its ability to continue a competitive technical competence.
Let’s break it down.
An organization’s continuing ability to hire and retain senior, competent, technical leadership for each of its IT domains…
The simple truth is that it’s difficult to hire an individual who is considered a subject matter expert (SME) in a technical discipline, and who is also capable (let alone experienced) of managing humans along with their technical estate. I get that, and I’ve been there.
Note: In this post I’m referring to those individuals placed in positions of authority whose direct-reports are the people producing technical artifacts, as opposed to a director or VP level manager (which I’ll write up on at a later time). Also, by IT domains, I am referring to the various disciplines that make up the vast world that is IT, such as: Networking, Web Development, Data Science, InfoSec, etc.
It is because hiring these types of individuals is hard that, typically, one of the following four deadly actions occur at an given organization whenever they’ve essentially given up on their search (or simply don’t give a fuck). These actions constitute the early stages of a negative spiral.
Action #1: Choosing to hire someone who is not a technical expert nor has a strong technical background (or, perhaps, not technical at all) in the domain which they will be overseeing.**
This rarely works. Someone without a strong technical background charged with overseeing engineers is almost always being set up for failure. Why?
Upper management will always place some level of pressure on engineering managers, it’s natural. These managers will rarely push back and will almost always relay that same pressure, unfiltered, down to their team. Every time this happens, the engineers will become increasingly stressed and eventually burn out.
Having been in that position as a subordinate, I’ll explain what happens. Mid sprint my manager says, “I just got word that we must add FeatureX this sprint! Can you make it happen?” The first time, I have no problem with it, I only have to put in an extra hour or so of work, per day this sprint and it helps the team and it helps the company. Why not?
Then it happens again and this time it’s two features. Shit, okay. Now I have to put in an extra hour at the office and maybe an hour or two at home.
This cycle continues. It never gets better. Soon, I’m working 2–4 hours extra at home and 8–10 hours over the weekend to meet my manager’s expectations. I start looking for a different employer. One month later, I’m gone.
Action #2: Opting for hiring a “lead” engineer who then reports to a non-technical person with managerial authority.**
This is great way to lose your senior engineering talent. First of all, you immediately create an extra silo: engineers, and management proxies. Secondly, these engineering leads are not typically skilled or well versed in corporate politics. They shouldn’t be.
What happens is simple. The engineering lead is typically given a full technical workload, owning the domain, and is expected to produce at the same tempo as the rest of the team. This, on its own, is fine. However, they are then bombarded with requests by the “proxy” manager for Level of Effort estimates, timelines, interviews, performance reviews, executive summaries, and the list goes on.
The 2 biggest problems with this are 1) They do not interface with upper management directly making it politically impossible for them to push back or modify what comes down since all decisions passed along by the “proxy” manager have already been accepted. 2) They aren’t “managers” by title yet are still given a similar set of expectations in addition to a complete or near-complete engineering workload. They will fail in their management duties or in their engineering duties; if they burnout, then both.
Action #3: Hiring a very talented engineer and hoping that they step up to the leadership plate without every expressing that hope in the hiring process**
This is unethical in the same way that car salesmen employing the “bait’n switch” technique are unethical. Don’t do it. That’s all I have to say about this action.
Action #4: Hiring a properly qualified engineering through massive financial incentives.**
This happens with big financial organizations (banks, hedge funds, etc) more than with any other type of firm in my experience.
Organizations that are flush with cash will almost always find this type of individual through massive financial incentives (like paying 100K+ above market rates for salary, huge RSU packages, etc). This only works out if the hire occurs simultaneous to an organizational commitment to change. I’ll go out on a limb and say that almost no engineer became an engineer for financially lucrative motivations. In other words, money is not their first love. As studies have shown, the relationship between money and happiness is weak. So yes, an organization might be able to seduce an engineering manager with lots of $$, but they might not stay happy for very long.
When a technical leader becomes truly unhappy with their job in this type of situation, one of 2 things generally happen:
They find themselves living a lifestyle that requires their inflated compensation packages and find it hard to leave, especially when they have families (sometimes they go to a competitor hoping that the grass is greener). In this sense, they get stuck, lose their engineering soul and no longer work with the same enthusiasm and motivation they once possessed. As they make the mental migration from the love of engineering to one of producing the minimal amount of required work in order to stay employed, their output quality, and the output quality of their subordinates, declines.
They stick around for 1–2 years to save some cash and leave. At face value, maybe this isn’t so bad. However, engineers talk to each other, and their exit is usually followed by a handful of their peers and subordinates (and it’s not even coordinated!). > # ..dictates its ability to continue a competitive technical competence.
Here is the theory addresses the consequences of the deadly actions. The longer an organization follows them, the greater the likelihood that their overall technical competitiveness declines.
But, why is that?
To that, I respond with another list:
Engineers like to create. Many times that’s the only thing they like to do. However, rarely are they so consumed by their work that they don’t grasp the political climate. It’s easy to find an alternative employer if the politics get too thick.
The deadly actions are a cause of high turnover among senior engineers within an organization. As an organization (that doesn’t change) replaces these folks, the “replacements” inevitably begin trending downwards, in terms capability, with each subsequent generation of replacements. In the worst case scenario, the turnover becomes trickle. It’s not because they finally hired the right person but simply the worst person. Someone who is happy to have any engineering management title but is incompetent at both engineering and management (many federal agencies and major financial institutions are in this situation with their technical leadership).
As a result of the downward trend in senior capacity, the ability to interview, screen, and hire less-than-senior positions goes down with it.
Over time, the organizational competency and competitiveness, in the given IT domains, dies.
The brighter side.
I want to elaborate on some of the fundamental approaches I’ve seen work well. While this theory applies to the negative, it also applies to the positive.
Regardless of the organization’s history and reputation, they almost always are able to hire a good technical leader…eventually. What matters most is how they found that person and how long they are able to keep that individual within their ranks.
The best, albeit most expensive, way to find quality technical leaders is through real relationship building. Going through a recruiter is not that in the least. Copy/pasting the same blurb to every engineer you can find on LinkedIn is not that. It’s about honest networking. Here’s a basic guide:
Suppose you’ve identified a potential candidate to lead one of your application teams…
Find out what they care about (use social media, blog posts, interviews, etc). Research them. If they participate in the meetup scene, go to the meetups they go to.
Reach out to them. Mention that you find A, B, and/or C of their current/former work interesting for D reason. This has to be genuine, it’s 100% noticeable when you’re bullshitting. Ask one meaningful question (not if they’re open to new opportunities…blah blah).
Wait for a response. If you get nothing, try again in a week or two. If nothing, move on.
After they respond, if they’re relatively local, see if they’re up to grab some coffee, lunch, or maybe some after-work drinks. Get to know them. Don’t pitch them right away.
Make an effort have a face-to-face interaction with them at least once per quarter.
Repeat this cycle at whatever level makes sense. In time you will have six, a dozen, maybe more, solid technical leaders who have an actual relationship with you.
Boom! Now when you have a spot open within your organization you now have several direct contacts who know and, hopefully, trust you. Better yet, even if none of them are open to moving, most (if not all) will be happy to connect you to other folks they might know; this dynamic only happens if there is a relationship.
Can you guess the amount of times I’ve ever forwarded along a job req from a total stranger? Zero. And know for a fact I’m not alone in this.
Keep in mind, just because you make a successful hire in this method, doesn’t mean you should stop. It is not enough to be successful in a single instance of a single hire. One common mistake I’ve witnessed has been when an organization manages to hire one capable engineering lead (or whatever title you use) and almost immediately stops its work ethic in finding such a person. Don’t stop.
It doesn’t matter if the organization is mess (as long as it was made clear over the hiring process). A good leader, a good engineer, enjoys a good challenge. The important thing is making sure that person is enabled to implement tools and processes, and hires that they have found to be a winning combination in their experience. The worst thing that can happen is for the right person to be brought on to a team and then be handcuffed to “the way things have always been”. Everyone loses.
Technical leaders need both autonomy and a proper level of power in order to be effective. This includes listening to them when they say they need X more people on the team, or perhaps that this, this, and that person need to be fired. Trust them.
They are hired to lead, let them lead. Giving them absolute or near absolute control of their estate is a great way to make sure your technical leaders stick around for pretty long time.
The important thing that should be taken away from this is simple:
To be competitive in today’s “every org is a tech org” landscape you need competent teams in your IT domains, which requires being able to hire and retain technical and competent leaders. This requires building and retaining long term relationships with leaders in the industry. When hired, they should be given the necessary freedoms and power in order to best leverage their experience and skills.