4 ms·
> Turn up the heat in every interaction and ask uncomfortable questions. Some of the questions I repeatedly ask: > Can we re-frame this in terms of the custome
by mkl95 4y ago
> Turn up the heat in every interaction and ask uncomfortable questions. Some of the questions I repeatedly ask:
> Can we re-frame this in terms of the customer’s problem?
> What’s the soonest we could get this done?
> What would you need to get this done tomorrow instead of next week?
Well, that sounds like a recipe for high turnover. I know few engineers who would want to work for this kind of low trust boss and they are all bottom of the barrel consultant types. I thought Stripe was doing better than that.
- tresil 4y agoThe context and frequency of these types of questions is crucial. As an engineer myself, I would love to see more of these conversations as long as they’re handled the right way.
- adamesque 4y agoContext is so important. If the expected response to "what would it take to get this done twice/10x as quickly" is "We shall work twice/10x hours or add equivalent headcount", then you have a serious context problem. The point of these questions should be to encourage really creative thinking to break out of "normal" operating modes (take on tech debt, etc) and if that's not well understood, or perceived to be an instruction to crunch, then you haven't set the context appropriately and will burn people out.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- sgustard 4y agoAs an engineer, I ask these questions all the time. Clueless product marketing people will request the most ridiculous features. I ask them: don't tell me the solution, tell me the customer problem. And what's it worth to you to solve this with the pieces we have now, instead of building something months from now? My teams have deflected years of pointless effort this way.
- treis 4y agoIt comes down to whether or not the person you're asking has the power to change things. If not then it's a fairly soul crushing question. Exponentially more when it comes from the same people that have not granted you the power to change things. Like we were handed a solution to implement that architects and product folks had been talking about for most of this year. But they didn't include anyone that was day in day out hands on with the systems they wanted to change. To do that and then ask the people implementing if we can speed things up would be quite annoying. It's asking them to contradict the design decisions that people 1-3 levels above them made. Risky business for sure. Even moreso for technical folks that in general aren't as adept at sussing out the difference between someone really asking and someone looking for a rubber stamp on a decision already made.
- dopeboy 4y agoThink of these questions less as interrogative orders and more as discussion points / negotiations. I agree that the latter two need to be deployed wisely, sensitive to context and frequency.