14

Our sales are selling stuff without consulting the technical team. I am about to lose my temper - this is a difficult situation because the CEO seems to be siding with the sales. We already had meetings and agreed on quick fixes as emergencies because the contracts specified these functionalities that don't exist. We have legal accountability for contracts signed by us, but the sales people do it again and the CEO does not punish them.

Another problem is that I have current tasks at queue and these developments are not my primary function. All this makes my primary tasks take longer. The CTO and CEO are aware of this and they are ok with delaying my primary tasks, but it frustrates me that the sales does not consult me or the CTO. My role is dev lead but there's no current PM for this product so the sales does need to consult me.

Is adjusting my milestones the only thing I can do?

Improve this question
8
  • 4
    Here I thought it was just MY company doing that. The sales team is always selling product based on what we will be programming next month.
    – Keith
    Commented Jun 27, 2019 at 17:28
  • You can't change what other people do; you can only change how you prepare for what you know they will do, and how you react when they inevitably do it. And they will do it; it's the nature of the Sales department to promise the moon if it will nail a sale.
    – shoover
    Commented Jun 27, 2019 at 18:14
  • Please don't lose your temper. (You sound pretty much in danger of this, plus you wrote it yourself : )
    – Helen
    Commented Jun 27, 2019 at 18:24
  • 30
    A salesman and an engineer go bear hunting. After they get to their cabin in the woods, the engineer lays out all of his hunting equipment and spends an hour methodically checking it over for correct operation. During this time the salesman has been absent. Suddenly the front door of the cabin flies open and in runs the salesman with a bear chasing him close behind. As the salesman heads for the cabin's back door he calls out to the engineer - "I've caught the first one! You deal with it while I go after the next one".
    – Peter M
    Commented Jun 27, 2019 at 21:01
  • @PeterM that's a great analogy except for the amount of danger each character is in
    – Nacht
    Commented Jun 28, 2019 at 1:30

5 Answers 5

Reset to default
15

Been there. Done that.

First of all, remember that your entire company has one purpose which is to sell your product(s)/service(s). If your company is not selling (at a profit) it ceases to be a company and everyone does not have a job.

That being said, what you've got going on is very frustrating (I've been in your place). Sales making promises without development input must stop.

  1. Have a product road map. This can be high-level. Something along the lines of "Feature xyz will be available in the 3rd quarter of 2019. Feature abc will be available in November 2019. This will also include the following big-fixes...". Then, when sales sells a feature/upgrade point them back to the road map.

  2. Always give alternatives. This is talking in business language to the business. If one salesperson makes a promise without development by-in then give them an alternative. "Ok. We can do your rush job for this new feature by xx/xxxx. This means that promised feature xyz will be delayed. Please confirm with your management that this is a acceptable trade-off. I will confirm with my management". Of course they will want both. You need to give the time/effort with the resources available for analysis, design, coding and testing.

For both of these you need to get management (at least CTO) backing. If you can't get this then it's time to look for a new job. Your team will be blamed as the one affecting sales. Unfair. Yes. Reality. Also yes.

Good luck.

Improve this answer
6
  • Thanks for the answer, what do you think it would happen if for example: say this feature takes 1 week but I tell them it's done in 2 months clients get angry and sales are blamed for it?
    – user86742
    Commented Jun 27, 2019 at 18:38
  • 4
    Don't play games, you're both working for the same company and you both have the same goal. You must be a team player and, eventually, teach them they also need to be.
    – Adriano Repetti
    Commented Jun 27, 2019 at 18:56
  • 2
    @RobertoTorres That may not be feasible long-term. There are lots of developers out there, and when they find one that doesn't pad the schedule that way you may find yourself replaced or marginalized. Either you will seem sub-par, or the new person will seem great, and in either case your leverage is gone.
    – Upper_Case
    Commented Jun 27, 2019 at 20:19
  • I have a lot of leverage because the supply is extremely low in my city, we have like 5 vacancies that it's been open for like a year and a half, we're struggling to even find juniors do you guys think it's still a bad idea to get into the politics game?
    – user86742
    Commented Jun 27, 2019 at 20:41
  • 2
    @RobertoTorres It's not about "getting into the politics game", it's about pursuing a strategy that is likely to have significant side effects which are not in your favor. If you don't like your job, quit and get a different one. If you do like your job, don't erode your reputation by unilaterally deploying easily-disprovable lies to cost your employer time, money, market share, and good will with clients in exchange for modest benefits to yourself alone. Other options to address the situation exist, and many of them are probably better than this one.
    – Upper_Case
    Commented Jun 27, 2019 at 21:25
