Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

medium.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#21

Post by foobarian »

mful wrote: post #14

> Do I want my team to value the number of tickets closed, or do I want them to value our critical business KPIs? 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…

Well, presumably the tickets you have are there to build KPI-improving features. The people who open the tickets open them for that purpose! At our company even people who "freelance" stuff still open tickets for that work, because it's useful to document stuff and help others learn.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#23

Post by foobarian »

bdcravens wrote: post #8
tyfon wrote: post #4

At first I thought the ticket was going to be "stop using JIRA/Confluence". 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.

I think Jira's knobs and settings can get in the way, but I've found it to be fairly effective when used in a focused way (and recent updates seem to have optimized for that)

I find that it's very effective at providing a "collective memory". People come and go, but as long as they document what they did in a ticket that information is easy to search and can save a lot of effort.

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.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#24

Post by jonathonf »

rootusrootus wrote: post #18
tyfon wrote: post #4

At first I thought the ticket was going to be "stop using JIRA/Confluence". 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.

The most irritating thing I run into with JIRA is that every time our ALM team rolls out a new point release, things subtly change; behavior is a little different, controls moved around, etc. Normally I'm not one to get all bent out of shape when someone moves the cheese, but dang, every. single. release. things just move around for no apparent reason and I have to relearn how to do the exact same task. Confluence is…

> So the amount of "documentation" we have is ever increasing and out of date

Has anyone found a _good_ way to maintain documentation?

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#25

Post by dagw »

dkyc wrote: post #9
ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” 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 thi…

I think this is meant in another way: sales and marketing should never discuss future features with potential customers . Meaning, they should not try to win deals by promising features not yet rolled out, rather than not being involved in internal priorization discussions. 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 w…

I guess it depends a lot on what kind of software you're selling. I used to work at a place that did very niche enterprise products, and if we got 10 new customers in a year that was a really great year. For a large enough potential contract we'd add almost whatever you asked for.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#26

Post by isostatic »

ukulele wrote: post #12
dkyc wrote: post #9

Earlier quoted context omitted.

I think this is meant in another way: sales and marketing should never discuss future features with potential customers . Meaning, they should not try to win deals by promising features not yet rolled out, rather than not being involved in internal priorization discussions. 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 w…

This approach is cutting off a major strategic artery. Sales & marketing can do much more than just pushing what they're given; they should be a valuable pulse on the customer, and the truest feedback you can get for an upcoming feature is whether or not someone will pay you for it. Particularly for larger or more advanced features, it makes much more sense to run engineering partly in parallel with sales & marketing…

Sure, but the conversation should be

Customer: "We want your product to do $FEATURE, there's nothing else that does it / other products that do it have these problems" Sales: "Thanks, we'll have a look at that and see if it's possible in the future"

or

When many customers want $FEATURE, it's something to consider

What shouldn't happen is

Sales: "Buy this product, it's great, and in the future it will have $FEATURE" Customer: "Great, we want $FEATURE, when will it be ready"

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#27

Post by stctgion »

ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” 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 thi…

I have witnessed the case where whole products were created to fill gaps in sales promises on the threat of law suits. It's not a great way to do business, both Dev and the customer end up upset.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#28

Post by tetha »

ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” 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 thi…

I am perfectly happy for sales to have an input into my priorization of my engineering team. Viewing sales, marketing, customer project management as an enemy is not productive.

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.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#29

Post by tetha »

bdcravens wrote: post #8
tyfon wrote: post #4

At first I thought the ticket was going to be "stop using JIRA/Confluence". 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.

I think Jira's knobs and settings can get in the way, but I've found it to be fairly effective when used in a focused way (and recent updates seem to have optimized for that)

Our JIRA is kinda our external memory and our input for external teams.

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.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#30

Post by toomuchtodo »

jonathonf wrote: post #24
rootusrootus wrote: post #18

Earlier quoted context omitted.

The most irritating thing I run into with JIRA is that every time our ALM team rolls out a new point release, things subtly change; behavior is a little different, controls moved around, etc. Normally I'm not one to get all bent out of shape when someone moves the cheese, but dang, every. single. release. things just move around for no apparent reason and I have to relearn how to do the exact same task. Confluence is…

> So the amount of "documentation" we have is ever increasing and out of date Has anyone found a _good_ way to maintain documentation?

Hire people to work on documentation.
Post reply on HN