It’s his job

Perhaps it is. But does he know it? Have you told him? In teamwork, as in marriage, implicit expectations create tension that’s bound to explode at some point. Disarming that bomb is as easy as saying “could you?”

Some jobs have tighter-defined responsibilities than others. Across the spectrum of employment that’s obvious—if you’re, say, a train driver your job is to safely steer a few thousand tons of steel, carrying a few hundred human lives to their desired destinations. If you’re an artist, there’s much less specificity.

Even within the IT industry there are vast differences in job descriptions. A DBA is tasked with maintaining dabatase servers, often including developing data models and optimizing queries for efficiency. For a developer, things get a bit more blurry, being expected not just to write code, but these days often also setting up server infrastructure, configuring deployments, monitoring service health and, perhaps hardest of all, understanding and catering for user needs.

Then there are the managers, whose job descriptions are becoming increasingly confusing. Ensuring timely delivery, supervising quality, motivating their reports and caring for their career development. Everybody nods their heads in agreement on those, but what do these mean in practice?

In the (inherent) absence of specifics in one’s listing of responsibilities, both the manager in question as well as everyone around them will develop their own image of what these should be. In particular, their reports will have varying expectations. Some will want them to be a communications bridge, others will prefer communicating directly. Some will want vision and guidance, others will want to have their own say. (I’m singling out managers here because of the evidence of the problem here, but the same concerns every job with a blurry description.)

The issue? Nobody tells them! The manager have their own view on responsibilities, obviously, and will execute against those. (Plus there are the manager’s managers to cater for.) They will, regretably, often not sit down for a frank conversation with their team to talk out what everybody’s role is. The result is frustration buildup. Reports holding watercooler conversations, complaining about their manager not leading this, not reacting to that, not talking to someone, etc. And they won’t tell the manager because they feel it’s inappropriate or for fear of retaliation.

I made a sport of calling out these situations. My lovely wife had thaught me from the outset of our relationship that if either of us wants the other to do (or not to do) something, we better voice it. Otherwise it’ll pile up over time, explode at the least opportune moment, causing irreparable damage.

It’s the same at work.

Take your manager out for coffee (if it’s your first time, the setting should help loosen up everybody), then tell them: “Bob/Kathleen, could you ask our CTO for help with resolving the issue we’re having with this vendor? Could you tell me how you see our priorities for the next three months?” No “I expect you…”, “it’s your job to…” crap. Just a human to human request—firm, direct, but very much considerate. You’ll be well on your way to deflating the baloon of unmet expectations that would’ve blown you both away when (not “if”) it popped.

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.