I just started at my first startup job a few months ago, and agree with a lot of the sentiment in this post.

The biggest difference I have noticed: at most companies, a new employee is a body to get done the same work, in the same way, as somebody else. You are defined by how well you execute an already-constructed set of tasks and goals.

At a startup, you are valuable if you add a whole new set of opinions and skills to the team. If you come in and just do what you're asked, even if you do it well, you probably aren't doing very well. You should notice things about the business that are not optimal, blind-spots that the previous employees hadn't thought about, easy ways to save or make lots of money, even though these things aren't part of your formal job description.

I disagree a little here. Taking on extra projects and solving problems outside of your remit is certainly great. However, you must also take the time to do the job for which you were hired - very well.

Your X factor value is important but don't leave the company with a hole you were brought in to fill.

Alternatively, be the first member of a new team (like I did). There are no expectations of what work you will do or how, so it's like being in a startup, except you have a lot more stuff to play with.

I'm just going to throw this out there, but I think this list is BS. There's really only two bullet points you need:

1. Get things done.

2. Make sure people know you're getting things done.

...and not necessarily in that order either. Being labeled "impractical" is the kiss of death in a startup.

Do those things, and most successful startups won't care about the other bullet points.

I think the idea of writing down your first impressions for later referral is a very good one. Once you become immersed in the problem domain, you tend to quickly lose that very high-level view that you first had as an outsider.

I appreciate a new employee making suggestions as to how we can streamline processes, make documentation better, get up later and do the same amount of work.. don't underestimate how valuable it is to have a fresh pair of eyes.

I would argue that they fall under "getting things done". Because they do help people get things done, right? :-)

I guess you can either have two bullet points and elaborate them quite a bit (because not everything is obvious to everyone) or just make more bullet points like the original. :)

Ask and you shall receive: http://jasonmbaker.com/get-results

...although this probably isn't a ton better. :-)

I do disagree with your 'you can be an asshole %X more if you are getting results'. In fact I would consider being an asshole indicative of not getting results as it can alienate your co-workers (and boss!).

agreed. though also "3. don't be a jerk/asshole" should be up there, in order to not pollute the culture and make company less attractive/retentive for coworkers.

Fair enough. It is amazing what people are willing to put up with if you meet 1 and 2 though. :-)

I saw something great in some Seth Godin piece. If your boss (or team) doesn't yet trust you to do big, impactful things, take on other projects to earn their trust. The breakthrough idea was that they don't have to be product projects. Just organizing lunch, a team build, software purchase, etc. can be enough. As a coder, those seem trivial but to a non-coder they're just as big and important a task.

There's another side to being optimistic that's extremely important when you're proposing an idea. I don't mean assuming every new idea is great or that every proposal will work out exactly as planned; that's obviously a recipe for disaster. In my experience, any sufficiently technical person will already have an opinion on whether or not some proposal works by the instant someone finishes explaining his or her big new idea. A lot of times, these opinions will be correct. However, often these opinions will be based on assumptions from situations in the past that were similar in some way but aren't necessarily important now.

As someone proposing a new idea, you should find out what the assumptions behind these objections are and why they're considered relevant now. Make someone explain the fundamentals of why something won't work instead of immediately walking away and telling yourself, "oh, someone objected, clearly they know more than I do and this idea will never be good."

Getting into the habit of identifying your assumptions and challenging them also helps you keep a more objective viewpoint over time by helping you to understand accepted wisdom instead of simply parroting it.

This post couldn't have come at a better time for me. While I'm not exactly working for a start-up--I'm working for a large publisher whose latest publication is almost two years old--a lot of this advice still applies. The biggest bullet point there for me is taking ownership, because it's true that things sometimes won't ever get done unless you do it yourself.

I would add to the list finding a big security hole or other risk and fixing it.

I joined an e-commerce team at a major systems integrator and discovered they had left the default password in place for the administrative interface of their flagship implementation.

It was actually possible to delete the entire product database using the website. I changed the password immediately, of course.

I get the idea that these things - thing actually - it is also called initiative - really can be said about any fairly flexible job and position.

I know a carpenter who is looking for the same thing when he hires or subcontracts.