Looking to hire? Reference check your candidates!


One of the most important aspects of hiring someone is to properly reference check them.  Although the interview gives you some solid information on the candidate, the people who worked with them directly know their strengths and weaknesses most.  This post covers how to efficiently and effectively reference check employees for a startup.

Talk to multiple people
You should talk to 3-5 references for most hires.  The references should be people who worked directly with the candidate, rather then people merely at the same company at the same time.  It is a plus if at least one of the references is a former manager.

Set context for the call
Explain to the reference what your company does and the role the candidate is being considered for.  This helps the reference answer your questions through the lens of the role to be filled. 

Ask the reference to set context on how they worked with the candidate, so you know if they worked together directly or not (in which case, their feedback may not be as useful).

If possible, backchannel a subset of the references
Since people often use their friendliest co-workers (or just plain friends) as references, you may not get a real view into the candidate.  Business people are the worst offenders on this – they will often talk about how amazing a person is even though they never worked directly with them.

If the option exists, find people (you already know and trust) who have worked directly with the candidate in the past.  They may have additional insights on how well they completed their past duties.  You need to do this discretely – e.g. don’t call their current boss to ask how good they are thereby screwing over the candidate, or alternatively causing their existing employer to make a big counter offer.  If in doubt, err on the side of caution and doing what is right for the candidate (i.e. don’t cold call random people to ask about the candidate).

Come to the call prepared with specific questions
  • If you are worried about an area of weakness from the interviews (e.g.”does this person work well with others?”), use the reference checks to get more data.
  • Have a list of questions written down that you want to ask and areas you want to probe in.  I have a generic Google Doc that I print out for each interview, to which I add a few candidate specific questions.  I like to include questions focused on (non-exhaustive):
    • Culture fit
    • Smarts / raw intellect
    • Ability to GSD
    • Ability to deal with uncertainty
    • Determination & drive
    • Willingness to do grind through crappy work for the good of the team (this is important in a startup as crappy work is inevitable)
    • Contributions in current role (what did they actually do themselves?)
    • What do they do well?
    • What can they improve on?
    • How do they resolve conflicts?
    • How pragmatic are they?
    • For managers, there is a whole set of questions on their management style.
Rephrase the same question multiple ways
Often the references the candidate provided are their friends.  Or, it is a long time co-worker who doesn’t want to say anything bad about the candidate.  By asking the same question multiple ways, you sometimes get more information from the reference, or the real answer emerges.  As an illustrative example, for productivity you can ask:
  • How would you rank Sarah relative to other people you have worked with in terms of raw productivity?  What percentile would she fall under?
  • Is Sarah one of the 3 most productive people you have ever worked with?  If not, is she in the top 5?  Top 10?
  • What is an example of Sarah being very productive at work?  How does that map to her day to day behavior?
  • When has Sarah not come through on something at work?  What was the reason for it?
  • Has Sarah ever bottle necked the team?  If so, what were the circumstances?
The above is meant as an example only.  The key takeaway is by probing for the same thing multiple ways, you often get to a richer answer and perspective.  On some reference checks I have done the tone has changed from the first such question “Yeah, Bill is great” to dramatically different by the last one “It is really hard to depend on Bill sometimes”.

Anatomy of a phone call
  • Set quick context.  What does your company do?  What role is the candidate being considered for?  What skills are needed for the role?
  • Ask how the reference knows the candidate.  How long did they work together?  How closely did they work together?
  • Run through your list of questions.
  • Give the reference a chance to summarize at a high level their view of the candidate at the end of the call, or ask you questions.  Alternatively, you can synthesize your takeaways from the call and see if the reference agrees to your summary.
The above should take 5-15 minutes total.  The best and worst candidates often have the shortest calls.

Wireframing your application: Nathan Barry


There are many “right” ways to design an application, so I want to be clear that this is my workflow (and the one I recommend), but it’s not mandatory. I know other designers who just jump right into Photoshop (or code) and produce great work. But if you find yourself having trouble visualizing a design or workflow in your head, give this method a try.

The mental model

