From $0-100million with no sales people. Atlassian's commandments for startups.(blog.businessofsoftware.org)
blog.businessofsoftware.org
From $0-100million with no sales people. Atlassian's commandments for startups.
http://blog.businessofsoftware.org/2011/09/from-0-100million-with-no-sales-people-the-atlassian-10-commandments-for-startups.html
112 comments
Do people generally like Jira and/or Confluence? I know they are popular in the enterprise. However, I've used them, and I consider them pretty horrible. Not sure if I'm just the odd man out on this though.
Hate them so much.
I had to deal with both products at my last company and maybe it was just how they set it up, but entering a bug into Jira was ridiculous. Finding anything was worse. It was probably the most user unfriendly piece of web software I've ever had to use.
Confluence? Ugh. The WYSIWYG editor was questionable at best. I had hours of fun cleaning up pages with big tables that were edited by multiple people. And seriously, a hierarchical wiki? Do you know what you get when you have a hierarchical wiki? A wiki that has almost no inner links because no one can remember what the path is to any document.
Again, it could have just been how they set it up, but I just feel like they threw every feature and the kitchen sink into that product in the name of "flexibility."
I had to deal with both products at my last company and maybe it was just how they set it up, but entering a bug into Jira was ridiculous. Finding anything was worse. It was probably the most user unfriendly piece of web software I've ever had to use.
Confluence? Ugh. The WYSIWYG editor was questionable at best. I had hours of fun cleaning up pages with big tables that were edited by multiple people. And seriously, a hierarchical wiki? Do you know what you get when you have a hierarchical wiki? A wiki that has almost no inner links because no one can remember what the path is to any document.
Again, it could have just been how they set it up, but I just feel like they threw every feature and the kitchen sink into that product in the name of "flexibility."
I had a very negative experience with Jira and Confluence. The context was a very small development team (around 5) in a very small company (under 50), and some very inexperienced administrators, so maybe some of those are key factors. And again, I want to emphasize that no one really knew what they were doing with it, including me, so maybe in 20 years I'll have better context that lets me appreciate what Jira was doing for us.
Certainly when I read ghshepard's several comments, I think "wow, okay, if you're a much bigger heavier bloatier organization, with much more byzantine needs from an issue tracker, maybe this thing actually has some value!"
I eventually got superuser privileges, and spent a lot of time myself trying to figure out how to beat it into getting out of our way and just tracking some frigging tickets. That's a week of my life I'll never have back, with no benefit to anyone.
At some point, management decided to double-down, and renew our license, to get an upgrade (I think to Jira 4.0, since this decision was late 2009). Oh my god. For one thing, we wasted SO MUCH TIME on that upgrade. And for another, the dashboard started taking 30-60 seconds to load, because it's suddenly full of clever (read: not clever, not performant) AJAX. And I still don't remember getting anything out of it.
Please, Jira, just get the hell out of our way!
At this point, if Jira was the only product on the market, I'd rather use one huge text file to track tickets, shared via svn or git. It would offer less useful features, sure, but it'd also offer way way less pain.
The main argument anyone could give was that it would have features not present in our other issue tracker, RT 1.0. Uh, y'think?
Short summary of my experience: on my small team, in a small company, with no experienced hands to manage it quickly and efficiently, Jira is a big bag of slow-down pain, with nothing to recommend it, and I'd rather use NO tool than use THIS tool. $10 for 10 users sounds like about $1000 too much.
Oh, and don't get me started on Confluence. I mean, less pain than Jira, but ZERO useful features (relative to free pain-free alternatives). Why would you ever choose this over Mediawiki? My new company uses ikiwiki, and that's beautiful, and it clocks in under 25kloc of Perl.
Certainly when I read ghshepard's several comments, I think "wow, okay, if you're a much bigger heavier bloatier organization, with much more byzantine needs from an issue tracker, maybe this thing actually has some value!"
I eventually got superuser privileges, and spent a lot of time myself trying to figure out how to beat it into getting out of our way and just tracking some frigging tickets. That's a week of my life I'll never have back, with no benefit to anyone.
At some point, management decided to double-down, and renew our license, to get an upgrade (I think to Jira 4.0, since this decision was late 2009). Oh my god. For one thing, we wasted SO MUCH TIME on that upgrade. And for another, the dashboard started taking 30-60 seconds to load, because it's suddenly full of clever (read: not clever, not performant) AJAX. And I still don't remember getting anything out of it.
Please, Jira, just get the hell out of our way!
At this point, if Jira was the only product on the market, I'd rather use one huge text file to track tickets, shared via svn or git. It would offer less useful features, sure, but it'd also offer way way less pain.
The main argument anyone could give was that it would have features not present in our other issue tracker, RT 1.0. Uh, y'think?
Short summary of my experience: on my small team, in a small company, with no experienced hands to manage it quickly and efficiently, Jira is a big bag of slow-down pain, with nothing to recommend it, and I'd rather use NO tool than use THIS tool. $10 for 10 users sounds like about $1000 too much.
Oh, and don't get me started on Confluence. I mean, less pain than Jira, but ZERO useful features (relative to free pain-free alternatives). Why would you ever choose this over Mediawiki? My new company uses ikiwiki, and that's beautiful, and it clocks in under 25kloc of Perl.
Until recently, I hated Jira, but my current company uses Jira + Greenhopper, and I actually really like it. Greenhopper gives you a sort of PivotalTracker like interface, except that I've always found PivotalTracker to be a good idea, poorly implemented.
We also use Crucible, which is a great code review tool, and Confluence, which I don't really care for, but I don't really dislike it any more than any other wiki software.
We also use Crucible, which is a great code review tool, and Confluence, which I don't really care for, but I don't really dislike it any more than any other wiki software.
I've never had any problems with Jira (about 3 months' worth of experience) but Confluence is so broken when trying to paste content into an article.
I use and manage our JIRA instance in a small tech group inside a large non-profit. Probably only ever had 10 users. I love it, and our team has grown to be more efficient as a result of its use.
Now, Confluence? Not a big fan. Tried it, ditched it.
Now, Confluence? Not a big fan. Tried it, ditched it.
I've used both tools for two start-ups now. I can't imagine using anything else (well, Redmine is a nice free tool). But you're not in the minority in startups. I personally can't understand how anyone is productive with PivotalTracker, Lighthouse, or GitHub Issues (at least the older one). But people are and to each his own.
FWIW, one of the reasons I love both of them is they're the only tools of their type that I've been able to throw a non-tech person at and they can use. When roping the spouses into helping out, that counts for a lot.
FWIW, one of the reasons I love both of them is they're the only tools of their type that I've been able to throw a non-tech person at and they can use. When roping the spouses into helping out, that counts for a lot.
I agree with you, but as a developer, I prefer these types of tools to get out of the way. Jira and Confluence seem to be written for managers that can live in them. For them, I'm sure the experience is much different.
Even as a developer, I think that Jira and Confluence are outstanding tools. They do a great job of allowing enough customization (easily) to keep them from detracting from your workflow.
What did you find particularly horrible about them, and what tools do you think do a better job at those aspects?
What did you find particularly horrible about them, and what tools do you think do a better job at those aspects?
We use Jira at our company and it's probably one of the best issue tracking systems I've tried. Confluence is alright but I think that there are a few open source wiki packages that are at least as good, if not better.
Which free ones do you like? My biggest Confluence draws are rich text editor (nice for one-off pages), attachment indexing, and attachment versioning. But I'm always open to trying something else.
For what it's worth - we have a huge new release of Confluence coming out in 4 days time. We've also released an infographic about the history of collaboration (and I'm still not able to find the easter egg):
http://www.atlassian.com/en/communication-through-the-ages-i...
Confluence 4 has a completely rebuilt rich-text editor with autocomplete - the ease of use of a WYSIWYG editor with the speed of an IDE. Love your thoughts on it when it ships.
Confluence 4 has a completely rebuilt rich-text editor with autocomplete - the ease of use of a WYSIWYG editor with the speed of an IDE. Love your thoughts on it when it ships.
Do you have any plans, in Jira, to allow sub-tasks to have their own sub-tasks. Only having one level of nesting is extremely restrictive and an annoyance we come up against a lot. On the whole though I quite like Jira, particularly its integration with FishEye.
FishEye is also pretty decent although it chokes a lot with the size of our repository - we have a lot of code and a lot of branches which have really pushed the size up. A few JS optimisations would be nice as well - it can really chew up the CPU sometimes.
FishEye is also pretty decent although it chokes a lot with the size of our repository - we have a lot of code and a lot of branches which have really pushed the size up. A few JS optimisations would be nice as well - it can really chew up the CPU sometimes.
Thanks for the feedback. Letting arbitrary levels of nesting is one of the things that keeps me, and the JIRA product manager up at night.
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.
It's interesting to hear that it's actually a user experience, rather than a technical problem. I was assuming there was some dodgy database code to blame! I will install the 3rd party plugin and see how it works for us though.
Our branches probably put us in the hundreds of millions of LoC category. It's unfortunate that for a long time we were prepared to allow each of our customers a separate branch for each release - each of which potentially has active development on it (not a real branch I know as we don't intend to ever re-merge them). As such we have a lot of code that potentially needs supporting. I'm not actually sure how often they are searched on as I'm lucky enough to work on newer parts of our software but the idea of dropping them from FishEye didn't go down too well.
I believe the guy who did the setup spent some time messing around with performance - I have no idea if he did everything right but he's a pretty smart guy.
I'll definitely take a look at the most recent release though, thanks for the tip.
Oh and thanks for taking the time to reply to my unsolicited feedback!
Our branches probably put us in the hundreds of millions of LoC category. It's unfortunate that for a long time we were prepared to allow each of our customers a separate branch for each release - each of which potentially has active development on it (not a real branch I know as we don't intend to ever re-merge them). As such we have a lot of code that potentially needs supporting. I'm not actually sure how often they are searched on as I'm lucky enough to work on newer parts of our software but the idea of dropping them from FishEye didn't go down too well.
I believe the guy who did the setup spent some time messing around with performance - I have no idea if he did everything right but he's a pretty smart guy.
I'll definitely take a look at the most recent release though, thanks for the tip.
Oh and thanks for taking the time to reply to my unsolicited feedback!
Hey Scott, I guess you don't need to spend too much time asking your customers for feedback when they so freely give it. Good skills!
What would be nice is if you could have some sort of warning in place for hosting Confluence instances letting the day-to-day users know that a major change is coming. It's pretty disruptive.
very nice, "Angry Nerds"
I don't have complex needs, but I like Redmine [1], and run it on a local box.
[1]http://en.wikipedia.org/wiki/Redmine
[1]http://en.wikipedia.org/wiki/Redmine
Jira and FishEye are a really good combination. Love it. Haven't been really keen on Confluence but it's a decent tool too.
Another good thing is that you can integrate Jira with Eclipse via Mylyn, and manage all the tasks you're working on without even opening Jira.
After using it extensively, I hate it with a passion. I don't believe they are conducive to development workflow at all, but they are built for middle managers.
Name a single product that works better for software development organizations as a generic issue tracker?
What I'm finding about the hate-on I'm seeing from some people about Jira, is that they CLEARLY have never, ever been forced to deal with the pain that is remedy as an issue tracker. Jira is like a breath of fresh air, a touch of heaven, compared to that product. I have a 50 bullet-point list of unresolved issues with Remedy. My issues with Jira are tiny-corner cases problems that 99% of users wouldn't even notice.
What I'm finding about the hate-on I'm seeing from some people about Jira, is that they CLEARLY have never, ever been forced to deal with the pain that is remedy as an issue tracker. Jira is like a breath of fresh air, a touch of heaven, compared to that product. I have a 50 bullet-point list of unresolved issues with Remedy. My issues with Jira are tiny-corner cases problems that 99% of users wouldn't even notice.
My issues with Jira are:
- does not handle workflow well
- does not clearly manage changesets
- does not clearly track codebase changes at an audit level
- allows too much meaningless configuration and reporting
TFS is much better solution and it's not even the best on the market.
Serena is a much better solution and it's not even as good as TFS.
Jira is not an enterprise solution. It's a toy for non-developers.
And if you are a public company, you sure as HELL better not be thinking that's an audit standard that will satisfy SOX.
- does not handle workflow well
- does not clearly manage changesets
- does not clearly track codebase changes at an audit level
- allows too much meaningless configuration and reporting
TFS is much better solution and it's not even the best on the market.
Serena is a much better solution and it's not even as good as TFS.
Jira is not an enterprise solution. It's a toy for non-developers.
And if you are a public company, you sure as HELL better not be thinking that's an audit standard that will satisfy SOX.
Actually - I agree with you about Jira not being an enterprise solution - it's fundamental flaw (and I'm being 70% serious here) is that it's a $10K package that can be set up in 10 minutes in a market where enterprise tools like Remedy go for $750K + a couple headcount (that usually cost $75K-$125K/year depending on your geography) and took us 3 months to do an out-of-the-box-no-customization ITIL deployment. I also agree with you that it's probably perceived as being weak on the SOX/Audit standards.
But some of your comments are describing features of an SCM "managing changesets", "tracking codebase" - TFS/Serena are full fledged SCM suites - and, I'll agree with you right now, they are definitely perceived as enterprise worthy systems.
But Jira is a lightweight issue tracker. It can link issues to an SCM (and indeed, fisheye/crucible are great additions that we use to connect to perforce) - but, at it's heart, it's an issue tracker.
Re: Workflow - Yes - could be more sophisticated. In particular, last time I tried, I couldn't find a way to (easily) gate an issue with multiple voters - that is, if I had an issue that required approval by five departments before it could move to the next stage - couldn't do it in Jira, and that's a pretty common use case for Workflow - so they have a ways to go. With that said - there are workarounds - JRA-10042 was a way of delivering equivalent functionality. Also - The 4.4 Visual Workflow Designer is elegant (and included in the base package of Jira)
Re: Meaningless Reporting - Problem is, what one person's "Meaningless report" is another person's "Must have" feature.
But, the overall theme of your comment, that Jira is not a heavy weight enterprise product - is accurate. It's functional, fast, and has a beautiful interface, and, for $12,000 for the unlimited user Greenhopper+jira package, is basically being given away for free to companies, and, at $10 for a 10 user license - is for all intents and purposes, free for individuals.
I've thought long and hard about this, and (to bring this back on track) - I've decided that Jira is such a beautiful product, is so elegant, and is so versatile, precisely because Atlassian _doesn't_ charge very much for it and doesn't have sales people or "Technical Account Managers" - large corporations paying seven or eight figures for software, expect to have some ability to influence the feature set, and, if you just charged someone $10mm+ for a product, you feel somewhat obligated to do so. And so your software ends up being this huge crappy enterprise system that yes, is fully SOX compliant, and is completely ITIL certified - but honestly - is just an absolute mess.
I'll state my position: I don't think there is a commercial issue tracker that I've seen, that can track issues, as effectively and beautifully, as Jira can, at any price.
But some of your comments are describing features of an SCM "managing changesets", "tracking codebase" - TFS/Serena are full fledged SCM suites - and, I'll agree with you right now, they are definitely perceived as enterprise worthy systems.
But Jira is a lightweight issue tracker. It can link issues to an SCM (and indeed, fisheye/crucible are great additions that we use to connect to perforce) - but, at it's heart, it's an issue tracker.
Re: Workflow - Yes - could be more sophisticated. In particular, last time I tried, I couldn't find a way to (easily) gate an issue with multiple voters - that is, if I had an issue that required approval by five departments before it could move to the next stage - couldn't do it in Jira, and that's a pretty common use case for Workflow - so they have a ways to go. With that said - there are workarounds - JRA-10042 was a way of delivering equivalent functionality. Also - The 4.4 Visual Workflow Designer is elegant (and included in the base package of Jira)
Re: Meaningless Reporting - Problem is, what one person's "Meaningless report" is another person's "Must have" feature.
But, the overall theme of your comment, that Jira is not a heavy weight enterprise product - is accurate. It's functional, fast, and has a beautiful interface, and, for $12,000 for the unlimited user Greenhopper+jira package, is basically being given away for free to companies, and, at $10 for a 10 user license - is for all intents and purposes, free for individuals.
I've thought long and hard about this, and (to bring this back on track) - I've decided that Jira is such a beautiful product, is so elegant, and is so versatile, precisely because Atlassian _doesn't_ charge very much for it and doesn't have sales people or "Technical Account Managers" - large corporations paying seven or eight figures for software, expect to have some ability to influence the feature set, and, if you just charged someone $10mm+ for a product, you feel somewhat obligated to do so. And so your software ends up being this huge crappy enterprise system that yes, is fully SOX compliant, and is completely ITIL certified - but honestly - is just an absolute mess.
I'll state my position: I don't think there is a commercial issue tracker that I've seen, that can track issues, as effectively and beautifully, as Jira can, at any price.
RT from Best Practical.
RT is a nice ticketing system, but Software Development Organizations run into a wall pretty much immediately (as in, once they grow beyond 40 or 50 employees) because of their lack of support for more sophisticated software development methodologies. The plugin and developer community is limited, and there is almost no commercial third party support for an ecosystem on top of RT.
Finally, it may have changed since the last time I used it (it's been about 8 years), but it had limited issue<-->code checkin integration (which is critical) and I don't even think Agile tools are part of it's vocabulary.
Nice ticketing tool, and, if Jira wasn't available in a 10 user license version, RT and Trac would be on my shortlist for quick-n-dirty ticketing tools for smaller software devel shops.
Finally, it may have changed since the last time I used it (it's been about 8 years), but it had limited issue<-->code checkin integration (which is critical) and I don't even think Agile tools are part of it's vocabulary.
Nice ticketing tool, and, if Jira wasn't available in a 10 user license version, RT and Trac would be on my shortlist for quick-n-dirty ticketing tools for smaller software devel shops.
You asked to name a "generic issue tracker", not a "sophisticated software development methodology tracker".
With 142,000 "generic issues" tracked to date (mostly software and network support, with 1 to 100s of replies per issue), we haven't run into a wall yet.
We don't use RT as our primary software dev tracker. We use it as a generic issue tracker.
With 142,000 "generic issues" tracked to date (mostly software and network support, with 1 to 100s of replies per issue), we haven't run into a wall yet.
We don't use RT as our primary software dev tracker. We use it as a generic issue tracker.
I'll agree with you - if what you are looking for is straight forward ticketing and issue tracking, RT rocks. Quick question (it's been a while) - do they have a free-text search engine like lucene that lets you search all the comments/tickets? That's probably near the top of my list of things I love about Jira - it's insanely fast search capability of all the comments/summaries.
Redmine
Trac, Redmine, Flyspray, Mantis, JetBrains YouTrack. Even Sharepoint and the ASP.Net issue tracker starter kit.
We use Jira with the Greenhopper Agile planning plugin at our startup and that's freaking awesome for planning iterations and releases. FishEye and Crucible are great for code reviews. As soon as we hit 10 users, Atlassian will have an additional paying customer.
I had a partner organisation insist on Jira for their project a few years back. It'll obviously have changed since then and much might be down to user-specific customisations, but I hated it. Awkward, obstructive, poorly thought out workthrough that mostly involved jumping through hoops and provided us very little actual value.
My main memory actually was of poor fit and finish. Just a tiny thing but every time I logged in, no matter how, it offered to remember my login. Every time, I clicked that box in hope. It never once worked.
My main memory actually was of poor fit and finish. Just a tiny thing but every time I logged in, no matter how, it offered to remember my login. Every time, I clicked that box in hope. It never once worked.
Sorry that 'remember me' didn't work for you. It could have been a bug with how it was set up, or equally likely - a bug in some edge case that you were hitting.
I can assure you that it works now :)
I can assure you that it works now :)
A second vote for the edge-case above. I used JIRA for six months until a few months ago and 'remember me' never worked well for me either.
What is the default timeout on 'remember me' in JIRA, if you'd know please?
What is the default timeout on 'remember me' in JIRA, if you'd know please?
'Remember Me' works fine for me on JIRA v4.3.3
Well, that's a start at least - I'm nothing to do with that project any more to verify if the workflow is any better and of more value to developers, but obviously that would be a larger concern and one I'd hope had also been addressed :-)
I've used Jira, Confluence, and testing out FishEye. We use Crowd for single sign on stuff. I really like fisheye because we have tons of different projects on different repositories. Confluence is nice although it took some getting used to. Jira was awkward, but we're still running Jira 3 and we'll be upgrading soon. For what it's worth, Jira is the best issue tracking software I've used on the web.
I hate Jira and Confluence too. Most in our team hate it. I'd rant but I've wasted too much time on that.
Having gone through half a dozen different issue trackers in my career, Jira is the first one I've fallen unreservedly in love with - and I'm fascinated as to why others wouldn't feel the same way.
Is it a Jira issue, or has someone created an overly restrictive workflow, complex data entry screen?
I'm not sure if you can blame the product for how it's configured by it's users, particular when the default configuration is pretty bog simple and easy to use.
What about Jira do you hate? What about other members of your team?
I'm genuinely interested - maybe I'll see something in a different light.
Is it a Jira issue, or has someone created an overly restrictive workflow, complex data entry screen?
I'm not sure if you can blame the product for how it's configured by it's users, particular when the default configuration is pretty bog simple and easy to use.
What about Jira do you hate? What about other members of your team?
I'm genuinely interested - maybe I'll see something in a different light.
I don't know much about the details of our Jira installation. Couldn't tell you what plugins there are or whatever. I've just been using what is there. For me it is all the little things that I need to do regularly that are real annoying.
- When I login the widgets that show me what issues I have are pretty useless. They don't show my progress/logged work, they don't show what you last worked on. The priority icon is kinda tiny. So I feel like I am having to track some information manually or in my head.
- If you start work on a new task and try to log work, the log work action is hidden under a menu. And when you do log work, it doesn't automatically set the issue to "In progress".
- Creating new issues is also a bit annoying. First it's hidden in a menu. Then it is a 2 step process. The first form is completely silly. You have 4 inputs, Project, Type, Next and Cancel. Did that really warrant it's own page?
- Subtasks are also a bit crazy. Once you enter your subtasks it's hard to reorganise and prioritise your tasks. It's actually simpler to use vim or a text editor when planning out work and then enter the issues into Jira when you are satisfied.
- No subtasks of subtasks!
- When I login the widgets that show me what issues I have are pretty useless. They don't show my progress/logged work, they don't show what you last worked on. The priority icon is kinda tiny. So I feel like I am having to track some information manually or in my head.
- If you start work on a new task and try to log work, the log work action is hidden under a menu. And when you do log work, it doesn't automatically set the issue to "In progress".
- Creating new issues is also a bit annoying. First it's hidden in a menu. Then it is a 2 step process. The first form is completely silly. You have 4 inputs, Project, Type, Next and Cancel. Did that really warrant it's own page?
- Subtasks are also a bit crazy. Once you enter your subtasks it's hard to reorganise and prioritise your tasks. It's actually simpler to use vim or a text editor when planning out work and then enter the issues into Jira when you are satisfied.
- No subtasks of subtasks!
I strongly dislike Jira. Everything about it is unwieldy. It's like a car with a top speed of 30mph, with a lever for each and every moving part of the car. Too many pieces of it are customizable, and all of the things which can be customized must be customized for anything to work. The amount of effort it takes to use Jira is almost enough to write your own issue tracker.
Also, a fresh JIRA install with no issues, projects, or anything has a memory footprint of over 0.6GB.
I don't know why people use it, but people do. My guess is that all the effort it requires provides a simulacrum of control and productivity.
Also, a fresh JIRA install with no issues, projects, or anything has a memory footprint of over 0.6GB.
I don't know why people use it, but people do. My guess is that all the effort it requires provides a simulacrum of control and productivity.
You can take Jira from "www.atlassian.com" to a fully running instance with a baseline Software Development Issue tracking Project in 15 minutes.
I will give you this - _should you chose to_ fully mastering it's screens, issue types, screen schemes, issue type screen schemes will take the better part of few hours to completely map in your head. Jira gives you amazing flexibility to do almost anything you want on the issue type level, but with that flexibility, comes an very complex model.
When I first encountered it, I was exasperated that I had to take those couple hours to draw the hierarchy and map it out in my head - but now that I know It, I'm happy it's there.
I will give you this - _should you chose to_ fully mastering it's screens, issue types, screen schemes, issue type screen schemes will take the better part of few hours to completely map in your head. Jira gives you amazing flexibility to do almost anything you want on the issue type level, but with that flexibility, comes an very complex model.
When I first encountered it, I was exasperated that I had to take those couple hours to draw the hierarchy and map it out in my head - but now that I know It, I'm happy it's there.
farkas! If you read this: you can solve all the real problems I have with JIRA by making all but the most commonly-used pieces of its UI be harder to find. You can find out which pieces to hide with user testing.
Interestingly - I just had this exact same feedback at a pub in Amsterdam with one of our customers.
I agree there is improvement here. But in my years of experience with JIRA, I do find that most software development teams approach things differently, and so there is no 'one size fits all' for most dev teams.
One team wants saved filters to be front and centre, another RSS feeds. One user creates a hundred issues a day (usually QA), whilst others rarely create issues at all.
I agree there is improvement here. But in my years of experience with JIRA, I do find that most software development teams approach things differently, and so there is no 'one size fits all' for most dev teams.
One team wants saved filters to be front and centre, another RSS feeds. One user creates a hundred issues a day (usually QA), whilst others rarely create issues at all.
No they are absolutely abysmal. Stay away for your own sanity.
My FINAL experience with JIRA + Fisheye + Greenhopper + Crucible nearly made me cry. This is on an 8 core Xeon, 12Gb RAM, 15k SAS RAID and Ubuntu 10.04LTS and Sun hotspot VM.
Random failures, null pointer exceptions all over the place that took us out for a couple of days, incredible memory usage, 8xCPUs jammed at 100% due to race conditions, Fisheye only barely just about works in Google Chrome because it's so slow, useless paid support, horridly slow and inconsistent UI, MyISAM tables causing relation failures (!!!!), don't even talk to me about their plugin management - it's a crock of shit.
I couldn't recommend it at all. It's worse than Visual Source Safe.
That's as a JIRA admin. As a JIRA user, I get people saying "can we have Trac back please".
If anyone at Atlassian is listening, please sort your product out. It's not fit for purpose.
My FINAL experience with JIRA + Fisheye + Greenhopper + Crucible nearly made me cry. This is on an 8 core Xeon, 12Gb RAM, 15k SAS RAID and Ubuntu 10.04LTS and Sun hotspot VM.
Random failures, null pointer exceptions all over the place that took us out for a couple of days, incredible memory usage, 8xCPUs jammed at 100% due to race conditions, Fisheye only barely just about works in Google Chrome because it's so slow, useless paid support, horridly slow and inconsistent UI, MyISAM tables causing relation failures (!!!!), don't even talk to me about their plugin management - it's a crock of shit.
I couldn't recommend it at all. It's worse than Visual Source Safe.
That's as a JIRA admin. As a JIRA user, I get people saying "can we have Trac back please".
If anyone at Atlassian is listening, please sort your product out. It's not fit for purpose.
I've been involved in my company in seven different versions of Jira, and have installed it personally, at other companies, and my own server, and for test purpose no less than 50 times.
The hardware we have installed Jira ranged from a 1 Gigabyte VM with 8 Gigabytes of Hard disk, up to a 2 CPU Dual core server.
90% of the time with mySql as the backend, 10% of the time with HSQL
Operating System has been whatever the LTS variant of Ubuntu, or the more up to date version of RHEL (or CentOS as the case might be)
JRE has always been the most recent version from Sun. We only use fisheye and Crucible internal to our company, but that accounts for 60% of my experience.
In the last four years (and 10 or so versions) - I've never had a random failure or null pointer cause a failure. It's been the most reliable software package I've ever used.
Interesting that we have two completely polar opposite experiences.
The hardware we have installed Jira ranged from a 1 Gigabyte VM with 8 Gigabytes of Hard disk, up to a 2 CPU Dual core server.
90% of the time with mySql as the backend, 10% of the time with HSQL
Operating System has been whatever the LTS variant of Ubuntu, or the more up to date version of RHEL (or CentOS as the case might be)
JRE has always been the most recent version from Sun. We only use fisheye and Crucible internal to our company, but that accounts for 60% of my experience.
In the last four years (and 10 or so versions) - I've never had a random failure or null pointer cause a failure. It's been the most reliable software package I've ever used.
Interesting that we have two completely polar opposite experiences.
My experience is more like yours. I've used Jira a ton of times and any problems we've had using Jira/Greenhopper have been organizational. The only problems I've had with Confluence have been fixed in newer versions.
Similar - 1 GB VM, allocated a single core, MySQL backend. Been running for years (although moved from a dedicated machine to a VM a bit over a year ago), solid as a rock. Confluence is running on the same VM.
One of the bits of infrastructure I never have to worry about.
edit: never tried any of their other products however. We use Pulse by Zutubi for continuous builds.
One of the bits of infrastructure I never have to worry about.
edit: never tried any of their other products however. We use Pulse by Zutubi for continuous builds.
Do you have ~100 developers using it and 1000s of issues? Definitely does not scale.
That's nonsense. I've used it on projects much (MUCH!) bigger than that.
You didn't try and use it with the built in database or something did you?
For a public example, https://issues.apache.org currently has 209560 issues, thousands of users and it works fine.
You didn't try and use it with the built in database or something did you?
For a public example, https://issues.apache.org currently has 209560 issues, thousands of users and it works fine.
...until you plug Greenhopper in.
919 Active Developers, 118,460 Issues. MySQL Backend.
#1 rule of Jira is make sure you have enough memory to keep the mySql Database in cache. The attachments don't matter so much.
What I love about the (Lucene?) index is that I can still do a free text search of all 118,000 issues in under 1 second, the same as I was able to when there were only 100 issues. Plus, the 4.x JQL (kind of a simplified Sql Variant) makes it easy to do ludicrously complex searches that still return in basically O(1) time.
DavidU - tell me a bit more about your trouble with Jira Scaling - was it case of the backend system not having enough memory? Jira isn't really disk speed limited, so that's about the only thing that could cause you problems.
Did you get a chance to run the typical performance tools to see if you were CPU, IO, or Memory Bound?
#1 rule of Jira is make sure you have enough memory to keep the mySql Database in cache. The attachments don't matter so much.
What I love about the (Lucene?) index is that I can still do a free text search of all 118,000 issues in under 1 second, the same as I was able to when there were only 100 issues. Plus, the 4.x JQL (kind of a simplified Sql Variant) makes it easy to do ludicrously complex searches that still return in basically O(1) time.
DavidU - tell me a bit more about your trouble with Jira Scaling - was it case of the backend system not having enough memory? Jira isn't really disk speed limited, so that's about the only thing that could cause you problems.
Did you get a chance to run the typical performance tools to see if you were CPU, IO, or Memory Bound?
We use Jira in a 1GB VM with Postgres.
No issues.
No issues.
It is indeed interesting. Thanks for your report. I genuinely wish I'd had your experience.
If you can spare the time, I'd love a more complete report of your issues with our products and support. If you can email me on [email protected], I'd love to hear your story and see if there is anything we can do to improve things.
Thanks - I will do that today.
Any chance I could chat with you about your experience with our support? If so, drop me an e-mail? donna at atlassian.com
"useless paid support"
Sorry if you feel the support is useless. We try our hardest but that's your opinion and you're entitled to it.
However, saying it's "paid" is flat-out wrong. No customer ever pays for support from Atlassian. It's included in the license fee. Free support to current customers is the only type of support we offer.
Sorry if you feel the support is useless. We try our hardest but that's your opinion and you're entitled to it.
However, saying it's "paid" is flat-out wrong. No customer ever pays for support from Atlassian. It's included in the license fee. Free support to current customers is the only type of support we offer.
I'm talking about the "maintenance agreement".
The funny part is trac isn't that fast either. It's overall a superior tool for the job, and loads simpler in every respect, but I get a healthy amount of delay on each and every action I perform in most trac deployments.
I keep meaning to take time out one of these weekends to profile and determine how to mitigate this, but it's just not a priority.
I keep meaning to take time out one of these weekends to profile and determine how to mitigate this, but it's just not a priority.
Switch to the postgres backend. The default sqlite one can get quite slow in high concurrency situations, although I've actually had 50 peple running quite happily off the sqlite backend.
Present concurrency is 0, it's just slow. It's not SQLite unless there is pathological behavior because I've demoed ideas to HN traffic with SQLite before and it performed better than a vanilla MySQL deployment. (Not saying this is advisable, just that SQLite isn't at fault unless Trac is doing something stupid.)
Are you positive switching to the postgres backend will help when there's almost no concurrency and the slowness is persistent and deterministic?
Are you positive switching to the postgres backend will help when there's almost no concurrency and the slowness is persistent and deterministic?
All I'm saying is that it worked for me.
How are you hosting it? I'm using Apache 2.2 with mod_wsgi on Ubuntu 10.04LTS. Don't use mod_python - it's terrible.
How are you hosting it? I'm using Apache 2.2 with mod_wsgi on Ubuntu 10.04LTS. Don't use mod_python - it's terrible.
Jira and/or Confluence are _not_ popular in the enterprise. They are the tool for the small scrappy startup, and end up in the enterprise because hackers, or team-leaders need a tool and just go buy it (Jira and Confluence both cost less than $10,000 - which requires almost no purchase authority in a company)
I _LOVE_ Jira - I find it to be the greatest extensible issue tracker out there, and, after extensively using both it, and Remedy (a tool which costs on the order of $800,000 to do an enterprise install, and another $100,000/year to support, and is therefore popular in the enterprise) - I can say with some authority it outperforms Remedy in almost every category.
There is zero doubt in my mind that if someone is looking for a flexible issue tracker, that Jira has to be final-3 consideration in any down selection.
Ask me anything about Jira - I live, eat, and breath the product.
I _LOVE_ Jira - I find it to be the greatest extensible issue tracker out there, and, after extensively using both it, and Remedy (a tool which costs on the order of $800,000 to do an enterprise install, and another $100,000/year to support, and is therefore popular in the enterprise) - I can say with some authority it outperforms Remedy in almost every category.
There is zero doubt in my mind that if someone is looking for a flexible issue tracker, that Jira has to be final-3 consideration in any down selection.
Ask me anything about Jira - I live, eat, and breath the product.
We just started using Confluence. Design-wise, it's an absolute piece of junk. Nothing aligns, everything is ugly. Lots of plugins to adapt to what you want (which is great), but all those plugins add yet more design differences.
We use it. We love it. Confluence / Jira / Fisheye really work together very well for our needs. I don't understand people being negative about this toolset... I haven't hit any real limitations yet with it. Mind you, our software teams are small teams (7 people or less), but it's work splendidly for us.
We are a manufacturing / media / distribution company with billions in revenue.
We are a manufacturing / media / distribution company with billions in revenue.
I've had my frustrations with both, but I haven't found an alternative that does everything we need and isn't way more expensive. Things I need to do, outside of the usual:
By far, my biggest complaint to Atlassian is upgrades, which are a huge PITA. There has to be an amazing new feature for me to go through that.
- time tracking
- detailed planning/reporting (we use Greenhopper)
- customer service (hiding projects and fields for internal use)
- integration with version control
By far, my biggest complaint to Atlassian is upgrades, which are a huge PITA. There has to be an amazing new feature for me to go through that.
> By far, my biggest complaint to Atlassian is upgrades, which are a huge PITA. There has to be an amazing new feature for me to go through that.
Just as a FYI - the latest version of JIRA (4.4) and the soon to be released (next week) version of Confluence (4.0) have had the install and upgrade process rewritten from the ground up.
If you've been bitten in the past, I'd strongly recommend taking another look.
A summary of the features here: http://blogs.atlassian.com/jira/2011/06/jira-44-sneak-peek--...
Just as a FYI - the latest version of JIRA (4.4) and the soon to be released (next week) version of Confluence (4.0) have had the install and upgrade process rewritten from the ground up.
If you've been bitten in the past, I'd strongly recommend taking another look.
A summary of the features here: http://blogs.atlassian.com/jira/2011/06/jira-44-sneak-peek--...
I use Trac for all those things with the following plugins:
* Time tracking: http://trac-hacks.org/wiki/TimingAndEstimationPlugin
* Planning/reporting: simple trac reports + wiki dashboard.
* Customer service, we have a separate trac instance with Intertrac set up between so you can link tickets.
* VCS integration: works with hg and svn fine
I've used both and have been happy with them.
On the other hand, I've never seen an instance of Fisheye deployed for an OSS project that didn't take minutes and minutes to load a single page.
On the other hand, I've never seen an instance of Fisheye deployed for an OSS project that didn't take minutes and minutes to load a single page.
I'm developing on a 4 man team trying out Jira+fisheye+crucible. I have no complaints so far and the crucible review process is pretty slick.
Those of us who have to use Jira on a daily basis have a saying - jira delenda est.
Absolutely not. I was forced to use Jira at a previous job which actually made me actually quit my job and start building my own project management app (which took part in YCS11)!
Atlassian as a company rocks (the code behind some of the products less so but I digress). The reality is that they do have sales people, in fact a lot of them.
It's just that they are not Atlassian employees but are Atlassian partners employees. Atlassian has a massive partner/reseller network these days
It's just that they are not Atlassian employees but are Atlassian partners employees. Atlassian has a massive partner/reseller network these days
The thing that I don't get about Atlassian is that they make gigantic, unwieldy products that have ludicrous hardware requirements for what they are (compare the performance of a mediawiki install and a Confluence install on the same box) yet they AREN'T targeting the enterprise. In fact, they seem outright enterprise-hostile in their sales process (they don't take purchase orders, period, so you have to find someone with a company credit card, that is authorized to use it on software, that ... you get the picture.)
You have a cap of licensed users, but no way to view only users who are burning a license (we had open registration on our Confluence install for a while, so many employees made 5 or 6 accounts - the only way to figure out which ones are still enabled and which ones aren't is to manually click through every fucking one), things like that.
I love the feature set of Confluence, and feel like it is generally pretty easy to use and well-received by my users, but I dread the annual license renewals (and the upgrades that automatically start sending your users mail with no way to opt out of that globally -- that you have to install, because they contain security fixes.)
You have a cap of licensed users, but no way to view only users who are burning a license (we had open registration on our Confluence install for a while, so many employees made 5 or 6 accounts - the only way to figure out which ones are still enabled and which ones aren't is to manually click through every fucking one), things like that.
I love the feature set of Confluence, and feel like it is generally pretty easy to use and well-received by my users, but I dread the annual license renewals (and the upgrades that automatically start sending your users mail with no way to opt out of that globally -- that you have to install, because they contain security fixes.)
It's a good talk, but I disagree with the advice "you don’t have time to go out there and talk with the customers, get feedback."
Not every company builds products that they might need internally, and even among those that do, their use of it may not match the usage patterns of ideal customers.
Not every company builds products that they might need internally, and even among those that do, their use of it may not match the usage patterns of ideal customers.
"If I had asked people what they wanted, they would have said faster horses." - Henry Ford
Mr Ford's reasons for not talking to customers though is a lot better than "you don't have time"
Mr Ford's reasons for not talking to customers though is a lot better than "you don't have time"
I do love that quote and I find that it's true that customers don't know what they want. But what that quote tells us is that the customer's problem is speed. That is the value of talking to customers, not asking them what they want, but learning what their problem really is.
Sometimes customers don't know what they want. Many times they do. It's rather arrogant to believe otherwise. Most of us aren't creating cars. Some of us think we are and we spit out Segways (should've heard all the dummies that wanted faster legs!). But most tech startups are providing incremental, not disruptive, improvements. And flat out ignoring feedback from people that are going to buy your product and doing so because "they don't know what they really want" is an odd approach to me.
What really kills me about all this is your customer almost certainly understand the competitive landscape, problem space, and industry better than you do. Maybe every other entry failed because they tried to read between the lines rather than delivering what people want.
That's not to say your product should be built as an amalgamation of every feature request thrown your way. Balance is key. But thinking you know better than your customer might not be a great strategy.
What really kills me about all this is your customer almost certainly understand the competitive landscape, problem space, and industry better than you do. Maybe every other entry failed because they tried to read between the lines rather than delivering what people want.
That's not to say your product should be built as an amalgamation of every feature request thrown your way. Balance is key. But thinking you know better than your customer might not be a great strategy.
Exactly - customers and users think in terms of features that they want. Our job is to look through the features and pull out requirements, then prioritise those requirements and work with a great team (or alone) to turn them back into the features that bring the most value.
So feature: I want a faster horse
Requirement: Get places faster, and without stopping for rest periods
New feature/tool: <profit>
So feature: I want a faster horse
Requirement: Get places faster, and without stopping for rest periods
New feature/tool: <profit>
I totally disagree with this. What the quote means to me, is that the customer's imagination (for lack of a better world) is so limited, that their problems are sandbox by the context of their understanding.
Something that doesn't shit all over their yard might actually be more important than speed, but they wouldn't even begin to think of asking that because it's not a possibility in their world.
What do you want in the next Blackberry? "real touch" and "real browser" were pretty far outside the box when the iPod touch launched..people weren't asking for it because they didn't know they wanted it (or that it was possible).
Something that doesn't shit all over their yard might actually be more important than speed, but they wouldn't even begin to think of asking that because it's not a possibility in their world.
What do you want in the next Blackberry? "real touch" and "real browser" were pretty far outside the box when the iPod touch launched..people weren't asking for it because they didn't know they wanted it (or that it was possible).
I think jonpaul is exactly right with his response to the famous Ford quote. Perhaps the customer's imagination is limited, but they know the pain points well. If you're listening carefully, you could figure out the solution. Unfortunately, too many companies use this quote as an excuse to think they're smarter than the customer and develop in a vacuum.
RIM did this. I was a Blackberry to iPhone convert, and I bet a company that was willing to listen to me could eventually figure it out. I would have asked for a browser that actually worked, a larger screen, and thin enough to fit in my pocket (rather than the ridiculous belt clip I had to wear). I had no idea we were capable of the iPhone when it came out, but sounds like my checklist doesn't it?
RIM did this. I was a Blackberry to iPhone convert, and I bet a company that was willing to listen to me could eventually figure it out. I would have asked for a browser that actually worked, a larger screen, and thin enough to fit in my pocket (rather than the ridiculous belt clip I had to wear). I had no idea we were capable of the iPhone when it came out, but sounds like my checklist doesn't it?
Mr. Ford might not have actually said that.
http://www.foolproof.co.uk/three-old-chestnuts-cracked/ http://www.quora.com/Quotations/Did-Henry-Ford-actually-say-...
http://www.foolproof.co.uk/three-old-chestnuts-cracked/ http://www.quora.com/Quotations/Did-Henry-Ford-actually-say-...
This actually reminds me of a Simpson episode (http://en.wikipedia.org/wiki/Oh_Brother,_Where_Art_Thou%3F) where Homer designed a car according to his own needs. It didn't go well :P
Customers know their problems - not necessarily the solutions required to solve their problems. They may have a solution in mind for their problems. It is the job of the founder is boil down problems to their core and find solutions.
edit: grammar
edit: grammar
Also important for founders not to leave the customer with the impression that the customer's solution will be the one implemented
A car is a faster horse.
Yes, if you're trying to create something new, like a car or an iPad, then both Henry Ford and Steve Jobs are right - most people don't know what they want until you build it and show it to them. And to succeed you need people with some mix of vision, taste, and demanding standards making something they want to use for it to succeed. If it passes their test, it will most likely pass the test for the general public as well.
Yep - I don't think that I said that particularly eloquently. And it was related to a point (that I can't remember) that had been brought up earlier in the conference.
But my overarching belief about product design: - build stuff you are passionate about because you use it - listen to customers, but don't do what they say
The reason that products all start to look the same is that customer's only experience of 'better' is a competitors product. That's why you have Audi's advertising about their safety record, and Volkswagon's advertising about their performance features.
A great read on this topic is Youngme Moon's book different: http://www.amazon.com/Different-Escaping-Competitive-Youngme...
But my overarching belief about product design: - build stuff you are passionate about because you use it - listen to customers, but don't do what they say
The reason that products all start to look the same is that customer's only experience of 'better' is a competitors product. That's why you have Audi's advertising about their safety record, and Volkswagon's advertising about their performance features.
A great read on this topic is Youngme Moon's book different: http://www.amazon.com/Different-Escaping-Competitive-Youngme...
Young Me's book is definitely worth a read. I am really sad that we are not able to share that video at her own request. I did take some notes and grab some pictures which give a short summary of some of her arguments.
http://thebln.com/2010/10/professor-youngme-moon-business-of...
http://thebln.com/2010/10/professor-youngme-moon-business-of...
I'd love to use bitbucket instead of github (since they allow free privste repos), but they need to have an online editor. I think they should just run through more of the feature requests.
Summarizing his points:
- Start with two founders
- You need a business model - freemium has serious advantages
- Use your own product
- Measure everything
- Test everything
- Always be closing marketing
- First idea will fail
- Think long-term
- Know when to switch gears
- Build something you want to work
The trick was about giving free licenses to big and popular open Java projects, such as Spring, Hibernate or JBoss. That was a million dollar idea.
Jira is the Microsoft Office of SCRUM teams, but that's not a compliment.
"I think for a company don’t give people cash. Use that cash and give people experiences."
It's interesting to contrast with the model Netflix seems to use, which is "Don't give people gym memberships, give them the money and let them sort it out." Attracts different types of folks I guess, everybody has their preferences.
It's interesting to contrast with the model Netflix seems to use, which is "Don't give people gym memberships, give them the money and let them sort it out." Attracts different types of folks I guess, everybody has their preferences.
We get a $30 per-week allowance for "OH&S Health and Well-being" - It can be used for pretty much anything exercise related, gym, green fees, tennis court hire, it's a lot better than simply being forced to go to some particular gym. It's not a massive amount of money, but it certainly adds up
As an interesting aside, JIRA is based on some of the code behind Apache's OFBiz: http://ofbiz.apache.org/
It would be more accurate to say that Atlassian wrote some of the code behind OFBiz (and a lot of other open source Java projects) back in the early-mid 2000's.
I find it irksome when founders talk about culture and firing people like its some kind of sublime process. Like this guy is some kind of pariah that wouldn't get canned or treated marginally by the next doofus manager who felt he/she didn't like him.
He doesn't at all but if you have ever been an entrepreneur, you will probably know that firing people is usually the worst thing that you can have to do but at the same time, the results of firing someone in terms of the impact on other people in a team can often be very positive.
Hey - I'm not sure what you mean? You mean do I realise that the guy I fired wouldn't find a job again?
Not really. imagine it was the other way around. imagine as company owner you can be eliminated by your employees on a "gut feeling" or because they decided you just weren't doing the job they envision you should be doing. I think most founders would be tossed out on the curb at one time or another.
I'm pointing out that culpability in a perceived bad job performance isn't a two way street and it would be responsible to speak about how you don't always get it right. nothing is more irksome then someone who has fired dozens of people and says they made the right choice every time. statistically impossible.
I'm pointing out that culpability in a perceived bad job performance isn't a two way street and it would be responsible to speak about how you don't always get it right. nothing is more irksome then someone who has fired dozens of people and says they made the right choice every time. statistically impossible.
I don't know where you are located abotwright, but out here in California, by the time it gets to a termination, the employee has all but stopped coming into the office and burned the place down. From my perspective, taking credit for always firing the right person, is setting the bar really, really low. I'm much more impressed with a manager that manages to fire all the people that should, not that he should have fired the people he did.
For whatever reason, only the bottom 5% ever get fired. Where organizations tend to make the mistakes you are talking about is during layoffs, in which quite often, the wrong person is let go - but, in "theory" layoffs aren't performance related - though, in practice, they almost always are. Top Performers are almost never laid off, despite their role in the organization, and bottom performers somehow always turn out to be redundant. One exception to this is when a company drops a division or location - then it's across the board.
For whatever reason, only the bottom 5% ever get fired. Where organizations tend to make the mistakes you are talking about is during layoffs, in which quite often, the wrong person is let go - but, in "theory" layoffs aren't performance related - though, in practice, they almost always are. Top Performers are almost never laid off, despite their role in the organization, and bottom performers somehow always turn out to be redundant. One exception to this is when a company drops a division or location - then it's across the board.
Anyone I know who's ever fired someone absolutely hated the experience. One guy told me after the first time he fired someone, he went into his office and wept. Wept. Even though he felt he needed to fire that person.
Read this: http://bhorowitz.com/2011/08/24/preparing-to-fire-an-executi...
Read this: http://bhorowitz.com/2011/08/24/preparing-to-fire-an-executi...
A good talk but from the title I was hoping there would be more about how they grew their sales. The talk was more about growing the company and evolving from a startup to a large company but with little mention of how they actually did that.
Interesting that they mention topgrading. It's a concept explained in the book Who: the 'A' Method for Hiring by Geoff Smart and Randy Street. When I first read the book, I was really skeptical, but maybe there's something to it.
I think that it is useful to understand the philosophy behind the process, but adapt the process to your own style.
There are two points that I have taken from the TopGrading process: - hire people who are 'A' players who have succeeded at whatever they have done AND who have a passion for the role you are hiring for - past performance IS the best determinant of future success, and the best way to answer the first question
The interview process generally starts at college where you dig into why they chose their course, the highlights, where they excelled, where they failed, who influenced them and why. Did they take on any leadership positions? Win any awards?
Then for each job they have had since, find out - why they chose it, what they found, what they fixed, what they learnt & what they would do differently. Would their boss give them a reference, and why did they leave.
At each turn, you are looking for: 'were they an A player / had outstanding results' and 'does their career path lead you to believe that they will be passionate about this job'.
There's a lot of nuances to it, but I wouldn't hire senior people any other way. I recently compared our hiring notes to a comprehensive personality test of a new employee, and they matched exactly.
There are two points that I have taken from the TopGrading process: - hire people who are 'A' players who have succeeded at whatever they have done AND who have a passion for the role you are hiring for - past performance IS the best determinant of future success, and the best way to answer the first question
The interview process generally starts at college where you dig into why they chose their course, the highlights, where they excelled, where they failed, who influenced them and why. Did they take on any leadership positions? Win any awards?
Then for each job they have had since, find out - why they chose it, what they found, what they fixed, what they learnt & what they would do differently. Would their boss give them a reference, and why did they leave.
At each turn, you are looking for: 'were they an A player / had outstanding results' and 'does their career path lead you to believe that they will be passionate about this job'.
There's a lot of nuances to it, but I wouldn't hire senior people any other way. I recently compared our hiring notes to a comprehensive personality test of a new employee, and they matched exactly.
How do you treat blips in people's past? What if they had a bad year at university, for example, but have been consistently "A" players since beginning a career?
The Greenhopper acquisition was pretty slick.
What used to be (I think) a $700 plugin now adds $2,000 to the annual maintenance cost of JIRA.
What used to be (I think) a $700 plugin now adds $2,000 to the annual maintenance cost of JIRA.
There are a lot of gems in here, this is a "save forever" post.