Managing During a Crisis

 

Mad gas mask back cover

There's no doubt we are in a difficult time. We are facing a global pandemic and ensuing economic crisis that is likely the most difficult situation the world has faced in generations. The past few weeks I've had many conversations with founders and CEOs about what they are doing. So let me share some thoughts and observations for managers, leaders and founders.

During a time of crisis the most important points are:

  • Communicate
  • Develop contingency plans
  • Make hard decisions
  • Take bold action sooner than later

Without getting political, it's clear that leaders in many countries have not done a great job in these areas. That makes it even more important for business leaders to step up. Not only to help flatten the curve, but also to provide guidance to their customers and employees.

Communicate

Communicate to your employees, your customers, your partners, your investors. People need to hear from you, whether you're the CEO, an executive, or a manager. Especially with many tech businesses operating in a remote / work from home environment. Reach out one-on-one with people, not just your direct reports, but everyone. Ask them how they're doing. Ask what you can do to help. Don't just send out a blanket email to customers either. You've probably got twenty of those in your in-box. Instead focus on your company mission and taking care of your customers.

Many of your employees will be facing dramatically different circumstances of working from home, dealing with family crises, worrying whether they will have jobs and so on. So give them flexibility in their working hours and the time to address family and personal needs.

Develop Contingency Plans

No one knows how long the lockdowns will last or what the longterm economic impact will be. But you must develop a set of contingency plans. What happens if we can no longer sell in Enterprise accounts? What happens if our customers stop renewing? What happens if we can no longer hire new people? 

Some scenarios that might have seemed extreme a week ago are now the de facto situation. The prudent thing to do is recognize that things will continue to change. Consider what signals will guide your decision making through the crisis. Watch carefully your sales funnel, what deals close and what gets pushed and who goes into production. Look for patterns that help you determine where to concentrate your efforts in marketing, sales, customer success.

Build a plan and then consider what if it gets even worse? And worse still? If you are selling to government, healthcare, financial services, logistics and tech companies, those segments may be ok. Retail, travel, hospitality, sports, manufacturing may be severely impacted. Non-essential businesses have been closed in many states and countries. What is your plan if that becomes nationwide? 

Many marginal businesses will be challenged during this crisis. If you've got less than 12 months runway in the bank and do not have clear product / market fit this is now an existential crisis. If the earlier dot com meltdown and 2008 recession are any indicator, VCs will be in triage mode and many will walk away from weaker companies. So don't expect a lot of guidance and certainly no further investment. Whatever goals you set with your board are probably out the window. Your most important goal may be as simple as: can we survive 2020? Figure out if there are one or two use cases or segments where you have some repeatability and focus your efforts. It may require a significant pivot to lower pricing, online sales, or specific narrow use cases.

Ideally you can cultivate an environment where everyone is generating ideas, whether these are ideas for cost reduction, or over time, ideas on how to innovate and identify new use cases. Sometimes the best, most creative thinking comes out of the constraints of a difficult situation.

Make Hard Decisions

Some of the healthiest companies I work with have two years of runway in the bank. And they are still being very cautious on spending, cutting discretionary marketing, putting a hiring freeze in place, putting expansion plans on hold. It may be hard to hit sales targets without the new hires you planned in January, but if things are even worse in June (and September) it will have been the prudent thing to do. 

Take Bold Action Sooner Than Later

Just as we wish our political leaders took more dramatic action earlier, do not fall prey to a "wait and see" attitude. Do not assume that your business will be ok. Yes, video conferencing and BI may be counter-cyclical. But it is better to be prepared for the worst than to be fatally optimistic. This is a good time to be very clear on the core mission of your business. Make sure teams are focused on what really matters, the small number of things that are essential to your business, not the "nice to haves." 

If you can afford to keep your team intact during this period, that is a great thing. People will remember that you took care of them and they will repay you with dedication, loyalty and hard work. 

