4 environment variables to make your async agile team successful
Leaders of teams that adopt async agile will need to use their judgement to decide a few factors that influence the team's success and the environment they'll work in. I'm calling these four factors, "environment variables".
- Create a lean, maker-centric team. Add managers only if necessary.
- Don't be a human router. Deemphasise your positional authority by writing things up.
- Make sensible tradeoffs so you don't undermine your teams' way of working. Here are some important tradeoffs.
- Speed & thoughtfulness
- Written communication & trust
- Defaulting to action and the consequences of actions
- Transparency and policing
- And lastly avoid the common pitfalls when going async.
- Creating second shifts for communication.
- Expecting results too early.
- Being too busy to improve.
In the last two posts, I described the elements to define your async agile culture and how you can create a motivating environment for your people to work in. In today’s post, I want to address four sets of environment variables that’ll affect your team’s productivity and happiness. What are environment variables? I’m glad you asked.
“An environment variable is a dynamic-named value that can affect the way running processes will behave on a computer. They’re part of the environment in which a process runs. A running program can access the values of environment variables for configuration.” - Wikipedia.
In a similar way, you as a leader will need to define some environment variables dynamically, depending on the situations you find yourself in. Judgement, experience and vision - you’ll use all three to define these variables. Your choices will influence your new async agile team’s productivity and behaviour. Sounds interesting? Let’s get started.
Team structure
We’ve addressed the difference between managers and makers right at the start. Here’s what that difference looks like on software development teams.
Makers build stuff. This includes your designers, testers, developers, writers, etc.
Managers oversee stuff. They coordinate projects, manage teams and people and remove obstacles.
While managers perform yeoman service on many teams, async agile is all about optimising for the makers. Managers’ schedules are incompatible with those of makers as we’ve discussed before. So you need to keep that management layer as thin as possible. If you don’t, you’ll frustrate all your makers, because the managers will want them to be in meetings, just to get a hang of what’s happening.
I understand if you find what I’m saying obvious. I’m saying it because in some organisations a maker-first thought process isn’t natural when structuring teams. Leaders often think about the management layer before they staff the makers. Before they know it, they construct a thick management layer. The thicker your management layer, the more bottlenecks and the more box-ticking your makers will have to do.
I suggest going about it another way. Staff your teams with the best makers you can find to solve the problem at hand. Once you feel good about that team, staff the thinnest management layer you think you can get away with. If you think the team can do without a full-time manager, institute a first amongst equals (FaE) structure, where someone takes the additional responsibility for management tasks. If the team expresses the need for a full-time manager or you see a gap in leadership and coordination, you’ll know that you’re solving a real problem, not an imagined one.
Async agile builds communication discipline in teams at the atomic level. This means you can automate a lot of communication and reporting that a manager would have otherwise have to do. Unsurprisingly, Liam Martin has found from his research that async-first organisations have a “50% smaller managerial level than their synchronous counterparts.” Be ready to embrace that efficiency.
Positional authority
While you sweat team structure, don’t forget to introspect about your own role. We’ve discussed this before - don’t be a human router! Your positional authority can make you the nerve centre of information flows for the team and the organisation. Inevitably, your good and bad habits will affect the team’s own discipline. Consciously remove yourself from being a router. You can do this by being a diligent writer. Document all conversations - no exceptions. You can always decide who needs to see these documents. Teach yourself to “respond with a link”. Not only will this make you an efficient and consistent communicator, you’ll also role model asynchronous work behaviours. Plus, you won’t block your people just to get information out of you. Liam Martin recommends you follow the “rule of three” to get disciplined at documenting things.
"I have what I call the rule of three, which is the first time that I do something, I don't document it. The second time that I do something, I think about how I'm going to document it. And then the third time, I absolutely document it. And the reason it's the third time and not the 100th time is you lose some details inside of that documentation."
Lead by example. Anything you have to say more than once, write it down. That’ll help you de-emphasise your positional authority, level the playing field, and make you a force for the change you’re driving.
The tradeoffs you make
When you introduce asynchronous work on your team, you’ll have to manage a fine balance. You know I’m not an asynchronous communication absolutist. I advocate for balance. While there’s the balance of values between synchronous and asynchronous communication, you’ll also make other tradeoffs. Let’s look at a few of them.
The choice of collaboration patterns rests on a fine balance.
Speed and thoughtfulness. Software delivery teams always make tradeoffs between speeding up and being thoughtful. There’s a bias for speed in most companies, but speed and productivity are not the same thing. So while defaulting to action speeds you up, you want to slow down so you can refine your ideas and give people time to exchange views. Communication benefits from slowing down. Who wants to drink from a firehose? Thoughtful, inclusive communication takes time. Conversely, when you have all the information available, you want to decide at speed. There will be times when you need immediacy. Balance those with an environment of thoughtful calm.
Written communication and trust. When you ask people to communicate in writing, they leave an audit trail behind them. No one wants their colleagues to use their writing against them in the future. The team needs to trust each other. Written communication exists to make people’s lives easier, not to crucify them. The written word is also easy to misunderstand. Your emails, documents, chat messages don’t carry tone. While you can convey emotion using tools like emojis, everyone else needs to follow a universal principle. I’ve heard some people refer to it as API - “assume positive intent”. So when you see a message that offends you, pause for a moment. Now assume the best possible intent from the writer and imagine they wrote it with a smile on their face. If it feels better, then maybe they didn’t mean it badly after all!
Defaulting to action and the consequences of actions. You want people to default to action and not wait endlessly for dependencies or perfection. This can only happen when people show a sense of entrepreneurship and risk taking. Things will inevitably go wrong. If they fear punishment and retribution for mistakes, few people will ever take a risk and default to action. As a leader, you’re responsible to set the right values for this environment variable.
Transparency vs policing. Let’s be very clear. Between time cards, task boards, chat presence indicators and all other digital footprints your people leave at work, it’s easy to be a nosy remote manager. You’ll have to cultivate a “light touch” approach. Be there for your people, but not in their way. Async agile promotes transparency and up-to-date information at all times, but if leaders and managers use that to create a surveillance state at work, the practices won’t hold up for very long.
There’s no definitive answer to any of these tradeoffs, except saying that asynchronous work needs a safe and calm team environment. Providing that environment is your job as a leader. And your response to each of the above tradeoffs will affect how people perceive their team environment.
Avoid the pitfalls
Async agile isn’t without its pitfalls. I recently read a post by a senior leader at a major tech firm, advocating for asynchronous communication. It sounded poetic until he wrote about how he has free time after dinner to read anything that anyone sends him. That, despite how crazy his day gets.
Think about that for a moment. We’re not advocating for crazy days at work. We’re aiming for calm, happy, productive teams. Async agile is not about a second shift just to consume written communication. And no, dear leader, you shouldn’t do that as well. It’s a poor example, and it sends the message that communication is not a part of your day job.
Virginia Satir’s process of change
The other pitfall is to expect results too early. We’ve discussed earlier that change is rarely a straight line. When you introduce a new way of working on a team, results will flag for a while, as the team copes with the change. Teams and their leaders get impatient at this stage and abandon the change, saying “it doesn’t work”. Be courageous and stay the course. Attempt to shorten that period of chaos and resistance, but remember - that dip in the graph is natural.
And last but not least there’s the pitfall of being “too busy to improve”. This is true of both teams and leaders. There’s always something important to do. An upcoming release, an upset client, people rolling on and off the team, production issues and whatnot. There’s never an ideal time to introduce change. If the team’s under the pump for a dozen other deliverables, improving their collaboration practices will be the last priority. You might as well not try. Your job as a leader is to make space for the team to think through these changes, to own them and to absorb them into their ways of working. Good things take time!
These four environment variables influence the configuration of your virtual workplace. Keep a close eye on them, because they’ll influence how your team works together. This ends my three-part series on team and organisational culture. Over the next couple of posts I’ll address two other leadership topics - how to spend your money and how you take care of your people. Keep your eyes peeled for those!