Self-Organizing Teams Need a Gardener

A flower garden with a wide variety of purple, red, and white blooms

The position of managing a self-organized team is a tricky one, and not many individuals promoted to management are suited for it. The traditional management candidate earns their stripes by being good at the technical task they are supposed to supervise, which does make a certain amount of sense. But the catch is a self-organizing team isn’t looking for a technical expert to tell them what to do; they’re looking for someone to block problems, provide insight, provide air cover, and maintain balance in the garden.

The manager on a team where there’s technically no need for one does what good managers on traditional teams have done for decades: they provide a vision of where to go, provide insight on how the journey is progressing, and remove problems as they appear in the path.

Teams as a Garden

The ol’ command-and-control model of teams and leadership is built on the idea that any butt in a seat, combined with enough other butts in other seats, can accomplish a task well. This thinking somehow survived into the 21st century, and is somehow getting a revival of sorts as the “return to the office” debate heats up. (It’s almost like a generation of decision makers has refused to either adapt with the times or get out of the way, but that will eventually resolve itself).

These days, it very much matters who is in what role, and how they interact with their other teammates. The GM of the Wendy’s I described in the last post described herself as a gardener: “I have to decide who to plant, where in the garden they’ll thrive, and do a little weeding and pruning to make sure everyone gets enough sunlight.” Jim Collins in Good To Great talked about getting the right people on the bus, and then finding the right seats for those people.

A team within a larger organization that has a budget, cannot be truly self-managing. The next best thing is a manager who views the team as a garden to be tended.

Maintaining Perspective

The manager’s role in a self-organized environment is largely about pointing things out.

“Was everyone aware there was a velocity drop last sprint?”
“The client had some specific notes from last demo…”
“Maybe this isn’t a fair conclusion, but it seems like pull requests are taking a long time to get reviewed.”
“I’m seeing a lot of work in progress that doesn’t seem to align with our sprint goals…”

When being trained to manage a Wendy’s in the mid 2000’s, the actual position assigned to the manager in charge was called the “Operations Leader.” (I have no idea if this approach survived the buyout that washed away so much of the Wendy’s Dave Thomas built). This was a change from the old way, where a manager worked in a position like sandwiches or fries and called the shots from there. It was like shifting from the player-manager arrangement baseball had early in the 20th century, to the modern “managing is a full time job” approach.

Not being tied to a position, being constantly on the move observing the restaurant operation, allowed the manager to see things like a slow moving front line. Or an over-full trash can. It allowed them to run to the back for more $1’s without hurting the flow of the team. I was taught that if I needed to step into a position, I needed to know how I was getting out of it — “I’m covering fries till Juan gets back from his break” or “I’m going to step in and help fill the grill with meat.”

The manager on a software team likewise isn’t heads-down writing code; they’re looking around, observing. They’re connecting with the client or the stakeholder. They’re digging into metrics. This gives them a wider perspective and more detailed context than most of the team who are writing code or similar tasks. From time to time, they dive in to pair with someone, or to take a quick look at some tricky problem. They’re uniquely positioned to reflect the performance of the team back to the team.

Maintaining Momentum

In a perfect world, this reflection should be enough to get the team started on either a solution or an explanation (as much as a senior leader might like an action plan when velocity dips, sometimes it can’t be helped). But we’ve all been in that meeting where everyone understands the problem but nothing seems to push the group towards decision mode.

This is where the manager needs to start asking some pointed questions.

“So I’m hearing this card isn’t needed — can we remove it?”
“Is the root cause of this bug in the data layer or the data itself?”
“I have to give George something…based on our velocity trend, can we do this in the current sprint?”
“Does this implementation work? Can we merge it now and add enhancements to the backlog?”

As the “ops leader,” keeping customers flowing through the lines is the primary goal. Sometimes a register operator is lingering a little too long chatting with a regular instead of getting the next order. Sometimes the grill operator is a little too focused on aligning the meat in perfect rows. Friendliness and attention to detail are excellent qualities we all want to see in people, but without the benefit of the wider perspective it can be hard to tell if we’re going overboard.

Even the most disciplined software creator will charge off into the weeds from time to time, and very few of them think deadlines or estimates are things intelligent folks deal in. By bringing their experience and perspective on the entire project to bear, and helping the team understand the big picture a skilled manager can be the difference between success and failure on a project.

The manager is also in a unique position to be the “first follower” of a suggested action, and thus break deadlocks or violent agreement. And if all else fails–and I mean, really fails–sometimes it’s the manager who needs to make the decision.

Maintaining Balance

Building teams out of individuals with different backgrounds and experience levels is challenging. Expecting them to just work together to accomplish common goals with limited direction is an extra layer on top of that. We can’t find a better example of this than the Wendy’s lunch team: high schoolers in an occupational intervention program, immigrants, retirees, college students, and occasionally a full adult training to be an assistant or general manager. One does not simply plop this group onto a restaurant floor and watch them work together in perfect harmony. This garden needed cultivating.

