What You Won’t Do Defines You

We often define ourselves by what we strive to build, the markets we want to enter, the customers we want to serve, and the visions we want to pursue. These are of course necessary, but they are not defining. The deeper source of identity is not what an organization chooses to do. It is what it chooses not to do.

This is uncomfortable because possibility feels like power. A capable team can always imagine another feature, another market, another customer segment, another partnership, another product line. The temptation is especially strong for talented founders because talent creates options, and options create the illusion of progress. The more a team believes it can do, the more vulnerable it becomes to doing too much.

But strategy is not the accumulation of possibility. Strategy is the disciplined rejection of most possibilities.

A company does not become distinct merely by having ambition. Ambition is abundant. What makes a company distinct is the courage to refuse attractive alternatives. The refusal to venture off into yet another direction is what gives a company its shape. It tells the team what matters, tells customers what to expect, and tells the market what the company is willing to sacrifice in order to become itself.

Artist are seen as those that are free to chase their every imagination, but making a 2 hour movie work is painstakingly an act of constraint and commitment. Imagine the push back that comes from wanting to represent a seen so badly that you push the a $10M shot that lasts 10 seconds. Could you commit to it when everything inside and outside your world is saying it is falling apart? What makes art such an inspiring form of achievement is the commitment to see a singular vision though to the end for – well – what some would call “just a little piece of expression”.

Apple is known for going big on marketing and charging a lot for their products. What most don’t see is Apple is a hallmark of restraint. Apple is not simply Apple because it builds computers, phones, operating systems, or services. Anyone can have a vision for a great computer or experience. Apple is Apple because it has historically chosen control over ubiquity. Upgrades over legacy. It has preferred integrated experience over maximum openness. That choice requires saying no to many obvious opportunities: software for every device, infinite customization, broad compatibility at any cost, and the short-term revenue that comes from being everywhere. (In fact, their lack of constraint is what almost put them under early in their growth – but that is a story for others to tell. )

Those refusals are not incidental. They are central to the product. That isn’t to say their decisions are required for success, but making those decisions and sticking to their identity is.

Few would say Microsoft is not successful and they are a very different looking company. For most of its history they made an opposite choice. Its power came from not being tied primarily to its own hardware. Windows and Office became dominant because Microsoft chose scale, backwards compatibility, options via licensing and distribution across a vast ecosystem of machines it did not manufacture. That strategic refusal gave Microsoft its own identity. It was not Apple, and that was the point. Both companies are shaped more by what they refused as by what they pursued.

The same pattern appears in many industries.

A company making a fast car is not merely choosing speed. It is often giving up affordability, mass accessibility, or low-maintenance practicality. A luxury brand is not merely choosing premium materials or elevated design. It is refusing accommodate everyone’s requests – in fact – they hope they are not. A great restaurant is not merely choosing a menu. It is refusing to serve every taste, every trend, and every customer expectation. The strength of the experience comes from the boundaries around it.

Most people know it when they see it, but chaos, disorganization, and what can feel like a lack of brand identity is merely the manifestation of a lack of restraint. Picking your lane is not giving up on a grand vision, it is dedicating your time to a specific outcome; it is an example of discipline. It is the difference between a light and a laser.

Even Costco, which appears on the surface to sell almost everything to everyone, is built on disciplined refusal. Its model depends on giving up selection of a myriad of options for the same product. It carries a limited number of SKUs, uses warehouse-like stores, bulks up on few variation of a product, and optimizes ruthlessly for efficiency and value. It will not take profits that don’t meet within these restraints.

This distinction matters because every “yes” has a cost beyond the immediate work required. Every yes changes the product. Every yes changes the company’s internal logic and dilutes identity.

Yes you can do anything, but no we can’t do everything.

How do we decide that line?

Proving ambition with breadth is how companies lose coherence. Rarely all at once. More often, they lose it through a series of individually reasonable expansions. One more feature. One more customer type. One more exception. One more “strategic” partnership. One more “why not?” One more compromise that seems harmless in isolation but slowly erodes the original center of gravity.

The problem is not that expansion is bad. Growth often requires expansion. The problem is having expansion without a theory of refusal. An investor without a thesis is throwing money around. Even if they make wins it is not a story they can sell, and without that sale there is no fund.

Without a clear understanding of what the company will not do, growth becomes drift. The company may get bigger, but it does not necessarily get stronger. It gains surface area while losing definition.

This is why the question “What are we building?” must be paired with a harder question: “What will we never build?”

What customer will we not serve?

What feature will we not add?

What revenue will we walk away from?

What behavior will we not reward?

What pressure will we not yield to, even when yielding would make the quarter easier?

What do we cut?

As the great quote says: I don’t sculpt stone into what it should look like, I chip away all the stone that isn’t.

For founders, this discipline is especially important because early companies are fragile systems. A young company has limited time, limited attention, and limited resources. You are ALWAYS stealing from Peter to pay Paul – you can’t pay both.

With AI the lack of constraints required is the very dirt founder can now bury themselves in ten-times over. A product cannot afford to become many things at once – even if it is able to. The founder’s job is not merely to inspire motion. It is to protect the company from compounding motion it can not manage. By being weighed down by its options.

In this sense, refusal is not negativity. It is not small thinking. It is not fear. It is not the lack of vision. It is the architecture of commitment. Vision may be the destination, but focus is not blowing all your travel money on the first stop. It is not getting married on the first date.

To choose anything seriously you must give up many other things. The stronger the choice, the stronger the refusals required to preserve it. This is true for products, brands, companies, and creative lives. You do not become distinct by remaining available to every possibility. You become distinct by rejecting most of them with enough conviction that the few remaining possibilities can be pursued deeply.

The world does not suffer from a shortage of people willing to add more. It suffers from a shortage of people willing to define what must be left out. That is where real strategy begins.

Keep It Right-But-Light

A clearer standard for building well

Most builders have inherited a bad vocabulary for early product work.

We tell people to build an MVP, but the phrase has become so overused that it often clarifies less than it confuses. Some people hear “minimum” and interpret it as permission to ship something brittle, awkward, or barely usable. Others hear “viable” and inflate the work into a miniature production system, complete with abstractions, infrastructure, tests, edge-case handling, and design polish that may never matter.

To balance that out we encourage people to “just hack it together,” which pushes the pendulum into a different problem. Hacky can be useful when it means fast, practical, and unconcerned with unnecessary ceremony. But hacky too often becomes an excuse for bad work. It works in the narrowest technical sense, but some see it as license to create terrible unpleasant use, error laden, difficult to understand, and fragile the moment reality touches it.

This is the gap “right-but-light” is meant to name.

Right-but-light means building something correctly enough that it earns trust, while keeping it light enough that it remains easy to change. It is not about doing less work. It is about refusing to carry more weight than the moment requires. It isn’t minimal or maximal. It is that harmonious balance so many folks have trouble finding. We don’t hack down the scope to get away with a bad implementation, we do it so the one thing we choose to do is done well – while still not evergreen or perfect.

The “right” part matters because users do not experience your product through your intentions. They experience it through the surface area you give them. A button that is twice as large as it should be may not break the system, but it may still signal that your offering is dangerously unkempt. A workflow that technically completes the task but makes the user think too hard won’t get used – at all. A prototype that loses data, hides errors, or makes the user feel unsure doesn’t give you the real signals you are looking for. These things may be excusable in a throwaway 24-hour hack-a-thon demo, but they are not balanced for an initial product seedling. They train the builder, the user, and the team to tolerate roughness where clarity was needed.

The “light” part matters because early certainty is usually fake. At the beginning of a product, most of the important learning still has to happen. The shape of the problem will change. The user may care about a different part of the workflow than expected. The thing you thought was a feature may turn out to be a demo path. The thing you thought was temporary may become the center of the product. In that environment, heavy architecture is often a liability disguised as discipline and thoughfulness.

A right-but-light implementation avoids both forms of waste. It does not ignore usability in the name of speed, and it does not overbuild permanence into something that has not yet earned permanence.

This distinction has become more important with agents. Human teams already struggled with the nuance between fast and sloppy, or thoughtful and overbuilt. Agents amplify that ambiguity. Ask an agent to “build an MVP” and it may produce a sprawling approximation of a real application. Ask it to “make it hacky” and it may skip the very details that make the product usable. The instruction was vague, so the output becomes a coin flip between underbuilt and overbuilt.

“Keep it right-but-light” is a better constraint because it tells both the human and the agent what kind of tradeoff is being made. The work should be correct in the parts that matter. The interface should be understandable. The happy path should feel intentional. The data should not vanish. The user should not have to forgive the product in order to use it.

But the implementation should remain light. Maybe the data lives in a JSON file before it earns a database. Maybe the workflow is hardcoded before it earns configurability. Maybe the UI uses an existing design pattern rather than inventing a new system. Maybe the feature does not need role-based permissions, event streams, audit trails, background jobs, and a full settings page on day one. Maybe the right version is simply the smallest version that behaves with taste.

Right-but-light also gives teams a cleaner stopping rule. The question is not “is this complete?” because early products are almost never complete. The better question is: “Is this right enough to learn from, and light enough to change after we learn?”

