tylerflint/pagodabox-expectation-values.mk

## pagodabox-expectation-values.mk
## You are an artisan, not an engineer

An engineer makes something work. You are more than that, you are an artisan. Artisans practice a craft and may through experience and aptitude reach the expressive levels of an artist.

Approach your work as a master craftsman.

Demand perfection of yourself.

## Style matters

Just because we're building infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See [The Substance of Style](http://books.google.com/books?id=MqdydvbWZgEC)

Slick and fun meets powerful and serious.

Style is expressed through design and workflow. Workflow and design will dictate architecture.

Never build anything without considering the workflow of our consumers or internal team. If the workflow is flawed, the architecture is flawed.

A workflow/design iteration can and likely will require an infrastructure refactor.

## Maniacle focus on elegance and simplicity

Passion and concern for your work is demonstrated by your work.

A lack of concern for cleanliness is a strong indicator that you don't care.

A product that simply "works" is a prototype, a finished product should be considered a work of art that you want people to admire.

Take multiple passes to consider ways to make your code more expressive, elegant, and clear.

It should be obvious to the next person who looks at your code that you care.

## Finish the job

A product is not finished when it simply "works". A finished product should be clean, documented, and tested.

If the product is a webservice, it should have at minimum a CLI to manage it. Sometime a web ui is needed.

Your product is not finished if you are the only person who can use it. You must have produced the necessary tools to manage the product, the documentation to reference, and a demonstration to at least on other person.

## Timing is everything

If you're building something and just can't seem to get it right, maybe now isn't the right time. You learned something in the attempt, set it down for a while. Maybe in a few weeks or a few months you (or someone else) will pick it up again and find that the world has changed in a way that makes it the right time to build the thing.

Consider the SHOVEL network as an example, wherein we spent 3 years attempting to build it and had to put it down dozens of times before the design was right, and the tools (OS) were sufficent to support it.

## Throw it away

It's not the code that is valuable, it's the understanding you've gained from building it. See [James' startup school talk](http://www.youtube.com/watch?v=3BhDLm9jo5Y).

Never be afraid to throw something away and do it again, it will almost always be faster to build and much better the second (or third, or Nth) time around.

## Everything is an experiment

Anything we do -- a product, a feature, a standing meeting, a workflow or colloboration tool -- is always subject to change. That includes discontinuing or shutting down whatever the thing is. Ending an experiment isn't a failure, since we often learn the most from experiments that don't produce the results we wanted.

## Question everything

The status quo is never good enough.

See:

* [The Innovator's Dilema](http://books.google.com/books?id=SIexi_qgq2gC)
* [Blue Ocean Strategy](http://books.google.com/books?id=BmPPAjGaDuQC)

## Use your intuition

Hunches guide you to places to create new value in the product. Users don't really know what they want. Creating products people loves requires treating product development as an art, not a science; but products have to solve real user problems. Understanding impact of product changes to existing product is best done by mining the data. When you have a mature product and many users you have lots of data on how they are using it. Use that data to make evidence-based decisions.

Don't just do something because a customer "needs" it. Be wise, use your intuition. Work to understand the real problem and design a solution that solves their problem in the best possible way, perhaps not the way they thought.

See: [Inspired: Created Products People Love](http://books.google.com/books?id=nE7NMQAACAA)

## Create value

Value is created when we endure pain on behalf of our users. For instance, the SSL process in general is painful. The SSL integration within Pagoda Box was really really painful. We could have avoided it and forced our customers to deal with it. Our customers percieve value by ease of use, internally, that means solving painful problems for them.

Empathize with our customers. If they are feeling pain, we have an opportunity to create value.

Be cautious. Sometimes a user's pain is self-inflicted and could have been avoided.

## Ownership, not concensus

Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is "the buck stops here" and makes the final call on what happens with the owned thing.

The owner can and should collect feedback from others, but feedback is just that: input that the owner might or might not choose to incorporate into their work. If something doesn't have an owner, no one should be working on it or trying to make decisions about it. Before those things can happen, it has to be owned.

Ownership can't be given, only taken. Ownership can't be declared, only demonstrated. Ownership begins with whoever creates the thing first. Later the owner may hand it off to someone else. If an item gets dropped for some reason, it's fair game for anyone else to pick up.

Apple's term for an owner is ["directly responsible individual," or DRI](http://www.quora.com/Apple-Inc-2/How-well-does-Apples-Directly-Responsible-Individual-DRI-model-work-in-practice).

Ownership may be revoked when:

- any of the aforementioned principles (style, elegance, simplicity, completion) are not observed
- the goals of the thing or project are not in sync with the vision of the company
- the decisions of the thing or project do not take the scale or growth of employees into consideration

## Ignore the competition (for the most part)

We're not a "me too" company. We innovate and trust our process. We don't make decisions to copy someone else.

At times standards and conventions are established by competitors and observed by the community at large. We cannot ignore these standards just because a competitor established them. Git is an example of this.

There are times when we need to make a strategic move to position ourselves in the market. This positioning is relative to the competition. We may incorporate features to apply leverage. Consider sublimetext's positioning within the textmate market as an example.

Competitors have good ideas too. Borrow them if they fit.

## Strong opinions, weakly held

Have a strong opinion and argue passionately for it. But when you encounter new information, be willing to change your mind.

Be blunt, honest, and truthful. Constructive criticism is the best kind. Avoid keeping quiet with your criticism about someone or something for the sake of politeness. Don't say something about someone to a third party that you wouldn't say to their face.

Be honest with yourself about your perspective. If you recognize that you are arguing for the sake of argument, withdraw from the debate.

If you recognize that you do not understand the entire perspective of those within the debate, speak up. Often times we don't understand the problem that is being discussed. If you find yourself in this situation, speak up. You cannot participate in a debate about solutions to a problem that you do not understand.

## Own up to failure

Did you make a mistake by posting to the blog at the wrong time? By failing to document the feature before you shipped it? By screwing up a customer's app? By not respecting someone's ownership, or hurting someone's feelings?

Own it. Admit your mistake, say you're sorry (when applicable), and feel the failure to make sure you learned from it. Then, get back to work.

## Work hard

Working hard and staying busy should make you happy.

There will be always be a need for hard "brow to the plow" work ethic here.

## Be happy

If you cannot be happy working for Pagoda Box with these expectations, you shouldn't stay. Ultimately, you should be excited about quality and that Pagoda Box holds such high standards. If this is not the case, you need to find a new direction for you to be happy. We can assist you in this if you'd like.
	## You are an artisan, not an engineer

	An engineer makes something work. You are more than that, you are an artisan. Artisans practice a craft and may through experience and aptitude reach the expressive levels of an artist.

	Approach your work as a master craftsman.

	Demand perfection of yourself.

	## Style matters

	Just because we're building infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See [The Substance of Style](http://books.google.com/books?id=MqdydvbWZgEC)

	Slick and fun meets powerful and serious.

	Style is expressed through design and workflow. Workflow and design will dictate architecture.

	Never build anything without considering the workflow of our consumers or internal team. If the workflow is flawed, the architecture is flawed.

	A workflow/design iteration can and likely will require an infrastructure refactor.

	## Maniacle focus on elegance and simplicity

	Passion and concern for your work is demonstrated by your work.

	A lack of concern for cleanliness is a strong indicator that you don't care.

	A product that simply "works" is a prototype, a finished product should be considered a work of art that you want people to admire.

	Take multiple passes to consider ways to make your code more expressive, elegant, and clear.

	It should be obvious to the next person who looks at your code that you care.

	## Finish the job

	A product is not finished when it simply "works". A finished product should be clean, documented, and tested.

	If the product is a webservice, it should have at minimum a CLI to manage it. Sometime a web ui is needed.

	Your product is not finished if you are the only person who can use it. You must have produced the necessary tools to manage the product, the documentation to reference, and a demonstration to at least on other person.

	## Timing is everything

	If you're building something and just can't seem to get it right, maybe now isn't the right time. You learned something in the attempt, set it down for a while. Maybe in a few weeks or a few months you (or someone else) will pick it up again and find that the world has changed in a way that makes it the right time to build the thing.

	Consider the SHOVEL network as an example, wherein we spent 3 years attempting to build it and had to put it down dozens of times before the design was right, and the tools (OS) were sufficent to support it.

	## Throw it away

	It's not the code that is valuable, it's the understanding you've gained from building it. See [James' startup school talk](http://www.youtube.com/watch?v=3BhDLm9jo5Y).

	Never be afraid to throw something away and do it again, it will almost always be faster to build and much better the second (or third, or Nth) time around.

	## Everything is an experiment

	Anything we do -- a product, a feature, a standing meeting, a workflow or colloboration tool -- is always subject to change. That includes discontinuing or shutting down whatever the thing is. Ending an experiment isn't a failure, since we often learn the most from experiments that don't produce the results we wanted.

	## Question everything

	The status quo is never good enough.

	See:

	* [The Innovator's Dilema](http://books.google.com/books?id=SIexi_qgq2gC)
	* [Blue Ocean Strategy](http://books.google.com/books?id=BmPPAjGaDuQC)

	## Use your intuition

	Hunches guide you to places to create new value in the product. Users don't really know what they want. Creating products people loves requires treating product development as an art, not a science; but products have to solve real user problems. Understanding impact of product changes to existing product is best done by mining the data. When you have a mature product and many users you have lots of data on how they are using it. Use that data to make evidence-based decisions.

	Don't just do something because a customer "needs" it. Be wise, use your intuition. Work to understand the real problem and design a solution that solves their problem in the best possible way, perhaps not the way they thought.

	See: [Inspired: Created Products People Love](http://books.google.com/books?id=nE7NMQAACAA)

	## Create value

	Value is created when we endure pain on behalf of our users. For instance, the SSL process in general is painful. The SSL integration within Pagoda Box was really really painful. We could have avoided it and forced our customers to deal with it. Our customers percieve value by ease of use, internally, that means solving painful problems for them.

	Empathize with our customers. If they are feeling pain, we have an opportunity to create value.

	Be cautious. Sometimes a user's pain is self-inflicted and could have been avoided.

	## Ownership, not concensus

	Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is "the buck stops here" and makes the final call on what happens with the owned thing.

	The owner can and should collect feedback from others, but feedback is just that: input that the owner might or might not choose to incorporate into their work. If something doesn't have an owner, no one should be working on it or trying to make decisions about it. Before those things can happen, it has to be owned.

	Ownership can't be given, only taken. Ownership can't be declared, only demonstrated. Ownership begins with whoever creates the thing first. Later the owner may hand it off to someone else. If an item gets dropped for some reason, it's fair game for anyone else to pick up.

	Apple's term for an owner is ["directly responsible individual," or DRI](http://www.quora.com/Apple-Inc-2/How-well-does-Apples-Directly-Responsible-Individual-DRI-model-work-in-practice).

	Ownership may be revoked when:

	- any of the aforementioned principles (style, elegance, simplicity, completion) are not observed
	- the goals of the thing or project are not in sync with the vision of the company
	- the decisions of the thing or project do not take the scale or growth of employees into consideration

	## Ignore the competition (for the most part)

	We're not a "me too" company. We innovate and trust our process. We don't make decisions to copy someone else.

	At times standards and conventions are established by competitors and observed by the community at large. We cannot ignore these standards just because a competitor established them. Git is an example of this.

	There are times when we need to make a strategic move to position ourselves in the market. This positioning is relative to the competition. We may incorporate features to apply leverage. Consider sublimetext's positioning within the textmate market as an example.

	Competitors have good ideas too. Borrow them if they fit.

	## Strong opinions, weakly held

	Have a strong opinion and argue passionately for it. But when you encounter new information, be willing to change your mind.

	Be blunt, honest, and truthful. Constructive criticism is the best kind. Avoid keeping quiet with your criticism about someone or something for the sake of politeness. Don't say something about someone to a third party that you wouldn't say to their face.

	Be honest with yourself about your perspective. If you recognize that you are arguing for the sake of argument, withdraw from the debate.

	If you recognize that you do not understand the entire perspective of those within the debate, speak up. Often times we don't understand the problem that is being discussed. If you find yourself in this situation, speak up. You cannot participate in a debate about solutions to a problem that you do not understand.

	## Own up to failure

	Did you make a mistake by posting to the blog at the wrong time? By failing to document the feature before you shipped it? By screwing up a customer's app? By not respecting someone's ownership, or hurting someone's feelings?

	Own it. Admit your mistake, say you're sorry (when applicable), and feel the failure to make sure you learned from it. Then, get back to work.

	## Work hard

	Working hard and staying busy should make you happy.

	There will be always be a need for hard "brow to the plow" work ethic here.

	## Be happy

	If you cannot be happy working for Pagoda Box with these expectations, you shouldn't stay. Ultimately, you should be excited about quality and that Pagoda Box holds such high standards. If this is not the case, you need to find a new direction for you to be happy. We can assist you in this if you'd like.