Management:

Hired for people who could play well with others
Got to know the team, and learned what different people valued
Observed interactions on the line and made note of good and bad matchups
Intervened with bad performance

Rather than thinking about the number of full-time equivalents they needed to hire, the folks at this Wendy’s thought about the skill and personality gaps. They were hiring for someone who could keep up with Janet, for someone who could be patient with Juan’s broken English. They were careful to not upset the harmony of their team by introducing someone who was obviously not going to be able to mesh with the rest.

This didn’t always lead to happily-ever-after, because people are people. So management learned that Janet and Teresa just didn’t get along, and it’d be silly to position them to work together. They discovered that Juan and Ricky apparently could read each others’ minds, and tried not to separate them.

They also took steps to support people who were really struggling, to eliminate an excessive burden on the rest of the team. A manager pairing with someone till they got the hang of things on fries, or giving direct feedback on how to improve saved resentful and friction among the team and let them just work.

In a worst case scenario, when we discovered that George had certain prejudices against immigrants he wasn’t willing to rethink…well, this is a capitalist society, and most teams (even self-organizing ones) can’t just eject people. That too fell to the manager to handle.

TL/DR:

The manager does the hard work of protecting the team. From outsiders, by way of handling senior management and careful selection of new additions, and from itself by way of monitoring and nudging members towards better performance. They also are charged with doing the hard work when someone is struggling to sync with the team and with being the bad guy in situations where someone won’t.

The manager on a team where there’s technically no need for one does what good managers on traditional teams have done for decades: they provide a vision of where to go, provide insight on how the journey is progressing, and remove problems as they appear in the path.

June 30, 2021 0

Self-Organizing Teams Are Teams of Leaders

Photo of an old-style Wendy's in Eugene, Oregon

I am a huge fan of a self-organizing team. I picked up this quirk long before I ever wrote a line of code — we’re talking at 17, working the lunch rush at a Wendy’s. The organized chaos of of the front counter is a thrilling thing to experience; two registers constantly loading up 2 orders each, a sandwich maker and grill cook working a choreographed dance to keep fresh beef and chicken flowing to warm buns, runners filling drinks as they call out for a Biggie fry. And…no manager.

The manager was there, obviously. Or more accurately, they were nearby. Observing the flow, looking for disruptions. Pulling the angry customer aside. Bringing up a sleeve of cups to make sure no one had to leave their post. Wendy’s went so far as to rename the position the manager had as the “operations leader” in order to rewire the company’s thinking. The manager didn’t direct the action, they weren’t a star player on the field — they were a coach, a strategist, a scout. You stayed on the sidelines, let the crew do their job, and jumped in to deal with problems as they arose.

Sure, if a register operator wasn’t asking anyone to “Biggie-size” their combo, the manager over-hearing this would remind them of procedure. But they weren’t sitting in the middle of the kitchen, directing everyone’s movement. Each member of that team understood their job and just did it. They would react to the feedback provided by the manager — “We have another 10 cars in the drive thru line” or “The void percent is getting high.”

Non-Manager Leadership

Looking back, the lunch crew wasn’t just a collection of A+ professionals executing as some amazing hive-mind. When I was started on being a runner, I theoretically knew everything I needed to do–how to fill the cups with ice, what the codes on the screen meant, where to stage trays, how to pack a to-go bag. But Jackie had been doing this job, with and without runners, for five years. She had a mindboggling wealth of experience, and fortunately was willing to share it.

“Don’t wait to get the chili on this order — it’s the only thing you need till the sandwich comes up, and you can use that time to make the drinks for this couple on the next order.”

“Okay, see those four construction workers that just walked in? Just call out the four Biggie fries now so Juan knows he needs to drop more.”

“Didn’t you see we just refilled that iced tea? It’s too hot–see if drive thru will get you one so it won’t water down as much.”

The same thing happened with everyone else — sandwich makers who would tell me how I could help them go faster, or suggest things I can do to finish the order while they were running behind. The folks on the fry station who would direct me to scoop my own fries while they dropped more into the fryer. A hundred or more little suggestions or directions in the course of a two and a half hour rush shift. Almost none of them coming from a manager.

Gradually, I began to be the person giving those directions. “Just set up a new tray every time, don’t bother waiting till they tell you it’s to-go or not.” “Hey Juan, I see about 8 people heading inside!” “Janet, the group that loves grilled chicken is here, do we have enough up?”

There wasn’t a diminished leadership presence because of the manager being removed to a more strategic role, there was an increased in localized leadership. People who understood the immediate needs spurred their peers in the right direction, helped to avoid mistakes, and provided praise for the little-but-crucial things done well that would never warrant attention from management with their eyes on the big picture.

The Software Tie-In

