8 ms·

Senior leaders and people that want to get there take note: cognitive load is the base problem one solves for when scaling development organizations. This artic

Senior leaders and people that want to get there take note: cognitive load is the base problem one solves for when scaling development organizations. This article is a pretty good introduction -- especially building with empathy and emphasizing "what" over "how". But one can also look to any tech company that provides an API devs like (my fav: Stripe) as an example of what low cognitive load relative to the problem looks like. Truly talented leaders tend to realize that high cognitive load comes from lots of places besides technical considerations too. It can be hard to think about a problem when you're also dealing with a toxic team member, untrustworthy leadership, lack of organizational focus, shitty HR policies, feeling unsafe at work, etc. Unfortunately, fighting against those elements is a never-ending battle. Leaders that mix low cognitive load with clear direction and an interesting problem start to approach that highly-sought-after "early startup productivity" that so many companies can't seem to figure out. At least until a re-org, acquisition, or change in the c-suite comes along and blows it all up.

frequentnapper 7y ago
Just also wanted to add a big factor can be personal problems as well. Many of them can't be helped, but things like transportation, commute time, local real estate prices, health insurance, etc. can be helped and should not be overlooked.
alexpetralia 7y ago
This is super useful. I've summarized this in my head as: minimize cognitive load for stakeholders (e.g. customers, employees, investors, etc.)
crimsonalucard 7y ago
This is why people who can't handle too much cognitive load end up being better leaders. Or in other words... less intelligent people make better leaders. On a side note, less intelligent people also write more readable code. The principle, Keep it simple stupid, aka kiss is indeed better followed by people who are described by the acronym. So in other words... A simple and stupid person is better at keeping their code and designs simple and stupid than a smart and complicated individual.
- pault 7y ago
  I respectfully disagree. Simple and elegant code is extremely difficult to write, and the ability to do so is mostly orthogonal to intelligence. However, below a certain threshold of skill and capacity for reasoning about spatial complexity, the developer is much more likely to write confusing, tangled, unnecessary, and verbose code. Reading through a codebase with tons of copy pasted code requires far more effort than a codebase with well designed abstractions. The key phrase there is well designed. What you are describing is someone who know which abstractions to use when and where, and that is a skill that requires lots of experience and technical maturity.
  - crimsonalucard 7y ago
    I respectfully disagree with your disagreement. Experience and technical maturity do not equate with intelligence. Abstractions serve one purpose and one purpose only: to reduce cognitive work load. Any abstraction above a primitive implementation only can offer added inefficiencies . Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly. So from a technical standpoint, we use abstractions only to reduce cognitive workload because other than that abstractions can only offer inn-efficiencies. Intelligent people do not put in the effort to learn about or implement proper abstractions because they usually deem it unnecessary to abstract what they perceive to be trivial cognitive workloads..
    - zamber 7y ago
      I respectfully disagree with your disagreement of that disagreement. Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity. From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python). If you want to utilize your intelligence to the fullest you abstract away most of the trivial stuff to the point where it pays. You can still go down and inspect or override the abstraction if it's needed. Experience in this case is knowing what to abstract in what manner so it will work for you. Intelligence is the act of keeping everything in a sane state without over-focusing on unimportant stuff. What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience. KISS is a suggestion, not a rule. It also applies to abstractions, so in one could argue that doing everything in assembly is actually the "simplest" way of programming, like a rough sketch of a scene is simpler than a full-blown oil painting. As an aside the whole notion of "intelligence" is a bit twisted with experience IMO. The "classical" IQ applies mostly to dumb pattern matching - a skill one can perfect. EQ can be trained by getting out and deliberately practicing human interactions.
vikiomega9 7y ago
Do you have examples of companies that come close to having low cognitive load?
- thomasmeeks 7y ago
  Unfortunately not any that still exist. The only companies that seem to be able to accomplish it are early stage startups; because it is orders of magnitude easier to do with such a small group of people. Code School & Envy Labs are my personal examples. I do think it is possible at large companies. I've built, been part of, and talked with managers that have created teams that obviously have low load (due to how much they produce, satisfaction with work, and level of trust). But it never lasts for long. Inevitably something like Radford is implemented by HR or some VP gets the reorg itch and tears down the system because these sorts of details haven't made it into boardrooms beyond "two pizza teams". Pluralsight and Amazon are my personal experiences with large companies.
cosmie 7y ago
> cognitive load is the base problem one solves for when scaling development organizations. Just to add, this generalizes beyond just development orgs. I've scaled out analytics orgs at a few companies, and one of the most difficult aspects is penetrating into the workflows of business functions. As a rule, most[1] business users tend to operate at a high level of cognitive load, with little in the way of support structures to reduce that. But effectively integrating operational analytics requires[2] contextualization. So more often than not, the analytics scaling acts as a forcing function to put in place the operational and process supports needed for that contextualization, which has the secondary effect of reducing the cognitive load of the end users. In more than one occasion, I've seen that secondary effect have a greater impact than the analytics itself. [1] A major exception to this rule are tech companies and companies with technical founders. If the core of your business is a technical system, then your business functions are created as extensions of that system and you get a lot of process/structure "for free" on the business side due to that fact. And if that's not the case but you still have technical founders, those individuals will approach business functions with a process/systems-first mentality since that's how they approach technical problems. While it has it's own issues, it does lend itself to reducing the cognitive load of those functions and enabling more efficient scaling. Business leaders will take the opposite approach, where they leave the function mostly unstructured and (ideally) create process, structure, and systems based off of the emergent needs. [2] You can certainly provide analytics deliverables without contextualization. But it won't be nearly as effective, will mostly be ignored, and will rarely actually help anything since it leaves the onus of contextualization and interpretation on the end user and therefore does nothing to reduce their cognitive load.
- techsin101 7y ago
  Commenting to read later. But I'd love an example
  - cosmie 7y ago
    Any particular industry/function/scenario you'd like used as an example? I can think of plenty of examples, but not sure which would click the best for you.

