How to Make a Team Awesome

[jlengstorf]

From an email to Deen:

1. Take the time to plan up front. It saves hundreds of hours.
2. Make sure each task has a single owner.
3. If a task is too big for a single owner, break it into smaller tasks.
4. Create a Single Source of Truth (e.g. GitHub issues) and enforce a policy where only things in the SSoT list will be acknowledged and/or worked on.
5. Automate as much of the peripheral work as you can. Make boilerplates, create processes that are enforced by robots (e.g. postcommit hooks to run tests), and other things that are hard for humans to remember and easy for robots.
6. Only set meetings if there's an agenda and a concrete deliverable at the end. If a meeting ends without one or more action items (and a single owner for each one) it was a waste of time.
7. Limit meetings as much as possible — force people into the habit of thinking through what they need before the meeting, not afterward. Follow-up meetings with new questions that should have been caught in the first meeting are a waste of time.
8. Dedicate time to learning/teaching new ideas and best practices. A weekly half-day is ideal (and pays dividends), but at least once a month. Have someone from the team teach about a skill or technique they're good at to everyone else. This builds teamwork, helps build a team ethos, and gets everyone doing things in a uniform way.

Most of it comes down to productivity and following a set of standards as a group. If I know how a project will look no matter who did the work, I don't waste time figuring out where things are or nitpicking implementation details — it's done OUR way, not MY way (or STEVE'S way).

The occasional team lunch or non-work activity so everyone feels like they're part of a team instead of a set of employees is helpful if you can swing it.

[darleendenno]

Is your focus on general team awesomeness? Or related to a specific field?

The first three points are vital, and enforced via agile (or agile-like) design/development. Too many times someone in management informs me I'm designing a thing, but fails to follow up with research, or information needed for me to task it out. Needles to say, if I can't task it out, I'm not designing it.

4. Creating a single source of truth is the best idea, yet the trickiest to implement. Designers need access to style guides (I use Frontify, but I'm sure similar/better tools exist), collections of assets (Lingo is okay at this), feature requirements, etc. It's difficult to find a solution for all of these 'truths', but doing so will mean team members spend less time trying to find something and more time doing.

5. A nice idea that we do is a 'learning lunch'. Once a week a member of the team demonstrates something they're working on, or a cool thing they learned/are learning during a 30 minute period. Then another 30 minutes is Q&A with discussion. It's been the perfect way to showcase internal talent, learn something new, and take a break from the current project.

Having a way to see what tasks everyone is working on provides transparency and allows the team to collaborate if one's plate is too full (again, one source of truth). Building a team mindset of getting to the finish line together eliminates the individual fear and stress of being unable to complete a task on time. We frequently reassign tasks, or offer to take a task when we have time to ensure all tasks are completed and everyone wins. If all tasks get completed on time, we also get bagels (thank you, PM).

This may be specific to software development/design, but it's important to have a general overall design of the application prior to designing individual features. Nothing pushes deliverables like redesigning/redeveloping features due to initial lack of understanding based on research. Changes in requirements happen, but ff something smells fishy to a team member, encourage them to speak up and ask questions rather than spend time designing something they feel will be redesigned later. Having a central point of contact for questions speeds up the "Who do I need to talk to?" process. We post ours on a whiteboard in the central lobby.

[jlengstorf]

Is your focus on general team awesomeness? Or related to a specific field?

I think there's very little that changes between fields, really. Every team has projects, and those projects require collaboration — it doesn't matter if the project is building software or organizing a bake sale.

Creating a single source of truth is the best idea, yet the trickiest to implement. Designers need access to style guides (I use Frontify, but I'm sure similar/better tools exist), collections of assets (Lingo is okay at this), feature requirements, etc. It's difficult to find a solution for all of these 'truths', but doing so will mean team members spend less time trying to find something and more time doing.

I was specifically talking about managing tasks, but this is a really good point to bring up as well.

I think it's okay to use multiple tools, honestly. The key thing is that for each thing — a style guide, assets, todo lists, etc. — there's only one source for each. A style guide that's half in a repo and half in an internal document is going to cause headaches and will likely get ignored. It's critical for the team to choose a single place for each key piece of information (and obviously the more consolidated the tools can be, the better), then stick to it.

A nice idea that we do is a 'learning lunch'.

This is awesome.

If all tasks get completed on time, we also get bagels (thank you, PM).

Never underestimate the power of a food bribe. :)

This may be specific to software development/design, but it's important to have a general overall design of the application prior to designing individual features.

I think this is universal for any collaborative project. Too many people end up with an underpants gnome roadmap, and things fall apart when we hit phase 2.

Without clarity, it's really easy to feel uncertain, which saps motivation and leads to procrastination. Not to mention the ownership problems that come with a plan that involves too many question marks.

Thinking through all of the steps by doing "boring" stuff like interactive prototypes (or writing out a full shopping list for a dinner, or whatever) catches most of that uncertainty ahead of time, or at least creates todo items with an owner that say, "Figure out what we need to know before we can plan X."

[darleendenno]

Another point: effective team feedback handling. It's important for team morale to establish a protocol for recommendations, feedback, and complaints. Discussing and writing down a process of what do to when a member expresses valuable feedback (even distaste is valuable) can evade gossiping. Assuming everyone responds to criticism in a professional manner is a pitfall of a number of teams. Don't allow room to build walls between members. This could be keeping a jar to write down kudos/concerns/complaints to remain anonymous. A better approach is to gather once a month to provide a safe place to discuss what's working and what's not working (though this does become another meeting).

Any recommendations?

[jlengstorf]

Assuming everyone responds to criticism in a professional manner is a pitfall of a number of teams.

This line stuck in my craw, but I'm not sure I have a good rebuttal. So let me ramble for a minute:

I think everyone responds to criticism well when criticism is delivered properly. So while I don't think it's possible to get to a place where everyone has the resilience to hear things like, "I think your idea is terrible," I also don't think it's necessary to build workarounds for frank discussion. (And, quite honestly, if a team can't give feedback without being anonymous, that seems like the sign of a bigger problem.)

But that's not to say, "Suck it up and deal with criticism." That doesn't work. If I come down on my brother about something he's doing that I disagree with, he shuts down and feels terrible and I don't get anywhere near changing his mind.

Instead, I think it means building team trust about what feedback is, and what feedback is not.

Feedback is:

• A tool for fine-tuning an idea by lending a different viewpoint
• An opportunity to express ideas for improving an idea
• A way to play devel's advocate and challenge the idea to see how it holds up

Feedback is not:

• A place to challenge a coworker personally
• A judgment of anyone's character
• An opportunity to make yourself look smart by making someone else look stupid

Probably the biggest challenge in this is switching the mindset that all feedback and criticism is negative. I've seen a lot of teams where the only time someone hears how they're doing is after they've fucked up. Naturally, people on teams like this are terrified of feedback because it's always negative.

It feels really strange at first to make a point of calling out good work, good ideas, and other positive traits on a team, but by incorporating positive feedback whenever it makes sense — and I'd argue that it makes sense often — it switches the internal narrative of the team: feedback is more often good than bad, so criticism isn't seen as an attack; it's seen as an effort to make the final product better.

This is at the core of the team's bond, though. If the team sees feedback as one person calling out another person, that means the team is looking at ideas as combat. This is wrong.

Ideally, the team sees itself as one entity moving toward a common goal. And since we're always calling out when we're doing things well, if someone sees that I'm drifting off-target and lets me know that I fucked up, I don't see it as a personal attack — I see it as a course correction.

A better approach is to gather once a month to provide a safe place to discuss what's working and what's not working (though this does become another meeting).

I'm by no means advocating the more dogmatic aspects of agile management here, but one thing I've really found impressive is how @shinytoyrobots (my new manager at @IBM) implements agile meeting framework.

It works like this:

• Every two weeks, we do a planning meeting (a.k.a. "sprint planning") where the entire team meets to:
  1. review what's on the the todo list
  2. break down projects into smaller, ownable tasks
  3. estimate how much work is required for each task
  4. decide how much can reasonably be accomplished in the next two weeks
  5. divide tasks among the team so everyone is clear on who's doing what
• Every day, the team has a 5-minute check-in (a.k.a. "stand-up meeting") where everyone answers three questions:
  1. What did you accomplish yesterday?
  2. What are you planning to accomplish today?
  3. Is anything blocking you from accomplishing today's goals?
• After two weeks, we meet to review our progress (a.k.a. "retrospective" or "post-mortem") and discuss:
  1. What went well during this period that we want to keep doing?
  2. What can we improve in the next period?
  3. How will we measure those improvements?

This means that the team can run on a single daily meeting. Any additional meetings come from a need to resolve blockers, gather information, or address an unforseen problem.

@shinytoyrobots also schedules a weekly 30-minute 1-on-1 session with each team member to give everyone a chance to discuss things that they may not be comfortable bringing up with the rest of the team.

This is really great for building a team that stays on the same page, sees how everyone is contributing, and feels comfortable giving feedback. I think a lot rests on management to lead by example in a setup like this, but it only requires a modest amount of organization to pull it off; this isn't some crazy supersystem of rules for managing a team — it's just a sane way of building a process that keeps clarity extremely high at every level of the team.

[shinytoyrobots]

Lots of people get concerned about the imposition of any kind of process. The gut reaction always seems to be "oh, this is just going to be more work".

A big part of that is because process changes and team management often misses out the "why" part of what's being changed. So if I'm making process changes in how a team works, that needs to have a reason and that reason needs to be clearly communicated.

...and like every other part of work, its impact needs to be measured. As a team we tried moving from a scrum approach to our work to a kanban approach. We talked about what we were trying to achieve, we agreed a point at which we'd assess progress against those success metrics. When we circled back, we could pretty clearly identify that what we'd hoped to achieve wasn't working (for various internal and external reasons). So we reverted back to scrum; but everyone knew why we'd changed, and why we'd reverted, and nothing was simply "top down" imposed on the team.

The post sprint retrospective is vital. Both in terms of improving the predictability of sprints themselves, but also for flagging problems in a space that is only for the team. It's a meeting where there are no other stakeholders, so it's purely self assessment on a team wide basis.

One thing that wasn't mentioned above; clearly defined and communicated team standards; agreed collaboratively among the team. They are always available for reference; they codify that we operate a no-blame approach, that the team are free to turn down meetings without a productive agenda, and in general is a clear listing of rights and responsibilities within the team.

[jlengstorf]

One thing that wasn't mentioned above; clearly defined and communicated team standards; agreed collaboratively among the team. They are always available for reference; they codify that we operate a no-blame approach, that the team are free to turn down meetings without a productive agenda, and in general is a clear listing of rights and responsibilities within the team.

This. I talked about clarity, but this is a much better explanation of what clarity actually means.

[jlengstorf]

@shinytoyrobots shared this resource, which is worth adding here: https://www.manager-tools.com/manager-tools-basics

[darleendenno]

We run in agile, which has been huge for team development.

I suppose my question is, how should management respond to a team member who does criticize others -- "Your design is stupid"? We ultimately decided that they weren't a good fit for our team, but I wonder if we could have retained them using a better approach. Perhaps they didn't feel heard or included? Is it better to cut off a limb to save the body? Or try to heal the limb?

[jlengstorf]

@darleendenno My argument has always been that it's fairly easy to teach someone new skills, but it's almost impossible to teach someone not to be an asshole.

(I'm fortunate because I've only had to deal with a troublesome team member once, so take my opinion with a grain of salt here.)

I'm sure there are valid reasons that could lead someone to call out another team member, but in my experience, the people who cut down other people are pretty unhappy about themselves or their situation; no amount of environmental adjustment will fix that until they've made the decision to address whatever demons are behind the anger.

I think you can coach people on how to give constructive feedback, but if they are unwilling or unable to adjust their feedback style, it's better to let them go.

[jlengstorf]

Another idea @marisamorby shared with me after seeing how @clearhead runs meetings:

Every meeting needs to have a collaboratively editable agenda/meeting notes doc before the meeting — without one, the meeting is cancelled.

And another from a discussion with @shinytoyrobots yesterday:

• Any meeting should start with the outcome in mind; what's the concrete result of this meeting?
  • This means "meet to discuss _________" is no longer a valid meeting request. Why? What do we need to come out the other side?
• Work backward from the end goal to build an agenda.
  • We need an answer about Thing 1? In order to know that, we need to know Thing 2 and Thing 3. And in order to know Thing 2, we'll need to check on Thing 4. Boom. Agenda achieved.

I really like this idea, because it solves two problems:

1. The person calling the meeting needs to think through why the meeting is being called. No more meetings to create the illusion of progress or to put off actual work.
2. The team sees an agenda before the meeting. If nothing on the agenda concerns you, decline the invitation.
3. If someone sees a challenge that didn't make the agenda, it can be added beforehand as an additional item.
   • This prevents the meeting that ends as soon as a developer walks in and says, "Whoa, we can't do any of this until _________ is done."
4. Meeting notes can be added during the meeting, in full view of everyone.
5. After the meeting, a public record of what was discussed, what the action items are, and who's responsible already exists — no need for extra admin work.