3 ms·

I can personally vouch for this imo silly little thing. It once came up in a meeting to which we said we could implement it immediately. You try explaining some

I can personally vouch for this imo silly little thing. It once came up in a meeting to which we said we could implement it immediately. You try explaining some stuff to totally tech illiterate people that make the business decision for a government company that needs to publicly do this. It's one big mess, they have to publish reasons and comparisons between several companies and they didn't make any sense when you read them because the people writing them didn't have any any of what they were talking about. You'd often find words like databases, servers, the cloud, and more words strewn around everywhere without making even the closest sense as to what they mean. After that meeting, when someone asked us whether our stuff is in the cloud, we just said yes. When they asked us whether we had SAML, we said yes. When they asked whether we had x, again, we said yes. It's not possible to explain to these people that you'd like to talk to developers or at least people who were trained at some point in their life.

cosmie 8y ago
As someone who has had to become fluent in Executive, Project Management, Bureaucratic Procurement, Software Development, and Operations (I consider each of those completely distinct languages), I can empathize. The best way I've found to improve on that type of pain is to try to shadow as many similar interactions as you can, but with people speaking the same language on both sides of the table, while having a lot of visibility into one side so you understand how their response differs from what yours would be in that situation. Unless something is horrifically wrong in a way which has clear consequences, I generally stay silent and keep my interjections to myself. And at most follow up after with the person "on my side" to try to explain to them, and let them decide if it matters enough to bring up. If they can't see the problem, it's generally useless to bubble it to the other party who has even less understanding of your position. I've learned a lot that way about how to appropriately articulate the same situation to each of those stakeholders. In your situation, the way I've learned to handle it is always a "Yes, our system is designed to be able to support that." The buyer side just has a list of checkboxes that at some point distill down to a bid. They have no idea what the checkbox means, nor care. But they understand that bids have a lot of variables. If you as the technical resource know that it's possible to, in some warped sense, adhere to that definition, then it's a yes. But never a hard yes - every check box on their end is a potential to pull out a cost. If you have to develop SAML support, but know that it's a net new feature that'll need integrated into your auth system, then it's a "Yes, we're capable of supporting that." followed by an explicitly called out segment of your bid that pushes the anticipated development cost onto them as a line item denoting the cost for that feature's support and it becomes another negotiation point. Maybe they don't need that checkbox, if the cost is too high. Or maybe you can frontload the entire development cost of that feature onto that one customer, and it's an inconsequential expense for them. Or maybe they need it, but aren't willing ot fully absorb that development cost and push back. You don't know, and they don't either if you just say yes and try to work out the math on your side to make it work.

cosmie 8y ago

As someone who has had to become fluent in Executive, Project Management, Bureaucratic Procurement, Software Development, and Operations (I consider each of those completely distinct languages), I can empathize. The best way I've found to improve on that type of pain is to try to shadow as many similar interactions as you can, but with people speaking the same language on both sides of the table, while having a lot of visibility into one side so you understand how their response differs from what yours would be in that situation. Unless something is horrifically wrong in a way which has clear consequences, I generally stay silent and keep my interjections to myself. And at most follow up after with the person "on my side" to try to explain to them, and let them decide if it matters enough to bring up. If they can't see the problem, it's generally useless to bubble it to the other party who has even less understanding of your position. I've learned a lot that way about how to appropriately articulate the same situation to each of those stakeholders. In your situation, the way I've learned to handle it is always a "Yes, our system is designed to be able to support that." The buyer side just has a list of checkboxes that at some point distill down to a bid. They have no idea what the checkbox means, nor care. But they understand that bids have a lot of variables. If you as the technical resource know that it's possible to, in some warped sense, adhere to that definition, then it's a yes. But never a hard yes - every check box on their end is a potential to pull out a cost. If you have to develop SAML support, but know that it's a net new feature that'll need integrated into your auth system, then it's a "Yes, we're capable of supporting that." followed by an explicitly called out segment of your bid that pushes the anticipated development cost onto them as a line item denoting the cost for that feature's support and it becomes another negotiation point. Maybe they don't need that checkbox, if the cost is too high. Or maybe you can frontload the entire development cost of that feature onto that one customer, and it's an inconsequential expense for them. Or maybe they need it, but aren't willing ot fully absorb that development cost and push back. You don't know, and they don't either if you just say yes and try to work out the math on your side to make it work.