Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to Make a Team Awesome #6
From an email to Deen:
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.
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.
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.
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.
This is awesome.
Never underestimate the power of a food bribe. :)
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."
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).
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 not:
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.
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:
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.
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.
This. I talked about clarity, but this is a much better explanation of what clarity actually means.
@shinytoyrobots shared this resource, which is worth adding here: https://www.manager-tools.com/manager-tools-basics
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?
@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.
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:
I really like this idea, because it solves two problems: