Skip to content

Shrinkage

Jerry: Oh… You mean… shrinkage.

George: Yes. Significant shrinkage!

So how do you enter a mature, well understood market?  The naive answer is: “well if we can just get 3% of this multi-billion dollar market then we’ll be doing okay”.  In practice, that doesn’t work – the market will eat you.  The rules of an established market are always stacked against newcomers, and in favor of the incumbents.

Well, how about destroying the market?  Shrinking it until the market leaders die?

Sounds harsh.  But this can be one of the more effective tools for a start-up trying to break in.  Instead of trying to carve out a space by following the existing rules of the marketplace, the start-up just lets all the air out of the balloon.  The incumbent giants asphyxiate from lack of oxygen (meaning money) and the startup is the only one left standing.  (Did I get enough imagery in there?)

Classic example: Craigslist.  Apparently there once was this profitable part of the newspaper business called “classifieds”.  Ostensibly, (and I know this may be hard to believe), people paid actual money to place their posts, er, ads, into the newspaper for other people to see.

Craig Newmark made short work of that.  Craigslist monetizes only a tiny portion of their posting traffic – recruitment ads primarily – posted by companies, not individuals.  Everything else is free.  It’s hard to compete with free (as the music industry found out), so most of the air has gone out of the classified balloon.  Craigslist snatched up the tiny amount of air that was left.  By shrinking the market, Craigslist successfully competed against the big guys.

If you think about it, it’s a brilliant application of lateral thinking to the business problem.  Problem: the market is too big for me to compete.  Solution: shrink the market down until it’s a size I can handle.

The Web 1.0 shrinkage story was Ebay, who let the wind out of every auction house in the world.  More recently there’s stubhub, who’s wiping out the lucrative event ticket aftermarket (also known as scalpers).

The ingredients of effective market shrinkage seem to be:

  1. Identify a cash-rich market built on inefficiencies – artificial scarcity, a massive imbalance of power etc.
  2. Enter the market, replacing the basic business transaction.
  3. Give 90%+ of the service away for free.
  4. Watch the big guys asphyxiate.
  5. Build your business on the remaining 10%- left over.

Presto – a market where you’re now the leader, at a managable size for you.  Mind the pile of bodies.

Posted in business, tech strategy.

Tagged with , , , .

No comments

By loren – August 25, 2008

Virtual Teams, Real Value

We’re knowledge workers.  Why do we need to show up in the same place every day?  It’s not like we need to physically haul our digital bits up and down some sort of assembly line.  So why is it so important that businesses cram every single employee into the same office, so they can silently sit next to each other – sending each other emails and instant messages?

Everyone knows what telecommuting is these days, but still, businesses are nervous about using remote workers.  In this post I want to talk a little about some of the benefits of using remote workers, as well as some of the obstacles.  Note that I’m going to use the term “remote worker” to indicate someone who may be a telecommuter, but may also just indicate someone working at a remote office.

Advantages of Remote Work

Remote Workers Can Mean Less Physical Infrastructure

Telecommuters frequently do not require businesses to supply office furniture, computers or telephones.  A company who’s workforce was sufficiently composed of remote workers would have less need for physical infrastructure, such as a big office.

Remote Work is a Perk for Employees

To work remotely means the comfort of working at home, or perhaps a conveniently located local office, and often in a more casual and comfortable environment.  Additionally, it can mean that many of the “costs of working” for the employee can be reduced or eliminated: primarily the cost of commuting.  Especially in the current climate of high fuel costs, the benefit of not having to commute can be a significant financial gain for the employee.

Remote Work Means Not Having to Be Local

When it no longer matters if an employee happens to live near the office, the labor market opens up significantly.  Suddenly it’s not so important whether there are jobs for someone in the town in which they live – they can get work from an employer in another city somewhere.  From the employer’s perspective, if it becomes impossible to hire local talent in a particular area, perhaps they can find someone elsewhere.  Freeing the labor market from geography also makes it more efficient – salaries are less likely to be either artificially inflated or depressed based on what’s happening in the local area.

So there are some clear benefits to using remote workers, or to being a remote worker.  So why don’t companies do it all the time?

Problems with Remote Work

Best Practices Are Not Well Known

We don’t know how to manage people that aren’t in the office.  It’s really that simple – many managers have never been trained in how to manage virtual teams, and are uncertain how to proceed.  Old habits like “managing by walking around” is going to be more difficult when the staff isn’t in the office.  Not knowing how to manage virtual teams can lead to fear, of course, and result in the manager rejecting the entire idea.

