Working with People

Presented at Tinderbox: Talks About Interesting Things on 2/11/2015.

Transcript

1. Working with People Christian Nelson @xianpants Christian Nelson, Director of Engineering at Carbon Five. I’m a developer who really likes working with people to build stuff. I geek out about finding ways to get teams to work great together. Asking clarifying questions at any point. Please save open ended questions for Q&A.
2. It’s hard to talk about teamwork without conjuring images of cringeworthy motivational posters. But we’re going to do it anyway!
3. Great Teamwork in Action Barcelona vs Sevilla 2009 (www.youtube.com/watch?v=5JPRvL8-Wfo)
4. “Unrealized Potential”
 Future World Cup Champs (www.youtube.com/watch?v=QrFSNiJZoaQ)
5. Silly comparison, but… There’s a common assumption that people know how to work together well (intrinsically) We actually have to learn how to work together and it takes experience Interviews often focus on design/dev chops, not team skills Even players with the best soccer skills need to practice as a team. The next time you’re interviewing someplace, see what they do to evaluate your team skills. Think about how you can interview them on the same.
6. Let’s define it… A team is more than one person working together in a coordinated fashion to get something done in a timely manner. For this talk, I’m mostly talking about small teams (20 or fewer people). I’ll talk a little about larger teams later, but it’s mostly out of scope. Getting a small team working really well can be a challenge on its own.
7. Well, of course! While few teams completely fail at being teams. Few teams get really good at it. Many teams are somewhere in the middle. And they’re kinda stuck there. You may be thinking… of course! It sounds easy, but it’s complicated… because we’re human.
8. That’s what this talk is about
9. Obligatory pseudo-mathematical graph! Efficiency (η) over Time (t) η is how well the team is performing (i.e. delivering awesome features).
10. Effective Teams We’re going to start with the things I see good teams do. Where “good” means the team does great work quickly.
11. Talk freely with one another If you have a question/concern, it’s likely someone else feels it too. Say it, really. It’s not personal, it’s about building awesome stuff for our users. Treat teammates with respect, even when you think they might be wrong. Don’t dwell on mistakes, move forward Sometimes, the only thing a team needs is the first person to say something. There’s talking about something that’s already happened, and then there’s talking to people before making decisions. Both are important. Hang out after work, or on the weekends. Get to know your teammates personally. Who knows, do a ropes course or try trust falls. ;)
12. Have an shared understanding of goals, and how those goals map to time. It’s not enough to understand the goals, how they map to time (i.e. their priority) is also important. The team should be working towards a plan. I’m not talking about a giant document or anything like that. The plan is a shared understanding of short term goals.
13. Focus on near term goals.
 Heads up: strategic. Heads down: focus on now. Not only is there a plan, but the plan focuses on nerm term goals. It’s always a good sign when a team can shift between strategic and tactical goals easily. Heads up: does what we’re working on still make sense in the grand scheme? Heads down: hyper focused on getting stuff done without sweating the details of what’s further away.