There’s really not much difference between a software team and a fast food team. In fact, I’d say the primary success metric is the same for both teams: how often can you deliver customized, completed work to the customer?

_{In-before-derisive-comments-about-“burgerflippers:” All jobs boil down to a series of steps to be followed. Mastery of a role boils down to understanding how those steps can and should be adapted in the face of rare or new situations. Is mastery in running a fry station an easier goal than mastery in writing data layer logic? Based on my experience, it’s impossible to tell — both roles have plenty of people who want to achieve mastery, and both have plenty who just phone it in.}

An incorrect order (a burger instead of a chicken sandwich, for instance) is a lot like a bug. And just like a bad software team that treats bugs as part of the process, a bad Wendy’s has adapted to remaking orders after the customer complains. A good Wendy’s (or software) team is horrified every time they make a mistake that reaches the customer — and works together to avoid the mistake in the first place. They aren’t just winging it, assuming “If I’m doing this incorrectly the manager will stop me.” And they aren’t letting their peers do that either.

A self-organizing software team is a group of professionals who are comfortable enough in their own skills and their place on the team to provide leadership when it is appropriate. If Jane sees a security gap in some code Bob worked on, she’s able to constructively point it out and help resolve it. If there’s a pipeline problem creating a bottleneck, no one waits for management to authorize fixing it — Mia just pops open the YAML file and fixes it. If there’s missing test coverage around a critical flow, Linda doesn’t need to get management’s permission to address it with Tyler before it gets merged. If all of these interactions had to flow through a single point of authority they’d just outsource the whole team within 6 months.

So what IS the manager’s role if everyone’s a leader? Let me get into that next time, since I’m willing to bet not many of you read even this far.

June 27, 2021 0

The Code, the Acceptance Criteria, and Does Anything Else Really Matter?

The words "finish line" in black block letters against a white background

Somewhere along the line, I think software creators got a reputation for being insanely smart. This is valid, largely accurate, and totally okay.

Also somewhere along that journey, some organizations decided that since software creators are so smart, software creators didn’t need specific instructions. General goals for a user story would suffice.

Also also somewhere along the way, some other organizations realized that smart people get their own ideas. Often, those ideas often weren’t what management or the client wanted, so those organizations use all the character limits and fields included in the card program to define user stories. Down to the method names to be created.

Two extremes, staring desperately at each other across a gulch. A gulch full of software creators from both sides who have hurled themselves into the abyss after realizing they can never actually deliver what’s required because of terrible systems.

Definition of Done

I think part of the problem is the vocabulary, and how there’s somehow multiple sorta conflicting definitions of what a “requirement” is, and “acceptance criteria” similarly can mean different things to different groups at different parts of the cycle. What every piece of work actually needs is a definition of what “done” looks like — how do you know this goal is finished?

When I set out to hike a trail, I know when I’m done. Even on a interconnected set of trails in a national or state park, I know that when I get to the overlook, or loop back to the start, or reach the fork right before the bridge, that’s the end of the hike. It should be the same way with picking up a card — “Go for a hike” as a title with nothing else to go on is a terrible definition of done, and so is

Wear the Walmart boots, not the Bean boots
Drive your spouse’s car
Head East out of your neighborhood
Drive I-71 North to exit 183
Find the Notch Valley Trail Head parking lot
Park in the shade
- etc etc…

Software creators are smart individuals who have been trained in the art of solving problems. If you give them a solution to implement, at best they will be bored and THAT is never a good thing. If you give them a poorly defined problem they’re going to fill in the blanks, which can lead to an implementation that isn’t actually useful in the wider roadmap.

Define the Problem in Sufficient Detail

The goal of a card should be to define the problem being solved. Be it a value story, a list of behaviors the software should have, a self explanatory wireframe showing what it should look like at the end, or ideally a combination of all that. If there are technical concerns — say, a specific database that needs to be involved or a security concerns to be considered — that should also live somewhere in the card.

You don’t want to be prescriptive on a solution before anyone’s started to pull back the curtain and started work on the card — what makes sense during a discussion with a product owner, backlog refinement or sprint planning might not make sense in practice. If the card is so specific one has to prove it wrong before they can do the work, that’s all bad.

But leaving it completely open ended is also a recipe for a terrible demo. Most software creators won’t have been in the meeting where the requirements were discussed with the client or product owner… meaning their solution to a minimalist prompt and it’s behavior might be absolutely inappropriate in the wider context.

TL/DR:

The goal in writing a card should be to put everything in it necessary for any member of the team to read it, maybe ask a couple clarifying questions, and come up with an implementation plan. The goal shouldn’t be to hand them an implementation plan. It should not be to create a cryptic post-it note reminder with a single sentence fragment. The card should resemble (in written form, obvi) that scene in “Apollo 13” after everything goes sideways: Gene Krantz first defining, and then telling the team to work the problem.

June 17, 2021 0