AIAIO: Our Blog
AIAIO: Our Blog
The pulse of Alexander Interactive
Author Archive
Cost of Leadership
(For the purposes of this post I’m defining leadership pretty broadly. It could be leadership in the context of business, community, technology, professional or academic areas. The sky’s the limit.)
It’s tempting to shoot for the biggest target; to attempt to establish leadership in the biggest market, in the most popular meme, or the latest craze. However there is a cost to leadership – it takes time, energy and skill (and sometimes money) to lead within a context. The more established that context is, the more of those resources it will require from a leader.
In the web world, for example, the leaders of the biggest segments get a lot of press. Amazon and Ebay are e-commerce leaders. Google is the search leader. Apple is definitely a leader of something, although we’re not sure what to call it (“coolness?”…ew…). Notice, however, that these leaders are also giants. Because they operate in such large, well-established spaces, they need to have immense resources in order to maintain their leadership position.
I’d like to propose that the benefit of being a leader follows a kind of “S”-curve. If you look at the graphic, the straight black ascending line represents the amount of investment (time, energy, money) necessary to attain leadership within a context. The red line is the benefit to the leader to hold that position. Notice that there are two places on the graph where the red line exceeds the black line. Those are the sweet spots.
The first spot, on the far right, is the one that gets all the press. This is the geometric value afforded to Amazon, Google and so forth, because they hold a leadership position in a well-known established space. The benefits here are obviously huge. Unfortunately it requires an enormous investment, which is often not an option for smaller companies, or individuals, making it seem like it’s an impossible task to get ahead through leadership.
However, there is a second, less noticed sweet spot just left of the middle of the graph. This represents a space in “early adopter” territory. A new idea that is beginning to get some traction, but hasn’t yet entered the mainstream is an area where a modest investment in time, energy and perhaps money can yield a significant benefit. One can “hitch their wagon” to the new thing, and become recognized as a leader for doing significant things at a modest scale. For individuals, small companies and organizations this is the acheivable sweet spot.
When the space matures and moves along to the middle of the graph the return on investment of leadership evens out: the idea has entered the mainstream, and the benefits of displaying leadership are no longer attractive in proportion to the amount of investment that has to be made. At this point it’s too easy to be accused of just “jumping on the bandwagon”, in other words – not a leader.
To sum up, the opportunity for benefit from leadership comes in identifying an idea, meme, technology or whatever that has significant momentum behind it, but isn’t quite ready for prime time for non-early adopters. Get involved, make things better somehow, contribute to any surrounding community. The benefit that comes back will exceed the cost of leadership.
Continuous Breakage

