Working in teams#
Working in teams is a lifelong skill that I don’t think anyone is perfect at. But there are many things that can help you get better. And, often times, especially in software engineering, we idolize that genius founder (Mark Zuckerberg, Bill Gates, etc.) who seemingly singlehandedly changes the world. But, when it comes down to it, humans are better working together: we can achieve more and do more.
Know when to step up (and down)#
Not everyone needs to manage. I feel like often times, the progression at work or even in sports teams as you get more senior is that you must be a leader. Perhaps this is effective if you’re seriously lacking a leader, but the point is, not everyone wants to be a leader.
In Tony Fadell’s Build, he calls these types of people individual contributors (ICs). He notes that, once you become a manager, you’re doing less of what did you successful. As such, it’s probably going to be scary! In the software engineering sense, you’re not coding as much anymore. If you’re the type who want to code for the rest of your career, there are paths forward that allow for that too.
As someone more leadership-inclined, I love good team players and seriously respect them. If I give them a task, they do it. And it’s not just like they’re following me blindly: I love working with these people because they are willing to roll their sleeves up and work together even if they’re not leading the vision. They’re helping out toward the vision.
A leader is a team player. They’re apart of a team, so why wouldn’t they be? But even more than that, if you’re a leader, you should know when to step down and listen to your team players. Often times they’ll be the expert and know more than you about something, and you can treasure that and use that to the entire team’s advantage.
Know when to step up to the plate, and know when to step aside to let someone else shine.
Know your team, know your people#
Get to know your team well! Care about them and ask them what they’re up to at work and outside of it. Most people will really enjoy that type of thing, and if they don’t – respect that boundary too.
Know things about your people. Maybe they focus better in the mornings; don’t disturb them then (unless it’s urgent), talk to them a little later. This helps everyone stay productive, and it builds a community and a culture within your teams.
I’ve worked with some people who process one thing at a time but really process it and deliver good ideas about it. With them, I make sure I’m not overwhelming them with information and instead we focus on one thing and get it done. I’ve also worked with people who don’t mind jumping around from thing to thing. Regardless, figure out what works for you and your people.
Communicate, communicate, communicate#
Communicate your feelings toward others. How do you feel about the work you’re doing as it relates to you? How do you feel about how the people around you are working an acting? If it’s bad, maybe tell your boss or tell people directly.
Communicate your vision: even if you’re not a leader on the team, you probably feel some sort of loyalty toward the vision of your project. (see Leadership section for how leaders might act.) Everyone who is working on a project has their own understanding of it and has valuable ideas for it.
Communicate your work: you’re probably going to be required to do this, but find ways to communicate your work. Whether it’s in a code review, 1:1 meeting with your boss, or to friends and family you talk to. If you can communicate what you’re doing and why it’s important to you, that should excite you (or perhaps clarify to you why it doesn’t excite you).