The hardest part of designing any application is picturing the entire thing in your head. When you are in the dreaming stage you can plan through an interaction a bunch of different ways, think through all the possible screens, and have fun doing it… except that if you’re like me, you forget things. Often I find myself unable to think through additional interactions since I can’t think that far ahead. For me it’s like trying to think through chess moves three or four moves out. It just makes my head hurt.
My solution is to get it out of my head and onto paper.
I use either blank sheets of standard printer paper or, lately, the DotGrid book from Behance. Start with regular paper. I don’t want the wait for the perfect tool to arrive to keep you from getting started today.
On the right side of the paper I usually make two lists:
The first is a feature list of sorts. For ConvertKit it included Landing Pages, Courses, Settings, etc. The list doesn’t need to be exact, but instead it’s a quick list of what I am thinking of including.
The second is a list of questions to save for later. As you plan out the features and workflow, all kinds of questions will come up. These are important, but also a distraction for the stage of the process you are at. If you stopped to research each one every time, you wouldn’t get anywhere. I write them down so that I can forget them (at least for now). Here are a few of the questions I wrote down for ConvertKit:
  • Which email delivery provider should I use?
  • How do you support custom domains for landing pages?
  • Which rich text editor should be used? Can it be stripped down to just what we need?
  • Should there be a one-to-one relationship between Landing Pages and Courses?
At the time I had some ideas about each of these, but certainly didn’t have the answer. To avoid distraction, I saved them for later.

Postage stamps

Next I use the rest of the page, starting in the top left, to draw small postage- stamp-size wireframes. At this point I am just interested in the user flow and main elements. Drawing too large will cause me to focus on the details, which I don’t want to do.
Other designers accomplish the same thing by drawing large wireframes using a marker instead of a pen. The exact implementation comes down to your preference, but the point is to draw at a low resolution.
The Workflow
When I plan out interactions between screens, I think I have everything covered. But inevitably there is something I missed. So until I draw out each screen and step through it in my head, I can’t fill in the missing pieces. Interactions are always simpler when you imagine them.
That’s why it’s important to add every screen to your interaction to make sure you aren’t missing anything. Then complete a task, just pointing at the buttons with your pen. Which button would you click? Where would it take you? Would there be a success message?

Increasing Resolution

Once you have the basic interactions in place and have tried several different iterations, it’s time to make higher-fidelity mockups, where you can actually pay attention to the copy and basic layout, and make sure you have all the elements. You could do this directly in code, use a wire-framing tool like Balsamiq, or a use a design tool like Photoshop or Fireworks. I like to use Photoshop.
These are my first three higher-resolution mockups of the landing page process. First is a list of all the landing pages (showing some basic stats), next is the landing page edit screen, and finally I add the landing page settings.
At this stage I can put everything on the page to get a better feel for development time and how I will lay things out. The edit screen stayed largely unchanged throughout the process, but the settings page is radically different. This is mainly because in the version you see here I just put everything on the screen, so it looks incredibly busy.
Hiding Complexity
The next step is to take that busy screen and hide the complexity. All those features and settings will be wanted at some point, so I need a design that works well without overwhelming the user.
My solution in this instance is to use tabs down the side to only show some of the features at a time. Most everything is still there (I removed a few features that aren’t needed until later), but it is in a much more manageable format.

Designing Courses

Landing pages are an important part of ConvertKit, but the real magic is in the email courses. Setting up a drip email series is a pain in nearly all email marketing software, so ConvertKit’s core value is in making that process easy. Below is an early iteration of the screen. I imagine I will spend a ton of time reworking and improving it over the next few months.
Each email in the course is listed down the side in a tab format. That way it is really easy to think of your course as a series (which it is), rather than clicking in and out of specific emails as you would in MailChimp.

Adding Polish

Taking the course page through to a completed design didn’t require a lot of changes, but one is important enough to discuss. Take a look at the date setting of the email. It reads in a sentence format with two editable values:
“This email will be sent [2] [weeks] after subscription.”
So you can fill in the number [2] and then select days or weeks depending on how you want to schedule your course. Turns out that could be a lot simpler. Since days are a subset of weeks (seven days in a week), we can get rid of that second option and just use days.
“This email will be sent [2] day(s) after subscription.”
This also removes complexity from the list of emails where each one specifies the time since subscription (2 weeks after subscription). If we allow both days or weeks to be entered it becomes a chore to list both options in the sidebar and keep them ordered by send date.
It would be nice to remove the (s) in “day(s)” to fake whether it makes a grammatically correct sentence. The solution I thought of is to use JavaScript to switch from “days” to “day” if the number in the field is 1, but for now it isn’t worth the effort.
The other details that add a level of polish are basic colors, subtle gradients, icons, and improved typography.
That’s my process. This design is simple enough that I could have skipped directly from a sketch to the coded design, but I think I achieved a better result by completing each step. One shortcut I did use was to define the style (colors and typography) on this page only and just apply it to the other pages in code.
What is your design process? Let me know in the comments.