Furthermore, many of the standard mechanisms of management become harder without physical presence.  Having a meeting where people call in remotely is often just not as good as one where all the people are in the same room.  Getting a virtual team together can require more reliance on new technology, with makes some people uncomfortable.  There’s nothing like wasting time trying to get some piece of collaboration technology to work to make you pine for a meeting where everyone is in the same room.

Lack of Trust

A common fear of managers is that remote workers won’t actually, you know, work.  This fear generally has its roots in a low level of trust between management and workers, and additionally in the lack of a usable metric to accurately gauge worker productivity.  If “productive” is merely defined as not being caught surfing the web by the boss then, yes, there is in fact no way to ensure that the worker is being productive.

Being Cut Off

One of the lesser known, but very real, problems with remote work is that the remote employee becomes separated from the hub office.  This can mean important news doesn’t reach them, they feel like they don’t have input in decisions, and over time this can result in them being passed over for opportunities.  The danger here is essentially that at a subconscious level, the people in the office don’t really consider the remote worker to be part of the team.  This is the product of the cumulative difficulty in communicating with the remote worker.

In conclusion, there are some tremendous benefits for both employer and employee in virtual teams, but there are also some major challenges to overcome.  In following posts on this subject I’ll talk a bit about methods and techniques that people use in working with virtual teams.

Worked in a virtual team?  Have an experience to share?  Send me an email at loren.davie <at> gmail.com, and let me know what you learned from it.

Posted in business, virtual teams.

Tagged with , , , .

2 comments

By loren – August 17, 2008

Stack ‘em Up

It’s been a bit longer than I wanted between posts – side effect of coming off of a vacation and going directly into a new job.  Sorry.  I’ll try to be more consistent, moving forward.

The idea of maintaining a single technology stack in a development shop is quite appealing.  If everyone knows the same programming language (the thinking goes), the same web framework, the same RDBMS and so forth, then life would be better.  Business really likes this kind of thinking.  It promises efficiencies of scale, reduced training costs, and easily replaceable employees.  This kind of “one true technology” approach is the foundational philosophy of corporate darlings Java and .NET.    Once you have the organization standardized on the tech, it is promised, then every part will play nicely with every other part, critical dependencies (such as employees) will be reduced, and the whole “what are we doing about technology” question just goes away.

Now, of course I support operational efficiencies, reducing training costs (well, to an extent: I view training as an investment), and so forth, but I think that the idea of “one true stack”, especially in service-oriented tech shops like web agencies, is a pipe dream.  The advantages of standardizing an entire company on a single tech stack are outweighed by the disadvantages.

Before I get into that, however, I want to introduce the idea of a “jealous” technology.  A jealous technology tries to take over as many aspects of the stack as possible; mandating a specific component at each level.  Some technologies are more “jealous” than others.  Microsoft is notoriously jealous:  the Microsoft web framework, ASP.NET, really wants to be deployed on the Microsoft web server: IIS, on the Microsoft operating system: Windows, backed by the Microsoft RDBMS: SQL Server.  Other combinations (yes, I know about Mono) simply don’t work as well.  And, on the other hand, Windows is something of a second-class deployment platform for most other web technologies (ever try to deploy Rails on Windows…with IIS?  Yuck…)

Speaking of Ruby on Rails, they’ve become a bit of a jealous technology themselves.  Rails projects now prefer a particular JavaScript framework (Prototype), version control system (Git), editor (TextMate), build system (Capistrano) and development operating system (OS X).  (As well as, obviously, programming language: Ruby). While it’s certainly not as bad as the Microsoft scenario,  I do have to ask the question as to why the web framework has any influence over what version control system I use.  Do you have to use all the technologies that I’ve listed above with Rails?  No, of course not.  But they are preferred.  Things go better with Coke Capistrano.

The point is that some technologies are better suited towards certain problems than others, and a blanket organizational standardization on a single tech stack leads to a tremendous amount of wasted energy spent on driving square pegs into round holes.  Ruby is not a great foundation for an enterprise-class messaging framework.  Java is not a good choice for a lightweight CMS.  And anything other than .NET is a bad choice for an app destined to be maintained by a bunch of MSDN types.

In fact, I’d argue that the cost of operation efficiencies lost by maintaining multiple tech stacks is exceeded by the cost of jamming technologies into inappropriate use cases.  So, as messy as it sounds, any technical organization that is project or service based (as opposed to being exclusively product based) should maintain a strategic “quiver” of different technologies, so it can deploy the best choice when faced with a business problem.  Otherwise a fragile monoculture is created, wasting a tremendous amount of developer effort, and adding artificial risk and expense to projects.

Posted in business, programming, tech strategy, web agency.

Tagged with , , , .

No comments

By loren – August 12, 2008

Hitting Pause

I’m going on vacation next week, so posting maybe slim.  (And by slim, I may mean nothing).  I may hop on to publish comments, depending on network connectivity and/or whether there are comments.

See you in a week!

Posted in meta.

Tagged with .

No comments

By loren – August 1, 2008

How to Work Web Agencies

I’ve performed postmortems on many, many web projects over the last couple of years, and over time I’ve seen certain patterns emerge; patterns that I now know push web projects towards success or failure.  While there are many reasons that projects succeed or fail that are entirely internal to web agencies, I have noticed that the client themselves wields tremendous influence over the success or failure of a project.

Over time I have identified 5 factors that clients bring to the table, that directly affect the outcome of a web project.  These factors can accumulate and ultimately swing the fate of a project from success to failure or vice-versa.

Here they are:

Don’t Be Overly Price Sensitive

Guess what?  Agencies are expensive.  If you want to build a website on the cheap, you probably don’t want to deal with an agency, you want to keep the project in-house as much as possible, and outsource the rest to individual contractors.  Quality can suffer this way, because you are now the web project manager (and presumably you have something else to do), but it theoretically can be cheaper.  Trying to pinch pennies with an agency can cause compromises in the quality or scope of your project that can be hard to predict.

Be Flexible on Features

Clients who want to control every last feature can lose sight of the main goal: getting a working web site that meets their business goals launched. In my experience, the best projects are ones with strict deadlines, but with some flexibility in scope.  Over the course of production, hard decisions may need to be made about whether features should be included in the upcoming release.  Generally speaking, being flexible on features, but sticking to the established release schedule, is the right decision almost every time.

Be Decisive

Clients who are indecisive, or who have decision-by-committee issues, bring risk to web agency projects.  The best projects are ones where there is a single project owner on the client’s side, who is empowered to make decisions and grant approvals about the web site.  The ability to provide clear, timely feedback and direction to the web agency is essential.  On the other hand, a client that waffles, takes forever to make approvals, or sends mixed signals to the agency just makes everything harder.

Trust and Defer

Trust the web agency, they know the web, that’s what you’re paying them for.  If you don’t feel like you can trust them, then you shouldn’t hire them in the first place.  In order for an agency to operate efficiently, it needs a certain amount of autonomy and independence from the client.  Only then can it employ its internal best practices, and do the best job it can.  Micromanaging an agency actually removes value for the client.

Be Savvy

Understand the web.  Understand your own business.  Understand how web agencies work, if possible.  The more sophisticated you are, the better the project will run.  In the past I’ve known clients who have asked for web sites, who never actually use the Internet themselves.  How could they make informed decisions about their own web site, if they spend no time on the web?  By taking the time to educate yourself about the environment in which your project lives, you’ll be stacking the odds in your favor.

There it is – clients that get all of these items right are a pleasure to work with, and they tend to get fantastic results from the agencies they use.  At the other end of the scale, clients that come down on the wrong side of all of these points can create situations that can be difficult or impossible for agencies to rescue.  By mastering these factors as a client, you’ll be doing the most you can to ensure the success of your project.

Posted in business, web agency.

Tagged with , .

No comments

By loren – August 1, 2008

Two Pizza Theory

Two Pizza Limit

Some time ago, back when I knew absolutely nothing (unlike today, when I merely know next-to-nothing), I allowed a number of business ideas be crushed by the fear that, once big competitors entered the market, I would be instantly destroyed.

Since then I learned about disruption and how it can provide a competitive advantage to new entrants in a market where they have no investment in the status quo.  Still, the massive resources that larger companies can bring to a project can be daunting.

Fortunately, there is a built-in upper limit to how many people can effectively collaborate together.  It seems that somewhere between 5 to 10 people productivity seems to top out.  Past that point, it starts to become necessary to formalize communications, with the unfortunate side effect of slowing everything down.  Teams below this threshold are sometimes called “Two Pizza Teams” or “ten-groups“.  At this size it’s easy to get everyone on the same page, so the “productivity-per-resource” ratio is going to be the best at this size.

The cumulative effect of this “two pizza limit” is that there’s a natural productivity resistance point at a relatively small number of people.  Beyond this point productivity drops off, consuming more and more resources for less productivity gain.  This effectively means that the playing field is somewhat evened between large and small companies, even though a larger company can, in theory, throw many more resources behind a project.