14. Lead through facilitation. “Leadership” is important to keeping things moving forward. But leaders don’t have to be dictators. I think of leaders as good facilitators. Encourage everyone to try their hand at facilitation. Rotating helps others build empathy too.
15. Raise everyone’s level by teaching through close collaboration. Check your egos at the door. When you’re on a team it’s all about what the team can do together, not what any one person is able to pull off. Spending time collaborating with someone else is never a waste of time. If you feel like it is (a waste), you’re probably part of the problem; or someone shouldn’t be on the team. It’s the long play that’s important.
16. Measure the team’s productivity, not individual’s. “How to be a 10x engineer: Incur technical debt fast enough to appear 10x as productive as the ten engineers tasked with cleaning it up.” @bmdhacks https://twitter.com/bmdhacks/status/560949130999365633
17. Converge on efficient conventions, communication and process.
18. Converge on… • Code style and conventions • Extremely low overhead communication • Efficient process getting and acting on feedback • Minimize time spent on overhead, maximize time spent on building features
19. Work together in the same place. (most of the time) People are mixed, and there are some very vocal proponents of remote workers. I’ve seen teams really struggle with it.
20. Remote Members Not impossible, but way harder. Requires exceptional discipline to compensate for the things that are easy in person. Bring people together, in person, often. It’s nearly impossible to fix a remote, dysfunctional team.
21. If you have to… • Google Hangouts - video chat • screenhero.com - screen sharing • slack.com - text communication • stickies.io - virtual post-its on a wall Fast, reliable network… even the best have issues. Even though the tooling is better now than ever, it still creates a lot of friction.
22. Reflect on how the team is working each week, looking for areas of improvement. This feedback loop is critical to improving coordination, communication, and everything else. We do weekly retrospectives/reflections with the whole team: I like, I wish, we will… scratch the biggest itch each week. <Explain> We like this because everyone has an equal voice.
23. Product / Engineering • Validate product ideas and gather feedback and metrics • Seize opportunities to accelerate learning, get to market quickly • Value code quality, write tests, and look for simple solutions I’m focusing on how teams work together, but good teams also…
24. Dysfunctional Teams These are some of the anti-patterns I have seen that result in teams that are frustrated, have low moral, and despite trying with all their might, just can’t move very quickly.
25. Misunderstanding of goals/time.
 “Wait, what are we doing this week?” If the team has a hard time defining a small bite-size goal and executing towards it, there’s really very little chance they’ll achieve something more ambitious. Build on frequent, small successes. Affects Time to Market.
26. “In the Zone” or “Off of the Radar.” I have no idea who this is! Some poor guy I found using google image search. It’s a signal to the rest of the team that you think your ideas are more important than the teams. Sets a precedent. If you think something is important, make it part of the plan. Affects Time to Market.
27. Leading at the tail end (aka too much code review) Manifests itself as a cumbersome code review or lengthy (often contentious) PR thread. Try walking over and talking to someone instead (ideally, earlier in the process). Try pair programming to accelerate convergence on style, conventions, and/or approach. Do with designers too. It’s easier to steer a solution before it’s happened then fix something that’s wrong afterwards. Check out Doc’s talk from Tinderbox last year.
28. Unproductive meetings, little consensus and decisions aren’t made. Meetings aren’t inherently bad, in fact they’re useful for maintaining a shared understanding of goals. But unproductive sessions are a tremendous drain. Put the phones away and close the laptops. Facilitation makes a world of difference. Let’s give <some idea> a try and see how it goes. Time box. Or just get rid of the meeting.
29. Emphasis on something other than building features. When your product is an application, the team should be building features. Features, not infrastructure layers, not lines of code, components… build things users find directly valuable. Allow architecture and infrastructure to emerge as part of feature development. Avoid over-engineering, have a clear understanding of what’s good enough for now.
30. Others… • Missing important skills to “get the thing done” • Siloing instead of collective code ownership (no fiefdoms) • Tolerating members who don’t play well with others • Too many meetings “I know that part of the system, I’ll just do it.”
31. Coordination is Process Process isn’t a dirty word, it’s what helps motivated people do great work quickly. Teams need rules of engagement for how they work together. It happens organically, but can settle at a local maximum. We have success working in a style heavily informed by Extreme Programming.
32. Big Teams? Outside of the scope of the talk.
33. Big teams • Don’t grow a big team! • Split into small (< 10), focused teams • Explicit coordination between teams • Encourage frequent migration between teams to increase knowledge sharing and build strong rapport across teams
34. In a Nutshell… • Talk to each other. • Reflect weekly on how it’s going, fix at least one thing each week. • Build user facing features. • Heads up (less) / heads down (more) time. • Co-locate. • Computers are easy, humans are hard.
35. References How To Scale a Development Team by Adam Wiggins
 http://adam.herokuapp.com/past/2011/4/28/scaling_a_development_team/ Other Side of Architecture by Coda Hale
 http://www.livestream.com/etsy/video?clipId=pla_780bfe22-12e8-4c7f-8c7b-06cc6cac9c49 Better Code Reviews by Doc Ritezel
 http://vimeo.com/100112679 Extreme Programming Explained by Kent Beck
 http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658
36. Go Team! Q & A @xianpants / carbonfive.com