Xjyuk

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?

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.

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.

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.

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.

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.