Spoilers: it’s not about whether remote or office work is better.

The prevalence of return to office mandates has provoked much discourse and strong opinions. For good reasons. Return to office mandates can tear teams apart by pushing out people who cannot relocate, at huge cost.   

Working physically together, in the same space, as a whole team, can be extremely enabling. Supporting a joyful environment. Sadly, too many offices were (and remain) environments hostile to collaboration. Return to those hostile environments has been imposed on many.

It makes me sad to see people…

…forced to return to offices that are noisy, cramped, illness-spreading, collaboration-killing environments. 

…conversing over video chat from across the same open-plan office, because while they’re in the same space it’s not set up to help them collaborate.

…excluded from teamwork because the rest of the team is in another location.

…stuck waiting on pull request reviews from people they are sat right next to.

Most of all I get sad when I see ineffective teams with no ability or motivation to improve—whether remote or co-located.

For many teams there can be huge advantages to co-located working, but these aren’t it. Different approaches better support different people, different teams, different contexts. 

Return to office mandates can destroy the effectiveness of teams who have uncovered better ways of working by going remote.

Tearing your teams apart and undermining their ways of working are tremendously damaging. Fabled watercooler serendipity will not make up for this.

You’ll cause harm by forcing RTO on teams with cultures that benefit from remote. Please, instead, help your teams craft their best environment. 

Remote isn’t always Best

Many people are very passionate about remote work. Remote can bring inclusion benefits. Offices can bring communication bandwidth benefits. 

This claim crossed my feed this week:

“Every successful company needs to have the most talented people. The most talented people no longer live in, or want to live in the same place.” 

This suggests that “acquiring” talented people is a zero-sum game. It’s not.

Rather, successful companies maximise what their people can achieve. One factor is indeed how talented the people who join are. Another is their pre-existing skills. Even more significant than these is the extent to which the organisation amplifies & accelerates, or impedes their abilities.  

Different organisations, and different ways of working, are more or less suited to make different individuals the most effective.  

Don’t Compromise

Mediocre teams compromise on their ways of working to avoid conflict; sacrificing their team’s potential on the altar of individual autonomy. 

Effective teams find ways of working that give themselves an advantage. They shape their environment to maximise their effectiveness. 

Hybrid work policies can easily result in the downsides of being anchored to an office location, with none of the benefits that could come from having everyone together.

It doesn’t just happen with location. Individual preferences for working exclusively in certain parts of the codebase can result in nobody working together towards the same mission. People who feel they get more done if left to their own devices for days or weeks are often right, and it can also be true that the team as a whole is less successful.

It’s easy to avoid conflict and get stuck in mediocrity. Optimising for individual happiness can result in less of the joy that people find in teams that achieve great things together.

If only effective collaboration had such an easy answer as asking everyone to come to an office. 

If you want to build up your teams rather than undermine them, start with curiosity about how they work. Invite and support them to uncover better ways of working for them. What helps them. Their preferences. Their lives. Their mission. Their constraints.

I’m privileged to have experienced working with many effective & ineffective teams & communities. Both in office environments and remotely, with a variety of collaboration styles.

I’ve experienced some of my most joyful work in teams working together in the same space. I’ve benefited from flexibility and inclusion with remote work. I’ve also been able to contribute as part of larger open source communities where I couldn’t even know everyone by name. There are plenty of reasons to be passionate about each approach. 

What I am most passionate about is teams finding the most effective ways to work together. Joy for the individuals involved. Successful team missions. Turning the constraints they’re working with to their advantage.

Beyond a Binary Debate

There are more options than just Office vs Remote. Distributed vs Co-located working is often conflated with Async vs Synchronous working styles. It’s not one or the other.

By Async I mean working independently. Coordinating via tickets, pull requests, mailing lists etc. 

By Sync I mean working together, on the same thing, at the same time—and not necessarily at the same place.  

Those who’ve experienced greatness at one extreme on this chart are often enthusiastic. Top-right and bottom-left have many proponents. However, bottom right can be glorious as well, and this seems to be less discussed. Fans of Async-Remote sometimes characterise Sync-Remote as being “unable to let go of the office”. However, I’ve seen it work tremendously well—often far better than the typical office space allows. 

Teams often compromise somewhere near the middle. A hybrid of workplaces and work-ways. Accommodating a variety of preferences and needs. 

The best teams I’ve seen move towards an edge and find a sweet spot. You can imagine a third dimension of effectiveness. With a pit in the centre.

Office and Async — Escape the Tragedy

I’ve not found a scenario where this quadrant is better than an alternative, despite it being, in my experience, the most common for most “teams”. Where teams are acting more like a mere convenient grouping of individuals than a collective with a common mission.

This scenario often arises through compromise on ways of working that are the least objectionable to everyone in the team. In contrast, better ways of working tend to arise from finding what works and turning it up to the extreme.

I’m interested to hear from you if you have seen a team better off in the Office & Async quadrant than they would be in another.

If you’re stuck in this quadrant, and you’re not finding it joyful, consider a move to another. Don’t suffer and merely survive, aided by your noise cancelling headphones.