So if you are a smaller company, but have a great, disruptive idea, and between 5 to 10 people to throw at it, you can swim with the sharks.  The nature of human collaboration will provide a degree of protection against much larger competitors with more resources.

Posted in business.

Tagged with , , .

1 comment

By loren – July 31, 2008

Everything but the Kitchen Sync

“Math Sync is hard” I keep hearing.  Why does this area suck so much?  Why is it so damn hard to synchronize my calendar and contacts with multiple sources?  What is up with that?

I mean, seriously, isn’t this just version control?  Haven’t we solved this problem a million times with Subversion, Mercurial, Git and so on?  Why is this such a big deal?  Take the latest version of the content, merge it in.  If there’s concurrent modification then identify a conflict and kick it up to the user to resolve.  Done.  Look, they even came up with a standard, SyncML, on order to normalize communication of sync information.

And yet still, in 2008, I’m sitting here on the verge of starting with a new employer, and I’m wondering about what I’m going to do about their Exchange server.  Do I go for a Mac and use Entourage?  Try to push everything into Google calendar?  Use Spanning Sync to connect up iCal?  These are a lot of acrobatics – why can’t this Just Work?

Just to demonstrate that I’m not completely talking out of a nether-oriented-orifice, I’ve even started to do some work to lend sync services to Django.  It should be no surprise that I’m letting Mercurial do the heavy lifting.

Why is this space so backwards?  Well, I’m tempted to blame Microsoft – they managed to get the whole world to buy in on Exchange.  Companies that made otherwise sane technology decisions went with classic vendor lock-in, probably because there wasn’t much else out there to compete at the time.  Microsoft (man, it feels tired just talking about this) plays well with other Microsoft products, but not well with others.  There’s no CalDAV connector for Exchange, for example, meaning there’s no standards-based access to their calendar.  Grr.

Another reason this space is so lame is because sync has been too long considered to be an application feature, rather than a service (perhaps an OS service?) available to be leveraged by various programs.  This is the approach now taken by OS X, so I guess there’s some hope.  Even in the relatively advanced world of OS X, there’s a lot of hacks still going on.  I’m currently sync’ing OmniFocus on my desktop with the OmniFocus on my iPhone, using a WebDAV server that I set up myself.  NetNewsWire syncs by using NewsGator.

Dodgy.  I mean, this sort of works, but people don’t go around rolling their own disk i/o or network stacks just because their applications use them.  This stuff should just be available to use.  And it should Just Work.

UPDATE:  Ironically, Google calendar announced CalDAV support today.

Posted in business, commentary, mobile.

Tagged with , , , , , , , .

No comments

By loren – July 28, 2008

Thinking in Concurrency

A few weeks ago, Anwar Ghuloum at the Research@Intel blog advised developers that they should start thinking about “tens, hundreds and thousands of cores”.  In essence, the people that control processor development are telling us that the future of programming is going to move out rather than up.  To get an idea of the time line, Intel’s CEO tells us to expect 80 cores by 2011.  We can probably assume the number of cores on a processor is going to increase geometrically in the years that follow.

The catch is that we don’t really know how to program for this.

To take advantage of massively multicore architectures, we really need to take our computing problems and decompose them into smaller bits that can be farmed out to various worker processes.  This idea is what Google’s MapReduce is all about, and is an approach that has worked well with certain categories of problems, such as bioinformatic data analysis, or 3D rendering.

Programming Crisis

I am seeing a pending programmer educational crisis coming.  Most programmers just are not trained to think about this kind of decomposition.  They’ve learned functional and object-oriented languages, and tend to think in a linear fashion.  Furthermore, the nature of the programming languages and platforms they’ve  worked on has ingrained the concept into them that multi-threaded programming is extremely tricky.  And with mainstream platforms, it is.

A lot of the existing difficulty with well-known languages, such as Java, is managing shared state, or memory between different threads.  Java has various synchronization mechanisms, but using them in heavily multithreaded environments can be challenging.  I’ve seen unit tests randomly pass or fail, swinging on race conditions – which thread ended first – that determine the success or failure of the test.

In the web world we’ve become rather fond of very high level languages such as Python and Ruby.  However the runtime story gets even worse – most scripting language runtimes can’t acknowledge more than one processor at a time – meaning that the only way to parallelize work is to instantiate multiple instances of the runtime.  Besides this being a hack, it makes communication between processes awkward (usually relying on expensive data serialization), and creates the kind of issues that we’ve been trying to get away from with high-level languages: the developer has to deal with boilerplate computer science problems, rather than being allowed to exclusively concentrate on their business problems.

