Process for the Enterprise » Steve Blank

Startup Lessons Learned Conference

Scott Francis — Tue, 27 Apr 2010 12:54:07 +0000

Every so often, a conversation builds to critical mass and demands an in-person meet-up. Eric Ries pulled this show together, and I have to say there is some great video, and there were some great presentations to browse to get to understand better what you can do with a lean-startup approach.

Steve Blank has one of the best overviews with links to all the important content. And here’s a link to the stream of his talk. You can find almost all of the presentations on slideshare with the sllconf tag.

Maybe I relate to this conference effort because we put on the bpmCamp unconference earlier this year. Mainly, I applaud the effort to build momentum and credibility around some really great frameworks.

A Process for Teaching Entrepreneurship?

Scott Francis — Thu, 08 Apr 2010 13:53:40 +0000

Steve Blank’s blog has a series of posts regarding the entrepreneurship courses he and his colleagues are teaching at Stanford and Berkeley. The thing that jumped out at me is that it sure reads like there is a process for teaching entrepreneurship.

Maybe that shouldn’t be surprising. But it was already eye-opening for me to read the process-oriented approach Steve advocates for developing your business model (aka “Customer Development” , good read on wikipedia by the way), and a process for product development that is highly complementary to this (Lean Startup, advocated by Eric Ries among others). But it looks like Steve is cracking the code for how to teach entrepreneurship. Of course, proof will be how well the entrepreneurs who take his classes perform relative to peers who do not attend these classes, and how many other entrepreneurs adopt the techniques Steve is advocating because they’ve heard about them from his students or writings.

Til then, we can apply our own subjective judgment to assess. So far so good.

Make No Little Plans

Scott Francis — Fri, 15 Jan 2010 13:58:02 +0000

Man. Steve Blank writes some great stuff. Makes me wish I had gone to epiphany back in the 90′s! He explains that if you’re going to go work for someone, make sure they have big plans, plans to grow the enterprise – because that growth is what you will benefit as a member of the team.

I thought his IMVU example was pretty interesting. He mentions Will Harvey and Eric Ries (of Lean Startup fame) as being cofounders who wanted to swing for the fences and turned down buyout offers. So, being me, I click on the link for Will Harvey – and I see he is at “Finale | Fireworks” along with Chris Hondl. What a blast from the past. Will was the TA of a Motorola 68040 assembly language class when I was in college (Stanford CS 110 if I recall) and Chris was the star student in the class. We had a “robot simulation” game where we programmed the strategy for a robot to interact in a maze. Mine was one of the four finalists, but Chris’ was a class above the rest in terms of the elegance of design and economy of action. Chris went to work with Will at Sandcastle, and most of us in class were fairly in awe of Will for his chops as the writer of music software for the Mac.

There are times when you realize it is a small world.

At bp3, we’re building a business process company, just like the tag line says, making no little plans.

Its the People. And the Free Soda.

Scott Francis — Wed, 23 Dec 2009 15:54:21 +0000

What a great post by Steve Blank, yet again, as he reveals a classic cautionary tale from start-up land (“The Elves Leave Middle Earth – Sodas Are No Longer Free”).

It’s about the Sodas no longer being free. Seriously. Coke. Diet Coke. Mountain Dew. No longer free. Free drinks are part of start-up culture and lore, and it is just one of the little perks that founders do for their companies when they themselves are interested in free sodas too.

Shouldn’t matter, right? But it does:

But the damage had been done. The most talented and senior engineers looked up from their desks and noticed the company was no longer the one they loved. It had changed. And not in a way they were happy with.

The best engineers quietly put the word out that they were available, and in less than month the best and the brightest began to drift away.

Worse, as he sat there in the board meeting as the free drinks were getting canned, he was amazed that none of the experienced VC’s in the room objected, or pointed out the folly of this change in policy – from free drinks to paying 50 cents.

Steve was amazed that they didn’t speak up. But I’m not. Its like Marvin Haggler once said: “It’s hard to get up and do roadwork when you’re wearing silk pajamas.” The VCs have forgotten why free drinks matter to engineers. They’ve forgotten what “road work” is like. Its surprising that Steve Blank still remembers it so clearly (perhaps the academic/historian part of him hangs on to these memories).

As Steve recalls it:

Then the new CFO got up to give her presentation – all kind of expected; Sarbanes Oxley compliance, a new accounting system, beef up IT and security, Section 409A (valuation) compliance, etc. Then she dropped the other shoe.