Option 1: Move remote, to get the true benefits of Async 

If you have the luxury of working remotely, and you prefer working asynchronously, then remote will open up lots of benefits.

You’ll avoid commutes. You’ll enable hiring from anywhere, including a wide geographical spread, making it easier to hire great people. You’ll increase timezone coverage for progress that never stops and improve operational coverage. 

Option 2: Move together, to enable Sync

If your team are all spread out within the same office, bring your desks together. Control your space as much as possible. Use the wall space. Separate your area with whiteboards / soundproofing.

If this isn’t possible, consider booking meeting rooms out where you could go to work together. It’s amazing how infrequently large meetings get questioned. Whereas making small changes to enhance the space you’re working in sometimes alarms bureaucracies.

Working in the same space will enable ad-hoc discussions. It facilitates pair programming with regular rotations. You can make the things most important to you visible in the workspace. You’ll also overhear opportunities to help each other.

Option 3: Move remote, to enable Sync 

If you can’t move your desks but have the luxury of working remotely, you could move to the bottom right to make collaboration easier. Then try some of the ways of working mentioned below.

Remote and Async — Open Source Style

Many of the best ways of working in this quadrant have emerged from the ways that distributed open source communities work. Pull requests. Mailing lists. Decision frameworks based on written proposals. 

This style enables large groups of people to collaborate effectively to achieve large things. Often larger than a traditional team could achieve. Sometimes at the cost of speed of decisions. 

Office and Sync — XP Style

Extreme Programming Practices are a great starting point for office & sync. Then experiment and iterate towards what works best for you.

If you have the luxury of being in the same space—be in the same space. i.e. get your desks together. Get big desks so you can sit and work together. Customise your space to be informative & facilitate collaboration. Track things on the walls. Keep living diagrams on whiteboards. Put up big displays with production metrics. 

One of the nice things about using a physical whiteboard as the information radiator in a team was
a) the ease of modifying the process visualisation and
b) the reinforcement of the constant reminder

Subtle effect from opinionated tools like Jira/Trello is stifling this. pic.twitter.com/HJeqeZR7t0

— Benji Weber :: @benjiweber@mastodon.social (@benjiweber) February 13, 2022

Remote and Sync — Learn what works

Less has been written about this quadrant. Kent Beck wrote this article recently which partly inspired this post. 

During the pandemic I saw several teams stuck in the Async-Colocated quadrant discover the benefits of collaborative practices. 

Teams stuck working as isolated individuals within the same office were freed. Absent the noisy office environments where they were artificially separated, they could start working together, in a remote-first way. 

Teams discovered new ways. These included re-discovery of XP practices unimpeded by hostile offices.

Eliminate wasteful Meetings

I saw teams inverting what they used synchronous time for. Things they did together through mere habit, like status updates for stakeholders, became async. Boring meetings of status updates that could be slack messages became slack messages. 

Instead, sync time was protected for actual collaboration. The higher cost of sync time when remote due to lower bandwidth incentivised using it more wisely. 

Always-on Zoom

An always-on video call for teams allowed people to drop in and out to work with each other and catch up on work others were doing in parallel. Analogous to a dedicated team war-room in an office. Without the bureaucratic hurdles to setting one up. Nor the challenge of competing with nearby teams for noise.

Dashboard Nudges 

Automated daily screenshots of dashboards with team KPIs. Regular snapshots sent to teams’ Slack channels replaced the physical TVs from the physical office. These nudges provoked conversation, increasing awareness of both the success of features, and production risks. 

Team Games

Opportunities to relax and have fun together needed to be intentional. Web based multi-player remote games were a go-to for several teams.

Virtual Whiteboarding

Discussions and brainstorms sometimes worked even better than their in-person alternatives. Unlike physical whiteboards, in virtual space there’s no problems with everyone crowding around. Nobody can hog the view. Everyone can participate at once. Not to mention saving a fortune in post-it notes. 

Pair Programming 

Pair programming works well when remote. For many teams it works better remotely; their office environments being so hostile to in-person collaboration. No longer having to compete with the din, pairs could focus.

Communication bandwidth isn’t as high as in-person, but the tooling to work together remotely has come a long way. Tools like VSCode Live-share, and Tuple make working together a breeze. Tooling like mob enables fast handover.  

Continuous Integration

True continuous integration (integrating to main multiple times per day) is even more valuable when you don’t have the opportunity to overhear what others are working on.

Serendipity is not a Strategy

All quadrants benefit from intentionally defining and writing down ways of working, rather than relying on accidental interactions and happenstance in an office.

Don’t rely on watercooler moments.

If you want folks to have unstructured conversations from which new ideas might emerge, create those opportunities intentionally. There are lots of mechanisms to increase luck and the chances of useful conversations occurring. e.g. No-pre-planned meeting days. Blocked lunch breaks. Group volunteering. Team meals. Quarterly Offsites. Retrospectives. 

Look for what’s working for your team and turn it up. Try changing things and uncovering better ways of working!

