Hacker News new | past | comments | ask | show | jobs | submit login
7 Sins of Doomed Teams (thehumanfactor.co)
48 points by gauberger on Nov 5, 2013 | hide | past | favorite | 16 comments



Repackaging the discussion into a platonified seven sins format is not the right way to approach this.


Agreed. I share the concerns that the author expressed, but I thought the seven sins angle was distracting because they are poor descriptions of what was being articulated.


I disagree. I actually really liked it. It was concise and the seven sins format made it actually easier to remember in order to catch yourself committing one.


...

I'm sorry, this list lost me when it said the first sign of a doomed team were that its members had a natural interest in technology, and a desire to explore that interest in their work.

Sorry, I'll make sure to not enjoy my job from now on.

edit: To be clear, I recognize what this author is saying is that these aspects arn't bad, they should be applied correctly. You should moderate your exploration, but convicted when you change technologies. Reasonable in defence, and humble in error.

None of this says how to do those things. Nor could it.


There is always a balance between trying and exploiting new technologies, whilst not being distracted by them to the detriment of the product.


I'm generally going to agree here.

I'm sick of seeing this heavy-handed language that produces this false dichotomy of "Tech Fetishism" versus "Getting Things Done".

Look, it's not this younger generation's fault that the previous generation abandoned Hypermedia. Stop throwing us under the bus because you started architecting TCP/IP without grokking your own ideas, that sat festoring, as regards what would get built on top.

> Eliminate those distractions. Focus on solving your problem at hand. Stick with what you know and stop lusting after shiny new things.

> Watch for unwanted features sneaking in, bogus justifications for unnecessarily complex architectures and signs of premature optimizations. Keep the product lean.

What problems? (Yes, 15 years ago it was easy to drop a form into a page. But also 15 years ago, Microsoft got sued for antitrust. Now look at where we are: India's going back to typewriters!) We just started figuring this business out. And the Web is a hard problem. And now these architectures are essentially an outgrowth of political questions like, "What is an open government, anyway?" "What is a 'semantic web' anyway?" It's not just aesthetic hooplah. This is condescending and misguided!

(Stop ridiculing us as gluttons. What does that have to do with anything? What good has religious reframing of any problem really done for any phase transition of a system?)

We're trying to get the Web done right. We've had enough of this grossly hierarchical system that you built because the government had an urgent need to keep secrets. Stop throwing us under the bus because we don't agree with an architecture or its substrate based on a war we obviously then, or even now, wouldn't want to fight anyway.

If you need to shoot a bullet, then yeah, HATEOAS, Polymer, Modularization, Open Standards, etc. will seem like a waste of time. But we're not fighting wars anymore; or at least now the way in which wars are fought presuppose a richer Web Architecture (and JavaScript cryptography: http://log.nadim.cc/?p=33).

I'm sorry for the pessimistic tone, but we're just getting to the point where we understand how to properly build these things. And this religious, terrestrial jazz is just not helping. (How do we get to the point where we're building space ships rather than silly hyper-point-of-sale-search-gadget-over-wifi-built-by-a-8-year-old-in-a-half-hour-because-it-figured-it-should-read-open-source-rather-than-Dr.-Seuss?)

It's talk about personality types in the midst of an effort to build a freaking spaceship: http://www.youtube.com/watch?v=b5pFv9NB9fs&feature=youtu.be&...


Although they're not 7 deadly sins, arrogance and delusions of grandeur should be in here somewhere.


I've encountered a team issue that's sort of opposite of "greed".

It's not about "my code", it's about "your code". I often found team members that's reluctant in taking responsibility to fix the problem. When they found an issue in the code base they didn't write, they find the person who originally wrote it to fix the issue rather than tackle it themselves.


I can see it now: Enraptured (#6) with a newly (#1) described 'right way' (#7) of doing things violators of rule (#5) are posting this to their coworkers and friends.


this seemed shoehorned, with teeth


I disagree with the premise that these are signs of doomed teams. All teams show these "sins" to some degree. Successful teams make them a virtue.

It seems to me that the post is not well thought out in its premise or conclusion.


Typo in first sentence is not very welcoming.


Thanks for catching this. Corrected.


Not a typo, but the usual metaphor here is "fiefdom":

"Excessive specialization and compartmentalization creates thiefdoms."


Indeed. Thanks.


The gist I gather is Don't Mix Talent, where if talents are mixed these Sins will become more probable, with varying degrees of manifestation. Why do I say this? – There is collaborative sinning; and sometimes we nurture the sins of our peers.

Hiring is a gamble, and we all play the cards we're dealt.

The rub is that with highly heterogeneous teams, players' sins will be traded quid pro quo under what the management knows (they're non-technical, right?) and under the radar generally.

A doomed team is one that lacks the wisdom to recognize that sinning is essential, one that lacks the flexibility to allow it, and one that lacks the awareness to judiciously calculate it. A team that leaves its sins untrained misses the opportunity to nurture it.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: