3 ms·

>often generalists have lots of historic operational knowledge and strong opinions *citation needed Edit: to be clear, in my experience the specialists that a

by dsnuh 9y ago

>often generalists have lots of historic operational knowledge and strong opinions *citation needed Edit: to be clear, in my experience the specialists that aren't also generalists on some level are the least productive on the team because they have trouble participating outside their knowledge domain. Maybe I have worked at the wrong places though...

shostack 9y ago
To clarify, when a company is young, you have a lot of people wearing a lot of hats. They may in fact be quite good at wearing some of those hats. Likewise, having visibility and exposure to multiple domains aspects of the same company gives a perspective that is hard to have if you live in a super specialized silo. However specialists don't need to be generalists to be productive as long as they come in with the mindset that they are specialists, and therefore may not know everything. And that is especially important, as I highlighted, for respecting historical context of the company and its operations. There might be VERY good reasons for not doing something the way the rest of the industry does it (which is what the specialist might be inclined to do). However a good specialist should also be adept at factoring that into how they approach problems, and properly weigh the new information against their past experience to determine if in fact this is a special snowflake situation, or if their approach is still the right one. Conflict can often arise when if they push for the latter, so strong communication skills are key (and that is something that never really changes for any role at any stage of company growth).
- dsnuh 9y ago
  I get where you are coming from. For me, being a long-term employee having gone through a few transitions from smallish to biggish, and when your storage guy you hired doesn't really know networking basics, or the database administrator has no clue about Linux, etc. it tends to slow everyone down. "Scale" often seems to equate with SF hotshots from one of the big names that will come in and airdrop a brand new architecture. These things take years and you need those generalists that have the tribal knowledge and the ability to jump in (almost) as deeply as a specialized developer, DBA, Network Admin, etc. I think the SRE movement is good evidence of the type of breadth and depth needed to operate a complicated system at scale.
  - majormajor 9y ago
    IMO that's a problem of hiring the wrong specialists, or BS artists in specialist hats (see the article's point about "the tech industry is not serious about hiring" :) ).
    - dsnuh 9y ago
      True. I think it's easier said than done to find the cream of the crop with a limited talent pool for many specialized areas.
    - dsnuh 9y ago
      In other words, we have to go to war with the army we have, not the army we'd like to have. Sometimes waiting for just the right fit isn't an option, either because of the need to keep adding heads for growth, and sometimes you have situations like a Director (just brought in from BigDealCo to lead the growth) has a former employee that knows is "perfect" for the job. Director leaves after a year, after installing people that don't have skills. Catch-22 sometimes.
khedoros1 9y ago
Starting dev of some product, you might have a lot of generalists. They make the original architecture and design decisions, do the first implementations of features, etc. It's their baby. Later on, the company identifies laser-focus areas where specialists are appropriate, and you contract or hire some. The original devs (the generalists) will have knowledge about why something was built a certain way, and might react strongly when the specialist advises deep changes to the program to help it scale up. That's the messy part of the transition: There's kind of the implication that past decisions weren't correct. It's easy for people to get emotionally involved and take personal offense. Example: Backup product. Design started in the late 90s. By late-aughts, multiple CPUs were obviously a serious thing. New guy was brought in, and set on the project of re-architecting the core program into a more asynch data processing model. 6 or 8 months later, the changes were working for base cases, but the senior devs threw an absolute hissy fit focused on how much of their code was changed. We should've banded together and fixed the edge cases. Instead, we spent years fighting over the structure of the program, and that dev transferred to another group. Bringing in security-focused employees worked out better. Their changes were more around the edges of the various programs, rather than in their cores. Fewer toes stepped on, fewer disagreements.
- shostack 9y ago
  >"That's the messy part of the transition: There's kind of the implication that past decisions weren't correct. It's easy for people to get emotionally involved and take personal offense." Thanks for highlighting something I missed in my post. Some of the time yes, the decisions might just be wrong because generalists may not be experienced enough to know the right way to do things. But quite often, they were in fact the right decision at that time and circumstances change. So any sort of process and culture that helps take the emotion and risk of personal offense out of those situations is really critical to gaining the benefit of historical context in a positive manner.

