Skip to content

The T-Shaped Engineer: Balancing Depth, Breadth, and Burnout

July 3, 2025 · Career & Growth

When I joined Mews as one of the first T-shaped engineers, I didn’t quite realize what I was signing up for.

At the time, the term “T-shaped” was starting to become more common in product and engineering conversations. The idea? Someone with deep expertise in one area (say frontend), but with broad working knowledge across many (such as backend, product thinking, security, threat modeling, performance, deployment, etc.). In practice? It meant stepping into ambiguity, learning fast, and finding your own path through it.

A year and a half later, I’ve come to appreciate this role not just as a technical challenge, but as a mindset shift. If you’ve ever been curious about what it’s like to live between specializations, and how it changes the way you think, work, and collaborate, here’s a peek into my journey.

Adapting to the T-shaped Role

On my first day, I was handed a backend ticket. That was to be expected; I had come from a backend-heavy background, so I figured I’d stick with what I knew.

There was no playbook. No “How to Be a T-Shaped Engineer at Mews” onboarding guide. Just curiosity, Slack threads, and people generous enough to explain concepts twice, thrice, or as many times as I needed.

I remember pairing with a backend engineer on a very small bug. What started as “just hook this frontend button to the API” turned into a two-hour dive into our architecture. He didn’t just help me fix the bug, he walked me through how data flows through our codebase, how we think about backend and frontend responsibilities, and where we draw the line between the two. That one bug fix taught me more about our platform than two weeks of documentation, something I wasn’t expecting, but was very grateful for.

Moments like that made clear: being T-shaped isn’t about knowing everything. It’s about being okay with not knowing, and delving into it. The role demanded becoming more open to asking questions, being more proactive with knowledge gaps, and more collaborative in the workspace.

The Day-to-Day of a T-shaped Engineer

Things started to get strange around month three. I was spending just as much time in backend code reviews as I was in frontend ones, and I was starting to feel confident in both.

What surprised me most wasn’t the technical work, but how different the mental models were.

At Mews, frontend work tends to move fast, with an emphasis on usability and UX decisions. It’s also more reactive, the feedback loops are much wider, as pull requests will get reviewed by people you’ve never talked to before. Backend work, on the other hand, moves a bit slower and is more deliberate. You think more in terms of system design, edge cases, data integrity, and a huge emphasis on security, so tradeoffs tend to feel heavier.

When working across both, you naturally start to blend between the two. I found myself in conversations where I could represent the needs of the frontend in backend discussions, and vice versa. A good example was during a refactor of our pricing logic: I contributed to connecting a complex, database-optimized backend with a frontend that needed simpler data.

Being in the room for both conversations meant I was able to contribute to designing data contracts that made sense across the stack. It felt less like switching between roles, and more like mediating between two perspectives that didn’t always speak the same language.

That dual fluency helped reduce a lot of the friction that can creep into cross-functional teams. And it didn’t just make me more effective, it made me more empathetic.

Broadening the T in T-shaped

As I got more comfortable moving between frontend and backend, I started bumping into a whole new layer of the stack: infrastructure, DevOps, and security. I never set out to learn how our build process worked, or how our services talked to each other in production, but the more I moved between domains, the more it became necessary. I found myself poking around our monitoring tools, reading logs I didn’t quite understand yet, and slowly connecting the dots between code and infrastructure.

Security came into focus the same way. In backend work, especially, I had to start thinking about more than just functionality: What assumptions were we making about user input? Were we leaking too much information in errors? I joined my first threat modeling session with no idea what to expect, and walked out realizing just how much security thinking can (and should) influence design decisions from the start.

These weren’t deep dives, but they were enough to change how I worked. I started writing code that assumed less, validated more, and played nicer with the systems it lived in. That broader awareness became part of the T-shape too, not just knowing how to build something, but understanding how it runs, how it fails, and how to keep it safe.

Managing Complexity and Mental Load

Let’s talk about the tradeoffs now. Being T-shaped can be mentally exhausting!

One morning, I was finalizing a frontend pull request to polish a new widget. By 2 PM, I had been pulled into a discussion about how to start migrating a project to a new microservice architecture. The next day, I was debugging timeouts on a very small query. I had been bouncing from task to task to task.

Each of those tasks required a different mental model. And while the work itself was quite interesting, the constant context switching had started to take a toll.

At one point, I found myself having a hard time concentrating in meetings, especially when discussions didn’t directly relate to something I owned. I was also becoming the go-to person for “quick” asks: frontend tweaks, backend reviews, threat modeling, investigating security issues, even questions about domain logic. It wasn’t anyone’s fault, but I’d become the person who “probably knows this,” and I hadn’t learnt to say no yet, which meant I was spending more time on other projects rather than my own.

I had started to recognize that I needed to put some boundaries in place, not to withdraw from the team, but to preserve the focus that the role requires, and block time for deep work. I became more intentional about the tasks I took on and learned that sometimes the most productive thing you can say is, “I’m not the right person for this right now.”

Lessons from the T-shaped Journey

Being a T-shaped engineer at Mews has been the most challenging and rewarding phase of my career so far.

It’s not just about touching multiple parts of the stack. It’s about learning to think in systems, to work with humility, and to collaborate across disciplines. It’s about embracing the grey areas where roles overlap, and making clarity from that chaos.

If you’re considering a T-shaped role or already in one, here’s what I’d leave you with:

The ambiguity never fully goes away. But over time, you stop fearing it, and start seeing it as a space where you can do your best work.