[varunjuice]

When you're hired as an executive, the state of affairs is either glorious or shit.

If its glorious, its because the previous executive left. You in this case have the excellent opportunity of not screwing it up. Good luck, but it'll be while before anyone figures out that you're an imposter. Typically, your team will know well ahead of the CEO. By the time the CEO knows, its too late to mentor you. The damage is done.

If the state of affairs is terrible when you join, as a semi reasonable executive, you should be able to identify the most basic things that are effed up, and show improvement within 90 days. If you're unable to improve things right away, when they are screwed up -- sorry, you don't have what it takes. No amount of mentorship will address this.

[floppydisk]

Wisest words I ever got early in my career from a boss who spent a couple of decades in senior management at a variety of big and small tech companies was if you're hired as an executive you immediately do three things. 1) Get in early, leave late, and read everything about the group you're running. 2) Get to know your people and understand the problems you're dealing with. 3) Change nothing immediately. Waltzing in and changing things willy nilly is a recipe for disaster. I'd counter and say within 90 days you should have a handle on the group you're running, what's going really well, what's going poorly, and identify plan(s) to address major areas that need addressing. It shows you actually understand and aren't simply kicking the apple cart for the sake of making an impression.

[varunjuice]

Fair point. When I say 90 days, I think if things are bad, it's typically easy to spot where the degenerate behaviors are starting, and correcting them. In 90 days, the leading indicators need to start looking good. It takes time for that to flow through the system.

[shostack]

The other piece of that of course is to communicate clearly to the rest of the executive that this is your approach in case some of them have expectations of you coming in making radical changes from day one.

[dikaiosune]

This has the benefit of also being able to develop some traction with your team before you make huge changes. Even if from day one you have a very clear (and right) idea of what needs to be fixed, it might take much longer to have the trust of your team so that your plan is executed well.

[withoutairs]

Indeed. "The First 90 Days"[0] is a great book that provides a framework and techniques for being strategic when starting a new job.

0: http://www.amazon.com/The-First-90-Days-Strategies/dp/159139...

edit -- links, how do they work

[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.