5 ms·
Whenever new people join the team, I always say, "Please ask stupid questions. I mean questions so stupid that you might think we would question why we hired y
by genghisjahn 5y ago
Whenever new people join the team, I always say, "Please ask stupid questions. I mean questions so stupid that you might think we would question why we hired you, because you think we think you should already know. Ask those types of really stupid basic questions. It will educated you, make us think, and I'm certain at least one other person already on the team doesn't know either."
- ryantgtg 5y agoI usually say, "please ask stupid questions, because if you don't then you'll run off in the wrong direction and work on the wrong thing for a week before the next review, and you'll have wasted a lot of project budget." At my work, there's a bad combo of senior folks who whip off vague instructions in a single sentence, and junior folks who are afraid to ask questions. I'm in the middle, and I try hard to demonstrate that it's fine to badger the senior folks with questions, and to check in with them constantly. The senior folks like it because it gives them confidence that you're working it out. But some of our straight outta school colleagues just don't do this ("Gotcha. Sounds good!" is a very common email reply from them) and it leads to confusion down the road. After giving them the "ask questions" talk two times, I usually give up on them. Also, in my position, I often have to review and edit reports that are largely written by electrical engineers and architects, and they all probably think I'm super dumb. I read the reports as the target audience (often non-subject matter experts), and so my comments are things like, "What do you mean by this [basic EE concept]?" I don't preface it with, "I know what this means, but the client might not, please elaborate..."
- cmorgan31 5y agoPlease, please keep doing this and encouraging this behavior. The more senior on the ic track you get the harder it is to find time to mentor. The reality is that is a core tenet of our position and we may be staying silent to not smother the room. If you need help and you have a competent senior they should encourage your questions or delegate to an appropriate senior if they are too busy.
- Kinrany 5y ago> I usually say, "please ask stupid questions, because if you don't then you'll run off in the wrong direction and work on the wrong thing for a week before the next review, and you'll have wasted a lot of project budget." Does it help? This sounds like they are expected not to waste time, so it might get even harder to ask a stupid question a minute too late, and especially to ask something tomorrow.
- ryantgtg 5y agoSo far it completely depends on the person. But you’re right that it might not be the best technique. I understand the hesitancy to ask questions after a certain amount of time has passed. I work as a consultant and our time has to be billed to projects. The onboarding stinks, so the new hires often have no concept of billability/utilization nor project budgets. So I’m trying to drill in those concepts, too. One of the additional lessons here is “the boss doesn’t always know what they’re talking about.” And that’s another hard one for them to accept. Question authority! If the instructions aren’t clear, then they might be nonsense. Have the guts to challenge the boss. And sometimes the challenge can come in the form of a million stupid questions.
- Tabular-Iceberg 5y ago> The onboarding stinks, so the new hires often have no concept of billability/utilization nor project budgets. As an aside, do you think there is a business opportunity in teaching companies better onboarding? Growing headcount seems like an afterthought most places, and it’s a colossal waste. The worst example I’ve seen is one company hiring some very expensive onshore consultants to build the basic structure of the application and then quickly hand it off to cheap offshore ones. What really happened is that the onshore guys created a horrendous mess of untested and undocumented code full of bugs that the offshore ones had no hope of making sense of. And being remote and from a culture of high power distance further exacerbated the problem. It certainly worked out well for the onshore guys who got to bleed the client out of a whole other year’s worth of expensive hours.
- 5y ago