Mobile World Congress hangs by a thread after Nokia, DT and other big names back outFebruary 14, 2020
Dark Screen Fix?February 14, 2020
TL;DR Looking for advice on fielding boilerplate technical questions from a sales team that's ambitious with the type of customer they're pursuing and a lack to stop deals dead before many human hours are wasted.
I'm the CTO for a small tech company (SaaS product) that runs our product with a cloud vendor. I didn't pursue this position, it was just one of those situations that falls into your lap after working as a senior engineer for long enough. My only point in mentioning that is I don't see myself as a CTO, nor do I have any past experience in any C-level role. I get imposter syndrome on the regular, which leads me to being uncertain what is “normal” versus what is a “red flag”.
We're a resource strapped business (what's new??) and have an infinite list of development projects on our roadmap. Seeing wasted time go down the drain with no positive outcome or improvement in revenue is frustrating to say the least.
In my role, I often am presented with “technical questions” from prospective clients, or they may come in the form of responding to a large RFP with a section on technical requirements.
I have several issues with this I'll go over. Looking for outside advice from others who have been in this position, or witnessed this sort of experience.
- These RFPs typically look like they're written 20 years ago, most of the technical requirements don't apply to cloud-based software. What gives? You can only say “not applicable” so many times. I've worked in very large enterprise, I realize they're behind, but are they really that far behind?
- Requests for us to host the product in a certain geographical reason that is not currently where our product is hosted. Logistically we just don't have the resources to make these changes, yet it comes up often and we (sales) don't flag it as a deal breaker. Why? Is that my responsibility to call a potential deal dead in the water when region-based requirements arise? This requires some finesse since often times we're already several weeks (and calls) into the relationship by the time I am pulled in. People have become emotionally invested already.
- Requests or requirements for certifications of some kind (SOC 2, for example) that we do not have, don't have the budget to attain, or the resources to put it on our short term roadmap. Same questions as previous item, to me this is an instant deal breaker, but it rarely ends up being that way. Yes, various compliance certifications are on our longer term roadmap, but we're quite a ways off from attaining them to say the least.
- Requests to host our cloud-based product with a different cloud vendor. No, we cannot “lift & shift” from X to Y to support client A, yet it comes up (less frequently than the others, but it has been a request several times in the last 2 years).
- Requests for us to disclose technical details of our infrastructure, such as a high-level diagram of all the services we rely on, what type of database (software & version) we run, what programming language we use, etc. I bristle at disclosing these technical details out to the world and often insist we put very clear usage constraints on these disclosures. Am I being too overbearing? Is it normal & acceptable for a client to ask this level of detail, and for the vendor to readily respond? My perspective tends to be one of what I do behind the curtain is none of anyone's business but our own.
- Lastly, all of these technical questions are more or less repeats of past questions we've answered. The language varies a slight amount, and I end up re-saying the same words over and over again. It's become enough of a problem that I've implemented a workflow to help us move quickly to get the client the answers they seek, with as much async (mostly docs+commenting) communication as possible.
Thanks for any input and feedback you can provide. Outside perspective is always helpful.
submitted by /u/startup-advice