10

I'm going to give a bit of an ugly answer:

  1. You don't know what your primary function is
  2. Your beef isn't with the Sales Department.

Let me explain what I mean by that.

You mention that you keep getting pulled from your "primary function", and that your CEO and CTO are fine with this. Well... no. If the CEO and CTO are both saying they want you to spend most of your time working on XYZ... you can't call something else your "primary function". You may want it to be your primary function, but ultimately the CEO/CTO are setting your priorities. They get to decide what your primary functions are while you work for the company. Developing new features requested by sales is one of your primary functions.

Second, your Sales team isn't actually doing anything wrong, not exactly. If the CEO is okay with the Sales team deciding what the priorities are for future development, and the Sales team isn't promising anything undeliverable, and the CEO is approving of the Sales team actions? Then the Sales team isn't overstepping: they've been given the authority to decide what features should go into future releases. Getting mad or trying to change the behavior of anyone on the Sales team is pointless; within the current company dynamic, they're not actually doing anything wrong.

So, going forward?

First up, instead of focusing on the Sales team, build a case for why your team would be an asset for planning of future development - and try to convince the CEO/CTO that you need to be involved. Because, right now, they don't think you are - if they did, they wouldn't let the sales team decide future functionality without you.

Second, change your mental attitude on the process. Between the tenor of your question, your mentioning of frustration, and your comment asking if you should sabotage the sales team? You're spinning your wheels in a way that's neither helpful to yourself or to your company. Instead of focusing on "But this isn't what I want my priority to be!" - focus on what your sprint tasks are, and do them as good as you possibly can.

... actually, change the order on those. It'd be tough to convince people you'd be an asset to strategic planning while you're in the mindset that sabotaging the sales team is a good idea.

Improve this answer
3
  • 3
    Sales team isn't actually doing anything wrong are you sure about this? what if the feature takes me 6 months? the customer already paid and they are being charged monthly
    – user86742
    Commented Jun 27, 2019 at 21:38
  • 2
    You missed the "... if they're not promising anything undeliverable." Which, to be fair, you didn't really talk about in your post. You were complaining about having to do emergency fixes, that you weren't consulted, and that you were being taken away from your primary function. Put another way: you'd still be angry if they only promised deliverables that took you away from what you want to be doing.
    – Kevin
    Commented Jun 27, 2019 at 21:52
  • 1
    @RobertoTorres I agree with Kevin. All you can do is inform the sales team and CEO of the risk (over promising a feature or deadline to the client which is unachievable may lead to the client leaving / taking legal action). If they want to mitigate the risk they should engage your team for an estimate before making a deal. Then it is up to them
    – Daveo
    Commented Jun 28, 2019 at 3:20
2

Roll with it.

Pretty much all advancement in high-tech products and services since about 1945 has been driven by overenthusiastic salesmen promising overexcited customers things that don't yet exist but obviously should. If you sales force doesn't do this, at least sometimes, then your company will take its place in history alongside New Departure Inc., universally accepted as the best buggy whip maker on the planet.

So don't lose your temper over such a natural -- and valuable -- phenomenon.

