141 karma · joined January 24, 2012
On the other hand being free from arbitrary limits is great.
in my experience it has just been a way to help business decision makers credibly claim they are managing risk when buying from a startup
you first cull the set by saying "only parents with at least 1 b, line up to be examined". i think it's clear that the selected population will be 1/3 bb parents, 2/3 bg parents, right?
on the other hand the second problem is you saying: "all parents with a b born on tuesday, report to be examined!". note that most of the parents that were in the question 1 selected population are now excluded. try to imagine which parents get selected by this one.
you can't make the inference back to the original question because it's a different question about a broader group of people. question 1 population distrubution actually is 1/3 vs 2/3. the key is to think of it as selecting different subsets of the parent mob.
we're calling it "advanced professional", and has 3 levels, the highest being equivalent to the leader of a function, if you're familiar with the domain / function / specialty paradigm. This is essentially a director level individual contributor which I think is a pretty cool.
We're just a medium sized services company (localization, AI training data production, digital marketing). so if we're doing this I expect a lot of people will be soon enough.
its not like the solutions are usually that hard to figure out, it's always a problem with people and their incentives ultimately.
the fixer role is basically to give confidence to the CEO that disempowering certain people is safe and there's a path out.
1. many of these grassroots apps are a mess, filled with bugs and security flaws.
2. often they don't align with standard platforms and technologies that are in use. this includes source control, CI, unit testing standards, SSO, etc, not just the code itself)
3. no one put together a business case, so no budget or justification exists for support and maintenance costs, and no planning has been done to execute on that.
4. the application was not built in compliance with internal processes. this can mean it will never pass an audit (because the org is operating under ISO 9001 or something). at a minimum, some valuable and time-constrained people may have to analyze it carefully to figure out what the risks are
for an IT org, there are usually a lot more good ideas than there is capacity for supporting, maintaining, testing, and managing applications. further, maintenance costs dwarf initial build costs. "here, I built you this" doesn't really solve the whole picture. it feels more like an annoying effort to skip the line and hand off a white elephant that has to be babysat for ever.
Note that this is not a justification for the stonewalling or cold shoulder. in this type of org, i'd expect IT to help write the business case and make it easy to do things according to policy