5 ms·

Ugh. I just finished reading "Staff Engineer" book [1] and it listed "Architect" as one of four archetypes. The architect there is very different from the one

Ugh. I just finished reading "Staff Engineer" book [1] and it listed "Architect" as one of four archetypes. The architect there is very different from the one in this article, and I'll support the book than this article. Simply put, the architect in this article is probably too micro-managing and tyrannic. Although that isn't stated explicitly, the lack of arrows across devs is symbolic, as well as the "surgeon" metaphor. The team I'd like to be in is more loosely coupled and less hierarchical, and I'd love an architect to be more ambient than opinionated. Many architects would disagree and that's fine. I just want to drop my 2c here. [1] https://staffeng.com/book https://staffeng.com/book

all2 5y ago
Pop psych structures and archetypes are sometimes useful for thinking about ourselves, our relationships with others, and our orgs. I think they can be overwrought, though, and used precisely when they're supposed to be a "if you squint you might see these things around you" way. I'm rather a fan of the Biblical "raise a child in the way they should go and they won't depart from it"; train someone with the essentials of the their job, reinforce the good habits, and (if they take ownership) they will continue to do those things they were taught even when they are no longer closely managed. The above presumes "close management" at the beginning of the "life" of someone new to the job, and then as they age in the organization "distant management", and eventually leadership. close management != micro management, consider close management to be the same kind of process a child goes through when learning. First we show them, then we explain to them what we did, then they try it with supervision (this is where most of my learning occurs), then we let them do it without supervision. You could think of this in terms of how big a learner's feedback loop from others is: at the start their feedback loop from "engineer dad" is tight; they get feedback very often, correction and discipline where necessary. As they learn, the feedback loop loosens and they have a chance to move into their "engineering teens". Eventually the feedback loop is loosely coupled; "engineer dad" now advises infrequently and offers guidance and advice when requested. ;) My little framework is as useful as any other pop-psych, you just have to squint at your org/experiences to see it.
- Mauricebranagh 5y ago
  This is based on real world surgical practice
  - azalemeth 5y ago
    Is it really? What about the expert, critical yet friendly review from other colleagues/competitors; the MDT meeting; the ward round? Most surgical patients have an incentive to never see the surgeon again, and the surgeon is strongly incentiveised to avoid having to see them again in the immediate future (i.e. to fix a postoperative bleed, etc). Is the same thing true of corporate programmers? All metaphors are wrong. Some are useful. Is this one?
    - Mauricebranagh 5y ago
      Well it was the inspiration I believe it was IBM - I will have to check my copy of Mc Connell Rapid Software Development
      - wheelinsupial 5y ago
        If you’re referring to this part of the comment: > First we show them, then we explain to them what we did, then they try it with supervision (this is where most of my learning occurs), then we let them do it without supervision. It strikes me as coming close to the TWI job instruction training method [1] the US developed in the 40’s to train workers for war production. [1] https://www.allaboutlean.com/twi-job-instructions/ https://www.allaboutlean.com/twi-job-instructions/
Mauricebranagh 5y ago
I think in our industry this is normally called CPT (Chief Programmer Team) I have worked in teams like that and the idea is the Chief and developers do the development - though normally individuals can have multiple roles in smaller teams. The chief Programmer is a hands on role as I see it. With the Right Team its great - developers that obsess about leetcode scores arenot going to be a good fit

all2 5y ago

Pop psych structures and archetypes are sometimes useful for thinking about ourselves, our relationships with others, and our orgs. I think they can be overwrought, though, and used precisely when they're supposed to be a "if you squint you might see these things around you" way. I'm rather a fan of the Biblical "raise a child in the way they should go and they won't depart from it"; train someone with the essentials of the their job, reinforce the good habits, and (if they take ownership) they will continue to do those things they were taught even when they are no longer closely managed. The above presumes "close management" at the beginning of the "life" of someone new to the job, and then as they age in the organization "distant management", and eventually leadership. close management != micro management, consider close management to be the same kind of process a child goes through when learning. First we show them, then we explain to them what we did, then they try it with supervision (this is where most of my learning occurs), then we let them do it without supervision. You could think of this in terms of how big a learner's feedback loop from others is: at the start their feedback loop from "engineer dad" is tight; they get feedback very often, correction and discipline where necessary. As they learn, the feedback loop loosens and they have a chance to move into their "engineering teens". Eventually the feedback loop is loosely coupled; "engineer dad" now advises infrequently and offers guidance and advice when requested. ;) My little framework is as useful as any other pop-psych, you just have to squint at your org/experiences to see it.

Mauricebranagh 5y ago
This is based on real world surgical practice
- azalemeth 5y ago
  Is it really? What about the expert, critical yet friendly review from other colleagues/competitors; the MDT meeting; the ward round? Most surgical patients have an incentive to never see the surgeon again, and the surgeon is strongly incentiveised to avoid having to see them again in the immediate future (i.e. to fix a postoperative bleed, etc). Is the same thing true of corporate programmers? All metaphors are wrong. Some are useful. Is this one?
  - Mauricebranagh 5y ago
    Well it was the inspiration I believe it was IBM - I will have to check my copy of Mc Connell Rapid Software Development
    - wheelinsupial 5y ago
      If you’re referring to this part of the comment: > First we show them, then we explain to them what we did, then they try it with supervision (this is where most of my learning occurs), then we let them do it without supervision. It strikes me as coming close to the TWI job instruction training method [1] the US developed in the 40’s to train workers for war production. [1] https://www.allaboutlean.com/twi-job-instructions/ https://www.allaboutlean.com/twi-job-instructions/

Mauricebranagh 5y ago

I think in our industry this is normally called CPT (Chief Programmer Team) I have worked in teams like that and the idea is the Chief and developers do the development - though normally individuals can have multiple roles in smaller teams. The chief Programmer is a hands on role as I see it. With the Right Team its great - developers that obsess about leetcode scores arenot going to be a good fit