culled from: nathanbarry.com

Mark Suster: Time to earn or learn?


I often have career discussions with entrepreneurs – both young and more mature – whether they should join company “X” or not.  I usually pull the old trick of answering a question with a question.  My reply is usually, “is it time for you to earn or to learn?”
Let’s face it.  If you’re thinking about joining as the director of marketing, product management manager, senior architect, international business development lead, etc. at a startup that has already raised $5 million the chances of you making your retirement money on that company is EXTREMELY small.  That’s Ok.  Not every job you have is supposed to be your big break.  It’s Ok for that to be your job to “learn.”
Yet I often hear people asking about these types of opportunities express their questions to me whether I think this company is going to be a big hit.  It’s clear to me that many people confuse learn with earn.  I will do a simple calculation for them that goes like this.  OK, you would own 0.25% of the stock.  They raised $5 million in their B round.  Let’s assume that the company raised it at a normal VC valuation, which means it gave up 33% of the company and thus $5 million / 33% = $15 million post-money valuation.  If you never raise another round of venture capital (a big if) and if your company is sold for the normal venture exit ($50 million on average for 200 or so annually that get sold) then what is your stake?  $125,000.  Yup.  Simple math would have solved that but people rarely do the calculations or think about it.
And let’s say that it took 4 years to exit – that’s $31,250 / year.  Now … these are stock options and not restricted stock so you’ll likely be taxed at a short-term capital gains rate (see comments section for why).  In California that averages around 42.5% so in my state after tax you’d make an extra $18,000 / year and that’s in a positive scenario!  BTW, this ignores liquidation preferences which actually mean you’ll earn less.
So let’s go CRAZY!  You get 1%, you sell for $150 million and it’s in 3 years (e.g. you won the lottery).  That’s an after-tax gain of $287,500 / year for 2 years.  Not bad.  Doh!  Wait a second.  Stock vests for 4 years.  You didn’t get acceleration on a change of control?  Sorry bud.  We’ll have to either cut your earnings in half to $143,750 or you’ll have to complete 2-years at BigCo that bought you making the money spread out over 4 years so it’s $143,750 / year for 4 years.

Don’t get me wrong.  This isn’t shabby money.  But given that a home in Palo Alto or Santa Monica will set you back $2 million it’s hardly riding off into the sunset.
I’m not trying to depress you.  I’m just trying to be realistic.  If you want to “Earn” (and by earn I mean the chance to buy your house outright or greater) – you have to start a company or join as a senior executive.  Or you have to hit the lottery and be an early player middle management player at Google, Facebook, MySpace or Twitter.  Let’s be honest – how many of those are created per year in the entire country?  1?  2 max?  I spoke with an investor recently who told me that 1,500 deals get funded / year in the US, 80 (5.3%) eventually sell for $50 million and only 8 (0.5%) eventually sell for $150 million or more.
So when the Stanford MBA, the ex senior technology developer or the former Chief Revenue Officer of a company is calling me and asking my advice on their next gig you can see why I start with “are you ready to earn or to learn?”

