The reality of working at a sales-led company is that sales conversations often shape the roadmap, and enterprise deals can influence what gets built and when.
Despite how it sounds, that isn’t to say that engineering just takes orders. It means we’re closer to what the customers are asking for, and what the business needs to deliver. Done well, it’s not reactive, it’s responsive. It’s not chaotic, it’s prioritisation with context.
Now whilst that all looks great written down, it does take a different kind of mindset to make it work.
At Pinpoint engineering doesn’t sit far from the frontlines. Often we’re just a Slack thread away from a strategic account, a pre-sales deal, or a customer who is particularly passionate about that “one missing feature”.
Yes, that proximity can sometimes feel a lot like pressure, but it’s also an insight. It gives us an understanding about what actually drives buying decisions.
That’s important because it keeps us grounded in reality , we’re not building in a vacuum, we’re solving problems that real people are facing right now. That sort of visibility helps us prioritise what matters and build things that actually move the needle (for them and for us!).
Yes, the roadmap will move. Deals will land, priorities will shift, and timelines will evolve.
But that’s not chaos, it’s business. In a sales-led world, agility means being able to shift focus without losing footing.
That requires more than sprint ceremonies and velocity planning. Agility for us is structural: code that behaves when priorities change, backlogs that allow for re-ordering, and teams that can pause, refocus, and regain momentum with minimal drag.
Yes, when priorities change it’s usually engineering that feels the whiplash. The context switch, the “can we squeeze this in?”, the shelving of work in progress. It’s real, and frankly sometimes frustrating.
That’s why sales and product/engineering have to stay closely aligned at all times. When those teams move in lockstep — sharing rationale early, making trade-offs visible, and keeping feedback loops tight — change does actually feel less disruptive.
In this context engineers thrive when they think beyond the backlog. The very best ones are totally product-focused: curious about customer context, eager to understand business value, and comfortable with ambiguity.
They fully understand the notion that great code that solves the wrong problem is still the wrong solution.
Hiring and nurturing that mindset is challenging, but critical for shaping an engineering culture where success isn’t just about shipping code but about achieving business objectives.
For one, it sets the bar higher, but the rewards are better too.
You need tighter comms, sharper prioritisation, and a stronger sense of ownership across the team. Engineers who ask why, not just when and how. People who want to understand the bigger picture, not just what’s on their board.
And in return? When it works, you’re not downstream from strategic product decisions, you’re in the conversation where they’re made. Your work connects directly to what pushes things forward: closing deals, unblocking users, solving actual business problems.
I’ll also concede that it’s not always perfect. Things can go awry, and they usually do so as a result of misalignment. When it’s not working, there’s a good chance it’s because context has gotten lost, decisions weren’t shared, or product/engineering are disconnected from the bigger why.
Things only work when everyone in the business is pulling in the same direction, with a shared goal and a clear view of why the work is important.
This kind of engineering definitely isn’t for everybody. It asks you to care for more than your corner of the codebase. But for teams that do lean into it, it’s where engineering and product teams start to feel connected to something bigger than architecture decisions, delivery timelines and ticket counts.