Probably unpopular here, but this is a misguided, engineer-centric view of a business. Sales & marketing should absolutely have some leeway on unreleased features, as they have very close relationships with customers and can get early feedback in the realest way possible: "Will the customer pay for it?" Cutting off this avenue is popular for engineers (myself included) but not necessarily good for the long term health of a business.
I happen to agree with the author to an extent. Selling future things rather than what's presently available makes sales a lot easier (which is why reps are often eager to do it), but the true value is created when sales sells what is already there. My father always put it this way: You have to sell what you have.
Particularly for larger or more advanced features, it makes much more sense to run engineering partly in parallel with sales & marketing (with feedback between the two) rather than in serial. Product and innovation cycles in the company are much tighter that way, and more accurate.
Within a year or so, I've had a couple of requests of 'Ok sales is offering X, but honestly, we might order X like 18 more times, and each X might be 12 times bigger than the last X.' Scary. Sure. But you know what? Those were big customers. I went with my team, I made a big plan which included a bunch of technical debt cleanup, and refactoring things towards a cleaner structure for their need and gave sales that as a pitch, and also kinda included whatever they wanted to pay us for as a benefit. We've been paid gold to clean up our code, I tell you. And a number of small customers later, we're just making money off of that.
Walls don't just exist between Dev and Ops, guys.
They should have input (ie. ability to make suggestions) but should no say. The Product Manager, who is in theory supposed to have all the metrics and has talked to all the customers, should be the one making the INFORMED decision based on DATA.
Sales is motivated by making the sale. Period, end of story. They want the sale because it makes them money. There's nothing wrong with that because that is exactly their job description, but it biases their decisions. Its their customer, and they want whatever that specific customer wants because it affects their salary. That's not healthy for the company.
The product manager should have the freedom to make decisions based on what is best for the company and for the large collections of customers. If they need to change the roadmap, which happens OFTEN in real life, they should do that because it's healthy for the company. They shouldn't be held to a feature because some salesperson promised it to a customer. That's how product strategy gets fucked up.
This is taking the most extreme end of the spectrum as a baseline, and suggesting the polar opposite (sales & marketing get no leeway) as a response. There are benefits in the middle of these two extremes, where you can have sales & marketing discussing potential features and also have a well defined strategy from PMs.
There is so much time wasted on this system where I work it's amazing. Some people sit all day updating JIRA with all kind of crap instead of actually doing their job.
At this point I'm starting to get the same feeling towards it as towards SAP.
Confluence is also evil. Not because it's Atlassian, but because wikis have many downsides to go along with the upsides. Everyone can create their own pages, so ... they do. And they don't keep maintaining it. So the amount of "documentation" we have is ever increasing and out of date. And like you say, a few people seem to do nothing but confluence work all day long.
Has anyone found a _good_ way to maintain documentation?
For team members, it's easier and more effective to bob a post-it onto the right white board and explain it during standup. Hosted JIRA is just infuriatingly slow for that workflow, tbh.
For everyone else, yeah. Put in a JIRA ticket, one of us will put in clarifications there. If it's something weird, we'll document steps there and convert them into a runbook later. It's good enough for that.
And by "document" I don't even mean a fancy design doc and pages of spec. Just a few sentences on why something was done, or a couple of copy-pasted command lines used for testing or reproducing a bug can be a big help.
What I have not seen, is evidence that it helps improve the data. So, if you have someone that is good at keeping the data healthy, they can make the tool look amazing. The tool doesn't really help people get there, though.
I don't think there is a universal answer here, yet. :(
I would love to be proven wrong.
This is not a statistically valid way to test the effectiveness of your change.
For example, if you sell toys, and you run an analysis on the week before Christmas, then you make your code change, and then check again on the week after Christmas, you are going to have differences in customer behavior that have nothing to do with your change.
How does this look in practice, in large organizations? Is everyone empowered to freelance on whatever they think will improve said KPIs?
At some point, someone needs to have the power to decide what is being built (hopefully with an eye towards KPI-impact), and others need to fall in line and close some tickets.
