Note: Gender doesn’t matter here, I chose “guy” instead of “girl” or “person” because I’m thinking of specific examples across my career, all of whom were men. So feel free to swap out pronouns as you read this.
If you’re a Principal, Staff Engineer, Tech or Team Lead, basically anyone with seniority on an engineering team then you have responsibilities to the junior members. You are uniquely positioned to influence project success and business outcomes not just through the development of code, but also through the development of your colleagues and the examples you set for them. I’m not talking about making sure everyone knows your code style and syntax preferences. Let’s be real, your preferences for streams over for loops or where to put curly braces isn’t going to move the needle for the business. I’m talking about not being “That Guy”.
That Guy reviews PRs by submitting large revision commits rather than suggestions or constructive feedback. He’d rather just do it than explain how. He may be impatient or may have wanted this work for himself. That Guy may be thinking “I could do this in less time than it will take me to explain it”, not realizing (or caring) that an investment of time now will pay off in future productivity. No one gets better or faster at a task without practice. Don’t rob junior engineers of the opportunity to learn and grow. However, it’s true that sometimes we need to align the work with the person who’s best suited to do it quickly. But if you aren’t under a time crunch and you simply want a particular bit of interesting work then stake a claim, pull rank at planning, say so upfront, don’t take over someone else’s work at the PR stage.
That Guy thinks another teammate’s success threatens his own. He’ll be publicly snarky toward rising stars. They’ll use backhanded compliments at best, downright insults at worst, in attempts to chip away at another’s confidence, cast doubt on the quality of their work, or imply they don’t deserve the credit. Unless you are in a head-to-head competition then someone else’s success doesn’t come at your expense. Do your best work, celebrate others, and put the team first.
That Guy’s ego won’t let him admit that anyone on the team, be it a summer intern or a Product person, can have great ideas and insights. They may come up with novel solutions or ways to simplify a design. Senior engineers may have more experience, but don’t have a monopoly on creative thinking.
Don’t be that guy. Be a leader. Leadership doesn’t mean being the smartest person or the best engineer on your team. It doesn’t mean doing all the hard work or getting credit. It means helping to make others better by sharing your knowledge and experiences while letting your team make some mistakes of their own, letting them struggle a bit while offering encouragement and advice; by being open to everyone’s ideas, considering them objectively; by not just acknowledging other’s successes, but celebrating them.