Face-to-face conversations The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Manifesto for Agile Software Development teamwork
On Teamwork What I’ve always felt that a team of people doing something they really believe in is like, is like when I was a young kid, there was a widowed man that lived up the street. He was in his 80’s, and a little scary looking, and I got to know him a little bit — I think he paid me to cut his lawn or something — and one day he told me, “come into my garage, I want to show you something.” And he pulled out this dusty old rock tumbler. It was a motor and a coffee can and a band between them. And he said “come out here with me,” so we went out to the back and we got some rocks, just some regular old ugly rocks and we put them in the can with a little bit of liquid and a little bit of grit powder, and he turned the motor on and said “come back tomorrow,” as the tumbler was turning and making a racket. So I came back the next day and what we took out were these amazingly beautiful and polished rocks. The same common stones that had gone in — through rubbing against each other, creating a little bit of friction, creating a little bit of noise — had come out as these beautiful polished rocks. And that’s always been my metaphor for a team working really hard on something they’re passionate about. It’s that through the team, through that group of incredibly talented people bumping up against each other, having arguments, having fights sometimes, making some noise, and working together, they polish each other, and they polish their ideas. And what comes out are these really beautiful stones. Steve Jobs, Steve Jobs: The Lost Interview teamworkpassionargument
A small team of committed coworkers The innovative designer also likes, perhaps needs, to work with a small team of committed co-workers who share the same passions and dedication. Nigel Cross & Anita Clayburn Cross, Winning by Design: The Methods of Gordon Murray On Talent teamwork
We come as a team There is a legend at Cooper of one team who found pairing with each other so powerful and fruitful that when they left that company, they sought out opportunities and even interviewed at other organizations as a pair. Gretchen Anderson & Christopher Noessel, Pair Design: Better Together teamwork
Hand and brain chess In hand and brain chess, each team has two players: a “brain” and a “hand.” At the beginning of each turn, the “brain” tells the “hand” which piece to move, and the “hand” then has to move that piece, but can move it wherever they think it should go. No other communication is allowed. Matthew Ström, The hand and the brain matthewstrom.com gamesteamwork
Serendipity This was not meant to be like Bell Labs; there were no expectations that the clerical workers would run into their managers in a “serendipitous encounter” and produce a new innovation. The ideas was rather to create a workplace in which status barriers seemed to dissolve, in which participation and friendliness all around made the work environment look less like the white-collar factory it was. Nikil Saval, Cubed The Art of Doing Science and Engineering: Learning to Learn teamworkcommunication
The cubicle The cubicle had the effect of putting people close enough to each other to create serious social annoyances, but dividing them so that they didn’t actually feel that they were working together. It had all the hazards of privacy and sociability but the benefits of neither. It got so bad that nobody wanted them taken away; even those three walls offered some kind of psychological home, a place one could call one’s own. All these factors could deepen the frenzied solitude of an office worker. Nikil Saval, Cubed workteamworksolitudeprivacy
Viability, usablity, feasibility In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us. However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap. Marty Cagan, Product vs. Feature Teams svpg.com What went wrong? teamwork
Intuition and systems Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team? Frederick P. Brooks, Jr., The Design of Design designteamwork
Political chains of influence In Chicago, formal chains of influence and authority are entirely overshadowed by the ad hoc lines of control which arise naturally as each new city problem presents itself. These ad hoc lines depend on who is interested in the matter, who has what at stake, who has what favors to trade to whom. This structure, which is informal, working within the framework of the first, is what really controls public action. It varies from week to week, even from hour to hour, as one problem replaces another. Nobody’s sphere of influence is entirely under the control of any one superior; each person is under different influences as the problems change. Although the organization chart in the Mayor’s office is a tree, the actual control and exercise of authority is semilattice-like. Christopher Alexander, A City Is Not a Tree politicsteamworkorganization
Instruments of cooperation When work isn't shared, the instruments of cooperation – listening, taking note, adjusting – atrophy like muscles that are no longer in use. Ursula M. Franklin, The Real World of Technology workteamwork
Rapport "Bob's rapport with the workers is extraordinary. Reminds me of something Noguchi once pointed out about Bernini during the days he was building St. Peter's in Rome: how what made him so special, aside from his own obvious gifts, was his ability to extend himself through the work of others, to get them on his side and working in his direction." Lawrence Wechler & Robert Irwin, Seeing Is Forgetting the Name of the Thing One Sees leadershipteamwork
The power of One An Article by Kathy Sierra headrush.typepad.com It's not teams that are the problem, it's the rabid insistence on teamwork. Group think. Committee decisions. Most truly remarkable ideas did not come from teamwork. Most truly brave decisions were not made through teamwork. The team's role should be to act as a supportive environment for a collection of individuals. People with their own unique voice, ideas, thoughts, perspectives. A team should be there to encourage one another to pursue the wild ass ideas, not get in lock step to keep everything cheery and pleasant. ideasteamworkcollaboration
Individuals matter An Article by Dan Luu danluu.com One of the most common mistakes I see people make when looking at data is incorrectly using an overly simplified model. A specific variant of this that has derailed the majority of work roadmaps I've looked at is treating people as interchangeable, as if it doesn't matter who is doing what, as if individuals don't matter. Individuals matter. On Talent teamworkplanningwork
Design Leadership Truisms An Article by Peter Merholz www.petermerholz.com PEOPLE ARE NOT THEIR JOB TITLES. TEAM MEMBERS ARE NOT “RESOURCES”. PEOPLE WORK BEST WHEN THEY CAN BE THEIR FULL SELVES. YOU CANNOT CALCULATE AN ROI FOR DESIGN. FRAMING THE PROBLEM IS MORE IMPORTANT THAN SOLVING THE PROBLEM. (DESIGN) LEADERSHIP IS MORE TALKING THAN DOING. YOU’LL DO A BETTER JOB IF YOU LIGHTEN UP IF YOU HAVEN’T PISSED SOMEONE OFF, YOU’RE NOT DOING YOUR JOB RIGHT. NO ONE OUTSIDE YOUR TEAM UNDERSTANDS WHAT IT TAKES TO DO GOOD WORK. THE OUTCOMES ARE BETTER WHEN EVERYONE IS A DESIGNER. AGILE TRANSFORMATIONS ARE HOSTILE TO GOOD DESIGN. WHAT A DESIGN TEAM NEEDS MOST IS A CLEAR SENSE OF PURPOSE. YOU ARE ON THE FRONT LINE OF A GLOBAL WAR FOR TALENT. EVERYONE APPLYING FOR A ROLE HAS AN INFLATED TITLE. INTERVIEWS ARE A POOR WAY OF ASSESSING CANDIDATES. DESIGN EXERCISES ARE A BAD INTERVIEWING PRACTICE. YOU WILL NEVER HAVE ENOUGH DESIGNERS. YOU WILL NEVER HAVE ENOUGH TIME. THE SKILLS THAT GOT YOU HERE ARE NOT THE SKILLS THAT WILL CARRY YOU FORWARD. Truisms designleadershipteamwork
The Small Group An Article by James Mulholland jmulholland.com Lying somewhere between a club and a loosely defined set of friends, the SMALL GROUP is a repeated theme in the lives of the successful. Benjamin Franklin had the Junto Club, Tolkien and C.S. Lewis had The Inklings, Jobs and Wozniak had Homebrew. Around a dozen members is the sweet spot of social motivation: small enough to know everyone, yet large enough that the group won’t collapse if one or two members’ enthusiasm wanes; small enough that you are not daunted by competing with the whole world, yet large enough that you still need to be on your toes to keep up. Seeing Is Forgetting the Name of the Thing One SeesMutual appreciationSceniusTossing an idea around teamworkcreativityinnovationcollaboration
Mutual appreciation A Fragment by Matt Webb interconnected.org To use slightly different terms, mutual appreciation is a healthy jealousy without envy – a drive to achieve the same but without wanting to take it from the other. The Small GroupScenius collaborationteamwork
The small web is beautiful An Essay by Ben Hoyt benhoyt.com I believe that small websites are compelling aesthetically, but are also important to help us resist selling our souls to large tech companies. In this essay I present a vision for the “small web” as well as the small software and architectures that power it. Why aim small?Features and complexitySolving the problem of software bloatRaw size isn't enough Rediscovering the Small Web wwwmicrosites
Why aim small? Why aim small in this era of fast computers with plenty of RAM? A number of reasons, but the ones that are most important to me are: Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong. Small software is faster. Fewer bits to download and clog your computer’s memory. Reduced power consumption. This is important on a “save the planet” scale, but also on the very local scale of increasing the battery life of your phone and laptop. The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone. performancesystemsconservation
Features and complexity Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called A Plea for Lean Software. His take is that “a primary cause for the complexity is that software vendors uncritically adopt almost any feature that users want”, and “when a system’s power is measured by the number of its features, quantity becomes more important than quality”. A Plea for Lean SoftwareSpeed is a featureRequirements proliferation featurescomplexity
Solving the problem of software bloat But instead of just complaining, how do we actually solve this problem? Concretely, I think we need to start doing the following: Care about size: this sounds obvious, but things only change when people think they’re important. Measure: both your executable’s size, and your program’s memory usage. You may want to measure over time, and make it a blocking issue if the measurements grow more than x% in a release. Or you could hold a memory-reduction sprint every so often. Language: choose a language that has a chance. Remove: cut down your feature set. Aim for a small number of high-quality features. My car can’t fly or float, and that’s okay – it drives well. Say no to new features: unless they really fit your philosophy, or add more than they cost over the lifetime of your project. Dependencies: understand the size and complexity of each dependency you pull in. Use only built-in libraries if you can.
Raw size isn't enough A few months ago there was a sequence of posts to Hacker News about various “clubs” you could post your small website on: the 1MB Club, 512KB Club, 250KB Club, and even the 10KB Club. I think those are a fun indicator of renewed interested in minimalism, but I will say that raw size isn’t enough – a 2KB site with no real content isn’t much good, and a page with 512KB of very slow JavaScript is worse than a snappy site with 4MB of well-chosen images. ...[Instead, it's about] an “ethos of small”. It’s caring about the users of your site: that your pages download fast, are easy to read, have interesting content, and don’t load scads of JavaScript for Google or Facebook’s trackers. minimalismcontentsize