frequentnapper 7y ago

Just also wanted to add a big factor can be personal problems as well. Many of them can't be helped, but things like transportation, commute time, local real estate prices, health insurance, etc. can be helped and should not be overlooked.

alexpetralia 7y ago

This is super useful. I've summarized this in my head as: minimize cognitive load for stakeholders (e.g. customers, employees, investors, etc.)

crimsonalucard 7y ago

This is why people who can't handle too much cognitive load end up being better leaders. Or in other words... less intelligent people make better leaders. On a side note, less intelligent people also write more readable code. The principle, Keep it simple stupid, aka kiss is indeed better followed by people who are described by the acronym. So in other words... A simple and stupid person is better at keeping their code and designs simple and stupid than a smart and complicated individual.

pault 7y ago
I respectfully disagree. Simple and elegant code is extremely difficult to write, and the ability to do so is mostly orthogonal to intelligence. However, below a certain threshold of skill and capacity for reasoning about spatial complexity, the developer is much more likely to write confusing, tangled, unnecessary, and verbose code. Reading through a codebase with tons of copy pasted code requires far more effort than a codebase with well designed abstractions. The key phrase there is well designed. What you are describing is someone who know which abstractions to use when and where, and that is a skill that requires lots of experience and technical maturity.
- crimsonalucard 7y ago
  I respectfully disagree with your disagreement. Experience and technical maturity do not equate with intelligence. Abstractions serve one purpose and one purpose only: to reduce cognitive work load. Any abstraction above a primitive implementation only can offer added inefficiencies . Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly. So from a technical standpoint, we use abstractions only to reduce cognitive workload because other than that abstractions can only offer inn-efficiencies. Intelligent people do not put in the effort to learn about or implement proper abstractions because they usually deem it unnecessary to abstract what they perceive to be trivial cognitive workloads..
  - zamber 7y ago
    I respectfully disagree with your disagreement of that disagreement. Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity. From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python). If you want to utilize your intelligence to the fullest you abstract away most of the trivial stuff to the point where it pays. You can still go down and inspect or override the abstraction if it's needed. Experience in this case is knowing what to abstract in what manner so it will work for you. Intelligence is the act of keeping everything in a sane state without over-focusing on unimportant stuff. What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience. KISS is a suggestion, not a rule. It also applies to abstractions, so in one could argue that doing everything in assembly is actually the "simplest" way of programming, like a rough sketch of a scene is simpler than a full-blown oil painting. As an aside the whole notion of "intelligence" is a bit twisted with experience IMO. The "classical" IQ applies mostly to dumb pattern matching - a skill one can perfect. EQ can be trained by getting out and deliberately practicing human interactions.

vikiomega9 7y ago

Do you have examples of companies that come close to having low cognitive load?

thomasmeeks 7y ago
Unfortunately not any that still exist. The only companies that seem to be able to accomplish it are early stage startups; because it is orders of magnitude easier to do with such a small group of people. Code School & Envy Labs are my personal examples. I do think it is possible at large companies. I've built, been part of, and talked with managers that have created teams that obviously have low load (due to how much they produce, satisfaction with work, and level of trust). But it never lasts for long. Inevitably something like Radford is implemented by HR or some VP gets the reorg itch and tears down the system because these sorts of details haven't made it into boardrooms beyond "two pizza teams". Pluralsight and Amazon are my personal experiences with large companies.

cosmie 7y ago

> cognitive load is the base problem one solves for when scaling development organizations. Just to add, this generalizes beyond just development orgs. I've scaled out analytics orgs at a few companies, and one of the most difficult aspects is penetrating into the workflows of business functions. As a rule, most[1] business users tend to operate at a high level of cognitive load, with little in the way of support structures to reduce that. But effectively integrating operational analytics requires[2] contextualization. So more often than not, the analytics scaling acts as a forcing function to put in place the operational and process supports needed for that contextualization, which has the secondary effect of reducing the cognitive load of the end users. In more than one occasion, I've seen that secondary effect have a greater impact than the analytics itself. [1] A major exception to this rule are tech companies and companies with technical founders. If the core of your business is a technical system, then your business functions are created as extensions of that system and you get a lot of process/structure "for free" on the business side due to that fact. And if that's not the case but you still have technical founders, those individuals will approach business functions with a process/systems-first mentality since that's how they approach technical problems. While it has it's own issues, it does lend itself to reducing the cognitive load of those functions and enabling more efficient scaling. Business leaders will take the opposite approach, where they leave the function mostly unstructured and (ideally) create process, structure, and systems based off of the emergent needs. [2] You can certainly provide analytics deliverables without contextualization. But it won't be nearly as effective, will mostly be ignored, and will rarely actually help anything since it leaves the onus of contextualization and interpretation on the end user and therefore does nothing to reduce their cognitive load.

techsin101 7y ago
Commenting to read later. But I'd love an example
- cosmie 7y ago
  Any particular industry/function/scenario you'd like used as an example? I can think of plenty of examples, but not sure which would click the best for you.