But if you have less than 12 months of runway, you will need to reduce your burn rate and it is better to do so sooner and all at once rather than dribbling out a few cuts at a time. Cut spending to the point that it hurts. If you need to make a further reduction in headcount expense, consider a pay cut at the executive level before you eliminate jobs. There are no easy decisions here. But if you need to cut jobs, cut deeply all at once. The worst situation is you have a layoff, it's not deep enough and then some weeks or months later, you do it again. 

Do your best to provide some kind of safe landing (severance and recommendation) for any employees whose jobs you eliminate. Treat people with dignity and respect so that when it is time to rebuild they will want to come back to work for you. 

A crisis such as we have now is an opportunity for all managers to demonstrate real leadership. It is a time when people show their true colors, for good or for bad. It will be difficult, but become the leader that your company needs.

If you have other ideas or suggestions, please feel free to add comments below.

Update: And here are some excellent articles


Delphi Informant: Giving Birth

This article appeared in Delphi Informant magazine in April 1996 discussing the development of Delphi 1.0.

Zack Delphi 1.0 launch Feb 1995One of the most fun things I’ve done in my career is to help build the “1.0” version of Delphi. Okay, 2.0 was pretty fun too, but, as they say, there’s nothing quite like the first time.

When we started building Delphi 1.0, it was hard slogging. A lot of the tools out there, like PowerBuilder, SQL Windows, and Visual Basic were pretty good. Long before we even had a prototype up and running, I was on the road talking to developers to understand the problems they were facing. Most of them were pretty happy. I remember particularly thinking that the VB corporate users by and large were just the happiest bunch of developers I’d ever met. Heck, they were even having fun! I remember one particular meeting with about a dozen developers from a major airline. They told a not uncommon story of how a senior VP had decreed that they would use Visual Basic after he prototyped an application on a weekend. The developer told me that he didn’t want to have any association with — ugh — Basic, but after trying it out for a while, he changed his mind.

Another time, I was meeting with a development team at a Wall Street foreign exchange. They showed me this tremendously impressive application for monitoring currencies — written in SQL Windows. It was beautiful. I thought, “Oh no, another satisfied customer. Time to move on.” So after a demonstration I asked how they liked the application. His answer: “It’s a dog.” The response time was simply too long to even be considered for production use. After all, Wall Street practically defines the phrase “Time is money.”

I saw these scenarios repeated in meeting after meeting, city after city. On the surface, customers seemed pleased with the productivity gains of “Rapid Application Development” tools. But as I delved further, I found the love affair often came to a bitter end when they tried to move from prototype to production. I found lots of spaghetti code out there, and DLLs written in C to make up for performance bottlenecks in applications written in PowerBuilder, SQL Windows, and VB.

It was some nine months into the two years of the development of Delphi 1.0 before we showed it to potential customers. There were two reasons for that. First of all, Delphi was an underground project that was truly secret. Heck, for the first year we had more code names than beta testers! Secondly, and perhaps more importantly, I wanted to make sure we understood customers problems rather than simply gauging a reaction to a demonstration. That way we could ensure we were building the right product, rather than fine tuning the wrong one.

When we finally started showing Delphi to customers, the reaction was dramatic. After all, we were solving the problems they had told us about. Our mantra: “Performance, Reuse, RAD, and Scalability.” This helped us to not only define the product, but to communicate the benefits to the customer.

Oddly enough, one of the problems we faced was how to name the product. As Jerry Coffey pointed out in this column [“Symposium,” Delphi Informant, January 1996], we were experimenting with all kinds of names. Although we had early on decided that “Pascal” should not be included in the name since it wasn’t really meaningful except to long-time fans, we really hadn’t made much progress on the name until a few months before its release.

Leading contenders included “Visual AppBuilder” (luckily, it was taken) “Application Architect” (too much like a CASE tool), “Client Builder” (sounds like a sales prospecting package), “Object Vision” (ahh, we used that already, didn’t we?) and just about every combination of the words “Visual”, “Power”, “SQL”, “Application”, “Object”, and “Builder” (“Visual Power SQL Application Object Builder” anyone?)

