(Image generated using ChatGPT)

Software engineering is not just about writing code, it’s about solving the right problems. Yet, many engineers hesitate to ask questions that would help them understand their work, their user stories, or how a feature fits into the larger business context. Instead of engaging product managers, designers, or business stakeholders through curiosity, they often walk away with assumptions.

"Stay hungry, stay foolish." – Steve Jobs

The Story of Aditya: A Costly Assumption

Aditya had just started his dream job as a software engineer at a promising tech startup. During a sprint planning meeting, the product manager outlined a user story:

User Story: "As a user, I want to receive notifications about new updates relevant to my preferences so that I can stay informed."

Aditya listened, nodded, but did not ask any questions and assumed it meant sending notifications to users periodically. He didn't seek any clarification on what "relevant to my preferences" meant, no details on how frequently notifications should be sent, and no discussion on whether users could customize their preferences.

Over the next sprint, Aditya built a time-based notification system that sent generic updates to all users. When he finally demoed it, the product manager frowned. "This isn’t what we needed," they said. "Users were supposed to receive notifications based on their engagement behavior and explicit preferences, not just random updates."

Aditya had spent entire sprint working on something that didn’t align with the business needs. A few simple questions like "What defines relevance? How does a user set their preferences? Should we consider engagement history?" could have saved time, effort, and frustration. Instead, his reluctance to engage in a conversation cost him a sprint’s worth of work.

This scenario plays out too often in software teams. Engineers hesitate to ask product managers, designers, or business stakeholders questions about the larger picture. Instead, they make assumptions, leading to misaligned features, wasted effort, and missed opportunities for innovation.

 

Hurdles to asking questions

Despite being problem-solvers by nature, software engineers often avoid engaging deeply with the "why" behind their tasks. Let's explore some of the factors that contribute to this behavior:

1. Fear of appearing uninformed

Engineers may feel that asking product or business questions will make them seem inexperienced or out of touch. What if their question is stupid or irrelevant? What if their question is un-related to the discussion at hand? Many such fears often keep engineers from asking any questions.

"He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever." – Chinese Proverb

2. Tunnel vision on implementation

Many engineers focus so much on "how" to build something that they forget to ask "why" it’s being built in the first place. These engineers are passionate on their craft. They are thinking about design patterns to apply, how to de-couple and ensure the solution is extensible. Their brains go into an overdrive on solution design without wasting a second.

3. Lack of cross-functional communication

Engineers may see product managers and business stakeholders as separate entities, leading to minimal direct engagement. They often build reliance on a Tech SME or an Architect and expect them to ask all the questions.

4. Time constraints

When engineers are under pressure to deliver, they might believe they don’t have the time to ask clarifying questions, assuming that figuring things out later is more efficient. They do not wish to spend upfront time understanding all the stories but decide to do the analysis when they pick up the stories to work on.

5. Cultural aspect

Many educational systems and work cultures discourage questioning authority or established processes, leading engineers to accept requirements without deeper inquiry. Engineers coming from such a system would expect that the processes to ensure all the requirements to be documented in full details are in place, while their own role being reduced to just code as per what is documented.

6. Self-confidence issues

Some engineers, especially juniors, are nervous to speak up in a group setting. They hesitate to ask questions out of fear that they might look incompetent. Some might even freeze at the thought of speaking up. These engineers might need help in the form of some communication training.

7. Attitude of indifference

This is by far the most problematic factor. Here, engineers think, "It’s not my problem, I just build what I’m told". They operate with I don't care attitude. This lack of ownership can lead to subpar solutions that don’t serve the end-user effectively.

 

The consequences of not asking questions

Failing to ask questions doesn’t just affect individual engineers but it has a ripple effect on the entire organization.

• Misaligned features – Engineers can end up building what they assume is needed, but if it doesn’t match business goals, it would result in wasted effort and rework.
• Inefficient development cycles – When engineers decide that they will ask questions later when they actually start working on a story then teams end up going back and forth making corrections mid sprint, which eventually slows down the entire release.
• Poor customer experience – When engineers fail to engage upfront, then they end up working with incomplete information causing subpar experience for the clients or customers. This causes frustration for product managers and business stakeholders as they feel unheard.
• Missed strategic opportunities – Engineers who don’t engage with product or business teams, then they miss opportunities to contribute valuable technical insights that could shape better solutions.

Jeff Bezos, once said, "If you don’t understand the details of your business, you are going to fail." This applies to software engineers too, understanding the "why" is just as important as mastering the "how."

 

How can we change this culture?

To create a culture where engineers actively engage with the bigger picture, both individuals and organizations need to take action:

• Encourage engineers to think like product owners - Instead of just implementing tasks, engineers should be encouraged to ask: "What problem are we solving?", "Who are we building this feature for?", and "How does this feature impact the user?" The more they understand, the better their solutions will be.

• Make cross-functional collaboration a habit - Regular interactions between engineers, product managers, and business teams should be built into the workflow. Techniques like product discovery meetings, joint brainstorming sessions, feature readouts, and early technical discussions help engineers see the bigger picture.

• Normalize curiosity in team culture - Leaders should model the behavior by asking product related questions themselves. Engineers who ask questions challenge assumptions and drive innovation. Allow time for engineers to prepare their questions on features before discussions. Leaders can encourage engineers to write down these questions so that it becomes easier for them to ask during the meetings. Avoid having one spokesperson who handles all interactions with business stakeholders but rather make them responsible to get entire team engaged in asking questions.

• Create a safe space for questions - Many engineers stay silent because they fear looking uninformed. Companies should cultivate an environment where curiosity is encouraged, and no question is seen as basic or unnecessary or stupid. Bring the team together and get them to spend time together, so that they feel confident in engaging within the team itself. Have the client or stakeholders visit the team and spend time with the team having lunch or dinner or at an outing event.

• Train engineers on effective communication - Engineers should be taught how to frame their questions in a way that leads to meaningful discussions. For example, instead of asking "What do you want me to build?" they can ask, "What’s the goal of this feature, and what problem are we solving?". Arrange for professional communication training or setup internal communication building groups for engineers.

• Integrate business context into onboarding - New engineers should be trained not just on the codebase but also on the company’s products, users, and business objectives. This helps them develop a habit of thinking beyond implementation. As part of project onboarding include a session that covers:

  • Who is the client or customer?
  • Who are the important stakeholders?
  • What is the client's main business?
  • What are we building for them?
  • Who are the users of the product?
  • What are the pain areas for the users or business?
  • What are the milestones or releases or phases for release?

 

"The important thing is not to stop questioning. Curiosity has its own reason for existing." - Albert Einstein

 

Conclusion

So next time you receive a task, don’t just nod and start coding. Pause, think, and ask: "Why does this matter?" It could be the question that changes everything.