You Can’t Fake Passion When You Can’t Use the Product

Imagine this. Working at your desk is in Hyderabad as part of the “feature team” building the checkout flow for a major US retailer. Great, right?

Sure, you’re earning less than your colleagues. But the cost of living is lower, so you don’t mind too much. You might work in one of those companies where you need to work “US” hours which, while not fun, is covered by your salary.

It’s hard to feel passion for a product you’ve never used

You Can’t Unit Test Intuition

If you’re working on a product from another continent you can’t use it. You’re not a customer and “dogfooding” is simply feeding your canine friend.

You don’t know the difference between the “RedCard” and the “Red Store Brand Cola.” But you’ve got a ticket in your sprint backlog asking you to “make the checkout feel more aligned with our brand tone”.

How are you supposed to code toward a feeling that you’ve never experienced?

It’s not just that offshoring separates teams geographically. It separates them from the product and companies pretend this doesn’t matter. I guess it doesn’t matter if the company as a whole doesn’t care about the product (or those who work on it,

This is not a criticism of offshore teams. This is a criticism of how companies manage their affairs and “offshore” the most important parts of their business.

Context to Prevent Garbage Output

Much of life as a well-rounded developer is about preventing friction. The issue is that friction can be subjective. 

That means Temu looks…interesting from a US perspective. Why not give us another voucher? That can actually stop purchasing intention (at least it stopped me). Sure, it doesn’t matter for a dollar store app as they’re competing on price but surely the quality of experience matters for the software you and I are working on.

Give someone bad news in an app (your payment failed!) and the button says “got it”? I’m not sure that’s a good look, and failed our user testing. 

Yet shouldn’t we be able to catch these issues sooner in the development process?

Barriers to Dogfooding

Developers are working so hard to make customer behavior easy and remove friction from the experience.

The further your development team from the customer physically, likely there’s extra barriers to them removing barriers from your process. That’s not what anyone wants when creating great software.

Many companies use internal software for their own operations, yet I’ve seen it when contractors can’t even sign up when they’re expected to. One guy said, “I’d use it, but we don’t even have that service here”. Yet somehow, they’re supposed to build the next iteration of the user experience?

Agile Can’t Fix It

You can’t solve cultural disconnection with Agile ceremonies. Daily stand-ups filled with timezone-lagged status updates don’t magically turn a squad into a team.

I’ve seen offshored engineers wait days for a code review because the “core” team didn’t prioritize them. I’ve watched backlogs filled with tickets written like riddles: “Make flow more intuitive based on recent customer feedback”…with no access to the feedback.

Sprint velocity is meaningless if the direction is arbitrary.

Conclusion

Hiring offshore devs or contractors is a business decision. Fine. But don’t pretend you’re hiring “mission-driven” engineers when your offer includes no benefits, no bonuses, and no ability to shape the roadmap.

Companies want innovation without inclusion. They want passion without presence. They want loyalty from people who can’t even get swag from the company store.

About The Author

Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.

The Secret Developer is as passionate as someone who has lost interest in life.