chetatkinsdiet

I'm a manager of people and compensation is one of my levers (not my only) for both rewarding high quality work and retention. While on the surface role-oriented firm salaries seem like a noble idea, it results in a mess. I have a bunch of people who work for me who aren't ready for a title oriented promotion, and may not even be ready to level up, but are doing exemplary work within their band- why shouldn't I be allowed to financially reward them for their work?

Most times they don't even read the books. They just stop at "what doesn't get measured doesn't happen." Great, that leads people to measure all sorts of stupid stuff like lines of code to production. Who cares if it isn't something that contributes to a thing that someone's going to use.

Easy enough in a small org, much more difficult in a big org. Part of the point of OKRs, when done right, are that it shows how the thing you're working on today ladders up to the big thing that drives the entire company forward. That said, in reality it's rarely executed well or with any precision whatsoever. I worked at a 1000 person place whose top level OKRs were so vague they were garbage. You could have created any feature whatsoever and shoed it into those.

Fun fact, if you're an enterprise customer you can demand full second rounding, or if you're mid market you can bring that down to 6 second rounding in many telco oriented places.

Super easy and a bunch of apps do it, the problem here is that the numbers actually have a leasing cost if you want to hang on to them vs something like an email alias/front.

the difference is that it's pretty easy to tell a good b school (lots of objective rankings). at an early stage, it's really tough to tell a good startup- as a candidate you are at a significant disadvantage in choosing a startup employer due to the lack of available information. not saying one is better than the other, but that making that choice is far more difficult than the couple of sentences you mentioned.

I was with you until your last sentence. There are plenty of extremely highly successful companies selling products at a very high clip that require credit facilities (aka loans) to finance the selling of their products. The reality is this- to get scale you put out a ton of cash before you sell the product- a loan helps you offset that timing and spreads your risk to another party.

As someone who's worked with a lot of these engines, Nuance and IBM are the only really high quality players in the space. CMUSphinx and Julius are fine for low volume operations where you don't need really accurate response rates, but if you want high accuracy neither comes close from my experience.

IBM split from Nuance a year or so ago- it's now its own engine.

A really good read- we don't spend enough time talking about the strategy for startups as it relates to larger companies. We talk about disrupt, disrupt, disrupt, but it doesn't always have to be that way. When aligned properly a larger company can pull a startup upwards.

We are a bit bigger (150 people or so, so take this with a grain of salt).

We use Zendesk to track bugs. It's nice because of its assignment features. That said, I find it terrible about everything else.

Feature requests are currently in UserVoice, however we're about to move over to Aha.io instead as we use that for product roadmapping and it's easier to move a request right into the plan and then push into rally (we use rally instead of jira for sprint planning)

Good point- that all said, if we're automating requirements we're not solving the problems that tend to matter. The key to requirements building is in the process. The best process I've found so far is User Story Mapping (Jeff Patton has an amazing book on it)

If this is how you're defining requirements for software or new product creation you're doing it wrong.

The goal should never be to describe every single outcome or scenario- the goal should be to build understanding between business/product/development team so that they understand the point of the work that the software replaces. It's no different with hardware or really any new product creation. The goal is to create a conversation that gets us to solving the problem- when the spec gets to covering all cases the chances we get this wrong and stray from solving the actual problem goes up massively.