“Do you know how much our company is spending on free sodas and snacks?” And to answer her own question she presented the spreadsheet totaling it all up.

There were some experienced VC’s in the room and I was waiting for them to “educate” her about startup culture. But my jaw dropped when the board agreed that the “free stuff” had to go.

I sure hope Steve spoke up and let them know what a mistake they were embarking on. I know he wasn’t on the board, he was a guest – but all too often I’ve seen bad outcomes come to pass because no one felt comfortable or felt it was their place to speak up for what they thought was right…

I lived through one of these transitions as well, but for our firm, it really was the beginning of the end – not just a sign for people to look around, but a sign that the management of the firm had dramatically changed their priorities to reflect a new, tougher, economic situation, and the layoffs that were about to come.

Why Doesn’t “Continuous Improvement” Philosophy Apply to #BPM Vendors?

Scott Francis — Fri, 25 Sep 2009 16:07:32 +0000

I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software.

In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years. In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release. They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions. Why do they talk the talk and fail to walk the walk?

Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business. Heck, their articles should be mandatory reading for people deploying BPM software as well. The traditional “product development” model consists of four phases:

Concept / Business Plan
Product Development
Alpha/Beta Test
Launch / 1st Ship

And Steve Blank rips the heart out of this process:

The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

So. Off to a good start. So what are the problems?

Focusing on a finished product instead of minimum feature set. Lots of resources are going to be wasted on features that won’t matter to customers. Those resources won’t then be available to invest on features that DO matter to customers. Guess what? Software vendors have finite resources. These prioritization decisions matter.
Founders or Executives hand-off responsibility for validating the vision. Marketing and Product Management now own that, and Sales. The founders and executives aren’t hearing directly from customers which features are buying criteria. Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.

In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement. Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade. Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple: they lack a good feedback loop. Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results. The learning cycle is too long to take hold.

A fantastic example of what can go wrong in a big organization:

Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?

The most telling quote of all:

The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.

Its worth reading that one twice. Three times. Now. If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization. You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement. But I say to you, how long was the development effort that led to this latest version? Why was it more than 3 months? Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new?

Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution. These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0″ out there. I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved.

What’s wrong with the traditional product development model for BPMS vendors (my observations):

There are large sets of features that languish without improvement for many years. A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006. This “feature” might be something really important to customers: reporting, versioning, integration with salesforce, etc. But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released. So, that PDF export you wish you had in product continues to be something professional services had to provide. That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
Low priority defects never get fixed. Why fix them, when the “new release” is coming. Wait for the new release, then consider fixing these minor things on the new release. The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on. So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.

If your major versions take more than 1 year to ship, you’re doing something wrong. And that may be generous. How do I know that? Apple ships new versions of an operating system every 12-18 months. That’s a much more daunting task than a new BPMS. Much larger installed base. So why does it work?

You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc. These programs work. The changes they propagate have to be *contained* and backward compatible. But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else. Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
Independent components imply that you have to have good API’s. If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product. API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
You have to respect data formats. The data is sacred and hast to be protected. See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services. And you won’t be able to change upstream services without breaking your data.
You have to believe in the evolutionary/incremental over the revolutionary. If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
You have to allow for individual accountability for product. If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product? What are their other responsibilities? How long have they owned it? Can I talk to them about what they’re working on now and why? I want to understand their thought process.

I see enterprise BPM vendors talking the talk about continuous improvement. But I don’t see them walking the walk in their enterprise software offerings.

Sometimes Leadership Means Executing the Plan

Scott Francis — Tue, 25 Aug 2009 13:48:07 +0000

There are times when we must ditch the plan and we often talk about these moments when a good leader has changed course to effect a better outcome. These tend to be fascinating decisions to study because we wonder, how did this person know that now was the time to change course, and not earlier, or later? What was the information that led them to this decision?

But there’s another situation to look at: when the plan (or process!) is clearly defined, but we fail to follow it. In reading Coffee with Startups (by Steve Blank) I couldn’t help but think about the fact that Steve has outlined a clear process (Customer Development), some clear differentiators to apply to that process (what type of market – an “Existing Market” in this case), and published myriad articles about the subject. He describes coffee with four startups that claim to follow the Customer Development process but communicate clearly in the first few minutes that they have not followed it or completely missed the point.

This can happen with processes within your own organization – no doubt you’ve observed cases of this yourself. But you can’t afford to have the captain of the ship ignoring the process that is understood to be the right one to follow. If they pick a plan or a process, they need to be able to implement the plan – both in order to make it work, but also to be sure that if you decide it doesn’t work, you’ve actually given it a chance by trying it in the first place.

The entrepreneur may decide that Customer Development isn’t the right process for their company to follow… But if it isn’t, then the entrepreneur should follow the one they believe in, and not play lip service to one that they don’t. The same advice follows for process – if you define the right process – follow through on it. Implement it, get your organization to execute it well. Only then can you change it from an informed baseline opinion.

Faith-based versus Fact-based

Scott Francis — Sun, 21 Jun 2009 22:55:24 +0000

No, this isn’t a political posting!

I just read Steve Blank’s blog on Faith-Based versus Fact-Based Decision Making, and it resonated really well with my experiences at prior startups. As he points out, starting the company is an article of faith. The first company I worked for was started by 5 Stanford undergrads, most of whom dropped out of school to start the company. That is certainly an act of faith. However, as the company grew, there was more and more data available with which to make good decisions. Steve Blank’s post focuses primarily on the product development, customer development, and marketing aspects. But it is true of every facet of your business. And the transition from faith to fact is important. Not doing it can lead to some pretty bad decision making down the line. At the company referenced above, 10 years after its founding, veterans often referred back to faith-based decisions in the past as articles of proof that the right way to make a decision was based on faith rather than based on facts. “If we had relied on your facts, we never would have ”.

Well, it is often hard to counteract this sort of discussion. But let’s take another aspect that most people can relate to: hiring. The first time you hire someone for your startup, it is an act of faith. Oh sure, you have the resume, you check references. You interview. You interview again. You have lunch, dinner. You meet for coffee. You spend a lot of time with that person. And it is still an article of faith when you hire them. Why? Because the role you’re hiring for isn’t well-defined (almost by definition in a startup). Because you don’t have enough other interviewers to compile feedback from. Because you don’t have enough candidates who are willing to work for peanuts and equity (or even for cash for a risky proposition).

It turns out, at a larger company, every time you open a new position (role), you run into this problem again. You don’t know exactly what the job description is. You don’t have anyone else to compare the candidates to in terms of “this guy is good at that job”. You don’t even have consensus on what it means to *be* good at the job.

At a previous employer we needed to hire someone to run our recruiting operation. The first person our HR director brought in, came highly recommended by an executive at another local company. Our HR director was confident they would pass the executive interviews with flying colors. But the candidate bombed across the board. I told the HR director we’d likely have to interview 10 candidates before we would figure out what we really wanted out of the job, and if we were lucky, one of those first 10 would fit the bill – but if not we’d have to be prepared to interview and additional 5-10 people at least. She was mortified at the idea of doing that kind of work for “just hiring a recruiter”. But we wanted someone who would really make the recruiting process run smoothly and help us source good candidates. Sure enough, we churned through 10 candidates… and then made our compromise, by realizing that we needed a different style of recruiting for engineering than we did for our professional services team. Our engineering hires were heavily dependent on the local networking capability of the recruiter – we needed someone with deep Austin connections who could get people who weren’t looking for a job to pick up the phone, and help us make the sale. But for professional services, we needed someone who had a process for finding people all over the country, and screening them before they got to us so that we didn’t waste too many cycles interviewing people who were obviously not a fit. (Our professional services group had a regional staffing model)

But once you get big (as my first employer did) and you’re hiring for a well-understood role, you can establish really interesting hiring machinery. Everyone goes through 4-6 interviews with specific goals. You track statistics on each interviewer, and on the folks that you hire, to correlate interviewers positively or negatively with good hires (note: you have to have a review system for this to work). You correlate job performance with GPA, previous job titles, industries, etc.

