Crews Not Teams#
When was the last time you reached out to someone you worked with and said, “Hey, this is something I’m bad at, and you’re really good at. Can you do it instead?”
What does that sentence make you feel?
Does it make you feel like you’re becoming vulnerable? “What if she gets the promotion and not me?”
Does it make you feel like your manager will think you’re not showing initiative by learning skills others have in the team?
Whenever I see someone thinking like this, I like to think about a game I used to play as a child. It’s an old computer game called Commando. It had a small unit of commandos who’d go do covert missions. You couldn’t Age-of-Empires your way through the battlefield. You’d get 2 or 3 soldiers who each had a particular set of skills. You as the player knew each of their strengths and knew when to use them. They were a team, but not the sort that you see at your workplace. They were a unit, a crew.
Not a lot of people open up to their team members that way. Have you ever thought about what your strengths are that a team could leverage? What about your weaknesses? Do you ever try to find a team to fit into that could use your strengths and aid your weaknesses? Would talking like this hinder your chances at a job interview?
Example
I am extremely passionate about documentation. A friend of mine introduced me to the word “docuholic”. That is me 500%.
There is no perfect documentation. There is never enough. A lifetime ago, I would have said you only get the best information in textbooks. I genuinely believed that tech videos on Youtube didn’t have the density of information that the textbooks you would find from OReilly or No-Starch Press would have. I still resort to finding a good book on the topic to read, and I’d still recommend trying to find one, but that form isn’t for everyone.
You cannot make documentation or manuals that work for everyone. But that is exactly why you need a culture of documentation at your company.
You need a culture wherein your developers write docs not just to fulfill the requirement of some Jira ticket, heck no! You need a culture where your developers feel that their task is not done until their documentation teaches someone who hasn’t come into the project yet how to use it.
Who is your user? I’ve written about this before. Every thing you build, every line of code you write needs to cater to an audience.
A lot of developers don’t care about documentation though. And that’s okay. We’re a crew, a unit. Build teams where other developers are willing to fill the gaps, and those that aren’t fluent writing documentation can fill in other gaps. Maybe those are better at learning how to automate end-to-end deployments or enjoy that better. It is okay to lean on your colleagues for skills that you do not enjoy growing. At the same time, it is okay to take on work that others do not enjoy, especially if you’re good at it.
That’s what I enjoy doing. I can help improve my team’s documentation, while still delivering performant well-designed products of my own. There are things that all of us should be able to do, and then there are things that we can each specialize in.
Somehow, a lot of people consider this a vulnerability. Build a crew, a band, not a team that only comes together at a standup and only builds what is needed to get an Exceeds Expectations on an arbitrary review scale.
How do you begin though? I ask my team members constantly if I can add to their documentation. I’ve made PRs which merely clean up code, improving how readable it is. PRs I built in my free time. It doesn’t take me much time, and by that I certainly do not mean it would take others more time. It’s something I’m darned good at, and I do not feel that the team “owes me one” for doing it. I’m doing it because we’re all chipping away at the same rock, trying to make something. If some tasks are less glorious but improve things long-term, then so be it. If you work alongside sculptors, it doesn’t hurt to be the one to offer to sharpen their chisels.
Be a crew. Build a crew. Find a crew.