That question changes the conversation. It moves the team away from false binaries. You are no longer choosing between a disposable hack and a production-grade system. You are choosing the minimum level of correctness required for meaningful use, and the minimum level of structure required for responsible iteration. Yes, that is what MVP and lean startup. It is just that I have tried for YEARS to explain that to people and it either doesn’t land or get me in to trouble with “you said to do the minimum!”

For example, a right-but-light onboarding flow may not need analytics dashboards, branching personalization, enterprise configuration, and a polished admin panel. But it probably does need clear copy, coherent visual hierarchy, a reset path for testing, and enough state handling that the user does not get trapped. A right-but-light internal tool may not need a formal database schema or complex permissions. But it probably does need predictable inputs, readable outputs, and error states that do not require the builder to stand nearby and explain what went wrong.

There are many great product folks out there building things you love, and I am sure you have used a product you loved and realized there was no delete button and wonders “WTF? Why can’t I delete?!”. If you get a req for your unaware peers in different departments they would have died on the sword to put the obviousl “delete” in on v1, but no feature is truly “simple” and without a time cost. So, that product manager says “they need to love what they create before they need to delete.” One less unit of time for one side of the product, one extra unit of time for another. No one has infinite time or infinite money. No one.

So how do you chose? The point is not to lower standards. It is to place the standard in the right part of the work and be okay with walking away from the other.

Long-lasting applications deserve robustness, scalability, observability, automated tests, security reviews, edge-case handling, and design precision. But not every early feature has earned that full burden yet.

Premature permanence slows learning. It turns every change into a negotiation with yesterday’s assumptions.

Speed without standards is not iteration. It is motion. Wheels spinning fast in the mud.

It asks for seriousness without heaviness. It asks for speed without sloppiness. It asks for taste without vanity. It asks the builder to cut everything that is not required, while doing the remaining things with care.

That is the deeper meaning of the phrase.

Right-but-light is not another way to say MVP. It is a correction to what MVP has become. It restores the part people forgot when “agile” and “MVP” became a household term.

Can You, Did You, and Taste

Three stages separate ideas from products, and products from things people love.

The first stage is capability.

Can it be done? Can the software be written? Can the company be started? Can the product be built? Can the problem be solved?

These questions matter because capability is the foundation upon which everything else rests. Nothing can be executed, adopted, or admired until it is first plausible.

This is where most people rest comfortably.

The surprising thing about capability is that proving something can be done often provides many of the same emotional rewards as actually doing it. Once someone becomes convinced they could build the company, write the book, get in shape, learn the skill, or launch the product, the pressure largely disappears. Potential becomes a source of comfort.

The entrepreneur enjoys imagining the startup. The author enjoys discussing the book. The engineer enjoys architecting the system. The athlete enjoys knowing they could get serious whenever they decide the time is right. People tend to love their own brains and marvel at what it can achieve. Potential is attractive because it is free from accountability. It cannot fail because it does not yet exist.

Did you actually do it?

The second stage is execution. It only lives in the past tense. This is where the conversation changes. Ideas become products. Plans become companies. Discussions become outcomes. Concepts become features available for use and critique to the public domain. The world stops evaluating intentions and starts evaluating evidence.

A customer cannot buy potential. A user cannot interact with ambition. An investor cannot generate returns from possibility alone (though they push this rule as much as possible). The market, unlike our friends and colleagues, is remarkably indifferent to what could have happened. It only responds to what did happen.

People who reach this stage deserve significant credit. The distance between an idea and reality is far larger than most people appreciate. Building something that survives contact with the real world is difficult. Something complete, end-to-end. It accomplishes its intend (big or small) and no hand holding or excuses are needed for it to be used properly. Launching is difficult. Selling is difficult. Maintaining momentum is difficult.

Most people never get there. And I am being generous with “most”.

Yet many who do arrive at execution mistakenly believe they have reached the finish line. They assume that because something works, people will care. They assume that because a solution is objectively better, adoption will naturally follow. They assume that utility alone is enough. They believe a logical use case exists and therefore usage will follow. A good plan and execution is all that is needed.

History suggests otherwise.

The graveyard of technology is filled with products that worked. Many were faster than their competitors. Many were technically superior. Some were years ahead of their time. Their failure was not one of engineering. Their failure was assuming that human beings make decisions primarily through logic.

Taste.

Taste is one of the most misunderstood concepts in business because it is often reduced to aesthetics. People hear the word and think about typography, color palettes, industrial design, architecture, or fashion. Those things matter, but they are only symptoms of something deeper.

Taste is the ability to understand how another human being will experience what you have created.