We were doing a lot of hiring of people from college. The data said that people with above a certain GPA, who also passed our rigorous interviewing process, generally did quite well. There wasn’t a lot of additional correlation of higher GPA to higher performance, surprisingly enough (some, but not much). However, the data also said that we rejected something like 99% of the folks with less than that cut-off GPA who were granted a first round interview… And worse, most of those we hired with less than that GPA didn’t perform as well as those with a higher GPA. My read on the data was simply that our GPA cutoff reflected more about commitment than smarts. After all, the people who passed our interview process were smart. So why would they get a bad GPA? Mostly, they weren’t committed during college. I’ve known people like this all my life – and most of them eventually find what moves them, get committed, and go forward with much success from that point onward (sometimes in highschool, sometimes in college, sometimes graduate school or the first or second job). But there is no way to predict what will trigger their inner mojo. And there is no reason to assume that your company is the secret ingredient that will unlock their motivation! Our recruiters, however, had it as an article of faith that some of the most outstanding employees had crummy GPAs (or even dropped out as the founders had!). They were arguing that we should continue to make these leaps of faith. But outside of the founders, every other successful anecdote with the low GPA was someone who had previous industry experience where they had demonstrated excellence. In other words, once someone has had a real job, GPA is pretty irrelevant as a predictor of performance, compared to data from their previous work history. We did NOT have a compelling case based on the facts, for college hires with low GPAs achieving success at our firm.

I think the key lesson is: when you don’t have enough data, you still have to make a decision, make the best decision you can. But when you have enough data, let that data inform your decision-making. Don’t confuse good fortune with a good process.

The Role of Corner Cases in BPM

Scott Francis — Tue, 05 May 2009 22:40:42 +0000

In a previous article, the Six Barriers to BPM Adoption in the Enterprise, #4 was “The Bus Brake Effect”. The short version is that anyone on the bus can pull the break and stop everyone’s progress. For many organizations, that is true of their BPM efforts (and indeed, most IT efforts). The problem is especially acute for BPM programs because BPM touches so many different parts of the organization.

I recently read Steve Blank’s article on killing innovation with corner cases, and it really struck a chord for me. He correctly points out that this problem is even more acute when you have a lot of smart, confident people in the room. His take on corner cases is almost perfect for either exceptions or corner cases for BPM:

A corner case is an objection that may be:

technically reasonable

may have a probability of occurring

its probability of occurring is lower than your probability of running out of money.

In the context of Steve’s article, discussing startups, his point is that running out of money is more important than any number of corner cases. We could look at BPM a little differently, because we’re not going to run out of money – but how about the probability that your project runs out of budget? or that your process improvement project doesn’t achieve positive ROI?

Steve’s suggestion, with which I concur, is: Listen to the objection or corner case. Ask the objector to calculate the odds, and estimate the damage. When you multiply the two together, you get your expected economic impact (a 10% probability of a $100 event is a $10 expected outcome…). The beauty of the approach is that it can help keep your meetings productive, and once people see your tactic, they’ll anticipate it and save you a lot of wrangling in front of 20-person meetings. It also is a teachable point of view on how to handle objections – something people can do for themselves even when you’re not in the room or in the discussion. It sure seems like a good way to mitigate the bus-brake effect!

Three Processes for “Product” Development

Scott Francis — Wed, 29 Apr 2009 00:54:25 +0000

Eric Ries’ presentation on “The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products” has three processes depicted for “product” development. I put product in quotes because I think you can accurately substitute “service” or “process” and the presentation still applies very well to the situation if you assume that some technology or other development activity is required to support your service or process.

The Lean Startup at Web 2.0 Expo

View more presentations from Venture hacks .

Here’s the presentation, but allow me to call your attention in particular to slides 20, 21, and 22. In slide 20, you see the traditional waterfall strategy, which Eric explains is appropriate when you know the problem well, and the solution is also well known and understood.

In slide 21, we see an Agile approach, where the problem is known, but the solution is not well-known and understood. In fact, a decent number of agile projects get into trouble because the problem is not well-understood and they get caught in what feels like “churn”.

In slide 22, we see the introduction of the Customer Development Process to the mix, and the situation is one where the problem is not known, and the solution is also unknown. So part of the journey is to discover the right problem to solve, as well as the solution that solves it.

I think a lot of BPM projects would do well to adopt this third method (or an adaptation of it) as well. At a high level we may know that there is a problem (opportunity), but we may not understand what that problem is at a detailed level that would allow us to design a good solution. So we have to do some level of customer development (in our case these may be users) to understand the problem adequately, and then use an iterative approach to get the proposed solutions improved and adapted as quickly as possible. At the very least, when taking on a BPM project, one has to keep an open-mind to improvements that haven’t been thought of, and to new problem-identification that may happen over the course of the project.

A blurb about the slideshow is available on O’Reilly here.

