When trying to convince teams to adopt a new technology, the most effective strategy is to implement the solution for them. Presenting a finished, working migration is a much easier conversation than asking them to take on a large, uncertain task themselves.
After struggling with his failing ComponentScript project for a year, a "meets most" performance review provided the objective, external signal needed to finally cancel it. Negative feedback, while painful, can be a crucial catalyst for making a difficult but correct decision.
When driving the controversial ComponentKit framework, Ryan Peterman didn't go it alone. He relied on influential allies who had different convincing styles and compromised by integrating a competing framework's technology. This created a shared win and brought skeptics into the fold.
Instead of formally studying different systems, a more effective path to T-shaped expertise is to deep-dive into adjacent systems only when they block your work. This "just-in-time" learning is highly motivated, practical, and builds cross-stack knowledge and credibility over time.
Instead of top-down directives, reviewing numerous diffs provides a natural context to debate practices and influence engineers. Good feedback spreads virally as those engineers apply the learnings in their own work and reviews, creating a scalable way to elevate code quality.
The failed ComponentScript framework insisted on using GraphQL for data consistency, adding significant friction. A competing server-driven UI approach succeeded by sacrificing consistency, which 80% of products didn't need. Prioritizing technical ideals over pragmatic user needs can be fatal.
Instead of worrying if his work meets the high bar of his IC9 level, Ryan Peterman intentionally ignores the pressure. He focuses on doing work he enjoys that is important to his organization, trusting his manager to provide course correction. This frees him to be productive.
The failed ComponentScript project served neither iOS engineers (who didn't want a new language) nor JavaScript engineers (who preferred React Native). Internal tools, like external products, must solve a specific user's problem, or they will fail to gain traction.