Cycling provides interesting examples for software development. It’s possible to race individually or in teams. A group that’s an effective team will outperform the same group acting as individuals every time. Teams compete towards a goal, and also against the environment, and many other teams, all with their own tactics, all at the same time. 

Ensemble working provides an Advantage

Cycling teams working together in a paceline can travel significantly faster—via the aerodynamic advantage of drafting the slipstream of the rotating leading rider. 

Software teams can build more stuff if each person works independently, than when working together. However, they’ll reach a team goal the fastest through working together, on the same stuff, at the same time, via pair or ensemble programming. 

Having all the perspectives, experience, and expertise available at the point of meeting resistance from unknown challenges, results in a sort of aerodynamic advantage. We get stuck for less long, and overcome obstacles more easily. 

A pair may not be twice as fast at shipping stuff as two people, but shipping stuff is not important. Working together they’ll achieve a goal a bit faster. Our goals have a cost of delay. The ability to ship a capability with associated revenue significantly faster, more than makes collaborative working worthwhile. 

Individual working provides an Advantage

Cycling teams are comprised of multiple people, they can send riders back for hydration & energy food. They can send riders ahead to mark breakaways and mitigate the risk of the breakaway succeeding at remaining ahead until the end of the race. 

Software teams that are paying attention, will see side opportunities & risks that are tangential to the main focus but too big to ignore. Often it helps for one or two people to go after them. Builds getting slow; someone peels off from the group to go fix that. Competitor launched a new product; someone peels off to explore how it works and whether should this change our plans.

Competitive Market

Unlike many pitch team sports where teams compete head to head, cycling teams compete against several other teams, at the same time. Each competitive team will employ their own tactics. Some teams may be more interested in overall win, or other incentives available such as intermediate sprints. Tactics have to take into account all the competition, not just a single opposing team. There are also environmental factors on the day such as wind and rain conditions, and the terrain. 

Organisations building software are competing against many other organisations with directly or indirectly competing interests. 

Sometimes it is advantageous to collaborate with the competition to conserve resources by working together. Cycling teams can work together to increase the chance of leading the race through a breakaway. Software builders partnering with competitors can build an ecosystem to grow the opportunity available to all parties.

Other times there’s an opportunity to get ahead of the competition by creating a break that your team is uniquely positioned to take advantage of.

Adapt to the riding conditions. Lightweight for climbing or Aero for flat. Wet or Dry. Similarly, as the economic climate changes, so do the tactics that are most successful for building software. 

Dynamic Reteaming to Breakaway

Working together, a breakaway made up of individuals from multiple teams can stay ahead of the race. They must take their own share of the hard work in the wind, and communicate effectively. If they refuse to help each other, the breakaway will fail, and will be absorbed. Breakaways often fail when competing incentives and ineffective communication reduce their advantage over the main peloton. 

There’s often a need and benefit to pulling together or self organising temporary short lived software teams. They can effectively chase an immediate goal that doesn’t neatly map to the existing team structure. 

Dynamic reteaming can be far more effective than dependencies between teams, and like a breakaway it can rapidly get ahead of what an unchanged organisation structure could achieve. 

Temporary teams also often struggle to communicate as effectively as a well established team; lacking the trust that comes from experience working with each other.

Marginal Gains Add Up

A clean well-lubricated chain could save you 5 watts, adding up to several seconds advantage over a race. Small tweaks to fitness training habits every day can add up to an advantage over a season. 

Software teams often underestimate how quickly small investments in their own effectiveness cumulatively create an advantage. Time spent making your deploy pipeline a couple of minutes faster, or time automating manual onboarding steps. The wins from these add up over time to help you outpace the rest.

Specialists 

You need specialists: climbers & sprinters. The rest of the team help get them in position at the right time for the challenges that they can best help with. Get your sprinters to the front of the race with a leadout in time for the sprints. Do the hard work to protect your race-winner’s ability to take advantage of a tactical opportunity when it comes. However, everyone needs to finish the race. Sprinters must be able to get over the mountains within the time limit.

Effective software teams have a mix of generalising specialists. They can all muck-in with whatever needs to be done towards the team goal. There’s also huge value to having the person with expertise in building UIs, the person with Data Science expertise, or the person who’s scaled databases. The right specialists enable help the team to overcome challenges.

Support Staff

Teams need support staff. If riders had to stop and repair their own mechanical issues, or carry their own food they’d be far slower. 

Engineering teams benefit from internal platforms, and developer experience tooling support functions. Invest a portion of your budget in these.

Beware Incentives

Unglamourous work is essential to team success. Teams are ruined if everyone tries to go for the win. 

Cycling teams need domestiques who will protect the leaders and fetch food. Software teams need people who’ll do glue work. People who help the whole team communicate. People who remove the friction slowing the team down. 

Organisational incentives often risk this essential work and destroy the potential of teams. 

Incentivise each of your riders to go for the win and the team will fail.

Incentivise each of your developers to chase promotions and compensation increases, on the basis of their individual impact, and your team will be ineffective. 

Work Sustainably

Pace yourselves. Only go all out when there’s a need for it, or you’ll not have the energy when it is needed. There’s a sprint at the end of the race. There’s another stage tomorrow. Don’t drop out. 

If you are successful, there will be production incidents and customer crises to handle. These will take your energy reserves.

If you run at 100% every day you’ll have nothing left to give when there’s a real need. 

Many software teams struggle with ever growing cost of change, and technical debt that risks overwhelming them. 

It’s always interesting to talk with folks and understand, how the system and incentives created this state. 

Often I hear from software engineers that management doesn’t give them permission for (or doesn’t prioritise) work such as tidying, refactoring, testing, observability.

Blaming management in this way may be accurate in many situations (they are indeed probably accountable for the system that created this outcome). However, the problem with blame is that it tends to short-circuit further thinking. How could the system be improved with the influence and control you do have, perhaps with minimal authority.

But what about from the management side? I often hear from engineering and product managers that they’re unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.  

Management has a bad reputation in the tech community. I’ve been very fortunate to work almost exclusively with managers who genuinely care deeply about the people and teams they support; who want what’s best for them in the long term.

And yet, it’s still common, with the best of intentions, to create systems that result in unsustainable software development, and lots of technical debt. 

How does this happen? 

The risks are not very visible. If managers were given the option of twice as much this month, in exchange for nothing for the next 6 months, they probably wouldn’t take it (perverse incentives like annual bonuses notwithstanding). Would that it were so simple. 

The decks are stacked against sustainability. It requires active effort from managers to combat the natural incentives.

Here’s three practical ways you can help as a manager.

1. Converse; don’t Coerce
2. Encourage Healthy Habits
3. Celebrate Sustainability

Converse; don’t Coerce

Get Curious

People will always want more than you’re able to achieve. Meaning we’re often starting from a position of saying no to lots of things that are very valuable; it’s faster to identify opportunities than it is to win them.

Most people don’t want to give bad news. Most people don’t want to hear bad news.  

This sets us up for miscommunication. 

<Manager> we need to do X this week
<Maker> Ok [unsaid: I’m going to risk a production outage by skipping testing]

If sufficient trust exists then it’s possible the risk will be vocalised, but the manager has not invited this feedback. Nor have they provided enough information for the maker to form their own opinion on the merits of the risk. 

It’s an instruction. There’s no curiosity as to what the impact or tradeoffs are, which shuts off thinking. 

It encourages risks. Some might infer an unsaid “…whatever it takes”. This could lead to taking risks such as skipping normal safety, or working long hours

It’s informationless. It’s a blanket “we need”. It doesn’t say what the value or tolerable costs are. The recipient has no information to make good judgements themselves with.

Things get a little better with even the slightest bit of curiosity.

<Manager> can we do X this week? 
<Maker> I think so [unsaid: cutting corners]
* next week *
<Manager> can we do Y this week?
<Maker> I think so [unsaid: that means they’ve decided not to clean up the debt from X]

At least the manager is now making it clear that there’s some degree of choice, although the power dynamic might make the choice seem illusionary. 

It’s a closed question. The manager’s likely to get yes or no answers. They’re not showing curiosity about the consequences of the team making X or Y happen. 

The manager is still asking the team to do things. Having to ask a team to do something is often a sign of a bug in the organisation. An organisational smell.

What’s stopping the team self-organising to the most important work? What information were the team missing to help them spot that X&Y were more important? What skills or perspectives are they missing to be able to make the best choices? 

Use Open Questions

Things improve further if we ask open questions:

<Manager> what would we drop if we tried to do X this week? 
<Maker> well we were planning on implementing the actions from last week’s post mortem, if we postponed those we might be able to do X.

or

<Manager> on a scale of 1-5, how risky would it be to release X this week? 
<Maker> Hmm, probably a 4, we’d not have any time to test or do a canary deployment so we’d lose our usual safety nets

Here the manager has asked open questions, and solicited information that might help make better decisions. Even if the manager then asks the maker to do the same thing, the risks have at least been taken more intentionally.

Prefer information over instructions

What if we didn’t ask the team to do X at all?

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hey that’s more than the total cost savings from what we were working on, let’s do X instead.

or

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hmm, but if we rush we risk breaking the service. Last time this cost us $10*n

However, this is somewhat optimistic. Even with all the information, people often have recency bias and eagerness to please. The power dynamic between manager and maker often exacerbates this.

Incentives conspire to eliminate slack time that would be used to keep development sustainable. 

Combining Curiosity and Information

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hmm, that sounds like a lot, I can get it done
<Manager> How risky is it on a scale of 1-5?
<Maker> Probably a 1, we’ve still got time to test it carefully. 
<Manager> What things are we dropping that we’d otherwise be doing?
<Maker> Oh we were going to refactor Y as changes in that area are slow
<Manager> Oh I thought Y was done months ago
<Maker> We shipped it months ago but have since noticed the design trips us up and we never have time to fix it with all these urgent opportunities.
<Manager> How much time has it cost us? 
<Maker> More than it takes to ship X just this month

Here the manager and maker have built a much richer understanding of the situation and tradeoffs. They are much better placed to make a decision than if the maker had simply been asked to ship X.

Encourage Healthy Habits

Team habits can help people escape the trap of needing permission from unsupportive or oblivious management. You will probably be unsupportive or oblivious at some point. Unintentionally coercing people is so easy. 

You can counter this by encouraging your team to adopt habits that will resist your efforts to coerce them into doing the wrong thing.

If your team practices TDD then you’d have to break a strong habit to encourage people to release a feature without tests.

If your team habitually drops everything to bring the build time down every time it creeps above 5 minutes, then they’re more likely to do the same even if you’ve asked them to deliver a feature.

If your team habitually prioritises work based on cost of delay, then they’ll likely ask you questions to find out the value before jumping on it. Even if you have omitted the information in your request.

Habits are hard to break. This can be a good thing. The right habits can add resistance to the forces that conspire to create creeping loss of sustainability. 

Celebrate Sustainability

If you publicly appreciate internal improvements you will signal for more.

If your only questions about the work are inquiries about when it will be finished, you’ll incentivise unsustainable working.

If your promo process only recognises features and customer impact, you’ll discourage sustainability.

Do you celebrate with the team as much when they halve their deploy time, as when the ship that flagship feature?

Do you thank folks for taking extra days to refactor and clean up the code?

Do you ask “how much more could we simplify it?” or “when will we be done?”

Do you ask “what if tried doing less?” or “how can we do more?”

I’ve worked in and with teams who would identify as agile for many years. I’ve written about how I think the most interesting part of the agile manifesto is the “uncovering better ways” mindset. 

With this in mind, I’ve been pondering how the principles in the agile manifesto have aged. Where do (and don’t) I share the same principles. 

Given the “better ways” of developing software we’ve uncovered, can we “turn up the dials” on the principles as well as the ways of working? 

Principles tend to stand the test of time better than specifics. The agile manifesto still reads as an aspirational document today, but I think there’s room for improvement.  

Here’s my take on things I’d tweak in each principle; hopefully staying true to the values. 

Bettering Ourselves

Building working software is a powerful tool to achieve our ends. However, I wouldn’t consider it the highest priority of a team. If we can achieve our goals without software (which can be a liability) that’s even better. 

Moreover, if the software we’re asked to build is harmful for humanity, or counter to our organisational/personal values; avoiding that comes before satisfying the customer. The negative impact software can have on society is increasingly evident as more of our society is controlled by software.

“Bettering ourselves” (optimise for learning) is at the heart of agile to me. To borrow from Captain Picard, I’d state our highest priority as:

Learning we’re Wrong

We’re not passively waiting for requirements. We can take more ownership over our goals and understand customer needs ourselves. We’ve shifted from requirements to forming our own hypotheses of what customers need.

It’s not that requirements change, it’s our understanding that improves. We learn how we were wrong and adapt our goals in response.

We don’t need to build for a customer-proxy (stakeholder who wants the software). We’re can build products for people; they are our customers.  By meeting customer needs, we build a competitive advantage for ourselves.

Continuous Delivery

The only thing worth changing in the continuous delivery principle, is that our tooling and platforms are so much better now than 20 years ago. We can deliver considerably faster and smaller.

A team can feasibly ship multiple times a day—given a good continuous delivery pipeline, reliable & fast tests, production safety net from canary deploys, and production observability. We’re no longer having to burn CDs with software builds.

All the Brilliant People

I’d replace project with product; due to the temporary-team fixed time/budget/requirements connotations of project.

I think longer lived product teams are more effective. I appreciate this won’t be for folks working in a project/consultancy context but I avoid those ;) 

I’d also expand to “all the brilliant people” as per Woody Zuill’s description of mob programming. Get everyone needed to achieve the goals together into the team, collaborating together every day. Minimising dependencies and handoffs.

Product Teams over Individuals on Projects

As per above, I prefer sustained investment in stable product teams over the project model.

Communication Quality over Efficiency

This is the only principle I feel like I’m watering down rather than turning up.

I think face to face conversation is still the highest bandwidth communication method. However, face to face communication is not always feasible for practical & inclusion reasons. Reasons such as geographic location, neurodiversity, family commitments, carbon footprints, and global pandemics! 

If face to face communication is infeasible then it’s not the most effective method of communication; even if it would be the highest bandwidth method.

I think the general principle is it’s better to trade off efficiency for quality of communication. Be willing to sacrifice time for better communication. You’ll save time in the long run. Prefer the highest bandwidth communication you can enable, even if it feels inefficient.

Results are the primary measure of progress

I don’t see working software as the primary measure of progress. We can ship oodles of working software every day and benefit nobody.

How are people’s lives enriched by our toil? How are our organisational goals furthered by our software? How is society better?

Have we achieved what we set out to? What have we learned from our experiments?

The less software needed the better!

Sustainability

I’d make the call for sustainbility more imperative. We don’t rely on static processes to keep development sustainable. It requires active effort and adaptation to combat the natural incentives in play.