As we were in the late stages of selecting a name, whenever I’d do a presentation, whether to potential customers, sales reps, or third party vendors, I’d always ask them what they thought of the proposed names like “AppBuilder.” Invariably, the response was lukewarm. Then they’d ask, “Why don’t you just call it Delphi?” So in the end, we did.

Danny Thorpe, then on the QA team, now currently part of the R&D group, had came up with the original code name “Delphi” since it was to be a client/server tool connecting to the likes of Oracle among others. We had to come up with a code name for our first beta test and everyone felt that Delphi was acceptable. We had many later code names for internal use, external use, different countries, and at one point, I must admit, I randomly made up a new code name for every presentation, so that if there ever was a leak, we’d know from where it came.

Delphi 2.0 has come a long way since then. Our original goal was to address a few of the usability issues and also migrate to a 32-bit compiler and take advantage of platform features like OLE automation, OCXes, etc. Along the way, we introduced several major innovations like Data Module Objects and Visual Form Inheritance that increased code reuse.

The 32-bit compiler itself was actually started way back when the original 16-bit version of Delphi was started. At the time it seemed like a safe bet that “Chicago” (Windows 95) would slip out of 1994 and that Windows 3.1 would still be a viable development platform for Delphi 1.0. We were able to have most of the VCL ported to 32-bits and running with the new compiler prior to the release of Delphi 1.0. So we were quite confident that the architecture would ensure compatibility with most code from Delphi 1.0, assuming it wasn’t dependent on 16-bit data assembler, data structures, or unsupported API functions.

Although it’s a bit too early to announce plans for the next version of Delphi, we’re certainly working on a number of fronts to further reduce the amount of code folks need to write, and make it easier to support very large projects.

Zack Urlocker is Director of Delphi Product Management at Borland International. The views expressed here are his own. He can be reached on CompuServe at 76217,1053.
(Well not anymore!)


Danny Thorpe: Why The Name "Delphi?"

by Danny Thorpe

This article originally appeared on the Borland museum website. 

Danny thorpe"Delphi" started out as a beta codename for a closely guarded skunkworks project at Borland: a next-generation visual development environment for Windows based on Borland's Object Pascal programming language. The codename hatched in mid 1993, after the development team had been through about 6 months of deep research, proof-of-concept exercises, and market analysis. Members of the then Pascal development team were hanging around R&D Manager Gary Whizin's office brainstorming clever codenames to use for the new product. It was not a large office, but it was not a large team either - about 10 people between R&D, QA, Pubs, and Marketing. It would have been odd not to see Anders Heilsberg, Chuck Jazdzewski, Allen Bauer, Zack Urlocker, Richard Nelson, myself, and several other regulars jawing away on some topic or another in Gary's office. For the codename jam sessions, there may have been some overflow into the hallway.

Borland has a long history of "unusual" codenames, some with catchy slogans or backgrounds that tie the odd name to the market or product focus. A codename should have no obvious connection to the product, so that if an eavesdropper overhears the name in conversation it won't be too obvious what product is being discussed. The difference between an everyday disposable codename a great codename is the pithy passphrase behind it. The most memorable for me was the codename for Quattro Pro 4.0: "Budda". Why? It was to assume the Lotus position!

So we were sitting in Gary's office, kicking around weird and wacky codename possibilities. The strategic decision to make database tools and connectivity a central part of the new Pascal product had been made only a few days before, so Gary was keen on having a codename that played up the new database focus of the proposed product, and of its development team. The database shift was no small matter - I remember having grave reservations about "polluting" the Pascal tools with database arcana that took me almost a year to shake off. It was a big gamble for Borland, but it was very carefully measured, planned, and implemented. In hindsight, making Delphi a database product was exactly what was needed to break Borland's Pascal tools out of the Visual Basic - C++ market squeeze play and set Delphi head and shoulders above traditional Windows development tools.
Gary kept coming back to the codename "Oracle", referring to SQL connectivity to Oracle servers. "Oracle" didn't fly with the group, though. Aside from the obvious confusion with the same-name company and server product, the name itself implied server stuff, whereas the product we were building was (at that time) a client building tool, a way to talk to Oracle and other servers.