by dsnuh 9y ago

shostack 9y ago

To clarify, when a company is young, you have a lot of people wearing a lot of hats. They may in fact be quite good at wearing some of those hats. Likewise, having visibility and exposure to multiple domains aspects of the same company gives a perspective that is hard to have if you live in a super specialized silo. However specialists don't need to be generalists to be productive as long as they come in with the mindset that they are specialists, and therefore may not know everything. And that is especially important, as I highlighted, for respecting historical context of the company and its operations. There might be VERY good reasons for not doing something the way the rest of the industry does it (which is what the specialist might be inclined to do). However a good specialist should also be adept at factoring that into how they approach problems, and properly weigh the new information against their past experience to determine if in fact this is a special snowflake situation, or if their approach is still the right one. Conflict can often arise when if they push for the latter, so strong communication skills are key (and that is something that never really changes for any role at any stage of company growth).

dsnuh 9y ago
I get where you are coming from. For me, being a long-term employee having gone through a few transitions from smallish to biggish, and when your storage guy you hired doesn't really know networking basics, or the database administrator has no clue about Linux, etc. it tends to slow everyone down. "Scale" often seems to equate with SF hotshots from one of the big names that will come in and airdrop a brand new architecture. These things take years and you need those generalists that have the tribal knowledge and the ability to jump in (almost) as deeply as a specialized developer, DBA, Network Admin, etc. I think the SRE movement is good evidence of the type of breadth and depth needed to operate a complicated system at scale.
- majormajor 9y ago
  IMO that's a problem of hiring the wrong specialists, or BS artists in specialist hats (see the article's point about "the tech industry is not serious about hiring" :) ).
  - dsnuh 9y ago
    True. I think it's easier said than done to find the cream of the crop with a limited talent pool for many specialized areas.
  - dsnuh 9y ago
    In other words, we have to go to war with the army we have, not the army we'd like to have. Sometimes waiting for just the right fit isn't an option, either because of the need to keep adding heads for growth, and sometimes you have situations like a Director (just brought in from BigDealCo to lead the growth) has a former employee that knows is "perfect" for the job. Director leaves after a year, after installing people that don't have skills. Catch-22 sometimes.

khedoros1 9y ago

Starting dev of some product, you might have a lot of generalists. They make the original architecture and design decisions, do the first implementations of features, etc. It's their baby. Later on, the company identifies laser-focus areas where specialists are appropriate, and you contract or hire some. The original devs (the generalists) will have knowledge about why something was built a certain way, and might react strongly when the specialist advises deep changes to the program to help it scale up. That's the messy part of the transition: There's kind of the implication that past decisions weren't correct. It's easy for people to get emotionally involved and take personal offense. Example: Backup product. Design started in the late 90s. By late-aughts, multiple CPUs were obviously a serious thing. New guy was brought in, and set on the project of re-architecting the core program into a more asynch data processing model. 6 or 8 months later, the changes were working for base cases, but the senior devs threw an absolute hissy fit focused on how much of their code was changed. We should've banded together and fixed the edge cases. Instead, we spent years fighting over the structure of the program, and that dev transferred to another group. Bringing in security-focused employees worked out better. Their changes were more around the edges of the various programs, rather than in their cores. Fewer toes stepped on, fewer disagreements.

shostack 9y ago
>"That's the messy part of the transition: There's kind of the implication that past decisions weren't correct. It's easy for people to get emotionally involved and take personal offense." Thanks for highlighting something I missed in my post. Some of the time yes, the decisions might just be wrong because generalists may not be experienced enough to know the right way to do things. But quite often, they were in fact the right decision at that time and circumstances change. So any sort of process and culture that helps take the emotion and risk of personal offense out of those situations is really critical to gaining the benefit of historical context in a positive manner.