Based on this summary, it may not even be worth your time to signup
> our interviews with executives, reveals that purpose is only one contributing factor; the level and quality of interpersonal collaboration actually has the greatest impact on employee engagement.2 In this article, we’ll explore why collaboration has that effect and which behaviors you can adopt and practic
> ... Google’s intense data collection and number crunching have led it to the same conclusions that good managers have always known. In the best teams, members listen to one another and show sensitivity to feelings and needs.
> ... Google, in other words, in its race to build the perfect team, has perhaps unintentionally demonstrated the usefulness of imperfection and done what Silicon Valley does best: figure out how to create psychological safety faster, better and in more productive ways.
> Project Aristotle is a reminder that when companies try to optimize everything, it’s sometimes easy to forget that success is often built on experiences — like emotional interactions and complicated conversations and discussions of who we want to be and how our teammates make us feel — that can’t really be optimized.
I recall a study that found that the difference between good and bad teams most of the time was ... if they have a bad member on the team or not.
It wasn't the quality of the members, it was if there was just one "bad" member, or not. One bad member could sink a team no matter how good everyone else was.
They did find a sort of magic outlier where if the team member had an outstanding leader they could overcome the one bad member. However they believed that those folks were so rare and you're unlikely to find them that it's not something a team can strive to have.
That's interesting. Do you have a link to the study? Also was "bad" here incompetence? Or toxicity? I would imagine they have pretty different effects.
Sadly I do not. I heard about it on an NPR story ages ago and can't find anything about it.
Their measurements as for "bad" was largely based on their observations of teams meetings. Factors like simply being negative, insults (or close to insults, what we probabbly call toxicity today), disruptive, disrespectful, not being prepared (I found this one interesting as NOBODY seems prepared for a meeting anymore), and things like simply trying to change direction on any plans that were agreed to repeatedly.
Your quote is incomplete and makes it seem like they only used interviews with executives. Here's the piece you're missing in case it matters to people, and it should, since I'd be a lot more interested to read something that wasn't simply a bunch of interviews with execs.
> our research using organizational network analysis (ONA) and our interviews with executives
Would have like to hear at least one concrete exemple of startup actually doing that.
Seems a bit theoretical at the moment, as big companies doesn't need to do that thanks to existing datasets, and I've never heard any startups using dozens (hundreds?) of contractors for this kind of job.
CrowdFlower does AI and ML-focused microtasking, though I have no experience with them. Even large companies need plenty of preprocessing done on their datasets, so it's common to use offshored services companies or divisions to do annotation and cleanup work on corpora before using them as training sets.
In very broad strokes this is how we power many of our API features at Diffbot. We have hundreds of thousands of human-trained web pages amounting to millions of individual elements that have helped to train our system.
Not a start-up and not deep learning (until now I suppose), but this have been done for years in the translation industry.
They feed their automatic systems with the output of the human translator. Every input means less and less manual work that need to be done in the future.
the post office used humans for many years to train OCR models, e.g. zip code readers.
I visited a postal routing facility once in the 90s and saw a long row of metal stationed by about 20 people, 10 to each side. Envelopes passed through on a sort of pneumatic tube-like conveyor, paused in front of a human operator who read a single digit of a zip code, keyed it in and sent the envelope to be read by the next person.
Once you have two providers, you are forced to only use the features offered by each of them and use an abstract layer (API agnostic dev).
Abstraction layers don't necessarily need to produce lowest common denominator results.
Plus, AWS offers a wide range of strategies to ensure the availability of its infrastructure (Availability Zone, Regions, CDN etc.)
You still wind up vulnerable to quirks of the single provider though! For example, account freeze for whatever reason (financial quirks, legal issues, regulatory change) any multi-site failures (eg. financial, operational, legal, security) at that provider.
> Abstraction layers don't necessarily need to produce lowest common denominator results.
Except in the special case that you can build the functionality not provided by using other functionality that is, I think they do, since otherwise it's leaking. A leaky abstraction is often worse than none.
I think your assumption is that cloud providers with different features cannot be abstracted without making the whole abstraction 'leaky'.
While your perspective may hold for a traditional, rigid, single-layer, abstraction layer with the most simplistic, binary-level feature presence, it does not hold for better formed solutions. From https://en.wikipedia.org/wiki/Abstraction_layer: All problems in computer science can be solved by another level of indirection (David Wheeler).
Some real world differences between cloud providers: available hardware, available installation images (OS images), available bandwidth, available logical location on the internet, available physical location (legal jurisdiction, etc.), scale-out time, cost model.
How do you conceive of these differences, and then deploy arbitrary services to an arbitrary number of individual instances running unique combinations of cloud provider specific features on unique cloud-provider deployed OS images in parallel? There are various approaches, but it's not that hard to come up with a functional set of abstractions. Think about it.
