Transitioning an engineering team from an outsourcing mindset to a product-driven one requires patience, understanding, and the right incentives. Changing the way engineers think—from task completers to product builders—requires addressing some deeply ingrained habits. Let’s explore these challenges through the lens of commonly used phrases you’ll hear in process-driven teams, and why they need to change (with a bit of humor to keep things light).
1. “I did as it was said in the task.”
The classic “I just work here” defense. This statement highlights a task-oriented mindset where engineers follow the spec to the letter but miss the bigger picture. Did they really understand the task? Did they question whether it made sense in the broader context of the product? Sometimes, what’s written doesn’t fully capture the problem—or might even be plain wrong (we’ve all seen those specs that make you wonder if it’s April Fool’s Day).
The Shift: Encourage engineers to truly understand the task and the business case behind it. If the spec doesn’t make sense, it’s crucial to raise the issue. First understand, then do. After all, blindly following instructions can lead to unnecessary rework. As I tell my teams, “Let’s aim for a feature that solves problems, not creates them.”
To foster this shift, leaders must react constructively to specification questioning and welcome “obvious and repetitive questions” without frustration.
2. “I worked for 40 hours on these tasks” vs. “This is what I’ve completed.”
Imagine hiring a painter to paint your house, and after a week they proudly announce, “I spent 40 hours painting!” Meanwhile, your house is still half beige and half primer. Logging hours is not the goal—delivering value is.
The Shift: Focus the conversation on outcomes rather than process. While unexpected challenges can arise (looking at you, cryptic error messages), it’s essential to ask, “What’s been delivered?” Measuring progress by tangible results helps ensure priorities are in check and keeps everyone motivated. And maybe consider upgrading the coffee supply for those truly marathon debugging sessions.
To enable this shift, create a safe environment where people can fail without fear of blame, punishment, or fines.
3. “I found a problem, but… that’s not my job to fix.”
We’ve all encountered the dreaded problem-dropper: someone who identifies an issue, announces it, and then steps back like a magician revealing an empty hat. It’s the workplace equivalent of noticing a flat tire and waiting for someone else to call roadside assistance.
The Shift: Foster a culture of problem-solving. If you see a problem, don’t just flag it—suggest a potential solution. Even if the idea isn’t perfect, it demonstrates engagement and a proactive mindset. Building a product is a team effort, not a game of pass-the-problem.
As a leader, avoid jumping in to solve every problem. Instead, ask questions like, “What solutions do you see?” or “How can I assist you in solving this?”
4. “Business makes us work overtime.”
This phrase embodies the “us vs. them” mentality, where engineers see the business team as adversaries constantly demanding more. It’s an easy narrative to fall into, but it’s counterproductive and creates unnecessary tension. Often, this mindset is rooted in past experiences of rushed, unrealistic deadlines.
The Shift: Build a sense of shared purpose. Remind everyone that business, engineering, and product teams are all working toward the same goal. Initiatives like cross-functional standups help teams understand each other’s challenges and foster empathy. Plus, nothing unites a team quite like reminiscing over that one release that almost went off the rails.
To support this shift, provide transparency on how the business is doing, empower the engineering team to make decisions, and make fair trade-offs (e.g., if a new task is added, another is removed).
5. “I’m an engineer. I code. Why should I care about anything else?”
Ah, the purist—focused solely on coding and leaving business goals, user experience, and everything else to “someone else.” But building a great product requires more than just great code.
The Shift: Reinforce that coding is just one piece of the puzzle. Engineers who understand the “why” behind their work can make better decisions and avoid unnecessary rework. One effective approach: involve engineers in user feedback sessions. Seeing real users interact with—or struggle with—their features can be eye-opening and inspiring. As one engineer put it, “Wow, I didn’t realize my button placement could ruin someone’s day.”
To foster this mindset, involve engineers in problem discovery, solution brainstorming, and user feedback sessions.
6. “I will be working on this” vs. “I will complete this.”
This one’s subtle but significant. Saying, “I will be working on this” is like saying, “I’ll start cleaning my room”—it doesn’t guarantee the job gets done. It’s often a sign of hesitation or fear of commitment. And yes, committing means accountability, which can be intimidating.
The Shift: Encourage engineers to confidently say, “Yes, I will complete this.” This linguistic change reflects a larger mindset shift toward ownership and responsibility. To support this, break tasks into manageable chunks and address blockers early. As I like to say, “If you’re nervous about commitment, start with one sprint. We’re not asking for a marriage proposal.”
To build this confidence, create a safe environment where it’s okay to fail and learn from mistakes.
Final Thoughts: Turning the Ship Around
Transforming an engineering team into a product-driven powerhouse is not a solo act. Transformation happens when everyone rolls up their sleeves together. It’s a collaborative effort that requires buy-in from the entire organization. Engineers can’t take ownership of the product if leadership constantly overrides their decisions or treats them like task robots. It’s a two-way street.
However, it’s also normal that not every engineer will make this mental shift. Some will, others won’t, and that’s okay. Your organization might find value in having both a feature team and a product team. Ultimately, it’s up to every organization to form the culture that fits them best.
As leaders, our job is to empower engineers, provide context, and trust them to make decisions. For engineers, the challenge is to step out of the task-oriented bubble and think about the bigger picture. Together, we’re not just building features—we’re building a product that users love (and that doesn’t keep us up at night fixing bugs). And if we can laugh a little along the way—like remembering the time we “successfully” launched a feature no one needed—all the better.