The Tao of Engineering

You might be familiar with the Yin-Yang symbol from Taoist philosophy. The black sections are yin - mysterious, chaotic, unknowable. The white sections are yang - obvious, ordered, legible. Yin and yang are fundamental properties of the universe. Just as the Heisenberg Uncertainty Principle balances any attempt to measure a particle's position with chaos in the particle's velocity, the universe conspires to balance any yang - legibility - with yin - mysterious chaos.

To non-programmers, software engineering is yin by nature. Bring any normal person into the engineering department and watch them marvel at all the black terminals and arcane symbols. Of course, this external yin is balanced out by internal yang - all the programmers know what's going on. We can, after all, read each others' code.

Yin-on-the-outside and yang-on-the-inside is the natural balance of a software engineering team. For the programmers, working inside the yang is generally a nice experience. Information flows smoothly, colleagues are helpful, and accomplishments are naturally rewarded with respect and admiration. A well-functioning software engineering team is a wonderful, collaborative environment - on the inside.

For the rest of the company, however, the yin on the outside is difficult and annoying. How is the company supposed to communicate its roadmap, when features just randomly emerge out of a mysterious black box?

The yin is particularly problematic when a non-programmer is granted administrative power over the team. How does the administrator decide who gets what work? Who to reward with raises and promotions or who to performance manage? These are all important questions that must be answered correctly for the engineering org to function properly, but they're very hard to answer from outside the yang.

Unable to penetrate the mysterious yin, the non-technical administrator responds by shining the flashlight of yang over the org. The flashlight usually takes the form of metrics - individual/team KPIs, semi-annual performance reviews, etc.

Unfortunately, Goodhart's law rears its ugly head:

When a measure becomes a target, it ceases to be a good measure.

Once individual performance becomes spreadsheetified, individuals re-orient their behavior to optimize their metrics. All job functions are vulnerable to this phenomenon, but software engineering is particularly vulnerable due to the enormous amounts of yin inherent in the system. The flashlight of yang is unable to eradicate the mysterious yin, merely to redistribute it - down to the atomic, i.e. individual contributor level.

An individual contributor whose compensation is tied to, say, shipping a specific feature, will prioritize shipping that feature over helping out their mates. Intentionally convoluted code will start infesting the codebase, so its maintainers can never be fired. Estimates balloon out of control, fiefdoms are carved out, and helpful information is jealously guarded.

The perfectly yang metrics in the administrator's spreadsheet come at a cost - the internal yang of the engineering team.

You can't have a double-yang situation. Law of the universe. Very sorry, take it up with Heisenberg.

An Org in Cosmic Balance

At Ivo Engineering, we believe in working with the universe. We don't want to mess up the yang. As such, we embrace the following principles:

1. A service-oriented exterior. The outside world may not understand us, but that doesn't mean they can’t like us. People like individuals and teams that are polite, helpful, trustworthy and reliable. So long as engineering maintains a reputation for professionalism, competence, and reliably shipping high-quality features and bugfixes not only quickly but on-time, the external world will be much less tempted to shine the flashlight. Our catchphrase is, welcome to engineering. How may we be of service?
2. Managers must code. This isn't so much so that the company can get productive economic output from their coding prowess, but so they can live inside the yang. So long as management is deep within the code, the flashlight is unnecessary. Why would you need it? You can tell who's doing a good job by looking at their code.
3. People over metrics. Rather than make administrative decisions on the basis of the spreadsheet, decisions will be made on holistic evaluations of employees' performance. This doesn't come for free - it places responsibility on management (see above) but also on the individual contributors. In the same sense that living outside of prison means that individuals must take responsibility for feeding themselves, living outside of spreadsheet managerialism means that individuals must take responsibility for their own career advancement. ICs are encouraged to actively solicit feedback and advocate for their own interests.

The Individual Contributor

ICs are the bedrock of an engineering org. How do we ensure that our "holistic evaluations" of them are fair and understood? The following is a (non-exhaustive) list of qualities that managers will keep in mind when evaluating engineering ICs' performance, which will be done on a continual basis.

1. Competence. The number one, most important quality in an IC is how capable they are of delivering high-quality results on time.
2. Seriousness. Competence must be built over time, but seriousness - caring about doing a good job - is an expectation from day one.
3. Trustworthiness. If they say they'll do something, others can safely take them at their word.
4. Proactivity. Great ICs identify problems, opportunities, feature gaps, etc., and take individual initiative to fix or exploit them for company gain. This is inherently risky behaviour, so I recommend making sure you're competent before going out on a limb.
5. Helpfulness. Internal helpfulness means contributing to the internal yang and mainly means helping out your colleagues when they're swamped or confused. External helpfulness means embodying that service-oriented exterior.
6. Discipline. Achieving a high-quality product sometimes means a long and lonely slog; in those cases, discipline is what gets you through.
7. Knowledgeability. There's a world of difference between an IC who knows the code and one who doesn't. An IC who knows the code can debug problems just from a description, or spot bugs before they appear. Their estimates are also way more accurate. An IC who doesn't know the code tends to take forever to fix bugs and also makes terrible architectural decisions.
8. Wisdom. A wise IC will have an instinctive sense of which risks to take, and which are unlikely to pan out. Wise ICs will be trusted with greater latitude and responsibility. There's no shortcut to achieving engineering wisdom, you just have to write and read a lot of code.
9. Risk-tolerance. We have to create a bunch of stuff that's never been created before. Creation is an inherently risky activity, so great ICs are ones who don't shy away from risk, but rather embrace and manage it. All the other qualities on this list combine to build individuals and teams that are capable of managing risk and creating hitherto nonexistent solutions.