[ABS]

> show improvement within 90 days

any (senior) executive who changes things in the first 90 days has got it completely wrong. And if who hired them expect sweeping changes in 90 days then they got it even worse.

Anything that a new hire can do in their first 90 days can be done, and better, by whoever that new executive will report to.

E.g.: if you hire me to fire the people you want fired then there is no reason to wait for me and you should do it yourself. The moment you hire me to get help you have to give me the time to decide for myself who to fire and who not to and it will take more than a few weeks to make sensible decisions.

And yes, that's the exact conversion I had when I found myself in that situation and it's not valid just for SMEs, see 'Who Says Elephants Can't Dance?' for basically the same idea in a place as big as IBM (when he talks about everyone expecting him to come up with a brilliant strategy fast)

[tonystubblebine]

I've been a VPE coming in from the outside. One thing to note right away is that the OP is talking about growing startups. That means that there are usually plenty of things wrong in the startup that everyone agrees are wrong but haven't made a decision on how to fix yet. So, absolutely, the new executive should be facilitating solutions well before 90 days.

As I recall, in my first 90 days:

1. On day one several people hinted to me about work from an under performing contractor. On day 2, I met with this contractor and looked at his code. On day 3 I put him on a performance improvement plan. On day 8 I decided that he was the wrong fit for the role and ended his contract. Great guy, but he was just hired for one thing and then asked to do something else. But there wasn't anyone else who was really qualified to track down whether the problem was direction or fit.

2. There was a general consensus that we weren't shipping code fast enough. On week 3 we implemented Scrum (it was 2005). The engineers kind of hated it. But Scrum achieved what was needed. The rest of the company had enough visibility into development speed to realize that the problem with the company was bad product/market fit, not bad developers. We pivoted a bunch of times. Twitter was one of those pivots.

3. We were running our own servers in a cage at 360 Main. Those servers had been setup originally by one of the founders. There was definitely a desktop computer in there serving production code. The servers were administered by various engineers on the team (administered poorly because it's not what they wanted to be doing). So I started recruiting for a sysadmin. I definitely had hired him within the first 60 days.

There were plenty of things in there that I tried to fix as well and failed at. I can't imagine an exec coming into a startup and not trying to fix things. 90 days is an eternity. Normally there's so much wrong that the exec actually has a lot of latitude from day 1.

[Spooky23]

I respectfully disagree. Any significant org is going to have have some process that sounded good at the time, but is now ridiculous.

If you're not finding and correcting those things in 90 days as an executive, you're warming a chair.

[bsder]

> Any significant org is going to have have some process that sounded good at the time, but is now ridiculous.

That most people will be inexplicably attached to emotionally.

Try this experiment if you're in a Unix shop. Get people to sign up to maintain the unpackaged programs in /usr/local, and then delete the ones that nobody signs up for. Bring popcorn and an asbestos suit. Make sure you take a backup before you do it.

Congratulations. You now understand about removing stupid processes from an organization.

[alexqgb]

"Any significant org is going to have have some process that sounded good at the time, but is now ridiculous."

And yet, it's still there. Understanding why that's the case is a pretty important part of ensuring that it actually changes. In other words, correctly identifying problems is the easy half of the problem. Dealing with the problems behind the problems is where things get tricky.

Fools rush in where angels fear to tread, etc.

[charlesdm]

It's often still there, because there are politics, and people cover their ass/don't want to take the risk of breaking things.

[Spooky23]

Re-evaluating process isn't necessarily a priority. One place I worked at had a paper handling process involving a specific method of stapling and folding a form.

Why? Nobody knew, but it was something that was audited by the QC people. The reason turned out to be a special accommodation for a one-armed man (literally) who was a clerk at some point in the past.

[ABS]

sure but there is a different between finding them, knowing how to changed them and executing that change. You need to know way more than what process is not working before knowing how to change it and you will need people on board to achieve a working lasting change. If you go in shooting from the hips you are very unlikely to achieve what you want, even if the problem is clear to everyone. If it were that straightforward they would do it without needing someone new

[varunjuice]

You're right. My heuristic is not without exceptions.