We don’t go fast now at the expense of tomorrow. We strive to keep the cost of change curve low. 

Technical Excellence

I find myself avoiding the words agile and agility since “agile” has become so semantically diffused it can create confusion.

Simplicity

The principle of simplicity is timeless.

Diverse Teams

I’d add diversity to the description of teams that produce the best results. Self-organising teams with a monoculture are not going to produce the best ideas; there’ll be shared blind spots.

I think it can also be useful to expound on some of the things teams need to self-organise effectively.

Double-loop Learning

I’d just add adjusting goals, in addition to tuning team behaviours. The most effective teams benefit from double loop learning. Learning-through-doing that our goals are wrong, or our assumptions when choosing our goals were wrong. 

Your Team’s Principles

How do your principles differ? I’ve only thought about things I’d tweak from the manifesto principles above, not what I’d add. What would you add?

What if we could visualise the cost of attrition?

Here’s a team. Someone leaves. We hire a replacement.
We get lucky and manage to find someone more skilled. Looks like we’re better off?

Really when someone leaves we lose all the relationships they had with the rest of the team as well. The team is a diminished more like 40% than the apparent 20% by their loss. It takes longer to rebuild the team than is apparent. Relationships take time.

It’s worse than that. The team probably wasn’t maximally-connected to start with. And it’s not just the interpersonal relationships that matter but the knowledge of tech and domain. A departure can break teams apart and organisational knowledge needs to be rebuilt.

Your organisation probably has multiple teams. Someone leaving your team reduces its connectedness to the rest of the organisation. Increasing the time to recover even with a swift new hire.

Internal mobility is less of a hit to the team’s connectedness due to pre-existing relationships. It also increases the whole organisations resilience by establishing more inter-team relationships.

Teams following the Isolated-individual model of work… (as opposed to collaborative work like pairing and collective ownership) …are particularly brittle & significantly impacted by staff churn.

How would we think about retention if we could visualise the full impact of someone leaving our team?

Beware looking at teams on a spreadsheet. If you have a hiring rate matching attrition rate it might look like the team health is maintained. It’s probably not.

Tracking tenure by team and average tenure in team can be interesting proxy indicators. Teams can be growing but have dropping tenure.

Bear in mind “All models are wrong, some are useful”. Sometimes teams benefit more from fresh ideas than the value of relationships lost in a change. Sometimes gaining someone who helps everyone else in the team form connections at a faster rate can accelerate the team.

This post is also available as a Twitter Thread

Here’s a team. Someone leaves.

We hire a replacement.

We get lucky and manage to find someone more skilled.

Looks like we’re better off? [1/10] pic.twitter.com/nSE8wJxElo

— Benji Weber (@benjiweber) January 9, 2022

Instead of starting from “how do we hire top talent?”, start from “what are our weaknesses?”

Why are you hiring? Are you hiring to do more, or are you hiring to achieve more?

Design your hiring process to find the right people to strengthen your teams’ weaknesses, rather than trying to find the best people. 

Instead of “how can we find the smartest people?” think about “how can we find people who will make our team stronger?”

Often the language used by those hiring betrays their view of people as resources. Or, to use its current popular disguise: “talent”. 

“We hire top talent” “the candidate didn’t meet our bar”, “our hiring funnel selects for the best”. “we hire smart people and get out of their way”. We design “fair tests” that are an “objective assessment” of how closely people match our preconceptions of good.

The starting point for the talent mindset is that we want to hire the smartest people in the “talent pool”. If only we can hire all the smartest people, that will give us a competitive advantage!

If you focus on hiring brilliant people, and manage to find people who are slightly smarter on average than your competitors, will you win? Achievements in tech seldom stem solely from the brilliance of any one individual. Successes don’t have a single root cause any more than failures do. 

We’re dealing with such complex systems; teams that can capture and combine the brilliance of several people will win. 

With the right conditions a team can be smarter than any individual. With the wrong conditions a team can be disastrously wrong; suffering from over confidence and groupthink, or infighting and undermining each other. Hiring the right people to help create the right conditions in the team gives us a better chance of winning than hiring the smartest people.  

Talent-oriented hiring

If we start out with the intent to find the “best people” it will shape our entire process.

We write down our prejudices about what good looks like in job descriptions. We design a series of obstacles^Winterviews to filter out candidates who don’t match these preconceptions. Those who successfully run the gauntlet are rewarded with an offer, then we figure out how to best put them to use. 

Hiring processes are centralised to maximise efficiency & throughput. We look at KPIs around the number of candidates at each stage in the funnel, conversion rates. 

Interviewing gets shared out around teams like a tax that everyone pays into. Everyone is expected to interview for the wider organisation.

Hiring committees are formed and processes are standardised. We try to ensure that every candidate is assessed as fairly as possible, against consistent criteria. 

We pat ourselves on the back about how we only hire the top 1% of applicants to our funnel. We’re hiring “top talent” and working here is a privilege. We’re the best of the best. 

Weaknesses-oriented hiring

There’s another approach. Instead of starting from our idea of talent and the strengths we’re looking for, start from our weaknesses. What’s missing in our team that could help us achieve more? 

Maybe we have a team of all seniors, frequently stuck in analysis. We need some fresh perspectives and bias for action.  

Maybe we are suffering from groupthink and need someone with a different background and new perspectives. Someone who can help generate some healthy debate?

Maybe we have all the technical skills we need but nobody is skilled at facilitating discussions. We struggle to get the best out of the team.

Perhaps we’re all fearful of a scaling challenge to come. We could use someone experienced who can lend the team some courage to meet the challenge.

Maybe those in the existing team specialise in frontend tech, and we’ve realised we need to build and run a data service. We could learn to do it, but bringing someone in with existing knowledge will help us learn faster.

Maybe we are all software engineers, but are spending most of our time diagnosing and operating production systems. Let’s add an SRE in the team.

Maybe we don’t even know what our weaknesses are—until we experience collaboration with the right person who shows us how to unlock our potential.

Identify your weaknesses. Use them to draft role descriptions and design your interview processes. 

Design your interviews to assess what the candidate brings to your team. How do they reduce your weaknesses and what strengths would they add? 

Leave space in the process to discover things people could bring to your team that you weren’t aware you needed. 

A talent-oriented process would assess how the candidate stacks up against our definition of good. A weaknesses-oriented process involves collaborating with the candidate, to see whether (and how) they might make your team stronger. 

If possible, have candidates join in with real work with the team. When this is not feasible for either side, design exercises that allow people on your team to collaborate with them. 

Pair together on a problem. Not what many companies call paired interviews where it’s really an assessor watching you code under pressure. Instead, really work together to solve something. Help the candidate. Bounce ideas off each other. Share who’s actually doing the typing, as you would if you were pairing with a colleague. Don’t judge if they solved the same problems you solved; see what you can achieve together.

A weaknesses-oriented process might mean saying no to someone eminently qualified and highly skilled; because you have their skills well covered in the team already. 

A weaknesses-oriented process might mean saying yes to someone inexperienced who’s good at asking the right questions. Someone whose feedback will help the experienced engineers in the team keep things simple and operable.

Why not both? 

It’s often worth thinking about when something good is not appropriate. There are rarely “best practices”, only practices that have proven useful in a given context.

At scale I can see the need for the talent-oriented hiring approach in addition to weaknesses-oriented.

Exposing all of your teams’ variety of hiring needs to candidates may create too much confusion.

You may well want a mechanism to ensure some similarity. A mechanism to select for those who share the organisational values. To find those with enough common core skills to increase the chances that they can move from team to team. Indeed, long-lived and continuously funded teams are not a given in all organisations.

If you’re getting thousands of applications a day you’ll probably want a mechanism to improve signal to noise ratio for teams wishing to hire. Especially if you don’t want to use education results as a filter. 

I suspect a lot of hiring dysfunction comes from people copying the (very visible) talent-oriented top-of-funnel hiring practices that big companies use. Copy-pasting as the entire hiring mechanism for their smallish team.

Start from reflecting on your weaknesses. Whose help could you use? Some of the practices from the talent-oriented approach may be useful, but don’t make them your starting point. Start from your weaknesses if you want strong teams.

If you’re struggling with how to get to tidy code, fast feedback loops, joyful work. How to get permission, or buy-in. Try team habits.

Create working agreements of the form “When we see <observable trigger>, instead of <what we currently do> we will <virtuous action>”. This is a mechanism to pre-approve the desired action.

In last week’s “level up” newsletter Pat Kua likened developers asking product managers whether to do activities such as refactoring and testing, to a chef offering washing and cleaning to customers. i.e. it shouldn’t be a discussion.

I strongly agree, but I can see that some people might still be stuck with the how. Especially if you’re the only cook in the kitchen who seems to care that there is mess everywhere.  

I recently suggested every team should be paying attention to the delays in their feedback loops. Keeping time to production under 5 minutes. Running all programmer tests in a matter of seconds. 

Measuring what matters is a good step towards being able to improve it. But it’s not enough. Especially if your manager, product manager, or fellow developers seem unperturbed by the build time creeping up, the flaky tests in your build, or the accumulating complexity.

How we get stuck

Maybe you point to graphs and metrics and are met with “yes but we have a deadline next week” or “just do something else while you’re waiting for the slow build”. We easily get stuck at how to break out of seeking permission.

How can we become a team with code we’re proud of? How can we become a team that has fast effective feedback loops?

I’m a big fan of radiating intent rather than asking for forgiveness, but what if you’re the only person on your team that seems to care? Acting autonomously takes courage. It sends a positive signal to your coworkers, but it could easily be shut down by an unsupportive or unaware manager.

You might give up when your small solo efforts make little headway against a mammoth task. It’s easy to become despondent when a new teammate rants about the state of the huge codebase you’ve been refactoring bit by bit for weeks. “Ah, but you should have seen it before” you sigh. 

People get stuck asking for permission. Asking permission, or taking a risk to do the right thing every time is wearisome. “Just do it” is easy to say but is risky. Especially if you have leaders who are reluctant to let go of control. 