It is the recognition that people do not merely consume functionality. They consume stories, emotions, identity, aspiration, status, trust, culture, and delight. A chair is not simply somewhere to sit. A restaurant is not merely a place to eat. A home is not simply shelter. A product is not just a collection of features. Even a purposefully poort taste for those that are tasteless is, in fact, a taste. The trickle down story line of decisions and focused intent lead to those that have the same test to become interested. Taste is not being fashionable, it is knowing people need clothes and certain groups of people like cheap clothes, some like expensive clothes, and some like expensive clothes that are on sale – but they know which group of tasters they want to have.

Every meaningful creation eventually becomes an experience.

This is why two products with nearly identical functionality can produce radically different outcomes. One becomes beloved while the other is forgotten. One creates a movement while the other creates a user base. One becomes part of a person’s identity while the other remains a tool.

The difference is often explained by taste.

The creators who understand taste recognize that presentation is part of the product. Storytelling is part of the product. Culture is part of the product. The emotional experience surrounding something is not separate from what is being built. It is one of the things being built.

Most people spend their lives asking whether something can be done. A much smaller group proves that it can. The rarest creators understand that neither capability nor execution guarantees significance.

The first stage asks whether something is possible.

The second proves that it is.

The third determines whether anyone cares.

Updated Review of LLM Based Development

I tried developing using GPT mid-2022. While I was amazed by the potential, I was not impressed enough to add it to my daily development workflow. It fell off my radar as a development tool, outpaced by a far more impactful use of text generation and image creation. A toolset that has significantly changed my day-to-day productivity.

Recently, a group of peers convinced me to give coding with LLM another shot. They loved using A.I. to develop code in languages they were not comfortable with. Or, as a manager, a way to better explain what they wanted to see in a project from their team. What convinced me to try it again was their highlighting of how well the results were formatted, syntactically correct, and well documented from the get-go. While they admitted the development of code may not be faster, the prospect of all those benefits culminating into a cleaner, well formatted final product convinced me to develop with GPT again in earnest.

I began my reexamination of the tooling via demos, as we often do. I was very impressed. I converted code into PowerShell (which I don’t know well) and re-created functionality I came across in weeks prior. I was so impressed, I showed my team examples of how the work they completed in the past could’ve been done with the help of GPT instead.

After those successes, I committed to using GPT to develop. Over the next few weeks I made sure to use it on projects I was working on.

While the technology showed incredible advancements since I tried it last year, it still hasn’t become my go-to in the same way using ChatGPT has for writing content.

Here are some areas I was both impressed with but left wanting:

Code completion
- Pro: Impressive. The look-ahead came in handy similarly to code-completion functionality of the past, with the added benefit of more contextual relevance that was not just a “cookie cutter” snippet.
- Con: It gave me a useless hint quite a bit and I found myself typing almost as much as before with the incumbent “dumb completion”. I think it is because my mind is moving ahead to what I want the code to do, not necessarily what it is doing on the console at the moment. In the end, it is using patterns to make predictions. So, any new code that is a result of changes to my approach, or my on-the-fly reworking to fix a bug (that was not due to syntax issues) took as much time to develop as non-GPT-based code completion.
Testing
- Pro: When it comes to testing an existing application, the A.I. hits it out of the park. Ask it to “write a test for myFunction() using Jest” it creates an awesome base test case that I would have hated to write for each function.
- Con: Some of the same issues outlined in the “Code Completion” and Functional Development” can be problematic here. It doesn’t always create a great test for code I haven’t written yet. (i.e. TDD) However, if the code is already there, it uses that context I’ve provided and its LLM to unpack what it the function is suppose to do and generate all the mocks and assertions needed to create a well written unit test.
Functional Development
- Pro: Much like helping me get past the dreaded blank page in text generation, I found it more useful than Google searches and StackOverflow reviews to develop a series of functions I wanted, without developing entirely from scratch. Better than code snippets, the snippets A.I. gave were pre-filled based on my prompts, variables, and existing object definitions. That was appreciated. I didn’t have to review the documentation to tweeze out the result I wanted. The A.I. pulled it all together for me.
  Additionally, the fact that it almost always has an answer goes under appreciated in other reviews I’ve read. The part that makes it so advanced, is it fills in a lot of grey area even if I (as a stupid human) carelessly leave out an instruction that is critical in generating a solution. If I were to get the response, “could not understand your request” due to my laziness, I would never use it. The assumptions it makes are close enough to my intent that I am either using the solution, learn a new path, or see what my explanation is missing so I can improve how I communicate with it.
