Teamwork is lesser work

The whole is greater than the sum of its parts—that’s not true. Not universally, at least. Science has known this since the 19th century, that a proper team working together will often deliver less, and of lesser quality, than if the same individuals were working on their own. It’s high time we question the holy grail of “teamwork” to see exactly where it works and where it fails.

I had an eye-opening moment reading Professor Richard Wiseman’s beautifully practical book 59 Seconds: Think a Little, Change a Lot:

In the late 1880s, a French agricultural engineer named Max Ringelmann became obsessed with trying to make workers as efficient as possible. (…) One of Ringelmann’s studies involved asking people to pull on a rope to lift increasingly heavy weights. Perhaps not unreasonably, Ringelmann expected people in groups to work harder than those on their own. But the results revealed the opposite pattern. When working alone, individuals lifted around 185 pounds, but they managed only an average of 140 pounds per person when working as a group. [emphasis mine]

How is that possible? It’s due to diffusion of responsibility:

When people work on their own, their success or failure is entirely the result of their own abilities and hard work. If they do well, the glory is theirs. If they fail, they alone are accountable. However, add other people to the situation, and suddenly everyone stops trying so hard, safe in the knowledge that though individuals will not receive personal praise if the group does well, they can always blame others if it performs badly. [emphasis mine]

Lest you think this applies only to physical work—not at all. It’s the same for blue- and white-collar jobs, physical and creative alike, and across cultures:

Ask people to make as much noise as possible, and they make more on their own than in a group. Ask them to add rows of numbers, and the more people involved, the lower the work rate. Ask them to come up with ideas, and people are more creative away from the crowd. It is a universal phenomenon, emerging in studies conducted around the world, including in America, India, Thailand, and Japan.

Our experience with teamwork

My manager once said in a loose conversation “remember how we were thirty people total? I’ve a feeling we got much more work shipped back then than we do now with 200 people”. Can we test his hypothesis? Can we measure it? Hardly, since to measure correctly would require lots of metrics which we never have nor probably ever will collect.

My personal, best experience with teamwork was in preparing several conferences for Toastmasters in Poland, from the country-scale Toastmasters Leadership Institute to the half-continent scale of the biannual District 95 Conference. All of those teams truly rocked.

  • everyone had their own, individual space of responsibility. I did the website and all of IT—if I blew it, I had myself to blame.
  • we all respected boundaries. I had the final say on the website format and content, but I might’ve merely expressed my opinions on marketing.
  • we worked individually, collaborated on a case by case basis as needed and met every few weeks for two hours total to synchronize.
  • we were all volunteers with no formal ties, so the two or three persons who couldn’t keep pace with the rest were promptly removed and replaced.

Contrast that with the reality of Scrum or any other Agile teams in a typical company—large and small:

  • you’re supposed to share responsibility for the work; all code is everyone’s code.
  • every sprint you’re asked to spend a half-day to a day in meetings, drilling into everyone’s performance (also called a “retrospective”) and collectively brainstorming the work scope (known as “sprint planning”).
  • everyone is on some contract and even in countries were it’s legally easy to fire someone, it’s still psychologically and organizationally taxing.

I did way too many “sprints” like these, and I’ve been in every role: developer, product owner, scrum master, team leader. Every single time people were dying to get out of the meetings and get back to doing productive work on their own. This never worked the way it was supposed to.

Agile is simple, but it’s not easy

The traditional response to “Agile doesn’t work” is usually that, to the contrary, it does, you’re just not “agile enough” or you have diverged from Scrum. That indeed, it’s hard to do agile right and it requires practicing all the great virtues of discipline, courage etc.

Just because some people can finish an IronMan race in 8 hours, that doesn’t mean everyone can, and in fact, very few people will ever be able to complete the distance in any time. It’s a very personal experience, of talent, character and choices, just like work style.

Fair Exam

Why then do we continue to try and swim upstream? Work against human nature?

The solution to fight the western world’s epidemic of obesity is not to ask people to be more disciplined with their diets, but to find out what the natural eating habits of people are and to create food that accounts for them and is healthy. Starting with less sugar and processing would already fix the most outstanding issues.

At work, instead of asking people to “try harder”, study them. Find out what turns them on or off, and change the work environment to account for it. Are they not empathetic enough? Perhaps that’s because we’re not built for empathy in large groups. Try making the organization smaller.