Concurrent Languages

One answer seems to be tech stacks that are designed for concurrency from the ground up.  Enter Erlang, a language developed for telephony applications by Ericsson.  Erlang handles concurrency very, very well.  For example, it circumvents the shared state problem by not having any shared state.  However, from the perspective of someone with a Java or Python background (e.g. me) it’s frickin’ weird.  Some serious adjustments in the way problems are approached have to be made.

Here’s a real simple code snip, that generates the squares of a list of numbers.  First a naive implementation in Python:

def squares(num_list):
    square_list = []
    for n in num_list:
        square_list.append(n * n)
    return square_list

A more compact version in Python, using a list comprehension:

def squares(num_list):
    return [n*n for n in num_list]

Here’s the same code in Erlang:

square([H|T]) -> H*H | square(T);
square([]) -> [].

Assuming you don’t know Erlang, can you even tell what’s going on? You’re looking at a completely different paradigm. The left side of the functions (to the left of the “->” marker) relies on pattern matching (sort of like regular expressions).  To the right side, the function implementation is tail recursion at work.  Needless to say, this is a bit of a departure for many developers.  I shudder to think of trying to take a department of developers who cut their teeth on Java and PHP, and train them up in Erlang.

This is why I’m so interested in projects like Reia.  In an attempt to fix the “impedance mismatch” between the coming massively multicore future, and today’s programming skills, their goal is to make a high-level Python/Ruby like language that compiles onto bytecode that will run on the Erlang VM.  It’s in a very early stage, and I’m not sure if it will ever gain critical mass, but this is a problem that needs solving, and I’m intererested in any attempts.

Posted in programming, rampant speculation.

Tagged with , , , , .

1 comment

By loren – July 24, 2008

Housekeeping

I’ve added the  WPTouch plugin, which puts up a nice mobile interface for this blog.  Also I discovered that I had a setting turned on that prevented the blog from being spidered by search engines, which probably explains why I wasn’t showing up on any of them.  Doh.

UPDATE: Also installed Akismet, upgraded to WP  2.6, installed the auto-update plugin (awesome plugin),  and finally made the permalinks prettier.

Posted in meta.

Tagged with , .

No comments

By loren – July 23, 2008

Not Your Father’s Beta

As I watched Django announce its 1.0 Alpha release, I experienced a vague sense of disorientation, which I suddenly realized was coming from the actual, correct use of the terms Alpha, Beta and Gold (or Final) by the Django project team.  You see, I work in the web industry, where those terms are generally just abused.

The proper use of the Alpha and Beta terminology are to describe early pre-releases of software, for the purpose of making the software available for late-stage acceptance testing.  Alpha and Beta software is, by definition, not ready for prime time.

Of course, this very concept is all rooted in pre-Internet shrink-wrapped software.  The Gold master was a CD, (or a cassette tape etc) that was physically shipped out.  It was critical to get the app into a stable state, because once it shipped it would be expensive to patch it.

With websites, the code that runs them is updated all the time.  I can pretty much guarantee that with any major website you frequent, the code that’s running it this month is slightly different from what was running it last month.  Or yesterday, for that matter.  The entire concept of releases is somewhat nebulous on the web.

But the business world thinks that software terminology is cool.  So we’ve labeled every web 2.0 website “Beta”.  It’s pretty widely understood now that “Beta” means “don’t blame us too hard if there’s bugs”.

In the agency world, there’s an even more shadowy use of these greek letters.  It has become a kind of psychological trick used to get clients to focus on only essential features.  It goes something like this:

Client:  I want a website with 8 million features of dubious value.  And a pony.
Vendor: Okay, okay.  We’ll get you that pony.  But let’s get the real core stuff out the door first.
Client: I want a pony!
Vendor: Okay, well how about we release Alpha this year with the core features, then Beta the year after that.  Then, we can focus on getting that pony for you in the 1.0 release, in two years.
Client: Well, okay.  As long as I get a pony for 1.0, then.

In a sane universe, these would simply be considered different releases: 1.0, 2.0 and 3.0.  But that doesn’t score the proper political points.  All that stuff that the client read about in Wired magazine has to make it into 1.0 in their minds, so the agency responds by re-defining what 1.0 means.  And that means abusing the Alpha and Beta terms.

Posted in web agency.

Tagged with , , .

No comments

By loren – July 22, 2008