Also, a more in-depth presentation was done previously on the Customer Development Methodology:

Customer Development Methodology

View more presentations from Venture hacks .

This version goes into a lot more detail on how to build the startup around this methodology, and makes a stronger case for why you need to iterate between business plan and hypotheses before funding, rather than proposing a business plan, getting funding, and *then* testing the market… its a good read!

People, Staffing, and Steve Blank’s SuperMac Series

Scott Francis — Fri, 17 Apr 2009 18:39:56 +0000

I’ve been trolling on Twitter recently – meaning, I’ve started following a few people, just to see if anything interesting crops up. I haven’t really felt the urge to post to twitter, but I thought I’d see what kind of wisdom arrives in 160-character tidbits. One thing I immediately don’t like – all the links are reduced by tinyurl to very small URLs – but this also has the effect of making it harder to tell if someone is sending you a malicious link of some sort (even by accident). Twitter accounts can be hacked after all.

So yesterday I had my first real “hit” on twitter – meaning, the first time I saw something that was really of interest and value that I would want to turn around and share. It was a link to one of Steve Blank’s articles on “SuperMac” – relating his experiences as Chief Marketing Officer (or VP of Marketing) of a graphics board company that focused on the Mac market. Honestly, who cares about the graphics market of 20-30 years ago, right?! But the lessons are not technical lessons, they’re more about understanding the customer and leading your team.

In “Strategy versus Relentless Tactical Execution”, Steve makes a fantastic case for why execution matters, and also points out one of the most common mistakes college grads make when interviewing:

Just as an aside, over my career I must have interviewed scores of business school graduates (some from the very fine universities where I now teach) who would say, “I want to do strategy.” Well yes, I understand that, but this is a startup, what else do you want to do? “I just want to do strategy.” Those were very short interviews. The “strategy” of learning who SuperMac’s customers were, what solutions they needed and what our repositioning would be was a three month effort.

The tactical execution took three years.

Note, if you want to do “strategy” (which is a fine endeavor) and nothing else, you have just defined your career as one in large corporation or in a consulting firm. Stay out of startups. Tactics mean tenacious and relentless execution measured in years.

On the technical side of the house, the analogy is “Design” instead of “Strategy”, and tactical execution in the technical world largely consists of coding. I did at least a hundred college technical interview screens each year for 5 years+ at Trilogy when I graduated from college. And one of the things I learned was that when a college grad started selling me on their design and architecture skills, versus their coding skills, it was a huge red flag. Of course, when I was a college graduate, I could have easily made the same mistake, assuming that my knowledge of software design and architecture made me desireable to a company, and up to that point, assuming that almost anyone much older than me didn’t know as much about software as I did (in the general population, that was probably true, but not within the specific software company population!). To succeed as a software engineer or technical consultant, you have to have the personality that will allow you to focus on the relentless execution of the plan. As you gain experience, your voice in the plan (the strategy, the design) will increase.

In his next article on SuperMac, “Building the Killer Team – Mission, Intent, and Values”, Steve further pounds the table on some principles of leadership that I think are critical:

Titles are not your job. Your job is defined in terms of what you are expected to accomplish for the company and how you further the goals of the company. Some of Steve’s examples of people in his group defining their job in terms of their narrowly-written title are pretty amusing.
You have to give your team a mission- something bigger than “set up the trade booths.” The mission for his marketing team was pretty specific – growing sales by a specific amount, at a specific margin. But it could have easily been written a little bit more high level, with some bullet points for the specific year’s financial targets. Given that mission, the team members and leaders can make better decisions about how to get from here to there – and about prioritizing the mess of work that might be in front of them!
Accountability. Steve describes a world where deadlines in his marketing department were not met. Consistently not met. And no one was surprised- there was always an excuse. Finally, he tells them no more excuses for missing commitments – that you can ask for help or work it out ahead of time, but no more showing up on due date with hat in hand full of excuses. I think this is not as frequently a problem in consulting organizations: our customers are going to demand a certain level of accountability from us. But I have seen that this is often a problem in Marketing organizations – precisely because there usually isn’t a customer picking up the phone when they miss. As a result, it takes more internal discipline and willpower to create that sense of accountability.

Look for more in this space on staffing thoughts. Because I think part of what Steve gets at is the motivation behind working – the “why” in Why we go to Work. At this stage in the growth of BP3, we think about the why’s a lot.