I look back at some thinking I did years ago on teams and realize now I got it only half-right. Yes, teams need to share goals, otherwise there’s no point in calling them “teams”. But “sharing work” is not about collectively executing tasks—that’s counterproductive. It’s about agreeing on outcomes where many individual streams of responsibility come together and yes, we can and should confront anyone who doesn’t deliver their portion.

Too long in one job

“What have you learned from maintaining your own code?” is a pretty decent question to ask candidate programmers. Many people we interview have never staid longer in a job than 2-3 years. That’s enough to build something of size, but often leave without seeing whether it’ll stand the test of time.

I’ve been with my current company for seven years now. It’s enough to let me see how my earlier ideas played out in practice. And boy, have I been wrong at times. Several of the components I wrote are now part of our technical debt and when I do a technical introduction for newcomers, on several items I repeat “that one’s my fault”. What I thought will ease maintenance and development, either doesn’t anymore or never did. It’s been seven years of excellent education, and one that I was being paid for.

There are a lot of good reasons to change employers. Abusive work environments and dead-end, repetitive, I’d-rather-die-boring positions top that list, and if you’re in one of these places, you cannot leave too soon. But my approach was always that once I agree with my employer to a set of conditions, including fair pay, humane work environment and, importantly, lots of space to grow, I become committed to that relationship for as long as these conditions are upheld.

On the other hand, some of my colleagues left, lured by offers “too good to refuse”, presenting massively interesting challenges to tackle. Modern technologies, booming industries, novel approaches. Often sweetened with better pay. I cannot blame them and I cannot say myself what I would’ve done if presented with such an offer.

One can certainly also make the argument, that others’ work is just as good a source of learning, as one’s own. That going to a different place, working with different people will expose one to other, often better approaches. Of course. I’m just afraid of this turning into a cargo-cult spiral, where you acquire new ways of working without taking the time to understand them—why they succeed and where they fail—before moving on to the next big thing.

Instruction vs. Experimentation

From Jessica Hagy’s Indexed

It’s complicated. There’s no good number or even range of years one “should” spend in a single place. Not without considering the context of this time—the company, the people, the work and alternative opportunities. And in a world of abundant opportunities, such as the one we have now in IT, it’s crazy difficult to decide whether and when to make a move.

Git hard or go home

I am in love with Git. It’s the neatness junkie’s dream come true. Multiple people can code away safely, independently, then every commit can be written and rewritten at any time to end up with a tidy, coherent product. As long as you know what you’re doing, that is.

With the years I worked out a few strategies for taming Git, making both mine and my collaborators’ work easier. Perhaps these’ll save you some headaches down the road.

Understand the model

A prerequisite to understand most of Git’s concepts is learning how the data model works. It’s so important, that before I let developers do anything with Git, I force them to read through the “Git Basics” chapter of Pro Git. The rest they can learn as they go. In essence:

  • all commits are nodes in a directed graphs, where
    • when multiple commits point to the same parent, they’re all branches,
    • when one commit has multiple parents, it’s a merge,
  • there’s no such thing as “branch” or “tag” in itself, they’re just labels given to specific commits—friendlier names to refer to than 63949df, so:
    • deleting a branch or tag merely deletes the label. The commit 63949df is still there and you can reference it. At least until Git decides to do garbage collection, when all orphaned commits are permanently deleted.
    • a “fast forward” merge moves a label to a different commit, as long as the branch you’re merging into didn’t have any commits of its own. Since there’s no separate merge commit for it, there will be no trace of this merge later in the graph, so make sure that’s what you want. Otherwise do git merge --no-ff.

Take your time to study the model, the charts and perhaps the commit graph in some existing repository. Working with branches will suddenly make much more sense for you, and more importantly you’ll grasp the concept of rebasing much, much quicker.

Rebase freely

Rebasing is the wonder broom that keeps the commit graph tidy. It’s what you do to get rid of commits saying Merge branch 'master' of https://github.com/your-name/your-repo.git which make the commit graph look like a Guitar Hero script—completely unreadable.

You can:

  • amend broken commits, if you:
    • mistyped the last commit’s message do git commit --amend and edit the commit,
    • forgot to stage some changes, add a file, do
      git add <missing changes>
      git commit --amend -C HEAD
      
  • squash obsolete commits, once you realize a commit other than your last one could use amending, do:
    git add <missing changes>
    git commit --fixup=<hash of commit to amend>
    git rebase -i --autosquash <hash of commit to amend>^
    

    Note the trailing caret ^ in the last line.

  • rebase instead of merge on pull, pretty please. This makes sure master (or any other branch) is a single, straight line, that’s easy to follow. This will also cause fewer conflicts and make the remaining ones easier to resolve. Use either git fetch && git rebase origin/<your branch> or git pull --rebase.

