Select Page

I had completed one year at my new job, which meant I had to discuss my performance with my project manager. Coming in as an entry-level developer, I felt great about my performance. After all, I started from scratch and came into this meeting with a small but existing portfolio of work. I came into this meeting with ideas on where to improve my work, such as taking more responsibility, ask fewer questions, or being more confident in my work.

After a few minutes of small talk we got down to business. My project manager agreed that I had improved and started to show signs of promise for the team and company. Then I asked about areas where I could improve. I expected him to list some of the things I mentioned above, but was surprised at his answer:

“You need to ask more questions”

I have read multiple articles about the value of asking questions. Everyone has them. They are necessary to get things done. Despite this knowledge, I still felt asking questions was a weakness. To me, asking fewer questions meant I understood more about the system, I was growing, and I was paying better attention. Asking more questions would make me look weak and clueless.  I asked my manager to explain why he suggested this. This is what he said:

  1. “I expect you to ask more questions because you are an entry-level developer”: This was not an attack on my novice status, merely an acknowledgement of my circumstances. Since I came in as an entry-level developer straight from college, the team expected me to have more questions. They knew I had no prior background in a work environment. Instead of embracing my circumstances I was embarrassed by it.
  2. “Why you develop a feature is just as important as how you develop it”: I was obsessed with mastering Spring MVC and the other technologies we used that I did not care to know why I was developing this feature. While I felt it was none of my business, I realized that a feature’s purpose would influence how I developed (choosing speed over readability, making code more modular so it could be reused, etc). While such practices seem obvious to implement, I have been in situations where I had to choose one over the other.
  3. “You are more than a developer”: Working in an Agile World made this point very clear. Though I was hired as a developer, agile teams succeed when they are self-organizing (Agile Principle #11) and cross-functional. Only wearing the developer hat would set myself and my team up for failure. While the Business Analyst (BA) on our team asked most of the questions, my involvement outside of development not only eased the responsibility on the BA, it added meaning to features being developed.

Since my review I have committed to understanding why I do what I am doing. I do not ask more questions now for the sake of asking questions, but I do pay closer attention in sprint planning meetings and take notes wherever I can. After this experience, I am less ashamed of asking questions.