- Con: The end result did not work out of the gate most of the time. Sometimes it never got it correct and I had to Google the documentation to figure the issue. This was due to what I think was more than one documentation existing for various versions of the library I was using. I’m not sure. While the syntax was correct, the parameters it assumed I needed, or the way the calls were made to interface with a library/API led to errors.
Debugging
- Pro: Per the “functional development” points above, I was impressed at how I could respond to a prompt result with “I got this error when using the code above: [error]”. It recognized where it went wrong, and attempted to rewrite the code based on that feedback.
- Con: Each response had a different result than the original. So, instead of fixing what I found was wrong (like a param missing) it also added or removed other features from the code that were correct. This made the generated result difficult to utilize. In some cases, it could never understand the issue well enough to generate working code.

One limitation I am not too surprised about, and am hopeful to see evolve in the future, is the AI’s understanding of a project in its entirety. Done so in a way that context is used in its function creation, making the solutions it provides “full stack”. Imagine a Serverless.com config, for an AWS deployment, that generates files and code that creates and deploys workflows using Lambda, DynamoDB, S3 and so on, all being developed based on prompts. With the yearly (and more recently) weekly leaps, I don’t think we are to far away.

As of today, I find myself going to GPT when filling in starter templates for a new project. I find it’s a much better starting point than starting from cookie cutter function as I set up my core, early, “re-inventing the wheel”-type, skeleton.

For example, I will use a Gitlab template for my infrastructure (be it GL Pages, Serverless, React, nodejs or Python and on and on), then fill in the starter code an tests via a few GPT prompts, and copying them over. Beyond that copy, I find myself detaching from GPT for the most part, and returning to occasionally “rubber duck” new framework functions.

Examples referenced above

Here I asked for a non-3rd-party use of promises (only await/async) which worked. Then I asked to modify the code by adding a zip task, and it re-introduced the promisify utility when it added the zip process.

Finding Nebo

In my journey from being “a writer hater to a writer lover”, finding the Nebo app was a defining moment. Of all the apps I tried, only Nebo could recognize my chicken scratch, retain my handwritten texts for review, and allow me an edit the original text before converting it to type.

Nebo beautifully melds the written form, digital tech, and typography. Its edit-gestures feel incredibly natural, the digital ink flows like your favorite pen, and the final product is compatible with the modern world. I’ve gained in all mediums and compromised in none.

It’s rare to find an app drives you to create opportunities to find excuses to use it. Especially when the app exists to enhance the mind, not rot it.

Feature Highlights

Chicken scratch interpreter

I’m amazed at how well the interpreter is, able to convert my god awful handwriting to text. It seems to combine A.I. OCR handwriting with grammar to assume a nearest approximation of what I’m trying to write. Whatever the methodology, the results far better than apple’s built-in note taking app.

Inline Editing in ink or between typed notes

In the event the interpreter fails, the editing features makes correcting easy and fun. For example, handwritten text is retained until you double tap it to convert to type.This allows you to review your writing before conversion. You can also preview the converted text in a banner scrolling horizontally above.

Wish List & Nits

Night/Dark Mode

Sometimes inspiration strikes right as I’m getting to bed. I reach for my iPad, open Nebo, and BAMB! An intensely white screen blinds me as my eyes try to adjust.

More Heading sizes

Simply put, H1 looks like H2, and I can’t bold text on Its own line without it becoming a heading. So, new H3?

Clearer New Line & Erase Interpreters

I like the natural feel of gestures. However, I find my self trying to gesture a new line over and over to no avail. I think the app can be smarter. Why not assume one new line is available, infinitely until converted. So, when I hit the end of a line I don’t need to gesture in the first place.

The question that keeps you up at night IS the sign you’re looking for

Have you ever woken up every morning with the same question burning in your mind? Do you constantly wonder if it’s worth changing paths, environment or career day-in and day-out but continue convincing that part of your mind to quiet down? Do you think you could make a decision to act if you had a sign, or a clue, or some sort of guidance from someone more experienced than you that could “show you they way?”

About 10 years ago I had those thoughts swirling in my head. I had a good, secure well-paying job and a bright future. Though, for some odd reason, I woke up constantly with those questions burning inside me day-to-day and week-to-week. “Why can’t I just be content with what I have?”, I would ask myself. “What’s wrong with me?!”

I convinced myself changing paths would be a form of quitting – and I was no quitter. Some friends would explain to me how “life is hard. No one likes what they do. Everyone has those questions – it’s normal, but you keep working until you get over them. Eventually they go away. Anywhere you go you’ll ask the same thing. Everywhere in the world is the same. You’re just running from your problems. Deal with it.”

It sounded like mature advice to me so I tried to overcome the doubts and concerns I had about my current path. Unfortunately, letting go of the questions turned out to be pretty impossible.

I got it in my head that I wanted more, something different, something challenging and I couldn’t kill that thought. I wanted to move to SF and be part of the startup community. I wanted to create things people used. I wanted to meet others that created the things I loved to use. Friends on the other side of the advice fence validated those thoughts telling me “it would be a great fit. Quit what you’re doing now and just go!”