Is quality code only something that teams with sympathetic managers can achieve? Are fast feedback loops something only very talented engineers can achieve? By no means!

A trap that lots of teams fall into is making the safe, sustainable, faster path improvement path the special case. We create systems whereby people have to ask for permission to clean and to tidy. We need to change the expectations in the team. It should be that tolerating a messy workspace is seen as the deviance that needs permission or risk taking. Not vice versa.

How to change this? Propose a new a beneficial habit to your team. 

How can you convince your team to try a new way of working? Make a prediction of the benefit and propose running an experiment for 2-4 weeks, after which the team can review. 

Good habits give teams superpowers. Habits can pre-approve the right actions. Habits unstick us from “doing things” to take necessary actions, when they’re needed, continuously. 

What do I mean by good habits? Refactoring constantly, making the build a bit faster every day, talking with customers. Feedback loops that increase our chances of success. 

Make them team habits and the onus will be on managers and team members to convince each other to not do the good things rather than the other way round.

Examples of good habits

TDD

TDD is great for habit forming—it creates triggers to do the right thing. When we see a red failing test we trigger the habit of implementing new behaviour. We never have untested code because the habit we’ve formed for writing code is in response to a failing test. When we see a green test suite we trigger the habit of refactoring. Every few minutes we see a green test suite and trigger our habit: spending some time thinking about how the code could be tidier, easier to understand, and then making it so.

Sure we could convince our pair to skip the refactoring step, but the onus is on us to make the case for deviating from the sensible default, habitual path.

“When we write code, instead of starting to implement the feature we will write a failing test first”

“When we see a red test suite, instead of writing lots of code we will write the simplest possible code to make it pass”

“When we see a green test suite, instead of moving on to the next capability we will stop and do at least one refactoring”

Zero Tolerance of Alerts

Are you suffering from over-alerting? Do you have flickery production alerts that go off frequently and then resolve themselves without action? Use them as a trigger for a habit. Agree as a team that every time an alert fires the whole team will down tools, investigate and work together. Every time an alert happens: come up with your best idea to stop it going off again for the same reason.

If that’s too extreme you could try with a nominated person investigating. The point is to make a habit. Pre-agree expected, good, behaviour in response to a common trigger. Then there’s no need to seek permission to do the right thing, plus there’s some social obligation to do the right thing.

“When we see an alert fire, instead of waiting to see if recovers by itself we will stop and investigate how to stop it firing again”

Max Build Time

Is your build getting slower and slower? You’ve made it measurable but it’s still not helping? Create a habit that will improve it over time. e.g. Every time you see the build has got a minute slower the next task the team picks up will be making the build at least two minutes faster.

Now the onus is on someone to argue that something else is more important at the time. The default, habitual, behaviour is to respond to a trigger of a slowed build with investing time in speeding it up.

“When we see the median build time cross the next whole minute, instead of ignoring it we will prepend a task to our ‘next’ queue to reduce the build by at least 2 minutes”

Time Waste Limit

Do you feel like your team is drowning in technical debt? Maybe you’re dealing with such a mountain of technical debt. Perhaps it feels like nothing you do will make a difference? Build a habit to make it better in the most impactful areas first. e.g. Make wasting an hour understanding an area of the codebase trigger improvement. When you realise you’ve wasted an hour, update a shared team tally of hours wasted by area of code. When you go to add a tally mark and there’s already a couple of marks there, drop what you were going to do and spend the rest of the day tidying it up.

If you pre-agree to do this then the default behaviour is to make things a bit better over time. Permission seeking is needed to skip the cleanup.

“When we notice we’ve spent an hour trying to understand some complicated code , instead of pressing ahead we will record the time wasted”

“When we notice our team has wasted 5 hours in one area of the code instead of finishing our feature we will spend the rest of the day tidying up”

Spend Limits

Does your team’s work always take far longer than expected? Are you struggling to deliver a slice of value in a week? Maybe even when you think a story can be completed in a day it ends up taking two weeks? Make a habit triggered by length of time spent on a given story. Keep a tally of elapsed days. When it hits double what we expected, the team stops and has a retrospective to understand what they can learn from the surprise. 

“When we have spent 5 days on one story instead of carrying on we will hold a team retrospective to understand what we can learn to help us work smaller next time”

How to help your team form a good habit

Asking your team to try to form a new habit is something anyone can do. You don’t need to be a manager. 

1. Look for a suitable trigger mechanism, in day to day working.
   
2. Think of a virtuous action that could be taken upon that trigger.  
   
3. Propose an experiment of a habit to try, combining items 1+2
   
4. Write it down, as a working agreement for the team.
   
   “When we see a green test suite, instead of moving on to the next capability we will stop and do at least one refactoring”
   
5. Review your working agreements next retrospective.

There’s lots of good habits that you can steal from other effective teams (such as TDD).

A team committing to try to form a habit will make a more effective experiment than one person trying to do the right thing against the flow. 

Let me know how it goes. What resistance do you run into? What are your team’s most powerful habits?