Understand that a company like yours must balance its investment in responding to market events with its investment in future product development. A company that exalts its developers and scorns its salesmen will fail because nobody will know that they have the best products. A company that exalts its salesmen and scorns its developers will fail because everybody will know that they have the worst.

"the CTO and CEO are aware of this they are ok with delaying my primary tasks"

Notice that they are not asking you to cancel your development tasks. Evidently your company is making the effort to find a proper balance. Contribute as best you can to this effort.

I recommend that you look for opportunities to leverage the apparent emergency nature of the sales-driven events into requests for additional resources. Do a good job husbanding these resources and once the emergency is over you can apply them to future development projects.

Improve this answer
4
  • 3
    No, sales teams selling something that developers can't deliver is neither normal, nor sustainable. It's one thing to shift focus / reprioritise based on sales demands and it's another to constantly lie to your customers. The former must be done with dev lead input, the latter is driving company into the grave.
    – Mavrik
    Commented Jun 28, 2019 at 3:20
  • @Mavrik: You have mendaciously substituted "something that developers can't deliver" for the actual topic under discussion, which is "something that developers don't have yet".
    – A. I. Breveleri
    Commented Jun 28, 2019 at 3:49
  • 2
    Yes, that's because developers need to be consulted so the difference between "can't deliver" and "don't have yet" can be resolved. It seems that there's a breakdown of corporate communication on that channel. Unfortunately very common, but still very damaging.
    – Mavrik
    Commented Jun 28, 2019 at 6:44
  • @Mavrik: You're right that it's not a sustainable or normal business practice. But it's also not something that the developers should be fixing. They can only alert those responsible for making those decisions. If management wishes to lie to the customers (or they let Sales do so), that's their decision. Especially when it reaches a point of willful lying, not just because management is unaware, you can't do anything about it as a developer. You have the same choice that you always had: work at the company or don't.
    – Flater
    Commented Jun 28, 2019 at 14:10
1

Schedule a meeting with the CTO,CEO, and head of sales.

Come to the meeting with hard facts. Dates, requirements, cost the company for delays etc.

Lay it all out, and then request some definitive direction as to how these kinds of things should handled in the future.

Either the the CTO, or CEO will put a stop to it and you are done, or if they side with sales, push to get an official policy on how to proceed.

If they side with sales, and you are not willing to work in the new policy rules, update your resume/cv and start looking to move on.

Improve this answer
0

It's unfortunate but the point to emphasise is not that it's annoying or that your milestones need to be adjusted. I assume that CEO is aware of that and this is his current policy. Unfortunate but JUSTIFIED, however compromises are - by definition - tradeoffs: what you gain in one side is always paid somewhere else.

What you have to highlight, if it's true in your case, is that code quality will suffer if you need to constantly face unscheduled emergencies. Why?

  • Quick fixes often are patches to remove a symptom without removing the root cause of the problem.
  • Unscheduled features may do not fit well in the current architecture and if you're addressing an emergency then you often do not have the time to properly design and test something new.

Why it's bad?

  • If you do not address the root cause then you'll pile up more and more quick fixes.
  • You accumulate technical debt.

Which are the long term effects?

  • Developers are more stressed and dissatisfied, there is an higher risk of burn out and higher turnover. Productivity will fall.
  • Quality will decrease causing an exponential number of real bugs.
  • Because of tech debt it will take exponentially more time to deliver a new feature. In a couple of years what should take a week will take two (or more). With enough time the entropy will win.
  • Any estimation will progressively become less accurate, without reliable estimations there can't be any any business plan. Without a business plan the sales won't be able to do their job.

Now that you know what you're looking for, you're able to extrapolate actual numbers (or good approximations). Go to the CEO and explain the actual BUSINESS PROBLEM. Better if you can also present a viable procedure to address the unavoidable emergencies.

Note that the solution might also be to adopt a completely agile approach and do not schedule anything beyond a PI.

Improve this answer

You must log in to answer this question.