How could I decide which piece of advice was right? Both had their merits and both came with a fair share of doubts. Growing as a person by learning to be content didn’t really feel like a great life-goal and quitting to follow a curiosity seemed irresponsible. As Kenny Rogers would say, “You’ve got to know when to hold them, know when to fold them” but how do you know when that is?! Why didn’t Kenny answer his song’s question?!

As my freshly shaven cheek chafed against my frosted collar while walking to work on a frigid winter day in DC I decided enough was enough. If there isn’t a clear logical answer to stay or go then I would break the tie on weather. I don’t care if it’s right or wrong – I was going to make the move. I was done with the cold. I quit my job, got on a plane and flew to a city that I had never seen with no work waiting for me on the other side. When what I’d done truly sank in at 30K ft I went to the bathroom and threw up.

Of course, I will never be happier that I came. Without a doubt, it was the best decision I’ve ever made. I realized this as I was walking home from my first job at a cool new startup in SF. I paused to catch the sunset of a spectacular view from the street, groceries in hand, when it hit me – I hadn’t had a sleepless question-filled-night or pensive morning in – well, since I arrived. Sure the process was scary, but the questions were gone. I still had tons of work to do and was working extremely hard, but, now, I had an open mind to do it. Life felt right again.

It was important to me to try and distill a lesson from this experience so I would never have to go through that period of agonizing unknowns again. After all, staying back in DC could have been the right answer too. Sometimes you are running from problems and need to face them in order to grow. On the other hand, it’s important to follow your dreams; life is short. So, do I know now how to make the right decision again when the time comes? What did I learn from all this?

The answer IS the question.

Yeah. It really is that simple. No, the “answer” isn’t any old “question.” It’s the questions that burn inside you. The ones that wake you up and put you to bed. The ones that you debate between constantly and ask advice for every chance you get. The ones spawned out of an interest to learn something different. Those are the questions I’m talking about. Those are the question that MUST be answered. They are answered through creating your own experiences.

Well, what if I follow that logic and I’m wrong?

That’s the beauty of these gut-wrenching questions. As I learned, even if I was wrong, the questions I had went away – they got answered. My mind was free and a freer mind can do so much more than a plagued one. So, you see – it’s a win/win. Either be half the person you are because you are preoccupied mentally every day with a burning question or be half the person you are because you made a bad decision. Only attempting the latter will leave you net-positive with no more questions and an ability to work towards living fully and clearly once again.

The mission to create space in your mind for thoughts to grow is paramount to moving forward positively in life. It is accomplished by oscillating back and forth between curiosity and answers. I realized there is a version of life that does not have the burning question running through my head every day (that was the fallacy in some of the advice I got early on.) Yes, life has its challenges and problems and it is important to work through them, BUT it’s a waste of life to circle around the same question. It deprives your mind of answers it needs to free up space so it can grow and more forward.

What do I tell those that ask me what to do next when they have a difficult question burning in their minds and causing tons of stress? I say the question IS the answer. Your body is your sign. Whether you are wrong or right it is important to know if you are indeed wrong or right. That knowledge is the catalyst that sets off the ability to ask and answer even more important questions, building answers upon one another to form clarity. Finding that answer clears the mind for more to fill.

Why am I writing this story almost a decade after it happened? Sadly, it happened to me again this past year. I’ve given this advice to so many people looking for direction yet I lost sight of it myself when the questions began to form in my mind again. It grew so subtly over time. This time, I made the excuse that it was different since I was older. That this time there was more to lose. And, yes, the concept of not being a quitter became more of a focus than learning, growing, exploring and building. I am writing it because I was wrong again and this is a message to me as much as it is to you. Your deepest hardest questions are only asked when your mind knows that it needs to find an answer. Your questions ARE the answer.

What a company manifesto means to me and what I would expect it to accomplish

A Manifesto reveals the strengths and values within a company, and does so in a way that decreases the number of complex decision making hurdles for its employees in the day-to-day.

The manifesto will be “the bible” (though only a page) of reasons that lead a team without a need for individual leaders to be present, and can help create the next generation of leaders to form in the same vein.

It relieves people from the stresses and distractions inherent to complex (or seemingly complex) decisions, in the middle of the workday, while fighting in the trenches.

Picture this: A team of army rangers are falling back in the middle of an amazonian battlefield. They realize one of their platoon members went missing while under fire. What do they do? Unorganized soldiers may scatter under this pressure and lose their head. Should the next step be “Every man for themselves!”, or “Let’s hide it out until morning”? Luckily this group of rangers knows that there is one core value that prevails in situations like this: “never leave a soldier behind”. – Boom, decision made. They spend their time devising a plan to find him first and foremost (no matter the hurdles – it will be resolved).