For most people it’s learn.  I only emphasize the question before I find it much more helpful to join a company with realistic expectations of what you want to get out of it.  My advice is often, “make sure that what you get out of working at this company is one or several of the following: a great network of talented excutives and VCs, more responsibility than your last job, specific industry or technical skills that will help you in what you do next, a chance to partner with companies that will increase your industry relationships, etc.”  Learn now to earn later.
When I was CEO of my first company (where I admittedly F’d up everything before I figured it all out) we initially calculated for people how much there options were going to be worth some day.  It was 1999.  Ventro was trading at $8 billion on sub $2 million of revenue.  It was easy to do these calcs.  Over time I realized that this created a rotten culture.
Over time I took to telling people the following, “join BuildOnline because you think you’ll get great experience.  Join because you like the mission of what we’re doing.  Join because if you do a good job we’ll help you punch above your weighclass and work in a more senior role.  And if you ever feel that in the year ahead of you you don’t think that you’ll increase the value of your resume and you’re not having fun then go.  Join because we pay well but not amazing.  Stock options are the icing on the cake.  They’ll never make you rich.  Don’t join for the options.”
Obviously you should only take jobs that you enjoy and that let you be passionate about coming to work every day.  That’s a given.  Don’t blindly join a company without knowing why you’d join or asking the right questions.
So a friend recently called to ask for advice on becoming the CTO of a startup.  He’d be employee number 3.  The company was being spun out of a larger company.  I asked him how much of the company would be owned by the parent company and how much would be owned by management.  He hadn’t thought to ask.  When we next spoke he had found out that the CEO had about 5% and there was no management option pool in place.  My advice was … run!  I said, “all the hard work is ahead. Why start the game with a company with a structure that’s likely to fail.”
Another talented young man I recently met called to talk shop.  He had an offer in NY, an offer with a well known startup in the Bay Area and an offer with a startup in LA.  He also has his own company that he started 6 months ago.  He’s not even 21.  He wanted to know what to do.  I told him that he needed to decide whether to learn or to earn.  He’s young enough to do either but know why you’re doing it.  I advised against the SF role because it was a bigger company and his role would be pushing paper from one side of his desk to the other.  If you’re going to learn then at least go work somewhere exciting where you can really do something.  If it works you can stay and grow for the next 5 years.  If it doesn’t you’ll have done 3 startups by 26.  And you’ll be ready to earn.
On the other hand, at sub 21 you have the ability to swing for the fences and try and earn if you’re so inclined and if you think you have the skill sets and the idea.  When you’re 40, have 3 kids and a mortgage this is much harder.
Now, for the “Earn” part.  Another friend of mine is a very talented executive.  He went to Harvard undergrad, Harvard Business School and has worked at 3 prominent startups and 2 well known big companies. He’s worked in the US and internationally.  He’s in his early 40′s.  Whenever he calls me he must think I’m a broken record.  I always say, “Dude (I live in SoCal now!) – it’s time to EARN.  Stop dicking around with another number 2 job (he always gets offere the number 2 job). It’s time for you to be in the driver’s seat.  Either start a company or go somewhere where they need a CEO.”
If you really want to earn you need to be in the top 3-4 in the company.  Best to be a founder.  Very few people can do this.  It’s a rare skill.  Be realistic about your skills, background and ideas.
Anyway, I hope this post hasn’t been too harsh.  I’m not all about the money.  I think working in a startup can be an enormously rewarding experience.  I wouldn’t recommend it any other way.  But you need to match your talents, age, skills, ambition and economic situation with your current reality.  At a minimum be realistic about the outcomes.  And make sure you ask yourself the question, “am I here to earn or to learn?”
culled from: bothsidesofthetable.com

Domain Knowledge or a Lack of it?

I believe that a lack of domain knowledge is the root cause of a lot of very bad software that gets developed and I think that it is up to computer programmers and their managers to deal with this. Acquiring domain knowledge is an essential component in the development of software that really works well for its users. A programmer that has to automate a warehouse but that has never picked an order and doesn’t have a clue about actual logistics is going to be writing far less effective software than someone that has done a few shifts on the floor. And that’s purely practical knowledge in a field that is reasonably well understood. There are many other examples where the effects of the differences between someone automating some solution with or without domain knowledge would be far harder to see.

