[HN Gopher] Updated Concept of "The Surgical Team"
___________________________________________________________________
Updated Concept of "The Surgical Team"
Author : ptr
Score : 49 points
Date : 2021-05-10 20:26 UTC (1 days ago)
(HTM) web link (www.codeproject.com)
(TXT) w3m dump (www.codeproject.com)
| pseudalopex wrote:
| Office suites and email clients don't handle correspondence or
| finish documents. Stack Overflow and Google only propose changes
| when people know what to ask. Static analyzers don't replace
| knowing the language and libraries in depth. Good requirements
| need tight cooperation.
| flakiness wrote:
| 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
| all2 wrote:
| 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 wrote:
| This is based on real world surgical practice
| azalemeth wrote:
| 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 wrote:
| Well it was the inspiration I believe it was IBM - I will
| have to check my copy of Mc Connell Rapid Software
| Development
| Mauricebranagh wrote:
| 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
| throwaway346434 wrote:
| I disagree in the sense the architect should be hands off and a
| source of good practice, recommendations, and an all round
| enabler. But the dev at the coalface? They own the solution.
| Mauricebranagh wrote:
| That is not how CPT / Surgical teams work
| throwaway316943 wrote:
| I don't think the updated concept in this article is an
| improvement. It seems to be a regression to the hog butchering
| style but with a chief butcher who draws a few lines on the pig
| and then tells his team to go at it while he makes a few of the
| more delicate cuts.
| codingdave wrote:
| This kind of content is good food for thought, but it always
| makes me think back to an article that I read 15 years ago (and
| cannot find again), that said in short, "Tech teams are full of
| smart people that will self-organize. They will ignore your org
| charts and team visions, and fall in line into the best working
| team they can, based on their own evaluations of each others
| skills and knowledge.... so long as you just leave them alone to
| do it."
|
| And my best teams have been the ones where the leadership let us
| do exactly that. They might talk to us about their ideas of how
| we should do things and how we should organize ourselves, but
| ultimately they did what most good leaders do, which is to hire
| smart people, task them with what needs done, and then leave them
| alone.
| codemac wrote:
| Of course the _best_ teams ended up like this - it means there
| were many many different explicit negotiations that didn 't
| need to happen.
|
| I think the harder problem to solve is mediocre teams, and
| mediocre management - all well meaning folks. I'd really like
| to see programming succeed with a mediocre team.
| aloisdg wrote:
| As someone interesting in self-organizing team, I would love
| that book's name if someone else know it.
| pseudalopex wrote:
| I agree to a point. A team will self organize better testing if
| you hire someone with interest and skill in testing though.
| marcinzm wrote:
| Why do YOU need to decide who to hire for the team? Let the
| team tell you what they are deficient in and then hire that.
| zepto wrote:
| What if they don't have the experience to know, but you do?
| pseudalopex wrote:
| They described a process that started with management
| hiring people. And it's true even when "you" is the team.
| But teams can have blind spots too.
| andrekandre wrote:
| I stand on the position that hierarchy is innate to human beings.
|
| im not sure, but isnt he conflating "division of labor is
| necessary for well-functioning projects/teams" and "human nature"
| ??
|
| maybe im missing something...
| random314 wrote:
| The article states that hierarchy is innate to human beings and
| links to Jordan Peterson as a reference?! This is a core belief
| of conservative thinking and is a political posture, not a
| scientific truth.
|
| Hierarchies are a characteristic of agricultural societies and
| almost completely absent in hunter gatherer societies that
| precede it. Hunter gatherer societies are typically egalitarian.
| prionassembly wrote:
| Yes, but are there any political philosophies that advocate the
| adoption of elements of the hunter-gatherer lifestyle?
|
| I mean, sure, you can speculatively postulate that HG-like
| egalitarianism is possible in non-HG societies. But that goes
| against the overwhelming mass of evidence.
| marcinzm wrote:
| Surgical teams work under very specific constraints such as a
| tight time limit, mostly repetitive/practiced tasks, limited
| concurrent work (only so many hands can fit inside a patient),
| team size limited by physical constraints of operating room, etc.
| Trying to apply this approach to other domains with different
| constraints, even if only philosophically, seems inherently an
| ill fitting idea.
| throwaway316943 wrote:
| It's metaphor illustrating the difference between a surgical
| team and a hog butchering team i.e. instead of everyone cutting
| away at the problem, just one person does the cutting while the
| others support him.
| pseudalopex wrote:
| It's just a memorable metaphor. Brooks advocated a small team
| of specialists and assistants supporting a hands on lead
| because it's a good way to develop software. Not because it's
| good for surgery.
| [deleted]
| zby wrote:
| The surgical team has limited size because of physical
| constraints - the software team does not have such a strict
| size limit. But we have seen that bigger teams get very very
| slow so we want small teams - so we look for ways to make the
| team smaller. It is useful to copy ideas from one domain to
| another one - it is called advanced analog field. For example
| the ABS system in breaks was developed for aircraft - but later
| someone observed that it would also be useful in cars even
| though they don't have the same operating constraints.
| http://web.mit.edu/evhippel/www/books/DI/Chapter10.pdf
| nwhatt wrote:
| Mythical Man-Month isn't trying to say "surgical teams work
| well - let's apply that approach to software". Instead, it's an
| analogy to explore Fred Brook's thoughts on 10x programmers and
| "building systems with as few minds as possible". Brook's
| attributes the idea to Harlan Mill's paper "Chief programmer
| teams, principles, and procedures" - which I can't find online,
| but I'd be curious how Mills treats the analogy.
| Mauricebranagh wrote:
| Having done this it does work well - a lot better that the
| botched Agile/Scrum solutions that many struggle with.
| marcinzm wrote:
| Most every methodology when applied properly to a well
| functioning organization will work better than a methodology
| applied to a random company. Which says less about the
| methodology and more about how most companies are
| dysfunctional and no methodology will magically make them
| better. So comparing average X to optimal Y isn't I feel a
| fair comparison.
| Mauricebranagh wrote:
| Just but you lose the self appointed scrum masters with no
| real code experience
| PaulHoule wrote:
| Replace "meritocracy" with another word, rinse, repeat, try
| again.
| prionassembly wrote:
| Proponents of "meritocracy" usually mean "no false positives":
| let us not have bad engineers or politicians; let cream rise to
| the top rather than keep messing with the mixture.
|
| Detractors of "meritocracy" usually mean "no false negatives":
| all the cream rises to the top, if you're good you'll win
| always.
|
| The first version is a desideratum; it's a desired end-goal,
| not a warranty. The second is a(n usually true under the second
| definition) empirical claim that meritocracy is impossible.
| PaulHoule wrote:
| The word meritocracy was defined in a work of fiction that
| used it ironically.
|
| People are so literal minded they dropped the irony.
|
| That is, people in power are so desperate to believe that
| they deserve every microgram they have that they grab to
| ideas like that.
|
| In the case of the article there are questions like: "what do
| the members of the team believe about the competence about
| the other members of the team?" and "how competent are the
| members of the team really?" and that is in the context of an
| industry where it is commonly believed that "anybody who uses
| Microsoft SQL Server is a buffoon" or "anybody who uses MySQL
| is a buffoon" together with many similar beliefs.
| seanhunter wrote:
| We have a friend who is an actual architect. Her children sleep
| on the second floor of a house she designed herself and built
| (with her husband). I wonder how many self-described software
| architects would have the confidence in their skills and the
| quality of their work product to put their money where their
| mouth is in the same way?
|
| Team concepts which put one person in the center as the single
| source of all knowledge have a lot of advantages if that person
| is really good, but carry a lot of risk if they are not. There's
| a reason you train to an extremely high level before you become
| the chief surgeon in an actual surgical team.
| echlebek wrote:
| Not to diminish your friend, but that house was almost
| certainly inspected by an engineer before anyone slept in it at
| all. It takes a village.
___________________________________________________________________
(page generated 2021-05-11 23:01 UTC)