Values help form a strategy. Most importantly, when things go wrong, values help keep the bigger picture moving tactically. Especially when “fires” make decision making difficult. Plans fail, but values do not.

More practically speaking, the battles on a tech company’s floor may be less tragic, but are battles nonetheless. Imagine there is a team developing a widget. It is done so with poor (if any) design, but is backend-ready and functional. A discussion may come up around the pros and cons of deploying something that doesn’t look good but is ready to ship for testing. The debate could rage on, but, with a core manifesto that decision is already made: if the core value says design is key to our tests – then the decision is made to implement a design before deploying. If the core value says release when ready and iterate – again the decision is already made.

Those decisions shape a company and should not change week-to-week, problem-to-problem, or day-by-day from department to department. They shape outcomes and the character of a company through a decision tree that is easy to repeat. Consistent and efficient decision-making is more important than re-assessing the perfect decision for the situation each and every time it comes up. The written word is amazing at facilitating that.

Of course, we all have great thoughts and your company has awesome values already, but having them written down is the difference between an interesting legend shared by some and a religion followed by many.

Documentation, although necessary, does not substitute for a short list of values. Documentation is rarely re-read, and often forgotten; we remember “Go when green” not “Statute 32 Section 5: All those that use public road shall obey stop lights based on the following color …..”

Finally, it is extremely important that your list of values are glossed over. One lazy move away from following your values can easily turn into a utter mess over the years. That does not mean you can’t change your values. If a situation comes up, and your values does not represent how you want to act two things MUST happen: 1) You re-examine your values and change them accordingly or 2) You adjust the situation to fit your values. Period.

As for my suggestions regarding the setting for how a document can be built as a team here are some thoughts.

Make sure people feel heard (i.e. right down every idea)
Help filter outlaws that promote restrictions (which end up being things people feel reprimanded for doing) and turn them into the concept that create direction and productivity to help people grow, expand, and focus. It is a document of supportiveness.
Use it to help give people clarity in situations that need tie breakers, or rules of thumb. For example, “future value does not trump current value” has saved our team from missing out on what we have while over planning for something we do not.
Be clear on what an item suggested means when it is written (often times one person’s perspective on what “awareness” can be, for instance, is different than another’s) Be descriptive.
Find a/the person that matches the essence of what a manifesto item describes. They will most likely be the champion of that thought and help keep it alive and well. Find the passion in the people and you will also find the strength in the doc.

I believe once the fundamental concepts are solidified into the manifesto it becomes a spine for current, and as importantly, new employees that come in so they can quickly latch onto and adopt the companies process/thinking as it expands in size.
There will be the debate over the items presented, and debate is good. As such, it may also be a good idea to nail down some keywords that keep the conversation on track to what we believe the manifesto points should adhere to.

The words I propose are:

positive
smooth
friendly
helpful
productive

If an item does not instill many of these words, for instance, then the item may be off track.

Erec Makes A Fire: A Children’s Book About Entrepreneurism

Erec Makes a Fire was successfully funded on Kickstarter! Thanks for all your support.

What is the book about?

Erec Makes a Fire is a story of how a group of kids stumble upon a cave covered in ancient writings depicting the story of how a unique young cave boy (Erec) accidentally created his first great invention, fire. The story shows how, even in the simplest of times, one is able to form a business, sell a product, and create a success. The book is written to subtly embed one of the most fundamental parts of business in a child’s mind: leveraging an opportunity when finding demand in your community and providing a supply for it. Even before cash, computers, technology, LLC formation or business entities, business and entrepreneurs thrived through observation and invention, and they still do so today. This story helps teach youngsters, and remind their parents, that entrepreneurism is all around us and to keep an eye out for one’s own personal “fire” opportunity.

Why did I write the book?

As a person who loves the world of entrepreneurism, I also love telling a story about how anyone can turn a will or idea into a business. I have enjoyed telling that story, and giving tips on how to do it best, for a number of years through various mediums such as interviews in print, in person, and on TV. Now that more and more of my close friends are having kids I want to share that passion and story through a form that their kids can benefit from. I noticed there wasn’t much out there in the world of children’s books that took business concepts and simplified them into stories kids could love, as well as learn from. So, what else was I to do as an entrepreneur but to fill that void. Erec Makes a Fire is the first in a hopeful series of books that builds a foundation of business mindedness in our children.

Beliefs that inspired

Two major beliefs of mine contributed greatly to the creation of this story: First, immersion is a great key to early developmental learning, and secondly, kids are extremely capable of learning and understanding complex concepts early on, especially when it is told through story and analogy.