When I started working at Ai there were about 6 people. Now there is about 40. In speaking with a colleague yesterday, I stumbled upon the essential mechanism of a scaling company: breakage. A scaling company is one in which good, working processes break. Continuously.
The mechanism itself is simple: business processes put in place when there are 6 people stop working when there are 12. Processes that work at 12 people then strain under 24. Processes at 24 fail at 35. Failing processes are a normal part of a growing company. It’s healthy. Painful, but healthy.
The role of good management is to be ready for process failures and respond actively: either by adjusting or replacing business processes to fit the needs of the company at its new size. Unfortunately, this can’t be done prematurely – it can be just as destructive to roll out a process that is optimized “too large” than it is to cling to one that is optimized “too small”. The balancing act is to wait until the appropriate time to adjust a business process, recognizing that occasionally it will feel like overkill when it is initially implemented.
The other factor that can be easy to overlook is that there are people involved. Processes shape people’s jobs and thus their experience at work. If a person’s job description changes as a consequence of a process adjustment, it can be interpreted as a change in their prestige or status. Great care needs to be taken in order to not unduly ruffle feathers in the pursuit of a working organization. The people have the same value they’ve always brought – its the organization that has changed.
Micro-Problems
Micro-payments. Cool huh? The term was thrown around for awhile as the solution to content providers looking to find a revenue stream. People could show up on a website and buy some content for a tiny amount – insignificant to them. But the tiny amounts would add up and the content provider would make some real money.
- $3 to $5 The Starbucks Range: It’s arguable whether this range is really micro-payments. It’s more like mini-payments. Equivalent to an espresso bar drink in terms of cost, this range has a relatively low resistance to sales for items that are perceived to have value. Movie rentals on iTunes are in this range.
- $1 to $2: The iTunes Range: Long been considered the range of acceptable pricing for music and TV shows ($1 and $2) respectively. This range seems to be low to no resistance for downloadable goods – at least for those who are willing to pay for digital media at all.
- Less than $1:The Mythical Range: The realm of the original micro-payments range. A price point considered to be so low that no one could possibly object to it. Not much in the real world lives at this tier, for reasons we’ll see in a minute.
Wither Windows?
So quite recently, the Ruby on Rails open source web framework announced that they would be migrating from the Subversion code repository they had to a new one managed by Git. Git is a version control system created by Linus Torvalds to manage the Linux kernel. Linus had several requirements in mind when he made Git, requirements that involved specific sets of features, scaleability, stability etc.
Triangles of Doom
Cheap. Fast. Good. Pick two. That’s the classic project triangle. As best as I can tell its an immutable law of the universe. No matter how much you try, you can only control 2 points at any given time. At Ai (driven by Wertheimer) we incorporate these points into a statement of priority from the clients, called a Faceted Feature Analysis. (Link will take you to the full story). Different clients are sensitive to some points on the triangle more than others, so we move the project priorities around in order to accommodate them.
This triangle is a source of confusion, however. That’s because there is (or at least seems to be) more than one triangle in play. In fact there are three, making a triangle of triangles.
The second triangle is the Faceted Feature Analysis (FFA) triangle.
The mapping between the first two triangles is mind-bending, but legit. What we’re saying here is:
- If Cost is the most important factor to a client, then Business Value is paramount.
- If Time is the most important factor to a client, then Technical Ease (how easy it is to build) is paramount.
- If Quality is the most important factor, then User Value (or usability) is paramount.
The FFA triangle is about prioritization. It is implied by the classic project triangle, but it serves a somewhat different purpose. This is all about trying to figure out which features are the most (or least) important.
Which leads us to this triangle – the bad news triangle. This is the one that gets pulled out when hard decisions have to be made, the one that people most want to deny. (Deny it all you want – this is like the Law of Conservation of Energy at work here…). At a certain point, something has to give – it can be that the schedule might not happen exactly on the target date, or it might be that the budget might be a bit different than originally anticipated or that the features delivered might be a bit different than originally anticipated. Maybe this should be called the Honesty Triangle.
UPDATE: Some people (who didn’t bother to leave a comment) feel that the last paragraph is too negative, that it implies that projects always ride off the rails, and that drastic scope needs to be cut, or drastic schedule slippage must occur or that massive budget adjustments must be made. Sorry if you got that impression – that’s not what I’m trying to say.
The point is that there MUST be a flexible point on the triangle. The triangle is viewable through various perspectives, depending on the condition of the project, which can be influenced by many, many factors. No one wants to be in the Honesty Triangle, which is the point at which you must make hard decisions. And most of the time, you don’t have to be there. But, should you, for whatever reason, find yourself with a project where the schedule is slipping, then its time to look at the honesty triangle. Honesty hurts, remember.
Distributed Art
Once upon a time I had a rock band called Blue Shift. We made music, loudly, in smoke-filled bars (remember those?) in the 90′s in Toronto, wishing we had enough money to be able to afford to record more of our stuff. I like to think that we were ahead of our time. As you may have noticed, you’ve never heard of us.
A little while ago I was suddenly struck with a revelation – a lot of the problems I had back in those days, stuff that held us back, had simply packed up and left in the night. I could now afford recording equipment, due to both my increased income (from, you know, zero) and by the fact that digital recording technology had made professional recordings so much cheaper than they used to be. There were many channels to digital distribution open on the Internet.
I had been sitting around thinking about trying to scrape together yet another band from craigslist when suddenly it struck me – why not just go and get the old band? The fact that we don’t live in the same city doesn’t matter.
So now I’m looking at four words I never, ever, thought I would see: “New Blue Shift Album”. We’re all sitting on our own project studios, as it turns out. The project will basically work like this:
- We’ll agree what songs to record. We’ll establish song structure and tempos.
- I’ll record a scratch vocal and guitar track to be a guide.
- Our bass player will be doing drum programming – he’ll create bed tracks (drum and bass).
- We will lay down our overdubs (guitar, vocals, keys etc).
Any one of us are allowed to mix at any time. Someone doesn’t like my mix? Fine – make your own. We continue to lay down tracks and make mixes as we go along.
Eventually we agree on approving mixes to be the “official version”. We get enough tracks like that – and that’s the new album.
I am quite inspired by this – this is a way in which the Internet has personally changed my life – something that simply was impossible before is now in reach. I’ll probably throw up a side blog to talk about this project as it progresses.
Meditations on Tech Conferences
I went to PyCon over the weekend. It was definitely the largest tech conference I’ve been to so far. Subcultures fascinate me in general, but this was really interesting. Over 1000 really smart, focussed and innovative technical types crammed together in the same hotel. It was kind of like drinking from a fire hose – I needed to take little timeouts in order to make it through the weekend.
Geek culture is generally polite and trustworthy. I found that I had no problem letting a complete stranger watch my laptop while I went to the bathroom.
Maybe it was just affinity at work. I sense that many people were dealing with similar problems that we were trying to solve in different ways. For example, I found that one tutorial leader was applying himself to a problem space (massive, fail-safe parallel computing), using Python, that seemed very similar to the kinds of things that Erlang was designed to handle.
Perhaps Test Driven Development should be called Guilt Driven Development. Mostly it seems to just make developers guilty about not testing their code enough. Or for those who do test, smug. Bastards.
Oh and finally, I learned a lot about using slides. So many people know this, but I’ve never seen “less is more” so graphically spelled out for me. I’m never using bullets on a slide again.
They’re baaack!
My life has been previously sliced up into distinct, and mostly non-overlapping chapters. I’ve lived in Toronto, Montreal, San Francisco and New York (and a couple of adjacent suburbs that I won’t get into). In each place there have been a number of people that I’ve known. In time, I’ve moved on and only marginally keep in touch with friends from the old ‘hood. I’m what they used to call a lousy letter-writer.
It’s not so bad. I have great memories from each place, and my life is organized into distinct chunks. I’ve gotten used to the idea of thinking in terms of ”so-in-so from my former life at location X”. Frozen in time, these memories provide a nice back drop for my identity.
Now, however, Facebook is screwing it all up. My entire life (in people) since high school has all been sucked into Facebook. Everyone I’ve ever known is already there. And they’re all friending me (or I them). Twenty years of time, compressed into nothing.
When yet another mysterious figure from my past “friends” me, I’m suddenly privy to some very disturbing photographs, where I can see the effects of 10 to 20 years of aging all at once. (“Dude, you have no hair! What happened?”) Often they’re accompanied by mysterious young short people in these photographs. Short people that weren’t there before.
I feel like I’ve fallen into a time warp, or maybe am watching my life flash before my eyes. Except it’s the life that I didn’t live, all the paths that I didn’t go down, with people that I didn’t keep in touch with. They’re all back. They’re on Facebook, they’re my friends and they’ve escaped from their neatly delimited chapters in the past to invade my present.
SLA’s for Web Services?
On Friday, Amazon’s S3 online storage service went down for awhile. Many different online services now use S3 as a way to distribute content and store media online, and everywhere S3 is used – things didn’t work for awhile this morning.
Is this an unacceptable failure of an automated business process? Or should we just accept it as the normal behavior for the web? Clearly a service like 37s Basecamp can’t ensure that S3 stays up, because they have no control over any of Amazon’s services. But their paying customers were nonetheless compromised when Amazon’s service went down.
Wikipedia defines a Service Level Agreement as an agreement between parties that defines a “level of service” in terms such as percentage of uptime, power uptime etc. It has its roots in agreements between telecom companies and their corporate customers.
As more and more mission critical business is moved over to online services that themselves may outsource functionality to other parties, the question of reliability comes up. Where is the assurance that the third party will be there when you really need them? It was these kinds of questions that led to SLAs in the first place.
SLA-backed web services could be viewed as premium – something that you pay an additional amount, in order to ensure that the vendor is investing in the infrastructure to ensure the required level of service. Vendor’s could look at SLA-backed service as a potential profit center.