How do you talk to an oracle? "The Oracle at Delphi" was the word association that popped into my head. So I offered up "Delphi": If you want to talk to [the] Oracle, go to Delphi.
The suggestion wasn't an instant hit. It's an old name, an old place, a pagan temple in the ruins of a dead civilization. Not exactly an inspiring association for a new product! As some press articles later noted, the Delphic Oracle was particularly infamous for giving out cryptic or double-edged answers - not a great association for a data management tool. Asking a question of the oracle was free to all, but having the oracle's answer interpreted and explained (compiled?) cost a pretty drachma. (The marketing guys liked that part)
Overall, though, the "Delphi" codename had a classier ring to it than the sea of spent puns that littered the room. Pascal is a classic programming language, so it just felt fitting somehow to associate a Pascal-based development tool with a classical Greek image. And as Greek mythologies go, the temple at Delphi is one of the least incestuous, murderous, or tragic ancient Greek icons you'll find.

We went through a lot of codenames during the development of that 1.0 product, coining a different codename for each press or corporate briefing of the beta product. This was an effort to limit rumors and allow us to track the source of leaks. The last thing we wanted was for you-know-who to get wind of what we were up to. Through all these disposable codenames, the Delphi codename stuck. Towards the end of the development cycle, marketing started using the Delphi codename across all prepress and corporate briefings, and as the codename for the final beta releases. That got the rumor mills talking to each other, and the tools industry was abuzz with talk about this secret project at Borland codenamed "Delphi". J.D. Hildebrand wrote a whole editorial in Windows Tech Journal about the "Delphi buzz" months before the product was launched. (paraphrased: "I can't tell you what it is, but I can tell you this: Delphi is going to change our lives.")

When it came time to pick a retail product name, the nominations were less than inspiring.. The "functional" name, a name that describes what the product actually does and is therefore much easier to market and sell, would have been AppBuilder. This name actually still appears in some IDE internal class names, such as the class name of the IDE main window. (R&D caved in to the functional name pressures and set about implementing it early) But AppBuilder didn't light up people's imagination. It didn't work well internationally - functional names are only functional in their language of origin.

Thankfully, a few months before Delphi was scheduled for release Novell shipped their own product called Visual AppBuilder. There was much rejoicing in the Borland halls, for at last the "AppBuilder" debate was laid to rest. With the functional name taken out of the running, suggestions started coming from all quarters to use the Delphi codename as the product name.

Delphi wasn't home-free yet. The lead marketing person had legitimate concerns about the extra effort that would be required to build name recognition in the marketplace for an "iconic" (opposite of functional) product name, so he requested a vote of the development team. There was only one vote against (guess who?). Much to our chagrin, someone came to the conclusion that the development team's views were not an accurate representation of the marketplace ("sample error" was the phrase I heard), and pressed for a survey of the beta testers. When that poll didn't produce the result he wanted, the survey was broadened again to include Borland's international subsidiaries, press, market analysts, stock analysts, corporate accounts, software retailers, and probably a few K-Mart shoppers. It became a bit of a comedy: the harder people tried to dismiss "Delphi" for the product name, the more it gained support.

"Delphi" has a classical ring to it. It has a consistent meaning/word association worldwide in all languages. It has no embarrassing vulgar slang meanings in other languages (that I'm aware of). Most of all, the marketing guys had done a marvelous job of building up market anticipation and buzz around the "Delphi" name. The market was primed and ravenous for this thing called "Delphi".

And that, boys and girls, is how the Delphi product got its name.

Danny Thorpe  joined Borland in 1990 around the same time I did. He worked on the QA Team for Turbo Pascal and later as part of the original Delphi team. Danny came up with the Delphi name and later worked on key parts of the compiler, VCL library and IDE.   


General Magic

General magic 400

I realize I'm late to the party on this, but I happened to catch the documentary "General Magic" recently and it's an amazing piece of work. It had been on my list of films to watch since earl 2019, but somehow never bubbled up to the top. So it was fortunate that it was available on a Delta flight I had recently. For anyone who wants to understand the ups and downs of what it's like to be in a high-tech startup, this is an in-the-trenches documentary that captures startup reality better than anything else I've seen.

The film documents the rise (and fall) of Apple spinoff General Magic, a company that embarked upon the audacious goal of producing the first connected, handheld personal digital assistant (PDA), predating such devices as the HP 95 LX, Psion 3, Palm Pilot. General Magic was founded in 1989 by Marc Porat, Andy Hertzfeld and Bill Atkinson, the latter two among Apple's most famous engineers for their work on the original Apple Macintosh. The company became a hotbed of innovation and secrecy. No one quite knew what they were up to, but given the pedigree, it was going to be big. The company attracted dozens of other prominent engineers and up and comers including Susan Kare who designed the UX, Tony Fadell who went on to help create the iPod, the iPhone and Nest, Andy Rubin who created Android, Pierre Omidyar who created eBay.

General magic prototypeThe documentary includes a large quantity of historic footage. The team at General Magic knew they were working on something important and they hired a team to film all of it. So there are team meetings (bean bags on the floor), demos, late night sessions, press conferences, nerf-gun fights and more. The historic footage is interspersed with contemporary interviews with key executives, press and analysts looking back on what they accomplished and why the company failed. 

It's a heartbreaking story. Here's a company with vision, financial backing, genius engineers, and a huge market opportunity and its obliterated to the point of obscurity. I doubt that today's startup engineers have even heard of General Magic, the Magic Cap operating system or any of the tools from that era. But the irony is that all of the technology became widespread within 20 years. That includes technology that later surfaced in the iPhone, Android, Twitter, Amazon. Ultimately, the people behind General Magic created multiple billion dollar technologies and arguably entirely new industries. It was the hard lessons of General Magic's failure that ultimately resulted in the triumph of its many brilliant engineers.

Having worked in the software industry since the late '80s, this film captures the essence of Silicon Valley better than anything else I've seen. It's a powerful tribute to what it takes to succeed in the valley and asks the question: is it worth it? 

Here's the trailer:

 


iWoz - Steve Wozniak

Iwoz

I must have read a dozen books about the founding of Apple Computer over the years, so when co-founder Steve Wozniak wrote his autobiography iWoz a few years back, I made a mental note of it, but never got around to reading it. Woz and I happened to be speaking at the same conference last week. They say you should never meet your heroes, but meeting Wozniak was a real honor. He is one of the most talented engineers and nicest guys I've met. His onstage interview was a bit scattered (imagine opening a faucet of Woz), but it was great to hear him speak about his experiences in designing the Apple II computer, how Basic and Visicalc helped turn the Apple II into a platform, the importance of privacy in social media, etc. 

iWoz is co-written with veteran PC Week reporter Gina Smith though told in Woz's unique style. Smith spent over a thousand hours interviewing Woz and then transcribing and reviewing the interviews and suffering through numerous Woz pranks. Woz's sense of humor and lightness come through in spades.

Zack wozAlthough Woz was less a part of Apple than Steve Jobs in later years, those who know the history know that Apple would not have existed without Woz. The Apple II computer effectively created the personal computer revolution. It was first all-in-one design, the first computer that you could plug in and use. The Apple II+ was the first computer I bought and I still have one in my closet. It works perfectly 40 years later.

With the average iPhone app today weighing in at 100mb or more, it's hard to appreciate how much work went into creating software that could run on a 48k machine running at 1Mhz. It was Woz and other early apple employees like Randy Wigginton, Chris Espinosa, Bill Fernandez, Daniel Kottke, who labored to make that Apple II a reality. Woz, gave some of these early employees shares of stock worth tens of millions of dollars out of his own pocket when Jobs refused. 

For those interested in the history of Apple, this book is a unique opportunity to hear it from the guy who built it. You get everything from selling blue boxes with Steve Jobs to how he built what became the Integrated Woz Machine (IWM) disk controller for the Apple II and Mac.

Here are a few excerpts from the Q&A with Woz:


More Tech IPOs

Pagerduty IPO

Looks like we're in another boom year for Tech IPOs! While everyone is obsessed with the mega IPOs like Uber, Airbnb and the like, I think we're seeing a very healthy number of B2B IPOs happening. Zoom and PagerDuty have gone out successfully and others like Fastly and Slack are on deck. I was an advisor to PagerDuty founder Alex Solomon in the early days, and it's great to see how the company has continued to grow. It's a company that had its share of growing pains in the early days as they built the management team. Ultimately Alex recognized he needed an outsider to scale the company to IPO level. He hired Jennifer Tejada who has done a fantastic job, while he's chosen to focus more on the technology. (Both of them are in the photo above.)

Here's to the many other B2B tech companies that have crossed $100m in revenue and are heading for their IPO.


Bumper Crop for IPOs in 2018

Zuora ipo

It looks like 2018 will be the strongest year in tech IPOs in recent history. Although some of the largest companies (Airbnb, Uber) are still waiting on the sidelines, so far we've seen a large number of very successful IPOs including DropBox, Zuora, ZScaler, Spotify and others. This week there were three strong IPOs including Ceridian, Docusign and Smartsheet which popped 30-42% in their debut. These companies all have much stronger fundamentals than some of the troubled IPOs of 2017 (Blue Apron, SnapChat) which gave investors pause. 

Pivotal is the only IPO that had a very modest rise on it's debut, a day when the markets were down overall. But in the following week, Pivotal has risen about 20%. DocuSign is a good example of a cloud company that has pursued a massive market opportunity. DocuSign has a $2 billion dollar run rate ($518m revenue in Q1, doubling over the last two years) with a quarterly loss of $52m, compared to $115m a year ago. While the company certainly could have gone public earlier, at a $6 billion market cap, the wait seems to have been worth it.

One of the factors fueling demand for new IPOs are the strong Q1 results among public tech companies including Amazon, Facebook, Microsoft and even Twitter.  Microsoft's stock has recently hit a historic high, based on the growth of its cloud business. Considering that Microsoft was a laggard in this space, it speaks to not only the disciplined management that CEO Satya Nadella has put in place, but also the huge upside that still exists for tech companies with recurring revenue SaaS offerings. 

And that's precisely why we should expect to see even more IPOs in the second half of 2018.  It looks like Acquia, Anaplan, Avast, CarbonBlack, Domo are likely to go out in the next few months. I would expect to see quite a few IPOs between now and mid-August when bankers head out on vacation and then more in the fall.

While there has been a lot of volatility in the market earlier this year, it has still been a nine-year bull market and at least in the tech sector, it seems that there is still a lot of headroom for growth.

What companies do you think will IPO in the rest of 2018? Will the bull market keep running? Let me know your thoughts by posting a comment below.

 


Hark: The Software Paradox

Hark

Stephen O'Grady at RedMonk has launched a new Podcast called Hark. In his second episode, he and Agile programming guru Kent Beck have a thoughtful discussion around the ideas in O'Grady's book "The Software Paradox."  Even though software is "eating the world" and become more widespread and strategic, its economic value appears to be declining rapidly. Certainly, we've seen a shift in the industry from traditional on-premise software commercialization to distribution models like open source, and software-as-a-service, with vastly different business models.

Simply put, the software industry is undergoing a significant disruption that is reshaping the economics of the industry and rendering older "tried and true" business models obsolete. And at a level that strikes closer to home for many, it's also reshaping employment models and careers. Although the parallels are not perfect, the software industry is going through a transformation much like the publishing industry or the music industry. (And we all know how well that turned out for writers and musicians!)

I would argue this has transformation has been going on for at least ten years already since the emergence of successful open source companies. In the early days of MySQL, Marten Mickos regularly talked about how his goal was to disrupt the database industry taking it from $9 billion in revenue to $3 billion, and then capturing a third of that. While this was possibly more bravado than business plan, it was based on the fact that MySQL was 90% cheaper than Oracle. (And for many, MySQL was 100% cheaper --after all, it was under a GPL license and free for most users.)

While we built a solid business with MySQL, growing it to just short of $100m in revenue and selling it to Sun for $1 billion cash in 2008, the long term impact of MySQL was far higher outside the database industry. MySQL, Linux and other open source infrastructure software spawned thousands of businesses that simply would not have been economically possible under traditional commercial licensing fees. We routinely met founders of companies that said their business was enabled in part because of the dramatically lower cost of building an IT infrastructure. So at least some of the value that MySQL disrupted was captured not by traditional software companies, but by newer companies like Facebook, Google, Skype, Craigslist, Priceline and the like. And many of those businesses also happened to be disruptive, which is why software is eating the world. 

Not surprisingly, there have been very few home runs in the open source business, at least as measured by revenues or exits. Red Hat, JBoss, Pentaho have all been successful as businesses and have had good payouts for their investors. But many more open source projects have had widespread popularity with remarkably little economic value generated. And that is precisely the nature of the Paradox. 

And as Mickos has recently noted "The bad news is: it's almost impossible to make money on open source. The good news: it has happened many times."  But at this point it's hard to say what the future successful models for software commercialization might be, but it's certainly not going to be the traditional on-premise up-front license model. And I don't think open source, in all its various forms, is likely to generate a large number of economic home runs. There are definitely a handful of promising companies like Acquia, CloudEraDataStax, MuleSoftPuppetLabsSugarCRM and the like, but they may be more the exception than the rule. (If I missed other rapidly growing open source companies, let me know in the comments below.)

Likely we will see more divergence over time with more value realized in other forms, whether it's service-based models, cloud-based businesses, advertising, data aggregation or perhaps something as-of-yet to be invented.

It's a fascinating topic with more questions than answers at this point.  And I'm sure we'll see more discussion on this topic at the Monktoberfest conference in October. 

The Hark podcast is available on iTunes, SoundCloud or wherever you get your downloads.


School of Herring

School of Herring

My former boss, Marten Mickos, has created an excellent new resources for early stage founders, managers and execs called www.Schoolofherring.com. Each post has a short write up and often a 2-3 minute video covering a topic such as giving feedback, Peter Drucker's principles of good management, what it takes to build an effective team, hiring for strength etc. Some of these topics are very practical, like how to send good email, others are more thought-provoking, such as the notion that bad news is good news --one of my personal favorites.

Some of these ideas come from legendary management guru Peter Drucker, but they are all shaped with Marten's unique and practical experience.


How To Lower Churn

GigaOm

Dealing with churn, is one of the most important elements of building a subscription business.  While some churn is inevitable over time, too much churn indicates a more fundamental problem: customers aren't finding value in your product.  

I wrote an article over at GigaOm on this subject including some examples about how to reduce churn from my experience at MySQL and Zendesk.

Having churn is like rowing a leaky boat. After a while, you spend more time bailing water than moving forward. By contrast, organizations that focus on reducing churn will find that their revenue grows every quarter.

To accurately measure what’s going on, you should begin by breaking out churn (customer cancellation) from contraction (a downgrade in spending). Measure downgrade and churn separately from upgrades and expansion; otherwise, your net growth numbers will mask problems that are bubbling below the surface. If your SaaS product has different editions (e.g. Basic, Pro, Enterprise) you should watch for downgrades that suggest customers are not seeing the value in the higher-end features.

It’s also worth paying attention to churn and contraction by customer segment. In most SaaS businesses, churn is highest in low-end customers — some of whom will inevitably be acquired or go out of business. Over time, if you move upmarket to larger SMB or Enterprise customers, low-end churn becomes less significant. Customers who spend a lot of money usually have greater commitment and resources for working through any speed bumps during implementation. They’re also far less likely to switch to another vendor with newer features.

Hopefully this article will spark some other ideas and discussions in your company.  You can read the full piece at GigaOm.