Skip to main content

Slicing Pie (Review)

I had the opportunity to review a copy of Mike Moyer's Slicing Pie: Funding Your Company Without Funds. Having worked at a number of startups at various stages,  I  was interesting in the insights this book gave into evaluating the value of and managing equity shares in an early company, before a company is making money, and before you have investors.

This seems like a book anyone involved in startups should read. Entrepreneurs can benefit from a reminder about the value of trust and fairness in dealing with those who join the company to help realize their vision. Those who join startups (even in later stages) can gain insight into the issues involved in bootstrapping a company. Anyone who works in small teams can gain insight into the psychology of motivation and compensation in team working to realize vision. This is a quick read, and the author uses frank, conversational language to explain the importance of fairness in dividing equity among founders.

The underlying concept is that, as an entrepreneur, you need to treat the people who join up early on to help you realize your vision fairly. This will sound obvious, but it's not a universal pattern. Part of the reason could be is that it's hard to know what "fair" is in the context of the uncertainty of a bootstrapping company. Value is uncertain and  people's commitment and enthusiasm can change over time. This book describes through how to define value and equity in a way that all the stakeholders can understand.

This book isn't just about philosophy, but presents a well defined process for managing equity in an early stage, unfunded company.  With case studies, examples, and online resources, this is a great book for someone looking to start a business, or someone thinking about getting involved in an early stage startup. For a short book it is very complete, covering not only the basic "equity" approach, but how the approach helps you to manage situations such as people joining and leaving the venture while still helping everyone to feel fairly treated.  This book is worth the time and the cover price for the information it contains. The book could benefit from some tighter editing, though overall the writing is concise and it's not hard to get past the few sections that are problematic. If you register the book on the author's web site you can get updates for free, so it's likely that my minor concerns about editing will be addressed promptly.

Overall this is a good book that provides actionable advice, for anyone looking to start a business, or join an early stage business.


When it comes to working with a startup practically no one only does the things their job title says they do. It's all hands on deck and everyone in pulling double duty for a long time, including your developers. Because startups are prone to changing so much before they "find their way" your entire team has to be ready to switch gears at the drop of a hat.
Steve Berczuk said…
What Kelby says can be true. But joining a startup does not mean that everyone is equally invested. While most people who join startups do so in part because they are energized by the concept, the possible return figures into what you can fairly expect people to invest. What I liked about the book was that Mike talked about fairness and expectations among all contributors, and not just business plans and investing.

Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…