"Yes, and" Your Next Assignment
"Jake, can you take this ticket? You know the most about our email templates." Get some seniority in programming, and you'll start to hear this. I understand the desire to ship with minimal friction. But I think there's another way, inspired by the improvisational comedy maxim "Yes, and."
"Yes, and" suggests that improvisers should accept what another improviser has created and build on it. If I improvise a fan cheering at a concert, and you're joining, you're at the concert, too. It fosters collaborative world-building.
One way I try to lead as an individual contributor is to "Yes, and" my colleagues. If someone ships a feature that adds a new page, and the next ticket in the backlog is a small refinement of that page, I tend to grab it. They created the world– I'm saying "Yes, and."
Picking up such a ticket can be challenging, because I'm stepping into something I might not be able to understand right away. The ticket might be incomplete because the requester wrote it for the original feature author.
Why volunteer for that discomfort? I do it because it helps me learn, improves the code, and long-term, signifies organizational health.
When I dive into a part of the codebase I didn't write, I'm learning about the business value of the total application. I get to see what my colleagues are building. Stepping out of your domain can be fun and challenging. You get a peek at the bigger picture of the software, much like what a customer sees.
It improves the code, too! The original author was building something from scratch, and that's hard. They probably cut some corners: omitted tests, imperfect names based on early assumptions, and meager documentation. They didn't know about relevant changes elsewhere in the codebase because they were shipping. Just touching the code with a spirit of curiosity is going to make it better.
Long-term, it's good for the organization, too. I'm inevitably going to ask the author questions and collaborate, and that strengthens the team. In the best organizations I've worked with, anybody can pick up any ticket under their skill set. Nobody owns code.
And the person who benefits most from "Yes, and" is the person you're saying it to. Picking up that follow-on ticket, especially as the more senior engineer, is the most direct way I know to show someone that you see and care about their work.
As a technical leader, you can practice this by getting every team member involved in various parts of the code. Assigning me to work on something someone else built shows that you believe in my ability to learn and you want the whole team to have context about what's happening. You'll recoup the small time invested as I get up to speed by getting an additional teammate who understands the domain. It's the long view of people and technical management.
The next time you're looking for something to do, build on the world that exists by saying "Yes, and."