Programming and systems analysis are like architecture in many ways. An architect has to have a reasonably good understanding of what a customer is going to do with a building if they’re going to do a good job of designing that building. An enclosure for a machine would have to match the guts of that machine just like a building encloses a company. Having the loading docks of a warehouse on the fourth floor is usually not what you want.
Software is much more intertwined with the institution commissioning it and the people using it than any building ever will be, with the exception of engineered structures such as the CERN ring. If all should fail a building, no matter how mismatched can always at least be used for storage. Fire-stations  can be converted to houses and industrial buildings converted to office space. But software that doesn’t match is unusable.
Imagine architects designing a fire station without consulting with fire-men and fire station chiefs and without understanding the basic operations of a fire-station and how the situation develops when a fire is called in. When utility matters, domain knowledge is very valuable.
One of the things to love about software is that it is everywhere, there isn’t an industry that doesn’t have software component in it nowadays. And for each and every one of those projects there was a large amount of domain knowledge to acquire. That’s hard work, and you probably can’t put it on the bill but it is an absolute requirement if you want to deliver a half decent product.
What that translates into is that when I worked for a company making CNC equipment that I learned how to use a mill and a lathe manually. Only when I understood how you work metal by hand did I reach a level where I could confidently write software to work metal by numerical control.
Working for a manufacturer of sails I soaked up piles of books on sail making and sailing and I actually spent some time on a boat. Half the library on that subject was digested for breakfast, lunch and dinner. Add another helping on fabrics and their properties and on stitching and cutting techniques! Knowledge like that helps a lot when you have to lay out your ‘panels’ on the cloth, and then afterwards when those panels have to be combined to form a sail. In that particular case I took great care to make sure that the panels had their major lines of stress run along the threads in the weave, even if that meant that we might get one or two fewer panels from a piece of fabric the resulting sail would be stronger and it would last longer. Quantity or quality is a business decision and if you’re not aware of this then you might accidentally make that decision for your employer without anybody being aware that a decision has been made. The software used the exact same terminology that the sailmakers used, and used it consistently.
When working for a company that did colour calibration software and pattern checking I read and learned about colour spaces and imaging hardware. All kinds of history there, from manual inspection to semi automatic inspection all the way to the present day. Industry is funny that way, you start out with a simple assignment (can you read values from this sensor) to sucking you in into a project that has a century of history behind it with lifetimes of domain knowledge that you need to absorb before you can even begin to properly automate the solution to some problem. It is also funny in that it all ends with knowledge about physics.
If there is a message in this blog post then it probably is that if you are currently working on a project that requires domain knowledge but you don’t have any of that knowledge yourself that you should probably take the shortcut of stopping your work and to first educate yourself about the field that you are operating in, and then to return to whatever problem you’ve been assigned to solve.
Programming without domain knowledge for a discipline that is steeped in it is like an architect designing a building without knowing its true purpose.
If you are working in some industry spend time on the shop floor, become a user of your software if there is any opportunity to do so. It will make you a far more effective programmer and it will reflect itself in the usability and the perceived quality of your software. The combined knowledge about the domain you are operating in and your IT knowledge is far more valuable than any of the two in isolation.
Domain knowledge is not optional, it is essential. The one common factor between the failed projects I come across is that they were automated by people that had little love for and little or no knowledge of the domain they were operating in. Companies and institutions should make time available to get their IT staff up to speed on the inner workings of the company and should allow their IT staff to be embedded on the floor for a taste of what the real world looks and feels like.
So stay clear of the trap of little or no domain knowledge and get your hands dirty, learn to see through your users eyes by acquiring the knowledge associated with the field you are working in, don’t treat IT as a world that only communicates with its users through tickets and requirement documents, step down from that ivory tower.

Gordon Koo: How to start working on a side project


