Everyone Does Everything
How to work on teams of generalists
--
When I first started studying graphic design I remember reading an interview with my favourite studio — the crazy Dutch modernists ExperimentalJetset. There was this quote that stood out — it didn’t mean much to me at the time but now really neatly summarises how I think product teams should be organised.
Q: Can you say how you divide up your workload between the three of you?
A: We once saw this interview with legendary player Johan Cruijff in which he explained the concept of ‘Totaal Voetbal’. Total Football is a system where a player who moves out of his position can be replaced by any other player from the same team. So the roles aren’t fixed; any player has the ability to be attacker, defender or midfielder. When you think of it, it’s a very modernist, modular system.
For the past few years I’ve been crafting myself into a weird designer-developer hybrid, whilst trying to convince others to do the same thing. As evidenced by David Cole’s great recent post, this is getting more and more common, but the industry is still catching up to where I think it should be.
At Makeshift—for the first time—I’m starting to connect the dots I first read about in the ExperimentalJetset interview. Whilst in the past I’ve worked with designers who work across traditional graphic design disciplines—as Jetset do—at Makeshift we’re assembling a true full-stack team.
A motley crew of generalists, each capable of handling everything from branding to UX and front-end engineering, to back-end and sysadmin. This is awesome — it’s the team I’ve always wanted to work on, but now that we’ve assembled a team of generalists we’ve found another problem.
No one knows how to work with generalists.
In the past I’ve worked on teams of relatively specialised developers. I’d write the odd few lines of Ruby but sticking mainly to design and front-end development was pragmatic if I was in a room with great Ruby developers. I’ve also worked with talented designers, coding features and taking names on the server side. That’s what we do best as generalists — figure out what’s missing from the team we’re on, and get on with it.
We’re like web-flavoured amoeba. Or Robert Patrick’s character in Terminator 2.
It breaks down when working with other generalists though. You know that thing when you’re about to walk into someone on the street? You walk to your left and they walk to your left. You walk to your right and they walk to your right. You either walk into each other (35%) or end up in this awkward, overly polite British stalemate on the pavement (65%). It’s like a shit game of chess in the morning when all you want is to get to a coffeeshop. Nightmare.
Anyway, working on a team of generalists has the potential to be a bit like that. Or a night out when you and two mates wear the same shirt. You know the one I mean — probably that same red, checked one. No differentiation. Who’s going to be the quirky one of the gang? Exactly. Awkward. You’re all going to have to go home and change.
We’ve got work to do though, let’s get back to the Kanban board. Not knowing how to divvy up tasks because you’re all equally capable of tackling them seems like a bit of a #firstworldproblem.
It’s definitely a problem I’d rather have than not but in an industry evolving towards generalists it’s also a problem that we need to solve. Annoyingly, I’m a bit short on answers — we’re kind of making it up as we go along, but I’ve noticed a few different working patterns crop up.
The split
For big features it makes sense to break them down into components and divvy up roughly according to ‘traditional’ roles. One of us will design the component and write the front-end code whilst the other implements the tests and server-side logic. This can sometimes result in some ‘smooshing’ even after the two streams are merged to make everything smooth — if we’ve both been working on the same HTML file things can get messy, ya know? If we’re doing this we try to regularly switch roles lest we each fall into ‘designer’ or ‘programmer’ forevermore. That’s not the goal!
The full-stack
A team of generalists affords you the luxury of each player tackling a small feature from start to finish. Design to front-end to tests to Ruby to “OH MY GOD WE’RE GETTING 500s ON PRODUCTION” to more tests to more Ruby to fixing it on IE to finish. Programmers are most efficient when we can hold the entire problem in our head and when you have a really good grasp of what you’re trying to solve it’s nice to juggle the design, HTML structure and your intended Ruby implementation in your head all at once.
If a piece of code is written by multiple authors, none of them understand it as well as a single author would. This is my favourite way of working, but depending on the complexity or scope of a feature it isn’t always feasible. Secret weapon time.
The pair
When I crossed the murky chasm from graphic design to product design and software engineering I was amazed to learn about pairing. The output of a pairing session always feels like more than the sum of its man-hours. This is great and I’d love to be in a position where Natalia (our other full-time hacker at Makeshift) I could pair all day, but we just have lots of different things to tackle and I worry that having both of us intensely focus on one narrow part of a narrow problem at one time would leave other things without love.
That said, pairing is a great way to break down the trickier bits of tasks that you’d otherwise go for a full-stack, single-person implementation on. Having two people look at a screen and hold the code in both of their heads at the same time means you don’t end up stepping on each others’ toes but you also have the increased problem-solving power of two people. A++.
Caveat
This is all rad when you’re working on the kinds of products that we’re building at Makeshift, but it would be naïve for me to think every software company is hacking in the same ballpark. I love the products that we’re making, but we’re not solving the same problems as engineering teams at Google, Facebook or Palantir. I’d imagine that generalists there would be ‘resourced’ totally differently.
The other thing I should note is that as we grow at Makeshift we’ll probably be looking for people with a little bit more specialism on either extreme of the designer/developer spectrum. But hey — this was a post about working with generalists :)
Diversity
No matter how little ‘design’ I actually do day-to-day, being ‘A Designer’ is an important part of my personal myth. When a friend brought up designer-as-self-identity the other day I could definitely relate. I started this deep-dive into engineering to enhance my design skills, not replace them. In any case, it’s important to break things up to avoid repetition. The full-stack, single-person small feature thing is great for that, but it’s also nice to do big features in different disciplines. Just the other week I got into some gnarly millisecond-counting performance work. I learnt a lot about different types of caching in Rails and how I could improve my SQL queries but afterwards I was challishing for a meaty bit of visual design.
And so, as a generalist, that’s exactly what I did.
This post started out as an idea on HelpMeWrite — an app I’m building to help you become a better writer.
Thanks to Anthony, Sam, Namit, Reuben, Cole, Peter, Anna, Jennifer, Natalia, Stephen, Thomas, Nick, Chris,Denichaud, Nick, Stef, Paul, Klaus, Steve, Jamie, Marie, Lewis, Gaz, Joel, Kevan, Sofia, R2k, Amanda, Jase, James & Marko for giving me the push to write it!
