Search posts, tags, users, and pages
How npm Inc. is different from other company's ?
For me, the #1 difference is that I get to help run the company, as one of the executive team. This isn't a shallow answer, because this means I experience the difference as one of responsibility and one of design.
I am responsible for npm's success in a way I've never been responsible for another company's success! This means that I think about it differently than I've thought about any previous employer, where I cared but wasn't in control. But where this turns into a difference other people might experience is that I have used that control to try to build an engineering organization that is the best one I can imagine. I want to have a company that I'd love working for, an engineering team where I'd do my best work, taking ideas from every great team I've been part of in the past. (And in some cases, avoiding some things that teams I didn't enjoy being on have done.) You can hear some of my thinking about this in some of my public speaking, and a whole lot in my twitter feed when I get started on How To Engineer.
Here are some specifics:
We really are serious about work-life balance. We expect 35-40 hours a week of quality attention from everybody, and no more. We track vacation time, unlike a lot of start ups, because we think of that time as a mandatory minimum! Everybody is expected to use up all their vacation, every year. We do this because we've learned over our careers that people do their best work when they're rested and happy, and when they have lives that include things other than work.
I also like having the space to be wrong. Not in the sense of failing or breaking things, but in the sense of learning. We try to talk problems through before we act on solving them, and the bigger the problem is the more discussion we give it. We can ask questions, not know how to do something, have to go do research, or even be outright wrong about how to fix a problem, and this is okay. The goal is to be right in the end, not to be right from the start. My favorite thing to do is to propose a bad solution to a problem just to get people jump-started at finding the right solution.
This is one of the cores of the "emotional safety" I talk about in my pinned tweet: twitter.com/ceejbot/status/761569569802551300
If you have to constantly prove yourself to a hostile set of colleagues, how can you ever learn anything? You can't. This is no good! I want a team that feels safe with each other and can disagree constructively.
I'm also really proud of our engineering staff meeting, which is not about status or projects or anything like that. Instead we take a discussion topic, new every week, that has something to do with the craft of software engineering, broadly interpreted. We talk about it and share what we know. Topics have been things like:
The goal here is to share wisdom & experience & level each other up. It is my favorite meeting of the week.
Isaac Schlueter once called our engineering team the most thoughtful team he's seen, and I think that is an amazing compliment. That's exactly what I was hoping to build.
Now these are aspirations, and sometimes I know we fall short of them. But we try, and we fix things when we realize we've gotten them wrong, and this puts us ahead of so many other companies I've worked for.