Going Beyond Code: Why Engineers Should Work with Non-Engineers
At Spotify, engineers are encouraged to become “T-shaped”: deep in their core specialty, but broad across adjacent skills. That broadening doesn’t have to mean learning another programming language or framework. For Design Systems Engineering Manager Tyce Clee, it means looking sideways at the whole product-creation process and learning from colleagues outside engineering entirely — a practice that carries concrete benefits long after the pairing session ends.
Learn the Product Before You Write the Code
Engineers naturally specialize. A JavaScript developer who loves data visualization may rarely touch GraphQL; a CSS-focused UI engineer may never think about complex routing or performance optimization. Pairing with other developers — say, embedding with a backend team to map out an API schema for the first time, then returning to your frontend work — widens that T-shape inside your discipline.
But pairing outside engineering expands your thinking laterally, past code and into the reasoning and process behind a feature. Clee describes working alongside a UX prototyper, which gave him early exposure to product inception: observing user-testing sessions, hearing product managers explain why a feature mattered, and sitting with designers on early UI mockups. When the time came to build, he had a vastly more cohesive context for what the team was making — and a clearer sense of why it mattered to the business.
Your Docs Are Only as Good as a Fresh Pair of Eyes
Clee recalls a humbling moment when a designer sat down to write code for the very first time. His team had rewritten and re-rewritten its contribution documentation, confident it covered every use case and discipline. What it didn’t cover: a machine that had never been set up for web development. The designer’s computer lacked Xcode command-line tools, Node.js, npm, Homebrew — basic prerequisites the team had stopped noticing long ago.
The fix wasn’t a lecture but a pairing session to add a new section to the contribution docs for complete beginners. The broader lesson: the best way to stress-test your documentation is to watch someone try to follow it. Hold back your tips and corrections, and let them stumble. Where they hit a wall is where your documentation failed — fix that before the next person arrives.
Build Empathy Through a “Day in the Life”
Understanding your colleagues’ work is key to building better products together. One efficient way to do that is to spend a day embedded with someone outside your discipline. Shadow them to every meeting, ask questions, take notes, and attempt a piece of work the way they would — whether that’s a designer tackling a small project or a UX writer explaining how tone and language shape an experience.
Then return the favor. Invite a non-engineer to shadow you, treating the day as an open conversation with concrete learning goals. That mutual investment pays off in future planning, work prioritization, and a shared understanding of what each discipline actually struggles with.
Clee once spent half a day pairing with a designer on a problem that sounded small: how to capture descriptions of each component in Spotify’s design system. Together, they found a way to store that data so it could surface as code hints in an IDE and display in Figma — a deliverable neither could have produced alone.
If you’re thinking you can’t spare the time from your sprint, consider that spending one day with someone else will permanently change how you interact with that person and their discipline. Diversity of thought is what allows teams to build products that impact a broader set of people.
Translate Your Jargon
Every workplace has its own acronyms and shorthand, which is helpful only to those already in the know. New starters and internal transfers need these terms explained in ways that make sense outside the originating team or discipline.
Spotify relies heavily on SEMVER, or semantic versioning. That release strategy doesn’t translate automatically to non-engineers. Clee remembers multiple occasions when his team walked through the fundamentals with designers and product folks, helping them grasp the terminology and intent. The result was a bridge of understanding — and, incidentally, a clear way for non-engineers to understand release schedules and themselves participate in shipping software.
The exchange works in reverse. A designer taking time to explain how a design critique works, what the names for various flows in a design tool mean, or the difference between vector- and pixel-based images goes a long way toward helping an engineer relate to the discipline.
Keep Testing and Translating
The recurring theme is straightforward. Stress-test your onboarding documentation with someone who has never done it before — embrace the awkward moment when your gaps surface, then fix them for the next person.
Share more between disciplines, and encourage everyone to translate potentially confusing language. And consider unusual ways to be T-shaped: a design course, a module on UX writing, or a study of how in-browser accessibility actually works. Those unorthodox expansions of knowledge, Clee argues, build a broader outlook that purely engineering-focused learning never will.
