Kevin P. Taylor

Transitioning to a Second Stager, or "Damn, we did it!"

You're the leader of a multi-million dollar business. You have begun putting your management team in place. But, you work 50-60 hours a week. In fact, you are still involved in most day-to-day operations. You know you need to slow down, think strategically, and improve the business's ability to grow sustainably. 

If these statements describe you, congratulations! You've grown your company into a second-stager. It is no longer a startup.

As you'll have seen, a startup must do three things to prove itself: validate its business model; sell reference clients; and, of course, get its hands on cash. This is an all-or-nothing proposition, and the founders of a successful startup will be intensely-focused on succeeding on all three counts.

Then one day, the founders will pull their heads out of the oven, look around, and think, "Damn, we did it!" Keep a watch out for this moment. It will happen if you are one of the fortunate (yes, fortunate) few who make it this far.

The pull-your-head-out-of-the-oven-look-around-and-think-damn-we-did-it moment is an inflection point. It is a point on the growth curve of every business where the founders need to decide what is next and what needs to improve in order to get there. Chances are good that nobody on the team has thought quite that far ahead. Why bother thinking about market share, management teams, advisory boards, business efficiency, vision, BHAG, or mission, before a fledgling business has proven itself in the marketplace?

If you don't recognize the inflection point when it occurs, your company's growth will flatten out. The three concerns of the startup described above are not the only, nor likely primary, concerns of the second-stager. Not recognizing this will mean the founders will be focusing on the wrong priorities. Growth will stagnate, or worse, will become uncontrolled and possibly threaten the company's existence (the proverbial implosion).

To sustainably grow a second-stager, its leaders must embrace the following mandates:

1. Create a management team
2. Create organizational clarity
3. Over-communicate organizational clarity
4. Create systems to reinforce organizational clarity

Looking forward, in which of the above areas must you focus to move your second-stager forward?

Hackerpreneur's Schedule

The maker's schedule is for those who create. Whether it is programs, prose, or polynomials, makers need uninterrupted time to imagine, build, and deliver.

The manager's schedule, on the other hand, is for those who lead, facilitate, and measure. Their most valuable tool is the meeting. Whether via status meetings, sales meetings, planning meetings, or board meetings, managers must hold meetings to be effective. In his essay, Maker's Schedule, Manager's Schedule, Paul Graham describes these two conflicting schedule paradigms.

Graham points out that meetings are rarely for the maker's benefit. Meetings are organized by managers for the benefit of managers. According to Graham, they are often outright disruptive to makers. A seemingly harmless half-hour meeting scheduled in the middle of the afternoon can derail a maker for hours.

In his essay, Graham describes himself as being on the maker's schedule. But based on his description, it is more likely he is on the hackerpreneur's schedule. Hackerpreneurs, like Graham, intersperse making with managing, managing with making. The hackerpreneur has a company to build and software to build. The two schedules compete for the hackerpreneur's time.

The hackerpreneur's schedule is for the person who refactors code in the morning and grabs coffee with clients in the afternoon; who takes pleasure in designing class hierarchies and organizational hierarchies; who calls Object.new one moment and calls prospects the next.

Understanding and managing these competing scheduling needs has been a challenge for me, also, since founding Obtiva in 2005. During our first eighteen months, I coded on projects 40-45 hours a week. I was on the maker's schedule. Then, we began to bring in new and more challenging clients‚ and the people and complexity required to service them. My manager's responsibilities began to outweigh my maker's.

For the next two years, I did little coding. The only pitiable device I thought up was to black out a few days or weeks a year to devote uninterrupted time to coding. But, as you can imagine that was a bit disruptive to Obtiva. The business demanded that someone manage it.

Graham doesn't offer suggestions on how to manage the hackerpreneur's schedule, saying only, "Those of us on the maker's schedule are willing to compromise." (Remember, he is not yet aware that he is on the hackerpreneur's schedule.)

This year, the solution to this common scheduling dilemma revealed itself to me very simply. This year I took on a new project, Eventwax.com, that has yanked me back into the world of making. EventWax is an online event registration application and also a bootstrapped start-up.

Our coding practices at Obtiva (and Eventwax) include pair-programming. In order to ensure I have time available to code with my developer pairs, who tend not to be available at midnight, I schedule blocks of coding time throughout the week and label them "EventWax Pairing" in Google calendar. These are best scheduled in half-day increments. Some days consist of two back-to-back half-day coding blocks, but most often I can only pull myself away from my manager's duties for a half-day of coding at a time. But, just as I don't let myself get pulled out of a scheduled client meeting, I don't let myself get pulled out of scheduled coding time.

Though the amount of time the hackerpreneur devotes to making vs. managing will evolve—or swing wildly—over time, the solution is clear. Schedule time for making. Block it out in your calendar. Set its priority as high as any of your other commitments.

Why Build Custom Software?

In Code rant: Why is 'Buy' not always better than 'Build', Mike Hadlow opens his blog post by stating that "Building software is hard." He goes on to describe how this fact eventually leads most organizations to ponder the universal question: Should we buy or build our next software system?

As Hadlow explains, commercial off-the-shelf (COTS) software is often a great choice for common business needs, such as word processing. I would go a bit further and say that COTS software is a viable choice for any business need that isn't, and shouldn't be, a competitive advantage for your organization.

What does that mean? Well, if your accounting system is unique to your organization, watch out. Worst case, your system may not follow GAAP accounting principles. More likely, it is simply not very effective software and doesn't follow industry best practices. This will be true for many business functions, such as call-center management, document management, and email marketing. Chances are slim that there are any ways your company can gain a competitive advantage by building its own software for any of these common business needs.

But, what if the software system in question provides functionality that you consider a competitive advantage? For instance, if you run a large head-hunting firm should you use a COTS system for finding, tracking, and managing your candidates and clients? If you are large and successful, the way your staff finds, tracks, and manages candidates and clients should be a competitive advantage. Why would you give up that advantage by moving to a COTS system that your competitors can also purchase?

If a COTS solution is better than your current solution for a business function that should be one of your competitive advantages, you need to rethink, and possibly re-engineer, how your company performs that function. For instance, a large e-commerce organization should have plenty of competitive advantages built into its warehousing, customer-service, on-line shopping, and vendor management systems. If not, they may be in trouble.

Buying versus building makes sense in many cases. But, without even considering the hidden costs of customizing and integrating COTS systems (which Hadlow covers nicely), it is often the case that building a custom software solution is the only choice that makes strategic business sense.