There’s a caveat to rebasing—it changes history, discarding some commits and replacing them with other ones. That’s not an issue, as long as all of the commits you’re replacing are only local to your sandbox, but once you pushed these commits out into the world, you might be peeing into the pool.

Branch smartly

Just because branching and merging with Git is easier than with older version control systems, that doesn’t make branching any less dangerous:

Start juggling too many [branches] at once, and you’re bound to drop a few. In most source control systems, you can create hundreds of branches with no performance issues whatsoever; it’s the mental overhead of keeping track of all those branches that you really need to worry about. Your developer’s brains can’t exactly be upgraded the same way your source control server can (…)

To stay on top of your repository:

  • keep branches short and small, branch off, make your changes, create a pull request and merge as soon as possible. I used to advocate the gitflow model in the past, but nowadays I consider its long-lived develop and release branches an anti-pattern, and favor the simpler GitHub Flow. Fewer branches mean fewer (ideally just one) sources of truth.
  • delete remote branches, once merged, usually right after a pull request is closed. If you ever need to resurrect a branch and add something to it, you can always push it anew. Otherwise it’s hard to see which branches are still active.
  • don’t git cherry-pick or commit the same patch of changes to multiple branches. It’s confusing and will likely give you headaches during merging. If you stick to a single, long-lived master branch with short-lived feature branches, you shouldn’t ever need cherry-picking. Otherwise, use rebasing to move a commit from one branch to another.

Push thoughtfully

Once your changes are out there, on the remote(s), you might as well assume everybody else has already fetched them. GUI clients like SourceTree have auto-fetching enabled by default. If you now realize you’d still like to do some amendments—say fix a silly typo or rebase the master branch—you’re screwed. You’ll have to ask everybody to git reset their local branches and cause a lot of grief.

Take your time before you push anything, and never, ever mark the “Push changes immediately to remote” checkbox in your Git client. It’s like disabling the Undo feature. Commit your changes locally, leave them baking for an hour or a day, then review them—see if there are no missing or obsolete line changes, files, whether commit messages are correct—and only then run git push.


Reduced amount and magnitude of merge conflicts, actually useful commit graphs, immediately obvious location of the most current code—all benefits I drew from applying these here practices. Call it Git etiquette or call it a way to improve the ratio of pleasure to pain in using Git. And do share your own tips in the comments, please.

Talking like you own the place

“Last year we acquired [company] and …” I was chatting with my friends about some recent business of the company I’m part of. They looked at me funny and interrupted “you keep saying ‘we‘. That’s sooo unusual.”

I always talked this way. How else should I be talking about the organization I spent over 6 years with, advanced through three positions and delivered numerous projects now used by millions of our users. I’m definitely making an impact on the day to day business of the company and if I wasn’t able to do so I’d be long gone and contributing elsewhere.

Apparently I’m and odd outlier here. Many (most?) people would refer to places they spend half their waking hours at for decades as some variation of “the company I work for” as if they firmly tried to distance themselves from someplace unpleasant. That’s what we do with people—when we don’t like somebody we use words to create distance:

  • revert to formal titles “Mr Smith”, “Mrs Jameson”, then
  • depersonalize references, replacing them with “this man” or “that woman”, reaching extremes with complete
  • dehumanization at “that miscreant” or “those idiots”.

The equivalents for a company would be:

  • “Google” (fill in your company name),
  • “the company I work for”,
  • “sweatshop”.

The moment I catch myself saying “the company I work for” will be my trigger to make major changes. Either in employment or in attitude.

Michał’s conference war chest

It’s not unusual for conferences to cost an arm and a leg. At €1,000 or more for just the entry, on top of which come travel and accommodation, and I often attend two or three events a year. That’s a pile of money in need of justification spending, and I can only do so if I bring back lots of valuable information. Here’s what I do nowadays—the tools and tricks I worked out for surviving and thriving as a conference attendee.

Preparation

During a conference I want to focus strictly on acquiring information and connecting with other attendees, so to free up time I prepare a lot upfront.

Session selection comes first. Conference schedules usually appear piece by piece, so a week or two before the event I go through all sessions and plan my agenda. The last thing I want is to make haphazard, effectively random decisions at the venue.

  • If I’m attending with any colleagues, we sit down together to split up the sessions and cover more ground.
  • If there’s more than one interesting session in a given time slot, I write down all of them and prioritize. This way I have more options when my first choice turns out to be a flop or suddenly gets canceled.

