Earlier in the week I did a poll on topics and the number 1 pick by an overwhelming margin (beyond Sad Ass Salad) was "Business Domain vs Functional Domain in Performance Evaluations."
Functional Domain vs Business Domain
In many corporate career development guides, there aren't any distinctions between functional skill and business domain knowledge.
Functional Skill Set is easiest described as the skill of the fundamental tasks needed to complete a job. Business Domain knowledge is easiest described as knowledge in company and business landscape
Here are Some examples of functional vs business domain:
Football Player: a wide receiver who has amazing combine stats vs someone who is already really familiar with a team's offensive scheme.
Product Manager: someone who can document any as-is state vs someone who really knows food delivery operations
Fighting Games: someone who is amazing at footsies vs super familiar with the latest meta
Business Domain and Institutional Knowledge
But to take it a bit further, especially with software development, there's a lot of parallel between business domain and institutional knowledge. Probably the most common example of someone excelling in their position is when they are able to contribute independently to a given application's code. In many situations, it's very common for one to use that as an example of a developer thinking that this knowledge allows them to be the Lead of a given team if that app is the main focus.
Knowing "where the bodies are buried"
Both business and institutional knowledge are foundations that are commonly built over time and exposure to the job and all the elements that come with it.
Knowledge of Business Industry
Business industry may not be something that is common in software engineering companies but probably most commonly it is surrounding experience and knowledge of use cases that one has been exposed to in past positions. My personal experience ranged from Navair conops, to trucking logistics, to on-demand food delivery, and now, ticketed events. An explicit example where my knowledge of a coworker's previous exposure to accounting use cases allowed us to very quickly build a subledger recording system that can ultimately be imported into accounting systems such as quickbooks or netsuite.
Probably the most prominent examples of hiring someone for their business domain expertise on the engineering side is Product Management, people who have already had hands-on experience in the use cases that you're looking for.
Outside of engineering, sales is extremely common in hiring someone who already has an established network within the leads that you're pursuing.
Both should be valued and nurtured
Both of these elements in one's contributions to a company are important and their strengths in either form play a large part to the makeup of your team. However, overemphasizing on one versus the other can hinder not only an employee's development but also create an imbalanced incentive structure that can lead to organizations not equipped to handle situations at hand.
Examples of Institutional Knowledge being over valued
As a manager, it's very easy to depend on the same person over and over again work in an area they are well practiced at. This may give the impression that they are a high performer. As a result, you may find yourself with people in higher positions that may not be equipped in handling new-to-them situations.
A common situation: a "lead" developer who has spent the past 5 years focuses on user facing features for an application being tasked with scaling the application for 2x annual traffic growth, where they may not be equipped to lead such a task.
Example of Functional Skill set being over valued
Conversely, someone who focuses entirely on developing to spec without taking the time to know the context of the ask can lead to a lot of redundant conversation in reviewing rationale for requirements.
However, probably the biggest impact of the line of thinking that "someone with the right skill will understand the job quickly" is reflected in the sheer breadth and scope in layoffs that we're seeing today. You want your teams to build institutional knowledge in low stress situations, not in a production incident. A lot of leadership teams are making assumptions that team members are interchangeable with little impact.
Tech Leadership and poor performance evaluation practices are responsible for the layoffs happening today
Hot Take: The tech industry is ripe with unqualified people in senior level positions commanding amazingly high salaries as a result of performance evaluations valuing little more than the institutional knowledge that they have developed, no matter how myopic it may have been. As a result, the price to productivity is at an all time low.
Companies feeling that price to productivity is low are responding with layoffs and lazily blaming remote work. Any seeming culture in complacency is a direct result of management, not generational differences.
In the end, having a balanced evaluation process identifying both functional skill and institutional knowledge as key areas of performance and improvement can bring you closer to having a productive team with the right incentives to succeed.
No comments:
Post a Comment