In regards to immersion, I believe that even if a child does not understand a concept introduced to them directly, being surrounded by that concept will help them become more comfortable with the subject matter as they mature. This makes the principles taught far less foreign to them, and therefore more easily consumed when they grow up, as compared to those learning the same concepts for the first time later in life.

I also believe that children can grasp complex concepts, like supply and demand or finance, far earlier in their lives than is generally taught today. I have always been amazed at how kids pick up core concepts so deeply. Yet, adults at times “protect them” from complicated concepts for worry of it going over their heads. Supply and demand can have complexities within – yes, but the basics are – well – basic and building stories around those concepts can most definitely be consumed by children. Look how well they understand other stories we give them, like ones around “how to share”, a concept that I find many adults still struggling to grasp. I remember sitting with adults during dinners as a kid while they talked to one another about their businesses around me. Over time and many family diners a grew more familiar with many of the things they talked about while still being a child. Although I was unable to articulate my perspectives on the subjects at the time I mades notes to remind myself that one day, when I got older, I would remember this: kids get more than you think.

Stickers — Sticker Collection Available Through KickStarter

Erec Makes a Fire is a new kind of children’s book that immerses young people in concepts they should be given the chance to understand early in life so that they can have a foundation for understanding it more deeply as they grow up. As such the company under which the book is created is called “Small People. Big Ideas. LLC”

How and When Can I get it?

The first few copies will be made available as gifted items through a fundraising drive on KickStarter. I have my initial proofs and prototypes complete. Based on how much I can raise through KickStarter I am shooting to making it available by the spring of 2015. There will be special gifts given out through KickStarter in addition to the books themselves to make things more interesting, such as: signed copies; custom printed copies; packages including digital, print version and stickers; as well as custom designs where our artist injects a characterization of your child into a character in the book! Books will be made available through softcovers, hardcovers, and ebooks.

About Kick Starter:

KickStarter is a crowd funding platform that allows projects to get funded before they start. It is a great way to start a business or project and works perfectly with the Erec Makes A Fire book as the funds are only released if the book gets enough demand. The simplest way to think of KickStarter is this: think of those PBS drives on TV, the “If you pledge more than $50 you get this free tote bag” type of promotions. For a project like mine my gift will be an early copy of the book and other creative unique offers mentioned above that only funders will be able to receive. You can read more about KickStarter here: http://www.kickstarter.com/help/faq/kickstarter%20basics#Kick

Erg: Erec's first customer as a Sticker — Erg: Erec’s first customer as a Sticker

Why Did you Spell “Erec” with an “e” instead of an “i” ?

The names of the book are witten with some historical significance in mind. Homo Erectus and Homo Ergaster are the scientific names for the two homonids believed to be around during the time period fire was discovered. So, the characters names in the book take each half of each of those names: Erec, and his friend Tus are the first two characters introduced. Followed by his first two customers Erg and Aster. Just in case though, we made sure Eric Makes a Fire works too 😉

Slides of Creative Process

Original Idea Draft	Draft Rewrites
Preliminary Sketches and Character Development	Backdrop Scene Development Sketches
Story Board Final Sketches	Final Sketches Converted to Digital
Final Layout Colored for Publishing

20130211-P1090359 — Printed Proofed Books

Get in to the cheering section and like us at http://www.facebook.com/ErecMakesaFire, and subscribe to email updates as we neat the big release here (http://signup.erecmakesafire.com)!

Fake Response Server: Slow response time generator

Here is another quick tool built on AWS. This one is super simple, but pretty handy. Today Twitter went down, and somewhere in our system we were using the Twitter API to display one of our status feeds. Them being down became us being slow.

Well, I wanted to do some quick tests to keep this from happening again, but byt the time I got to it Twitter was responsive again. To fix it I would need to create a bad URL. The crappy thing is I wanted a slow response time, not exactly a bad response/error. Creating a 404 error is easy, just go to some url that doesn’t exists and test. But I want a slowwwww response.

I quickly searched Google for something I could use, and didn’t find one. When I realized I would have to create a fake pause endpioint somewhere I figured someone else out there might benfiift from a quick public version of this system. So, I created fake response server. The first default endpoint available sleeps for a variable time.

https://fakeresponder.com

and add a sleep param to change the sleep time in milliseconds

https://fakeresponder.com?sleep=500

Nothing major, but why not publicize the tool incase it can help some other shmuck out there like me 🙂

Cheers.

What does coke, the bible, and good business gut all have in common?

On the car ride up from a meeting on sand hill, Daniel Odio interviews me in “the hot seat” on how process plays a pivotal role in your startup’s business success.