Answers That Depend: Tech Leadership Q&A, pt 3
Even more of your questions from the newsletter and podcast
Welcome back to another edition of the It Depends newsletter. Once again, I'm sharing insights from my most recent Q&A podcast episode, the penultimate new episode of the season (new episodes will return in September!), where I tackled four new questions that many of you are wrestling with in your organizations. Let's dive in.
Fighting the System: When Performance Reviews Kill Collaboration
From Aisha: "As a staff engineer at our health tech startup, I've noticed silos forming between engineering teams that might be related to our performance review system. Engineers seem hesitant to spend time helping colleagues when they're being measured primarily on individual deliverables and impact. I would appreciate your thoughts on practical strategies to foster collaboration while still maintaining performance standards."
This question hits close to home for me. I spent eight years at Microsoft in the '90s and early 2000s, where Bill Gates' competitive nature had shaped a performance review system that was toxic for collaboration. We had forced distributions even at the team level. Imagine trying to rank four people on a bell curve where only one could get the top score. It was utterly unreasonable, but that's what we were expected to do.
Here's the uncomfortable truth, Aisha: if your system is built around individual achievement with forced rankings or limited high scores, people will game it. It doesn't matter how much you encourage collaboration; the system actively discourages it. Why would I help you succeed if it means I can't get the raise I need?
As a staff engineer, you have some influence but limited power to change the core system. You can leverage 360 feedback if it exists, champion collaborative efforts in performance discussions, and try to "expose the system to itself" by having honest conversations with leadership about whether this competitive structure aligns with their stated values.
But let's be realistic: if the leadership is happy with the current system, you're fighting an uphill battle. Sometimes, the best answer is recognizing that a company's values, as expressed through its systems, don't match your own. It took me eight years to figure out that Microsoft wasn't the right fit for me. Hopefully, you're faster than I was.
The good news is that once companies make the shift to truly collaborative performance systems, it becomes an integral part of the culture. However, achieving this requires changing the system, not just encouraging different behavior within an existing one.
Innovation and Guild Structures: The Part of the Spotify Model that Can Stand Alone
From Mark: "I've been thinking about how we can better foster innovative thinking among our senior engineers while keeping everyone aligned with our product roadmap. Second, I'm considering rolling out a Guild structure in our engineering org to break down silos between product teams."
Mark, you've identified two challenges that are connected. Let me tackle them both.
First, when considering innovation within product constraints, it is essential to be clear about the type of innovation you're discussing. If your engineers have brilliant ideas that have nothing to do with your product roadmap, that's interesting but not necessarily valuable right now. If they want to solve roadmap problems in innovative ways, that's different and potentially game-changing.
The key is making the business case for the innovative approach. It can't just be, "This would be cool to try." You need to articulate how the creative solution provides additional benefits, such as improved scalability, easier integration of future features, or unlocking new capabilities. And crucially, you need guardrails. If your innovative approach isn't working by the one-month mark on what should be a two-month project, you need the discipline to fall back to the proven method.
This also connects to your second question about guilds. Of all the elements from the Spotify model that companies have adopted, guilds are probably the most successful because they don't require restructuring your entire organization. They're essentially company-based clubs for people interested in similar things.
The magic of work-focused guilds, backend guilds, frontend guilds, and mobile guilds is that they become peer groups for driving innovation and best practices from the bottom up. Instead of one team trying to drive innovation alone, you spread that effort across multiple engineers on different teams, each contributing a little time and perspective.
Here's the crucial part that most companies get wrong: there are no guild commitments separate from teamwork. Guild meetings occur once a week or once a month; that's another meeting. Any actual work that results from guild discussions still goes through each team's backlog and gets prioritized like everything else. The guild doesn't assign work; it incubates ideas that teams then choose to implement.
This approach solves both of your problems. Guilds provide a space for innovative thinking and technical exploration while ensuring everything remains aligned with team priorities and product roadmaps.
Making the Business Case for Accessibility
From Grace: "How can I effectively advocate for accessibility and inclusive design principles in a fast-paced startup environment where I need to influence tech stack decisions and strategic priorities from an IC role while balancing our ship fast mentality with thoughtful technical choices that serve all users?"
Grace, this is one of the most important battles you can fight, and unfortunately, it's often an uphill one. I've never met anyone who would say accessibility isn't important, but I've repeatedly seen it deprioritized when faced with feature deadlines.
The harsh reality is that accessibility arguments land differently depending on your business model. In B2C environments, you can point directly to lost customers. The statistics on users with accessibility needs are publicly available and compelling. In B2B environments, it's trickier because the end user is often not the buyer, although the argument still holds.
Here's my practical advice: make it visible and measurable. Build a dashboard that runs accessibility audits on your product regularly, weekly, or even with every build. Create a running tally of how many potential customers your inaccessibility is excluding. Publish monthly reports showing these numbers alongside your customer metrics.
This visibility does two things: it keeps accessibility visible to leadership, and it creates what I call "burning platform" opportunities. Eventually, someone will look at those numbers and realize you're losing a significant market opportunity. That's when you can propose an accessibility push where everyone works on it together for a focused period.
I've seen this work repeatedly. Once companies make that initial investment and start maintaining accessibility as part of their definition of done, it becomes just another aspect of quality. The key is getting past that initial hump, where it feels like extra work instead of essential work.
The other benefit? There's real marketing value in being accessibility-forward. At Onfido, our design team's focus on accessibility earned us awards and positive press. Companies aren't shy about promoting their commitment to inclusion, and rightfully so.
The Thread That Connects Everything
What strikes me about these questions is how they all touch on the same fundamental challenge: changing systems and culture from individual contributor positions. Whether it's performance reviews, innovation processes, or accessibility prioritization, the answer often involves making the invisible visible, building coalitions, and creating compelling business cases for change.
The hard truth is that lasting change usually requires shifts in systems, not just individual behavior. But as senior ICs, you have more influence than you might think. You need to be strategic about how you use it.
That's it for this week's newsletter. As always, your questions and experiences help shape these discussions. If you're wrestling with similar challenges, I'd love to hear about them. Please send me a message at contact@itdependsbook.net or reach out on Blue Sky, Twitter, or LinkedIn. If you found this helpful, please share it with someone else who may benefit.
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores