Imagine for a second you’re renovating your kitchen. You’ve hired an interior designer and a contractor to build things out. They’re incredible at what they each do, but it doesn’t take long to see they can’t communicate. The kitchen eventually gets built, but it took too long, cost too much, and now the sink keeps catching fire.
In software, that understanding — between designers, engineers, product managers, and especially clients — is just as essential.
The building details might be different, but the necessity of communication across roles is the foundation of a successful product.
Everyone needs to understand the product, from the client’s goals and projected outcomes to the production code’s constraints and nuances.
That’s not to say that designers need to know the ins-and-outs of a clean PostgreSQL migration, or that a product manager should be able to comp a feature in Sketch. But your title isn’t a shield against responsibility. Whatever your title is, it’s up to you to pull your weight in shipping a product — and that means communication and understanding.
Designing an attractive interface isn’t successful if it’s gonna bog down the code with API calls and huge file sizes, or break completely on certain devices. Developing software isn’t useful if it’s not built in a maintainable way so that others can understand how it all works and build on it. Managing it is impossible if you don’t understand what obstacles the team is facing as they try to meet a client’s goals.
We’re all in pursuit of the same thing: solving a problem and building meaningful products that live and grow long after we’ve handed it to the client. In a sense, it’s a language — every role might have its own dialect, but we need to speak it together. At MojoTech, that practice helps blur the lines between roles. Designers have to be able and willing to talk to engineers about the speed of the front end frameworks they’re considering, just as product managers have to be about making sure a designer’s UI system is meeting client goals.
It’s tempting to ignore problems that don’t seem to fall under your specific title, but the buck stops with you. You might not know exactly how to solve an issue, but you probably know the person who does. Reach out to them, and learn how they’ll fix it. Even if you don’t understand the finer details, you’ll gain some insight into how they approach the project’s challenges.
Good software is built thoughtfully when everyone involved understands the stakes, the client, and how things should be executed.
We approach those constraints from vastly different angles, but that mutual understanding is what ensures we build things sustainably and responsibly.
It’s not easy or comfortable. It means confronting the limits of what we know and acknowledging where we’re lacking. But working together through that discomfort makes us all better at what we do, and that means better software for everyone.