I add selected sessions into Google Calendar, synchronized across all of my devices. Some conferences have dedicated apps to store one’s schedule, but these may or may not work to my liking or could have issues on shaky Wi-Fi. Plus I quickly would’ve acquired a pile of useless apps and accounts.

GOTO Berlin schedule in Calendar

I’m really big on notes. Before the conference I setup a fresh Google Doc, since I’ll be taking notes on a tablet, with pre-entered:

  • sections for each chosen session, ordered chronologically,
  • names and
  • Twitter handles of speakers.

GOTO Berlin conference notes

Using Google Docs has a number of advantages:

  • I can share the document with colleagues, both at the venue or back at the office, where they can follow me in real-time,
  • Google Docs’ context-aware spellchecker is pretty decent, which helps a lot when (mis)typing on a tablet,
  • the chronological order lets me get ready quickly by opening the document and scrolling down to the next empty section,
  • speakers’ Twitter handles make live tweeting easier.

I’ll often write the Twitter handles with the conference hashtags, ie.:

 @mpaluchowski #craftconf

Note the leading space. This snippet I can easily copy and paste after every quote I tweet during a session.

D-Day(s)

The conference days are always intense, both physically as well as mentally, so my focus here is to stay light and fit.

I carry my own shoulder bag, currently the excellent Camel Active Dakar, which contains my tablet, wallet, business cards and a pen or two.

Camel Active Dakar shoulder bag

Conferences usually hand out their own bags, but most of these aren’t convenient to carry around for a full day. I carefully selected a good bag, that:

  • keeps my hands free all day—especially beneficial at standing lunches,
  • doesn’t bite into my shoulder(s),
  • doesn’t bump around my hip thanks to its vertical orientation,
  • easily fits into my lap during a session, when space is tight,
  • carries everything I need—the Camel one can easily carry a 12″ laptop or A4-sized documents.

Michal taking notes at CraftConf 2015

My device for note taking is currently the iPad Air 2. A laptop wouldn’t do because the vast majority won’t last a full day on batteries and I sure as hell don’t want to waste time on recharging.

Typing on a tablet is pretty cumbersome, but gets better with practice, plus Google Docs’ spellchecker helps a lot, and anyway I won’t be publishing raw notes anywhere without post-processing. A colleague is happy doing notes on an iPad Mini so the smaller form factor could work as well.

iOS 9’s Peek function was a real blessing, since I tweet a lot during sessions, on top of taking notes. Earlier I had to keep switching between the Google Docs and Twitter apps, whereas now I can just slide in Twitter on the side for a quick tweet and return to notes. Thanks, Apple!

A conference day is really hard for the body since I spend a lot of time sitting still in sessions, while my brain keeps working in high gear, burning lots of fuel and not getting nearly enough oxygen to clean up the trash from metabolism. This means unless I pay attention to my body, by the end of day I’ll likely develop a headache and won’t see much from the conference party. So I:

  • drink a lot of water, either carry my own bottle and keep sipping during sessions, or drink a glass at each break. The side effect is having to visit the bathroom often, but there’s a trick to that too.
  • move a lot in between sessions—no sitting, lots of walking, gesticulation, even leaving the venue when possible.
  • eat light, opting for complex fuel sources, like protein or complex carbohydrates. No pastry or sweets of any kind—these would burn up quickly leaving me hungry and distracted.

Finally, I try to sit near convenient exit rows, so that I can easily leave the session if I don’t like it, or reach the toilet before the crowd does. Trust me, this is a real problem during male-dominated software events.

Post-processing

There’s little value in all the information I acquire at a conference if it stays inside my head. Sharing it with others and turning it into action is where the payoff starts.

Conferences are often followed by a weekend, which is super convenient since I can focus on something completely different and then go back to my notes with a fresh look on Monday morning.

It takes me a day or so to process notes, where I rearrange them to:

  • group into common themes, ie. microservices, DDD, Agile etc.,
  • reorder into something that makes sense in the context, rather than whatever the speaker(s) thought would,
  • list out tools, books, blog posts and other resources I saw mentioned,
  • later add links to talk recordings, once they were posted.

Finally, I produce a brief summary from the pile of information, adding my own judgment of where I see the industry right now, or how it changed compared with previous conferences. This usually turns into a blog post, richly decorated with photos and tweets from the event.

We take a look at all materials with my colleagues to decide what is most relevant to us and what we’d like to try out now or later. These go into our regular planning and I get back to everyday work, counting down to the next great conference.