LeadTime#17 - Effective Team-Building
What activities break down social barriers rather than reinforcing them? How to include everyone in a hybrid team while respecting different preferences and comfort levels?
Hi, this newsletter is a weekly challenge for engineers thinking about management. I'm Péter Szász, writing about Engineering Leadership and training aspiring and first-time managers on this path.
In this newsletter, I pose a weekly EM challenge and leave it as a puzzle for you to think about before the next issue, where I share my thoughts on it.
Last Week’s Challenge
Last week, we had a more pleasant than usual challenge: figuring out how best to spend a moderate team-building budget. Read the details here if you missed it.
I'll approach this situation with my usual structure:
Goals to Achieve
Increasing Team Cohesion: Break down existing social barriers, especially between newer hires and veterans. Create shared experiences that can provide a foundation for better collaboration. The team is hybrid, which probably means that a lot of communication happens async. How people interpret a short, direct Pull Request comment or Slack message can be very different based on their pre-existing personal relationship.
Psychological Safety: Use team-building to reinforce that people can take interpersonal risks without fear of negative consequences. When team members know each other beyond their professional roles, they're more likely to speak up, ask questions, and engage in constructive disagreement. All these are key characteristics of a high-performing team.
Inclusive Participation: Ensure everyone can fully participate, regardless of preferences, location, timing, etc. This is key for creating a truly shared experience.
Sustained Impact: The activity should be the starting event for ongoing behavioral changes, not just serve as a one-time momentary spike. The goal isn't just a fun day, but establishing patterns and connections that persist and continue to improve when everyone returns to daily work.
Risks to Avoid
Reinforcing Existing Divides: Without thoughtful planning, team activities can strengthen rather than break down existing social patterns. If people only interact with those they're already comfortable with, we'll entrench the very problems we're trying to solve.
Comfort Zone Violations: Pushing someone too far outside their personal boundaries risks creating resentment rather than connection. Not everyone thrives in the same environments - what energizes one person might exhaust another.
Remote Member Isolation: Activities that don't meaningfully include remote team members can worsen their sense of disconnection. A "second-class" team-building experience for remote folks undermines the entire purpose — if travel is not feasible, it might be better to organize the entire event online for everyone. Hybrid events can leave remote folks feeling like second-class team members and not get the expected results.
Exclusionary Elements: Overlooking dietary restrictions, disabilities, religious observances, or cultural differences can make team members feel unvalued or excluded. (This is why the often default alcohol-centric activities might quietly alienate some team members.)
Leadership Extremes: Finding the right balance of direction versus autonomy is also important. Putting everything to a vote can lead to endless discussion and default to lowest-common-denominator activities, driven by more assertive team members. However, dictating every detail without input signals that team preferences don't matter. Align on the goals, run the organizing process with transparency, and offer clear intervention points where you rely on team feedback.
5 Questions
What type of activity would best serve our team's specific dynamics? Purely social events like happy hours might reinforce existing social groups. Skill-based activities could highlight talents beyond coding. Problem-solving activities that require cooperation might encourage new interactions. Something engineering-adjacent but unfamiliar to everyone (for example, a Capture The Flag security challenge, or building some hardware with microcontrollers) could provide both common ground and a level playing field.
How can we structure the activity to ensure meaningful cross-group interactions? Should we deliberately mix people from different project teams or tenure levels? What mechanics would encourage those who don't normally interact to work together? Can we design an activity that requires complementary skills from different team members?
What's our strategy for truly including remote team members? Is it better to bring them on-site or design a fully distributed activity? If we're bringing them in, how do we ensure they're not jet-lagged or stressed during the activity? If remote, what technology or approach ensures they everyone has equal presence and participation, even those who are more used to in-office work?
How will we measure the success of this team-building effort? What behavioral changes would indicate improved cohesion and better communication? What metrics (qualitative or quantitative) could we track before and after? How will we know if the investment paid off? These are important questions both for assessing the EM’s decision and providing learning opportunities, and both for securing next year’s team-building budget.
What follow-up activities or changes to team processes could sustain the momentum? Team building shouldn't be a one-off event. Are there some lightweight, regular practices we could implement that build on the connections formed? Should we adapt our daily work processes to reinforce the collaborative behaviors we're trying to encourage?
I didn’t include practicalities like how to ensure the scheduled event doesn’t disrupt delivery, how to minimize expenses, etc., because I felt it was more important to focus on these high-level questions. Besides that, do you think I miss any important considerations? Let me know in the comments!
Next Week’s Challenge
You've been recently hired as Engineering Manager for the web development part of a bigger engineering team that’s known for their stressful monthly releases. Each release day inevitably turns into a 48-hour firefighting session, with developers struggling to merge development branches, frantically debugging issues and occasionally reverting to previous versions or doing partial releases.
You've quickly identified several potential solutions - implementing proper CI/CD, moving to trunk-based development, using feature flags - but you're unsure which to prioritize or how to introduce changes without creating more chaos.
The director who hired you wants to see concrete improvements within the next quarter, but you’re afraid of rushing into changes that might backfire. The team consists of experienced developers, but they are nearing burnout and are somewhat resistant to new processes, having been burned by previous improvement attempts.
How do you balance technical improvements with team morale while delivering measurable results that satisfy stakeholders and customers?
Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future as soon as they are published:
Until then, here's an inspiring quote slightly related to last week’s challenge:
See you next week,
Péter