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.

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.

Developer turned Product Owner

The backlog is a mess. The order is random. There’s no grouping or coherence, let alone a vision of any kind. Stories are unclear, if at all described, and sprint planning takes forever while developers try to figure out what the product owner wants. I heard these complaints over and over again from teams, and then I had a chance to become a product owner myself. Turns out it’s not much different from a developer’s work.


Taking an agile approach means making small steps and testing how they influence the product. Just like TDD in programming:

  1. Think what you want to do.
  2. Decide how you will measure success, like you code a test.
  3. Have the team implement your idea, usually by writing code and just enough to make the test pass.
  4. Evaluate the idea against your KPIs, like you would run your test.
  5. With the findings, go back to 1 to adjust your hypothesis and approach.

Clean Code

The backlog items you’re preparing—usually stories, will be read and relied on by the team to build a product increment. The clearer the language, the easier it’ll be to understand and follow.

  • clear, unambiguous, expressive naming,
  • precise vocabulary,
  • short paragraphs,
  • good English (or any other language you use),

all of these are qualities that’ll help the team deliver faster and with fewer misinterpretations. All the same in code, where good naming for variables, functions, objects matters, and short, focused functions and components are preferred.


A good backlog is well organized, with related items grouped together into epics, aligned along a vision for the product. This in turn provides direction and focus for both the team and stakeholders, guiding conversations on how the product should be shaped, deciding what fits in and more importantly what doesn’t. It allows setting release and sprint goals, that the team can measure their progress against.

All this is exactly like abstraction in code, where similar logic gets grouped into objects, similar objects grouped into packages, named after the domain they cover. From an orderly, well-named code base one should easily be able to identify the purpose of the system, decide where to put new code and whether it belongs in there at all.

I know what the team’s doing

My programming experience is helping me tremendously in shaping the backlog and working with the team. Requirements are crisp, or quickly refactored to become so, order is clear and it’s easy to see what fits into our current vision and what should be deferred.

On top of that, I know the work the team does. When they come back reporting issues with implementing certain items, I understand those and we can easily adjust plans to reality, with the new information we received. Everyone’s work becomes easier and we’re steadily moving forward.

Obviously not every developer would make a good product owner. There’s a lot of touchy-feely people work involved, while many will likely prefer to deal with the clear, binary logic of computers. But for those who always liked to work on the edge between technology and people, this might just be the right career advance. One that’s surprisingly easy to make.