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.
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.
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.
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.
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. ;)
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.
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.
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.
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.
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
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.
• 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.
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.
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…
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.
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.
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.
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.
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.
• 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.”
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.
into small (< 10), focused teams • Explicit coordination between teams • Encourage frequent migration between teams to increase knowledge sharing and build strong rapport across teams
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.
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