Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "technical sales meeting"
- Sales people: we will deploy and install 100 customers by the end of the month.
Meaning: 100 it's impossibile, we want actually do 50, but we set a high target so people will sweat their ass off. But we don't tell them the truth.
- Tech people: no way, we will deploy and install no more than 25!
Meaning: we could do 100 but we would die. We will guarantee 25, but since we are good we will optimise the workflow and maybe we will make it to 50. But we don't want to create expectations.
Big misunderstanding arise if these two language are used in the same meeting.
At least if I'm in the meeting as technical people7
Many years ago, when I moved from a semi-experienced developer to an absolute beginner project manager at another company, my very first project was an absolute clusterfuck.
The customer basically wanted to scrape signups to their EventBrite events into their CRM system. The fuckery began before the project even started, when I was told my management that we HAD to use BizTalk. It didn't matter that we had zero experience with BizTalk, or that using BizTalk for this particular project was like using a stealth bomber to go down to the shops for a bottle of tequila (that's one for fans of Last Man on Earth). It's designed to be used by an experienced team of developers, not a small inexperienced 1-person dev team I had. The reason was for bullshit political reasons which I wasn't really made clear on (I suspect that our sales team sold it to them for a bazillion pounds, and they weren't using it for anything, so we had to justify us selling it to them by doing SOMETHING with it). And because this was literally my first project, I was young and not confident at all, and I wanted to be the guy who just got shit done, I didn't argue.
Inevitably, the project was a turd. It went waaay over budget and time, and didn't work very well. I remember one morning on my way to work seriously considering ploughing my car into a ditch, so that I had a good excuse not to go into work and face that bullshit project.
The good thing is that I learned a lot from that. I decided that kind of fuckery was never going to happen again.
A few months later I had an initial meeting with a potential customer (who I was told would be a great customer to have for bullshit political reasons) - I forget the details but they essentially wanted to build a platform for academic researchers to store data, process it using data processing plugins which they could buy, and commersialise it somehow. There were so many reasons why this was a terrible idea, but when they said that they were dead set on using SharePoint (SharePoint!!!) as the base of the platform, I remembered my first project and what happened.
I politely explained my technical and business concerns over the idea, and reasons why SharePoint was not a good fit (with diagrams and everything), suggested a completely different technology stack, and scheduled another meeting so they could absorb what I had said and revisit. I went to my sales and head of development and basically told them to run. Run fast, and run far, because it won't work, these guys are having some kind of fever dream, it's a clusterfuck in the making, and for some reason they won't consider not using SP.
I never heard from them again, so I assume we dropped them as a potential client. It felt amazing. I think that was the single best thing I did for that company.
Moral of the story: when technology decisions are made which you know are wrong, don't be afraid to stand up and explain why.3
Ever had that meeting where it's expected that you will solve cold fusion, catch rainbows and violate the laws of thermodynamics? Just because you are an expert in your field?
Also beautifully demonstrated here: