Thoughtleaders & Euphemisms

You’re not a thoughtleader.

You’re not a visionary.

You’re not an innovator.

You’re not an luminary.

You’re not an influencer.

If you use any of the above to described yourself, chances are people roll their eyes when you do.

You are not your follower or friend count. You’re a single person.

When people ask me who I am and what I do, I have a simple answer:

I’m Griffin Caprio. I like to help people solve problems.

Nowhere in statement do I specify the size of problems, the types of people I help or how I try and help solve their issue.

I know when I’m talking to someone who’s lost their love for solving problems when they’re only interested in solving HUGE, WORLD AFFECTING ISSUES. Smaller issues are of no interest to them. They get the same look on their faces that other entrepreneurs do when I tell them I’m not interested in VC for my company.

I get the same kick solving issues for my friends as I do by solving issues for companies.

It’s incredibly satisfying to see the look on someones face when you’ve helped them.

Start focusing on that and less on altering the world. Start improving your surroundings.

In-House or Outsource?

One of the main challenges of starting a products based company is how do you build your product? This is especially true of web based companies, whose product consists of mainly a web site and very little more. For many companies, their web site is their lifeblood. Unless you’re fortunate to have one or more technical founders, you’ll quickly be faced with this simple question:

Do we hack out a prototype somehow, find a developer or outsource the development?

All have pros and cons ( only some of which are listed below ):
1. Create the prototype yourself

  • Cheap – this only takes up the time of your and your founders.
  • Total Control Over Implementation – Since you’re building it, you have the kind of fine grained control over everything.
  • Flexibility – You won’t need to commit to something, either cash, equity or involving other people, upfront. You can make decisions as needed.


  • Slow – You’re not technical. Depending on the level of complexity and difficulty, it might not be the most efficient use of your time.
  • Un-knowledgeable – Since it’s just you and your partners, you might not be making the best choices.

2. Find and hire one or more developers

  • Implementation Speed – Developers working full time will be much more efficient for you and your product since they’ll be dedicated to your company.
  • Technical Expertise – Bringing expertise in-house is the best way to foster communication and feedback when building a product.


  • Money – Unless you have cash to pay, the pool of developers willing to work for equity is small.
  • Equity – It’s not unheard of for a developer to look at a web based company, see that he’s asked to build the entire product and ask for a large chunk of equity as compensation.
  • Access – Good developers are tough to find.
  • Communication – Hiring a technical employee early on can sometimes result in a founder developer gap.
  • Need – If you just need a prototype or initial version of your product built, hiring a staff might be premature. While your team is trying to iterate and perform Customer Developer, your tech staff will be idle. And there’s nothing idle developers like to do more than think of new features to implement.
  • Lack of Knowledge – Building out a technical team when you’re not technical is fairly difficult.

3. Outsourcing

  • Capacity – development companies have people waiting to build your product.
  • Known Entity – You only need to guide the development of the product, they take care of finding developers, development process, etc..
  • Delayed Commitment – You don’t need to worry about hiring on people too early.
  • Cost – Outsourcing tends to be cheaper than hiring on developers and building your product internally.


  • Cost – Most development shops work on a cash basis. There are a few that take equity, but a ) they’re rare and b ) you’re making a significant decision about your company pretty early on. If the relationship sours for some reason, severing it could become pretty hairy.
  • Lack Of Communication – Typically there is a very “over the wall” approach to development where you specify requirements upfront and they give you what you specify. The type of day-to-day communication that takes place when developing a product is limited when the development staff is outside of the actual company.
  • Lack of aligned interests – While there is a desire to perform good work, development shops are not necessarily looking at the long-term outlook for your product. They may make certain concessions or decisions that could hinder the flexibility of your application

There is also a hybrid variant of #2 and #3 above that I’ll call a development partner. A development partner is an consulting company that works very closely with you, similar to an internal development staff. They are looking at a long term relationship and are more likely to take a craftsman approach your product development. Thus, they typically take a vested interested in ensuring whatever they build will be able to evolve with the company. Lastly, they are more likely to take reduced rates, be open to a debt-to-equity relationship with you and your company or some other more flexible compensation setup.  

So given all of that, which should you choose? Well, like most decisions, it depends:

  • #1, from my point of view, is out. If you’re not someone who can get up to speed VERY quickly and hack out a rough prototype, it’s simply not worth your time and effort to make the attempt. Unless, of course, it’s your very, very last option. Options #2 & #3 would have to not be possible for you to go this route.
  • #2 is also difficult, though not impossible. It’s only a viable route if you have to cash to hire someone and you can keep them busy enough with relevant work, not just aimlessly spinning their wheels. Without the cash, you’re very close to being DOA. Most of the technically inclined engineers who would have the itch to work at a start for equity are already working on their own idea.
  • #3 is a viable option if the relationship is properly managed and the product itself is fairly well thought out ahead of time. However, it should be known that, especially early in a products history, it will fluctuate. Having a outsourced relationship that can withstand those fluctuations is critical. You should place a premium on outsourced companies where the speed of feedback and communication can be the quickest.

In the end, I think there are two preferred routes: either find a development partner or hire a technical advisor or CTO-type person to manage an outsourced, development shop relationship. For the former, the partner you choose should be flexible enough to work in small bursts for you, as needed. In the case of the latter, this keeps your staff and employee commitments down. The latter option also allows you at least one person that can act as a liaison between the purely business founders and the technology team, whether they’re internal or external. You can also use them to bridge from the development shop into a internal team setup when the need arises.

Basketball, Lean and Incentives

The NBA Finals are going on right now and one of the main story lines surround Kobe Byrant and his supporting cast. The general consensus of the national media is that despite Kobes point production, the Lakers need more from the other people to be able to win.

