Pacing your teambuilding efforts

Do you remember your first steps as a software engineer? You probably didn’t even call it this way, more probably just a coder. You learned about best practices, methodologies, architectures. And each time something new fell into your lap you were eager to test it and treat it as a silver bullet, trying to apply it to the fullest to any project you laid your hands on. This went on and on during your career. Maybe to a lesser extent now that you’re more experienced, but I bet you still find yourself overcommitting to shiny new toys.

At some point, your career path has diverged from making code. You became a manager. Then a leader. A whole new toolbox opened up for you. And this flood of values, best practices, and rules hit you:

• Being transparent with your team
• Giving direct and honest feedback
• Switching from mentoring (eg. telling people how to do stuff) to coaching (teaching others how to improve themselves)
• Valuing autonomy and only communicating the effects you expect
• Sharing context

They are all great foundations to build your team on. Why wouldn’t you want to apply them all in practice?

For the same reasons, you shouldn’t apply all of your engineering best practices at once. Because they are only tools, and as such, they can do more harm than good when used incorrectly.

Creative people indeed need autonomy. I believe it’s crucial to building great teams. But it’s far from stating that everyone should have full autonomy at all times. This is straight damaging to your peers. Not everyone can handle each task on their own and may need guidance. Not every problem should be solved without supervision. Give space where it’s needed, give tools where they are required, work as a team to have better effects, micromanage if someone struggles.

Transparently sharing context with your team is a great virtue, but is your organization ready for radical transparency? Should you share everything risking bad signal vs noise ratio? Did you prepare your team to have all your internal decisions revealed to them? Do you have any bad apples in your team that would turn this against you instead of appreciating your move? It’s your job to decide on your top-down communication, share selectively on a need-to-know basis, and be open about the details if anybody asks. I wouldn’t try radical transparency unless you established that your team expects it.

Creating a feedback culture is important, but it’s more of an art than science. Time your feedback well. Be vary of the audience. Make sure it’s received correctly. Think beforehand about the possible reactions. Be prepared not only to give but also to accept feedback. Always be thankful. Take into consideration that not everyone is mature enough to welcome harsh feedback.

In the end, your team might not be as enthusiastic as you to introduce this new teambuilding gizmo. They might be overwhelmed with the pace of changes and new ideas you’re introducing, all while they just try to get some work done.

Do you remember what happened when you dogmatically applied your engineering practices without a consideration for the project? To be brief: a mess. The upside is that code can be refactored. Teams not so easily.