This post was written for a technical audience, but its core ideas can also be applied to other fields.
There are many reasons for a software developer to work on a side project. It’s a good way to keep a pulse on technologies that are currently trending in the industry. It helps you keep your programming skills sharp. And it’s fun! Or, at least it should be.
But then there’s that thing we call “life” which can make it difficult to start a side project, let alone finish one. We’re often spending so much time trying to stay afloat in our hectic schedules that it can seem impossible to squeeze a side project in.
I started working on my first side project two years ago, so I am no expert on this matter by any means. During these past two years, I’ve made observations about how I got started on the side projects I’ve started and why I was able to finish some and not others. What follows is neither particularly groundbreaking nor an official guide to working on a side project, but merely the aforementioned observations I’ve made which you may find helpful.
Work on something that interests and excites you
I hesitate to write something that sounds so painfully obvious, but it’s very important. A side project should be something that you get excited about working on. When you wake up on Saturday and you start to go through your agenda for the day, what is your gut reaction when you consider the idea of working on your project? If your thoughts begin with the words “I should probably…”, you’re not off to a great start. If they begin with, “I get to…” or “I finally have time to…”, then that’s starting to sound a little better!
Take breaks
Your project should be many things. It should be fun. It should be something you look forward to working on. What it should not be is a chore. If you’re working on your project and you’re not enjoying it anymore, hit Save, get up from your keyboard, and go exercise. Play video games. Go shopping. Whatever it is you do to unwind, do it. Don’t come back until you feel ready to work on your project again, whether it takes a day, a week, or a month.
On finishing a project
The level of importance for completing a side project varies from person to person, and even from project to project. Some side projects serve as a means for experimenting with new technologies. It’s completely fine to leave those experimental projects unfinished. For the rest, however, having a goal to finish can be very beneficial. The desire to finish your project adds motivation to working on it, and it’s also a nice bonus to be able to show your work to others once you’re done.
Working on something you find exciting (point #1) is especially important for taking your project through to completion. If your project is even remotely substantial in size, you’ll be spending a great deal of time on it, and you may begin to feel fatigue from working on it after some time. The novelty of your project idea might diminish over time, and when that happens, you’ll want as much residual excitement to remain as possible.
One project at a time
While you work on your project, you may start to form other project ideas in your head and get the urge to work on them. That’s great! You can never have too many ideas. Write them down so you can work on them later, but don’t switch to another project until you’re done. Trying to work on two projects concurrently is the best way to ensure that you will complete neither. If you do switch projects, either have a concrete idea of when you’ll pick up where you left off with the original project, or acknowledge that you probably won’t finish the project.
By the way, it’s perfectly fine to end a project without finishing it. That just means that something about the project changed from the time that you started it. It might be technically infeasible. Maybe you’ve learned that your idea doesn’t make sense. Or maybe, for whatever reason, it’s just not fun anymore. Whatever it is, the important thing is to take that information and learn from it.
Find a time that works
Working a slot into your regular schedule is the best way I’ve found to sustain progress and motivation for a project. Make it a ritual. For me, it’s the first thing I do when I wake up on the weekends. I’ll go to my local coffeeshop for a couple of hours, sit and write out some code, and I’ll be done before lunch. This has worked great for me because there are very few social obligations that begin before noon. Furthermore, I’ve found that finding a reoccurring time where I work for a smaller chunk of time (one or two hours) has been more effective than finding those larger chunks of time (three to four hours).
Have fun!
If you’re not having fun, then there’s really no reason to be doing it. Creating something new should be fun and exciting, and when you do it right, it can be one of the best feelings in the world.
culled from medium.com

Ask for forgiveness, not permission!


AngelList “corporate policy” is that team members should ask forgiveness, not permission. We would rather have someone do something wrong than ask permission to do it.

Or better, we would rather have someone do something right and not need permission to do it. This is the most common outcome.

We would rather have people ship to production whenever they want, than go through an internal review process. We can fix it on production. We prefer the customer’s review process. And it isn’t too hard to reveal a new feature to a small portion of our users and iterate on it as we expand it to more users.

Eliminating permission increases speed and diversity
Eliminating permission increases the speed and diversity of our decision-making. Our incubator applications are a good example of diverse decision-making: one of our team members built it even though I was telling him, “This is fine, but I don’t think it is that important. Why don’t you work on something else.” It ended up being very important to our users and mission.
There are some sensitive parts of our product that are walled off from this “ask forgiveness” policy. There are some things we want reviewed by the people who “know better”. But it’s really rare.

How it works
This policy only works if you hire insanely smart and capable people, and let go of the ones who are not. We also filter for people who are mission-oriented, care about our customer and want to learn more.
And it doesn’t mean that the founders aren’t standing over your desk telling you, “this isn’t good enough to ship”. That’s why we write down and promote these ideas. Because there is always pressure from someone important to do it another way.
It also wouldn’t work without these other items of corporate propaganda:

You break it, you bought it
If you break something or your stuff is buggy, please fix it. As in straight away mate.
If people are going to ship whatever they want, we need them to sweat the details if they’re going to avoid mistakes.
The best way to do that is to have the rest of the team constantly complain that your code and/or design sucks or, in polite terms, “contains opportunities for improvement.”
Actually, mistakes are fine. They’re something you trade off for other variables like speed of iteration. We just want people to sweat the details because we care about the details.

Be real
Again, if people are going to ship whatever they want, whenever they want, how do we get them to make good decisions? One answer is that we ask them to “be real”. As in, treat our users like real people. Treat your teammates like real people. Just be real and do the right thing.

Do what you think is right (and be right)
If you have the freedom to make decisions, you also have the responsibility of being correct.

S/he who codes, rules
Another way we promote good decisions is by pushing the decisions down to the people doing the work. We memorialize that with the motto, “s/he who codes, rules”. As in, when we disagree, the person doing the work makes the decision.

Own the result
Pushing the decision-making down to the worker works best if the same person is responsible for the metrics. So we try to have 1-wo/man teams whenever we can, and we ask them to own the result. We also hire people who care about our customer and want to solve problems for them.

Freedom and Responsibility
All of these dictums are variations on freedom and responsibility. Netflix has a great presentation on the topic. So does ValvePeter Drucker probably wrote about it 50 years ago. We didn’t invent this stuff, we don’t claim to know what we’re doing, nor is this a perfectly accurate or complete model of how we operate.

  1. Ask forgiveness, not permission
  2. Do what you think is right (and be right)
  3. S/he who codes, rules
  1. You break it, you bought it
  2. Sweat the details and corner cases
  3. Be real
  4. Own the result
If you’re interested in working with us, we’re always hiring.

from venturehacks.com