Sports Economists have long pointed out that NBA players are rewarded for one thing: scoring points.   Often this comes at the expense of everything else around them, including winning.  The thinking goes that if everyone tries to score as many points as possible, their team will win.  A NBA players’ financial rewards, playing time and endorsements are based on very little outside of point totals. Thus, there is a huge incentive for players to shoot as much as the possibly can, regardless of how efficient they are at making those shots.

The problem is that basketballs are scarce resources.  A shot taken by one person cannot be taken by another.  All of those shots can cause havoc to the rest of the team and actually hurt the overall odds of winning.  Missed shots and turnovers increase fast break opportunities for the opponent and give more opportunities for your opponents to score.  Last week, Kobe Bryant missed more shots than he made and had 7 turnovers. Despite that, the prevailing wisdom is that he did all he can to avoid the loss.

So what’s this got to do with Lean? One of the core principles of lean is to optimize the system as a whole and not try to optimize through decomposition. One of the best ways to do that is to get rid of individual based performance rewards and incentives. If you have those types of incentives, you’ll find people working through their tasks with the sole purpose of maximizing whatever it is they’re being measured by and rewarded on. Lines of Code written, bugs found, projects delivered on time, etc… Unfortunately, this has the tendency to create a system with tons of churn:

QA testers are “finding” bugs as quick as they can, without regards to if they actually exist.

Developers churn out more code than necessary just to pump up their LOCs count.

Project managers rush projects into deployment just to increase their numbers.

All of the behaviors just increases the thrashing within a system, which increases the load on every single resource in the system.  Development spends more time looking for bugs that might not exist. Operations spends time trying to get a possibly buggy and non-functioning system to work. QA spends time testing features and code that isn’t needed. The cycle keeps going and going.  Sure, everyone gets their bonuses. Yet the entire team / department suffers.  What’s worse is that no one has an incentive to help out anyone else, since time wasted on you is time that I can’t be working towards my bonus.  It creates a very self-serving culture and isolated team dynamic.

The old adage of “tell me how you measure me and I will tell you how I will behave” still rings true .  Make the choice to measure your team on team based goals.  Place a premium on team communication, collaboration, ownership and overall delivery.   You want people chipping in to help, even when it’s not their particular area.  If you overhear “that’s not my area” or “let operations handle it”, your team priorities are counter productive and likely weighing you down.

Individual vs. Institution

While recently reading an article about Wikileaks, I came across this piece of wisdom about the founder:

He had come to understand the defining human struggle not as left versus right, or faith versus reason, but as individual versus institution.

I can’t believe how succinct this since sentence is, yet it embodies the transformation I have gone through for the past 3-5 years.

As the past few years have gone by, I’ve found myself steadily withdrawing from things considered ‘the american dream’. I’ve started down the minimalist path with my possessions, really placing a premium on buying experiences vs. buying items. I’ve scuttled friends after realizing that they weren’t friends at all, but rather immature drags on my life. I can’t remember the last time I bought a piece of clothing. In fact, I can remember almost 4 times that I’ve given away 6-12 items in the past few years. I eat less meat, I don’t drink pop, and I’ve given up fried foods. Very little TV and none of it live. It seems like as each month passes, I scuttle more and more “traditionally” accepted facets of life.

And I couldn’t be happier.

As I have removed less and less, I’ve noticed a considerable decrease in things weighing me down ( in addition to a slimming waistline ) and an increase in things I value: more time, more amazing experiences and more freedom.

Unfortunately, everywhere I turn, there’s someone else commenting on what I should be doing because it’s “normal”. What I’ve found is that these normal things are really constructs of the marketing and sales departments of large corporations. From personal finance decisions to spending / consumerism to what constitutes love between two people. Doesn’t it seem ironic that happiness is foisted upon us as a product of spending money / taking on debt? Doesn’t that seem strange?

I’m at the point in my life where watch where the majority of people will end up on….and proceed to the opposite direction. To me it’s as simple as following the chain of logic: Humans are notorious for not understanding the consequences of complex systems. The majority of people will flock to cheap connivence. Corporations will market and service that industry. Thus, I and skeptical of any and all marketing and anything that the majority of people deem “common sense” or “a no brainer”.

Dangers of Multitasking

During my Lean Software Development talk on Wednesday, I got into a small tangent about one of the 7 wastes of Lean: Task Switching. In the world of software development, this means multitasking. Much digital ink has be spread about the waste that manifests from multitasking. When going through a production process, this multitasking does extra harm because it makes the overall process susceptible to delays and delivery slippage.

I used the following example to bring the concept home for software developers. Let’s say you have 3 tasks, A, B and C. Each task takes 8 hours to complete. If you did them a half at a time, the resulting delivery would look like the below:

Screen shot 2010-06-12 at 6.47.12 PM.png

So it takes 24 total hours to complete all three tasks.  No surprise there since 3 * 8 = 24 hours.  However, it actually takes 16 physical hours to deliver each task.  For example, 4 hours for the first part of tasks A, B and C and then another 4 for the second half of task A.  That’s twice as long each task would individually take:

Screen shot 2010-06-12 at 6.49.27 PM.png


In the second example, any process or task depending on task A can get started a full 8 hours sooner than in the first example.  That can result in a huge gain in throughput for your team or project.  This is also assuming that there are no delays in delivering each task.  If they are delayed for any reason, suddenly you’re staring down the barrel at a 200%+ delay for delivery than the second example.    It also results in smaller units of work, which we’ve already discussed is a great thing.

So the next time you’re planning out individual tasks, think about how you can break them down into the smallest, deliverable chunks you can.  This will enable you to churn out smaller, more functional pieces quicker and with great precision.