Project Idealism
One of the biggest mistakes you can make is being willing to make a decision while you're confused about something. Or worse, not even realizing that a decision has to be made because you were content with not understanding a situation. It happens in the world of project management all the time, especially with new project managers. The best advice I can give people about this is to be comfortable with what you don't know, and have enough confidence in yourself to dig for answers.
Unfortunately, many people are unwilling to do this because they fear it will make them look stupid, or afraid it will agitate people on their team. The thing to keep in mind is that for every person you may be agitating, there's probably three or four more that are thirsting for the clarity that your questions will provide. As for looking stupid, it's just simply not true.
Think of it like this; the President of the United States can't be an economist, a general, a spy, a small business owner, and a doctor. However, it's perfectly reasonable that we expect the President to make informed decisions based on a series of discussions and questions with these people who are experts in their respective areas.
The key is to understand the difference between getting the proper perspective on a situation so the right decisions can be made, and getting too deep into the details of someone's work. It's true that it can be a fine line sometimes, but generally speaking after a couple questions it'll become clear as to whether you need to back off or continue asking more questions.
A software developer probably isn't going to want to sit down and explain every detail of their work to you. However, it's fine for you to ask why one requirement is being completed before something else that you know is more important, and that another team is waiting on. Maybe there's a technical reason, and if there is, the developer should be more than happy to explain it to you. If you get an answer that doesn't make sense based on your understanding of the situation, don't just walk away confused. Get clarification.
You may end up with new information that changes your perspective of the situation, which you can then share with others and in effect become an advocate for the developer. Or, you may realize that the developer misunderstood their priorities. Either way, your project will be better off because you were willing to ask questions.
This, by the way, isn't something that applies only to project managers or business. There's a whole world of people that thrive on you not understanding something. (Think banks, credit cards, politicians, lawyers, car dealers, and realtors) And, they count on you not being confident enough in yourself to probe them with questions to get the clarity you need to make the right decision. The best example of this is to go into a car dealership, talk to them about leasing a car, and start asking them all sorts of questions about the money factor. It'll totally freak them out and I promise you, they will have no idea how to answer your questions without getting "the finance guy."
Unfortunately, many people are unwilling to do this because they fear it will make them look stupid, or afraid it will agitate people on their team. The thing to keep in mind is that for every person you may be agitating, there's probably three or four more that are thirsting for the clarity that your questions will provide. As for looking stupid, it's just simply not true.
Think of it like this; the President of the United States can't be an economist, a general, a spy, a small business owner, and a doctor. However, it's perfectly reasonable that we expect the President to make informed decisions based on a series of discussions and questions with these people who are experts in their respective areas.
The key is to understand the difference between getting the proper perspective on a situation so the right decisions can be made, and getting too deep into the details of someone's work. It's true that it can be a fine line sometimes, but generally speaking after a couple questions it'll become clear as to whether you need to back off or continue asking more questions.
A software developer probably isn't going to want to sit down and explain every detail of their work to you. However, it's fine for you to ask why one requirement is being completed before something else that you know is more important, and that another team is waiting on. Maybe there's a technical reason, and if there is, the developer should be more than happy to explain it to you. If you get an answer that doesn't make sense based on your understanding of the situation, don't just walk away confused. Get clarification.
You may end up with new information that changes your perspective of the situation, which you can then share with others and in effect become an advocate for the developer. Or, you may realize that the developer misunderstood their priorities. Either way, your project will be better off because you were willing to ask questions.
This, by the way, isn't something that applies only to project managers or business. There's a whole world of people that thrive on you not understanding something. (Think banks, credit cards, politicians, lawyers, car dealers, and realtors) And, they count on you not being confident enough in yourself to probe them with questions to get the clarity you need to make the right decision. The best example of this is to go into a car dealership, talk to them about leasing a car, and start asking them all sorts of questions about the money factor. It'll totally freak them out and I promise you, they will have no idea how to answer your questions without getting "the finance guy."