If software development is really R&D work, then certain everyday habits actively undermine it—habits that make perfect sense in manufacturing but work against investigation and discovery.
Beyond the obvious obstacles, there are everyday behaviors that can quietly prevent teams from working like R&D organizations. These are harder to spot because they feel normal—they’re how we’ve always worked.
When someone asks about a task and you haven’t investigated yet, there’s a reflex to apologize. “Sorry, I haven’t looked at it yet.” “I should know, but…”
This frames not-knowing as a failure. But in R&D work, “I don’t know yet” is the honest starting point. Investigation is how you get to “now I know.”
The subtle shift: Replace “Sorry, I haven’t looked at it yet” with “I haven’t investigated it yet—want me to spend time on that?”
You spend an hour reading through existing code to understand how something works. Someone walks by and asks “How’s it going?”
The reflexive answer: “Still getting familiar with the code” (translation: “not doing real work yet”).
But that reading is the work. Understanding the existing system is investigation. It’s not preparation for the real work—it’s the core of the work.
The subtle shift: “Making progress—I’m understanding how the authentication system works” instead of “Still reading code.”
Product asks: “Can we add real-time notifications?”
The instinct is to say “Yes” immediately. It feels collaborative. It feels can-do.
But “yes” before investigation means you’re committing without information. The R&D response is: “Probably, but let me investigate what that involves and I’ll tell you the options.”
The subtle shift: Replace immediate “yes” with “let me investigate and tell you what’s involved.”
Many teams do “spikes”—time-boxed investigation. But there’s often pressure to keep them short. “Just a quick spike.” “Don’t spend too much time on this.”
This treats investigation as something to minimize rather than a core activity. A spike that finds a major problem isn’t “slow”—it’s valuable discovery.
The subtle shift: Stop calling investigation “overhead.” It’s the work. The coding is what happens after you’ve done the work.
You’re three days into a feature and still not sure of the best approach. There’s a gnawing feeling: “I should have this figured out by now.”
That guilt assumes you should know the answer before doing the investigation. But discovery takes time. Uncertainty midway through investigation is normal, not a personal failing.
The subtle shift: Expect uncertainty. Plan for it. “I’m three days in and I’ve learned X and Y, still investigating Z” is progress, not slowness.
Investigation often looks like: reading code, sketching diagrams, talking to people, sitting and thinking. None of this looks like “shipping.”
There’s subtle pressure to appear productive. So you start writing code earlier than you should, because at least then you have something to show.
But premature code is waste if you haven’t understood the problem yet.
The subtle shift: Make investigation visible. Share what you’re learning. “I discovered our auth system has three different session types” is progress worth reporting.
The requirement comes in. You investigate how to build it. You present options. You build it.
But investigation should answer two questions: “How should we build this?” AND “Should we build this at all?”
Often we skip the second question. It feels outside our role. But if investigation reveals this is a bad idea, saying so is part of the job.
The subtle shift: Every investigation should explicitly consider “Is this worth building?” Not just “How do we build it?”
At standup, people report “I finished the login component” or “I wrote the API integration.” These are tangible updates.
But “I investigated the authentication flow and found we need to rethink our approach” is equally valuable progress—maybe more valuable. It just doesn’t feel as concrete.
The subtle shift: Celebrate discovery. “I found out why password resets are failing” is a win, even if you haven’t written the fix yet.
“How long will this take?” “Same as last time we did something similar—about two weeks.”
But investigation might reveal this is very different from last time. The old estimate becomes an anchor that has nothing to do with current reality.
The subtle shift: Each task deserves investigation. Even if it looks similar, the context might be completely different.
You’re investigating a feature and discover it conflicts with something another team is building. The tempting response: “Not my problem, I’ll just build my part.”
But in R&D work, discovering conflicts and dependencies is valuable. Surfacing them is part of investigation.
The subtle shift: Investigation includes understanding how your work affects the broader system. Those discoveries matter.
These habits all share something: they optimize for appearing productive, certain, and fast. They treat investigation as something to minimize, apologize for, or skip.
In a manufacturing mindset, these habits make sense. You want to get to the assembly line quickly.
In an R&D mindset, they’re counterproductive. They rush past the part that actually matters—understanding the problem and the landscape.
The tricky part is these habits feel professional. They feel responsible. “I said yes, I’ll figure it out” sounds committed. “I’m not spinning my wheels investigating, I’m building” sounds productive.
But they work against investigation-driven development. The shift isn’t about working harder—it’s about recognizing that investigation is the work, not something to minimize before you get to the “real” work.