The engineering team at Compass had a problem. Our features were technically sound, but something was missing — genuine customer love. We were efficient at writing code, but were we solving the right problems?
As a Senior Engineering Manager at Atlassian working on Compass, I've spent years wrestling with this challenge. My team and I are responsible for building tools that help development teams manage their software components and resources at scale. When I first joined, I noticed a pattern that many engineering organizations face: we are great at delivering features but sometimes miss the mark on delivering value.
I've seen firsthand how engineering culture can make or break a product's success. At Atlassian, we don't just build tools for software teams — we live and breathe the same challenges our customers face daily. This gives us a unique perspective on transforming engineering culture, and it's why I'm particularly passionate about sharing what we've learned.
The traditional engineering disconnect
Let’s talk about a hypothetical product team whose story might sound familiar.
Tina is a senior developer known for her technical excellence. While her code was impeccable, she found herself trapped in a familiar cycle: receive requirements, write code, and deploy features. "I was writing code in a vacuum," Tina admits. "I had no idea if what I was building actually solved real customer problems." She wanted more customer context but felt limited by her focus on just implementation.
Rita, the team's product designer, faced her own struggles. She would spend weeks crafting pixel-perfect designs, only to receive crucial feedback during development that forced major revisions. "By the time developers point out technical constraints, it's often too late to maintain the original design vision," she explains. Rita needed better integration with the development process and a way to validate designs earlier.
Then there's Paul, the product manager, trying to hold everything together. He spent countless hours writing detailed requirements documents, but something always got lost in translation. "It feels like playing a game of telephone," Paul says. "By the time features reach customers, they've morphed into something different from what we initially envisioned." He was desperately seeking better collaboration between engineering and design teams, but the traditional handoff process kept creating barriers.
Rick, the program manager, had perhaps the most challenging role of all. Coordinating dependencies across multiple teams while balancing delivery speed with quality kept him up at night. "When teams work in silos, simple changes can cascade into weeks of delays," Rick observes. He needed a way to foster better cross-team collaboration and visibility.
Overseeing it all was Anna, the engineering leader struggling to transform how her teams operated. While she valued technical excellence, she knew something was missing. "We have incredibly talented engineers," she notes, "but we're not consistently delivering the value our customers need." Anna wanted to change the team's culture, but the traditional development model made it difficult to balance technical excellence with customer value.
This team's experience reflects a broader pattern in software development. While organized and predictable, the traditional sequential approach creates natural disconnects between those building the product and those using it.
Culture: The key to transformation
"Culture eats strategy for breakfast." While this quote is often attributed to management guru Peter Drucker, it gained prominence when Mark Fields permanently displayed it in Ford's war room in 2006. The message wasn't just a catchy phrase — it captured a fundamental truth we've repeatedly seen in the tech industry: even the most brilliant strategy will fail if it conflicts with your organizational culture.
When we decided to transform our engineering culture at Compass, we discovered something profound: technical excellence alone wasn't enough. We needed to bridge the gap between our engineers and customers. The numbers back this up: Companies with strong cultures see 4x revenue growth compared to their competitors.
Our transformation journey at Compass illustrates this perfectly. We moved from a traditional feature lifecycle process that typically took 6-8 weeks to complete to an iterative discovery process that brought us much closer to customer problems. This wasn't just a process change – it was a fundamental shift from a "know-it-all" to a "learn-it-all" mindset, where every feature became an opportunity to learn from our customers.
The evolution of product engineering
Software engineering has traditionally been about turning requirements into working code through systematic design, development, and testing. Engineers focus primarily on technical execution: writing efficient code, maintaining systems, and ensuring quality.
Product engineering, however, represents a fundamental shift in how we think about building software. While it maintains the technical rigor of software engineering, it adds a crucial element: deep customer understanding and continuous learning. Product engineers don't just write code - they participate in discovering and solving customer problems, bringing technical insight to product decisions, and owning the outcomes of their work.
The traditional software engineering model
In the traditional model, development follows a linear path. Requirements flow down from product management through design to engineering teams who implement them. Think of it as a relay race, where each team passes the baton to the next.
Our team's old workflow reflected this linear approach:
- Requirements documents took months to create and approve
- Architects and designers worked in isolation
- Engineers coded to exact specifications
- Testing and deployment came at the end
- Customer feedback was filtered through multiple layers
This approach worked well when requirements were stable, and change was expensive. But in today's rapidly evolving markets, we needed something more adaptive and customer-centric.
The product engineering continuous loop
Our transformation centered on replacing this linear process with a continuous learning loop. Instead of treating development as a relay race, we now operate more like a soccer team - everyone moves together, adapts to changing conditions, and keeps their eye on the goal of delivering customer value.
In this new model:
- Engineers join customer interviews and discovery sessions
- Development and design happen collaboratively, with rapid prototyping and testing
- Technical decisions are validated against customer needs
- Deployment becomes a learning opportunity, not just a delivery milestone
- Teams measure success through customer impact, not just technical metrics
From implementation to ownership
For engineers like Tina, this transformation meant evolving from pure implementation to true ownership. Engineers now:
- Participate in problem definition and solution exploration
- Bring technical perspectives to early discussions
- Validate assumptions directly with customers
- Own feature outcomes beyond just code quality
- Track business metrics and market impact
The results speak for themselves: Organizations adopting this model see faster time to market and higher feature adoption rates than those using traditional engineering approaches. Perhaps even more importantly, we've seen higher team engagement, better technical decisions, and stronger alignment between our technical solutions and customer needs.
How we enabled our transformation
Transforming how engineers work required more than just a mindset shift - it needed the right foundation. For our team, a crucial piece of this foundation was Jira Product Discovery, a tool that naturally brought customer context into our daily workflow.
The first challenge we needed to solve was making customer insights accessible to everyone. Before, customer feedback and product requirements lived in Confluence documents, Slack threads, and Jira tickets. Jira Product Discovery brought all of this context directly into our development workflow. Engineers could now see customer interviews, feedback sessions, and usage patterns right alongside their development work, making customer needs tangible and immediate rather than abstract and distant.
This accessibility fundamentally changed how our teams collaborated. When a designer like Rita created new designs, she could link them directly to customer pain points that engineers could see and understand. When Paul prioritized features, he could easily connect customer impact to technical complexity, leading to better-informed decisions. Most importantly, our engineers could finally see the complete picture - not just what we were building but why it mattered to our customers and how it would impact their work.
For teams considering a similar transformation, remember that it's not about choosing between technical excellence and customer focus - it's about bringing them together to create products that customers truly love. When engineers deeply understand customer needs, they make better technical decisions, architect more elegant solutions, and find greater meaning in their work because they can see its direct impact.
Want to learn more about how we made this transformation happen? Check out our webinar: The Magic Behind Product Engineering: Turning Customer Problems into Features They Love, where I'll dive deeper into our journey and share practical strategies and rituals you can implement with your own team.