Working in a multidisciplinary team is great, but it comes with its own challenges.
Most of what I do is a team effort. I might be the one writing the code and opening the pull request, but every feature goes through a process that touches a lot of different people, each with a different background and a different angle.
Everything we add has been thought through by product, and it’s only ever a tiny piece of a much larger mechanism, the whole app. Nothing reaches us left to guesswork or approximation, so even when we’re making small adjustments, we have to think about the bigger picture, not just our own little garden.
Then there’s how the feature will look. Most of my tickets have a frontend element or implication, and we don’t want the app turning into a jumble of mismatched components that vary depending on how each developer happened to feel that day. Every team has a talented designer overseeing what we do. We get a design before we start, exchange ideas and opinions as we build, and have it validated before launch.
In my case there’s an added layer: the BI side of the company. A lot of our work depends on, or has implications for, what my data teammates do, so there’s real collaboration needed there too. The problems and considerations are so different from standard software engineering that it’s a genuine learning process, and sometimes we simply can’t move forward without a professional, positive back-and-forth first.
On top of all that, there’s legal, compliance, safety, marketing, support. All these moving parts come together to make up a feature that’s genuinely well built and well thought out.
The key to navigating all these forces pulling in different directions is good communication. Knowing what to say, when to raise it, and how to deliver it is crucial. Each stakeholder has their own background, their own vocabulary, their own interests, and usually comes at the problem from a completely different angle than the developer does.
Sometimes compromise is needed. And sometimes we’re all actually saying the same thing, just in different idioms. The thing is, this only works long-term if you’ve built a team like ours, where everyone understands that each part is only interested in the success of the feature. The app and the users come first. That’s the shared goal, and it doesn’t matter how we get there, as long as we get there together.
These dynamics took real adjustment for me. I always worked in leaner agency setups, where quality still mattered but the structure was lighter and nearly everyone shared a similar background and spoke the same language. Easier in the short term, maybe. But I’ve come to see how much the plurality of views adds to the final product.
Going through all the hoops can be frustrating at times. But again, the output is the only thing that matters, and closing my laptop in the evening genuinely proud of what I worked on is worth more than the friction costs. I know what the mission is, and I’m completely on board with it. That makes everything so much easier.