I recently left my company to move from a development role to a management position. In the last couple of weeks before I left, I shared a few brief thoughts on the sorts of things I feel are important for teams to flourish, but are within everyone's ability to influence and contribute. Each item on the list is a single, simple act or behaviour that has a generative effect for the people on a team, yet requires a bare minimum of effort on the part of each individual.
Sometimes it's easy to get lost in the work and be wrapped up in your own world with your own list of stuff you need to get through. When we get help from someone, most of us would say thanks and figure "job done". That's absolutely ok! There's nothing wrong with that, but what if we worked toward building a culture of gratitude? Rather than just saying "thanks" and moving along, tell someone why you appreciate their help: "Hey, that spreadsheet list is really going to save me a heap of time. I'll be able to get through this task a lot faster now" or "You've really cleared that problem up for me. That really makes it a lot easier for me to concentrate on the rest of these changes. I'll probably meet that client deadline after all".
Telling people how they've helped you has a generative effect on the team culture: It describes a clear outcome for the person helping and recognises a direct impact of their involvement, it builds trust and communication within the team, and it also has the useful side-effect of being an example for feedback check-ins. Plus it feels good.
Technical people can be very particular about the tools they use and the coding style they adhere to. That generally serves us well in the industry but it also means we often have strong opinions about what makes a "good" vs "bad" approach. It's very tempting when someone asks for help or makes a mistake, to criticise their implementation or challenge their decisions that led to that point. "Oh! Why have you done it that way?", "Ugh. No wonder you've got a problem. Everyone I know is using [magical wonder-framework X]", or "You should never do [X]. The only good way to do [X] is... (huge lecture ensues)". These are all evaluations or value judgements that implicitly reflect on the person asking for help.
If someone is asking for help, they're consciously making themselves vulnerable to feedback and genuinely don't know the best answer. How we respond doesn't just affect how they feel about opening up for help in future, but sends a clear signal to anyone else watching the exchange and will either have a generative or dampening effect on the whole team. This is especially true if there is a power dynamic at play, e.g. someone asking their manager or team lead for help or input. When offering a solution it's often helpful to seek more context like "What things have you tried already?", "How did you arrive at this implementation?", "What was your decision-making process before you landed on this approach", or "Similar examples I've seen for this problem have included... (examples). Would any of those be a good fit?".
By establishing how familiar a person is with the technical problem they're dealing with, we're able to be more conscious of our own assumptions and implicit bias before making too many assumptions about what the person actually needs. Sometimes it's just a quick and functional fix to a simple road block; sometimes it's hand-holding through new, unfamiliar technology that they might be feeling self-conscious about.
How we respond to one person's requests for help affects the whole team's willingness to contribute in future, and that has a direct correlation with the team's productivity.
Often the best ideas or solutions are the ones we've never even heard about. In our own project teams - or even more so in support - we'll be focused on getting stuff done for a client and the small successes and clever techniques we employ seem fairly insignificant in the greater scheme of things.
Talking about a great outcome - even if it seems really small - can expose other people to a new idea they might not have been able to arrive at on their own. It gives people more context on the sorts of problems you're solving and increases your visibility as someone to turn to when they encounter similar problems themselves.
And if you see a colleague employ a technique or a trick that makes you think "Huh! That's quite cool." then tell your team. We all benefit by elevating each other and opening doors on what we're doing. It helps us all learn, it helps strengthen those team communication channels and it helps us describe the outcomes we're delivering for clients. It's almost never about the actual code; it's about how we've made life easier, faster or more reliable for the people who rely on it.
If a team is functioning well, its people are sharing opinions and thoughts with each other regularly and know that challenging those beliefs is an integral part of ensuring the outcome we produce is well-understood and can be justified to the end user. That means the team needs to feel safe to engage in constructive conflict.
We won't agree 100% of the time. We shouldn't: that's just not how humans work. Conflict is a healthy and essential part of any team dynamic. If you're not engaging in a debate about whether pair programming really helps or whether that routine you've just written should be refactored or if this Skype conversation should be a meeting or an email, then it means you're not communicating much as a team. If the chatter within the team is low (or non-existent), then you have a much bigger problem than conflict: it's likely your team isn't functioning as a true team; it's just a group of people with a shared job title working on their own stuff each day.
Unless there is transparency in your work and communications, and safety in how your people respond to challenges to their understanding of the work, then the work suffers. Assumptions are made; mistakes happen; people miss out on opportunities to learn and grow; productivity suffers.
It's ok to argue your point of view! Do it with kindness, respect, openness and in the spirit of wanting the best outcome for the people impacted by the decisions being made.
These are just a few ideas. There are plenty more. Tweet me with your suggestions! I'd love to hear them.