If you wanted to prove that dead-tree publishers are brain dead and will not be missed during the e-book revolution, exhibit #1 would be their handling of the Witcher saga, of which the third book is Blood of Elves. Whereas the first novel, The Last Wish was entertaining and a lot of fun, Orbit chose to release the third book in the series next, skipping over a lot of the back story for Blood of Elves.
The story revolves around Geralt's child surprise, whom he apparently recovered in the earlier book and finds himself having to care for. The novel moves forwards in spurts, with lots of time between many sections. One of the worst things, however, is that you never get a good overview of what's going on. A lot of hinting, and lots of wheels grinding in the background and a little clumsy exposition of various factions plotting.
We do see a few characters that showed up in The Witcher, but the reality is, the book ends before giving us any satisfaction.
Not recommended.
Friday, September 30, 2011
Thursday, September 29, 2011
REI Series of Talks is Over!
 |
| From BayArea |
At a WorldCon seminar, Sandra Tayler told me that people get hung up on the bookstore signings, and that's why they try their darnedest to be published by a traditional publisher rather than being an independent publisher. Well, even if you're an indie person, there's no need to give up on doing the bookstore signings, you just have to arrange it yourself. An Engineer's Guide to Silicon Valley Startups and Startup Engineering Management don't lend themselves naturally to public venues (though I've certainly given plenty of talks covering those topics in private venues), but Independent Cycle Touring was a completely different beast. I started off by giving a talk at the local Sports Basement, but after chatting with REI, was put in touch with Polly Bolling back in March about the possibility of doing a series of talks at various REI. Strung together over a period of about six weeks, this is about as close to a traditional bookstore tour as I'm likely to get. Polly had great insights as to what worked for an REI talk and what doesn't. She suggested that I focus the talks on Europe, and that destination-oriented talks really got people in the door, so I refocused the talk around Europe. You can see the slides as posted earlier.
Getting into REI is a long lead time process. It wasn't until late May that I was confirmed as booked, and it wasn't until June that I was given the OK to publicize the series of talks. I had no idea there were so many REIs: I could have done even more REIs, but at some point decided that I really didn't need to go to all of them.
The turnout at various REIs was widely disparate. I had as few as four people, and spoken to as many as 70 people in a fully packed room. The venues ranged from a professional looking classroom/community room to a warehouse where REI employees would make room in the space just an hour or so before the talk. With pleasure, I can say that the projectors and screens were always more than acceptable, and equal to what I found in industrial settings. The employees (including Polly herself) were always happy and enthusiastic and willing to do whatever it took to make the talk work. It was a good thing that I was given a few smaller venues to work with first before I started hitting the large ones (Berkeley/San Francisco/Mountain View/Saratoga). This gave me a chance to refine my talk, and let me get a good view of what played well with the audience and what didn't. I knew I had hit my stride when members from the Berkeley audience came to me after the talk and said, "Best REI talk I've ever been to, and I attend nearly every one." That was very gratifying. One reason I'd gotten good at talks, by the way, was that giving talks at Google was even more demanding --- if you did not proceed at a pace fast enough and fun enough to keep an audience's attention, Google employees would flip open their laptops and check e-mail instead. Authors/speakers who were used to a less demanding audience probably did not have a good time at Google.
Polly told me to keep my expectations for selling books low, saying that selling one or two books would be about right. Well, I kept my expectations low, but my conversion rate was about 12-15%: in other words, about 1 in 10 people who saw the talk would buy the book. That's far better than say, Adwords or classified ads, so I'd say that the talks were definitely worth the time. It was also interesting to see how every REI was different: some clearly catered to more cyclists than others, and it was clear that the North Bay had a wildly different demographic than the South Bay.
All in all, I probably won't try to do another book tour type event for the foreseeable future. I can see why some authors find them exhilarating: there's nothing like speaking to a fully packed room with an engaged audience, and the people flooding you with questions, asking to buy a book and asking you to sign one is extremely flattering. It's a lot like the high you get from getting to the top of a climb and facing a glorious descent afterwards. Ultimately, though, you still have to get back to writing interesting work for an audience that is willing to pay for it, and the talks and signings are a bit of a distraction from it, though I'm grateful for the sales and hope it sparks future sales!
(If you want to watch a short excerpt from the MTV talk, I've got one up on YouTube)
Tuesday, September 27, 2011
Review: The AI War
Daniel Keys Moran's Continuing Time series has been one of my favorites. He's a good writer with compelling characters that keep you reading, no matter how absurd the plots are. I once made the mistake of lending The Long Run to a friend on a bike tour, and during the night she retired to her tent and stayed up all night reading instead of sleeping and getting ready for the next day's ride. If you're unfamiliar with the series, read The Long Run and The Last Dancer before reading The AI War. The web-site for buying the book's incredibly unintuitive, expecting you to return to the product page after purchase in order to make the download, so you might want to visit Amazon instead.
The AI War is a Trent novel. Trent is one of Moran's great characters, and here he's involved in thwarting the Unification's big project. The plot-holes are pretty large: why build one giant ship instead lots of little ones. But the details are a lot of fun. Moran is a programmer by trade, and it's good to see his model of how a 10X programmer works. Trent infiltrates the project as the chief engineer, and soon puts the project on schedule. Along the way, we get a biography of a few side characters and some future sub-plots are set up.
If I'm annoyed by a few things, it's that the book's far too short (it says "part one"), and there's no AI war (yet) that as far as I can tell. I also wanted to see the unresolved plotlines from The Last Dancer filled in. Unlike other novels in other multi-part series, however, at least this is not a book where nothing happens, and it's a compelling read start to finish (I bought the book last night and it grabbed me by the eyeballs and made me stop reading the other book I was reading). You could read this book without reading any of the other books in the series, but I think you'd find the book a little less fulfilling without the rest of the back-story. Also, The Long Run is still a better read. Go buy it already.
The AI War is a Trent novel. Trent is one of Moran's great characters, and here he's involved in thwarting the Unification's big project. The plot-holes are pretty large: why build one giant ship instead lots of little ones. But the details are a lot of fun. Moran is a programmer by trade, and it's good to see his model of how a 10X programmer works. Trent infiltrates the project as the chief engineer, and soon puts the project on schedule. Along the way, we get a biography of a few side characters and some future sub-plots are set up.
If I'm annoyed by a few things, it's that the book's far too short (it says "part one"), and there's no AI war (yet) that as far as I can tell. I also wanted to see the unresolved plotlines from The Last Dancer filled in. Unlike other novels in other multi-part series, however, at least this is not a book where nothing happens, and it's a compelling read start to finish (I bought the book last night and it grabbed me by the eyeballs and made me stop reading the other book I was reading). You could read this book without reading any of the other books in the series, but I think you'd find the book a little less fulfilling without the rest of the back-story. Also, The Long Run is still a better read. Go buy it already.
Monday, September 26, 2011
Execution Strategy and Business Strategy
Rebecca Frankel shared on her Google Reader Feed this image:
I think it's a great example of execution strategy. A frequently used execution strategy is to standardize on one platform and optimize on delivery that way. The nice thing about this strategy is that if you're the startup and the incumbent has built in legacy systems and costs that keep them from executing on the same strategy, you'll have a built-in advantage that will continue for a good long time. For instance, it's hard for an airline to switch the hubs it's using after it's been locked into a long term contract. And obviously, it's hard for incumbent airlines to sell all their fleets and standardize on the 737. The strategy that RyanAir uses, by the way, was first pioneered by SouthWest Airlines. A good execution strategy like this can be easily explained to all your employees to the point where everyone knows what the strategy is, leading to broader alignment.
At Google circa 2003, the execution strategy was straight-forward: build clusters of commodity machines driven by a common software infrastructure so scaling was straightforward. Once MapReduce was adopted, for instance, your mapreduce jobs were datacenter independent and could be run on any number of datacenters. Similarly, all projects could share a single set of site reliability engineers, release engineers, etc., and your resource constraints could be relieved by effectively hiring in all these areas.
The problem comes when you have a new product that doesn't fit your existing execution strategy. Orkut, for instance, was initially written using Microsoft's .NET framework. That didn't fit in with what the rest of Google was doing. It rapidly became a popular product, and the system started falling over from the huge number of requests. The team was staff-constrained, and few engineers inside Google wanted to work on a product that was clearly way out on the left field with respect to Google's execution strategy. To be honest, nobody knew how big social networks were going to be. The result was that it took a while to rewrite Orkut to conform with Google's execution strategy, and by the time it was done enough time had passed and enough users had migrated to another social network that the rest was history. In retrospect, the right thing to do should have been to spin Orkut off, have it raise its own funding round (with Google kicking money), and race quickly to deal with its scaling problems independent of the rest of Google's infrastructure. Facebook might still have won, but at least Orkut wouldn't have been paying Google's strategy tax. Microsoft has its own strategy tax here in that everything has to be tied to windows, but I think even Microsoft's starting to move away from that with its phone and tablet entries.
Business strategy is a whole different animal. In some ways, it's like playing a strategic board game with your business. I'll give you an example. Microsoft invested $240M in Facebook in 2007 at the then stunning valuation of $15B. At that time, Facebook was not profitable (and would become profitable based on Microsoft's guaranteed revenue), and it looked like Microsoft was desperate, throwing money at Facebook. Well, 4 years later, it looks like a brilliant move. Not only does it look like Microsoft's investment will pay off (at least 4X, maybe more), Facebook's been a tremendous thorn on Google's side, probably accounting for no small amount of management distraction, time spent launching (and re-launching) competitive products, and I'm sure no small drain on Google's engineering team. Time will tell as to whether Microsoft's acquisition of Nortel's patent portfolio, essentially forcing Google to buy Motorola will be similarly smart, but spending $4.5B (and that's split between Apple/RIM/Sony/EMC, etc) so that your competition has to spend $12.5B (and ends up having to run a hardware business that's not particularly profitable --- Motorola's the weakest of the Android manufacturers) looks pretty smart right now.
Another company which is good at this is Amazon. The Kindle, for instance, unusually attacked the market from a completely different angle. It's early adopters were not the usual hip 20-somethings, but were the older generation: people who still read and whose deteriorating eye-sight and arthritis made the Kindle an almost must-have. This was so much ignored by other vendors (Apple included) that by the time other ebook stores launched, nobody else has made a dent in electronic book distribution. By ensuring that the Kindle App is available for nearly every platform, Amazon has gotten a choke-hold on electronic book distribution that's only starting to be realized at this point.
Someone told me a little bit back that Amazon's S3 services were priced at below cost at launch. Basically, they bet that they could drive costs down a bit, and that customers would see the move to their cloud services as a no-brainer at those prices and thereby gain them further economies of scale. At this point, I've run into lots of companies that have based their businesses on S3, but comparatively few who've done so on Google's AppEngine infrastructure AppEngine is a bit of a red-headed stepchild at Google because it can't be priced to produce high margins, while Amazon's very much used to low margins.
Obviously, business strategy is of no use if you screw up your execution strategy (or if your product sucks --- nothing ever saves you then), but ideally you want everything in place. Amazon's been the stealth surprise in the past few years in places that looked completely unrelated to e-commerce because of this. At the same time, Microsoft's not being doing so well at execution but its business strategy successes are being ignored by the press, and I think that counting them out would be a mistake.
I think it's a great example of execution strategy. A frequently used execution strategy is to standardize on one platform and optimize on delivery that way. The nice thing about this strategy is that if you're the startup and the incumbent has built in legacy systems and costs that keep them from executing on the same strategy, you'll have a built-in advantage that will continue for a good long time. For instance, it's hard for an airline to switch the hubs it's using after it's been locked into a long term contract. And obviously, it's hard for incumbent airlines to sell all their fleets and standardize on the 737. The strategy that RyanAir uses, by the way, was first pioneered by SouthWest Airlines. A good execution strategy like this can be easily explained to all your employees to the point where everyone knows what the strategy is, leading to broader alignment.
At Google circa 2003, the execution strategy was straight-forward: build clusters of commodity machines driven by a common software infrastructure so scaling was straightforward. Once MapReduce was adopted, for instance, your mapreduce jobs were datacenter independent and could be run on any number of datacenters. Similarly, all projects could share a single set of site reliability engineers, release engineers, etc., and your resource constraints could be relieved by effectively hiring in all these areas.
The problem comes when you have a new product that doesn't fit your existing execution strategy. Orkut, for instance, was initially written using Microsoft's .NET framework. That didn't fit in with what the rest of Google was doing. It rapidly became a popular product, and the system started falling over from the huge number of requests. The team was staff-constrained, and few engineers inside Google wanted to work on a product that was clearly way out on the left field with respect to Google's execution strategy. To be honest, nobody knew how big social networks were going to be. The result was that it took a while to rewrite Orkut to conform with Google's execution strategy, and by the time it was done enough time had passed and enough users had migrated to another social network that the rest was history. In retrospect, the right thing to do should have been to spin Orkut off, have it raise its own funding round (with Google kicking money), and race quickly to deal with its scaling problems independent of the rest of Google's infrastructure. Facebook might still have won, but at least Orkut wouldn't have been paying Google's strategy tax. Microsoft has its own strategy tax here in that everything has to be tied to windows, but I think even Microsoft's starting to move away from that with its phone and tablet entries.
Business strategy is a whole different animal. In some ways, it's like playing a strategic board game with your business. I'll give you an example. Microsoft invested $240M in Facebook in 2007 at the then stunning valuation of $15B. At that time, Facebook was not profitable (and would become profitable based on Microsoft's guaranteed revenue), and it looked like Microsoft was desperate, throwing money at Facebook. Well, 4 years later, it looks like a brilliant move. Not only does it look like Microsoft's investment will pay off (at least 4X, maybe more), Facebook's been a tremendous thorn on Google's side, probably accounting for no small amount of management distraction, time spent launching (and re-launching) competitive products, and I'm sure no small drain on Google's engineering team. Time will tell as to whether Microsoft's acquisition of Nortel's patent portfolio, essentially forcing Google to buy Motorola will be similarly smart, but spending $4.5B (and that's split between Apple/RIM/Sony/EMC, etc) so that your competition has to spend $12.5B (and ends up having to run a hardware business that's not particularly profitable --- Motorola's the weakest of the Android manufacturers) looks pretty smart right now.
Another company which is good at this is Amazon. The Kindle, for instance, unusually attacked the market from a completely different angle. It's early adopters were not the usual hip 20-somethings, but were the older generation: people who still read and whose deteriorating eye-sight and arthritis made the Kindle an almost must-have. This was so much ignored by other vendors (Apple included) that by the time other ebook stores launched, nobody else has made a dent in electronic book distribution. By ensuring that the Kindle App is available for nearly every platform, Amazon has gotten a choke-hold on electronic book distribution that's only starting to be realized at this point.
Someone told me a little bit back that Amazon's S3 services were priced at below cost at launch. Basically, they bet that they could drive costs down a bit, and that customers would see the move to their cloud services as a no-brainer at those prices and thereby gain them further economies of scale. At this point, I've run into lots of companies that have based their businesses on S3, but comparatively few who've done so on Google's AppEngine infrastructure AppEngine is a bit of a red-headed stepchild at Google because it can't be priced to produce high margins, while Amazon's very much used to low margins.
Obviously, business strategy is of no use if you screw up your execution strategy (or if your product sucks --- nothing ever saves you then), but ideally you want everything in place. Amazon's been the stealth surprise in the past few years in places that looked completely unrelated to e-commerce because of this. At the same time, Microsoft's not being doing so well at execution but its business strategy successes are being ignored by the press, and I think that counting them out would be a mistake.
Saturday, September 24, 2011
Review: The Dragon Never Sleeps
The Dragon Never Sleeps (DRM-free kindle-compatible edition) was a difficult book for me to read. The first time I tried to read it, I couldn't become interested in the characters, and abandoned it. However, at this year's WorldCon, Cook mentioned that it was one of his proudest novels, so I went back and read it again.
The universe Cook weaves is a compelling one. You've got organic military vessels that are nevertheless non-sentient. Starships travel through space on strands of the Web, which turn out to harbor a deeper secret. The war against methane breathers comes with deeper intrigues. Planet-side, the feudal structure of the milieu provides us with a key source of human intrigue. Just as interesting, cloning is an option and is frequently used, and used imaginatively by the author. Yet all this is done without long expositions. It all just happens inside the text. Cook is the master of the brief sketches and dialog that brings out character, and he uses that in this novel in spades. As you might expect, there are no plot-holes here. Everything makes sense if you've been paying attention, yet the surprises are genuine. It's also interesting that the science fictional world portrayed is one where technology is more or less static, and has been for thousands of years, so one military force (guardships) could be designed for immortality without the risk of obsolescence.
There are flaws in this book. The big one is that there are too many characters for you to properly care about, and the important characters aren't fully high-lighted, so if you're going along rapidly you might have to go back and re-read a passage when one reveal or another happens. Cook also flips between nick-names, titles, and real names all the time, which could be confusing, especially since the character cast so so large. All this combined together to make an unusually long (by Cook's standards) book means that the reading gets too dry at times and I had to take breaks. It took a long time to finish this book.
Nevertheless, if you're a fan of Cook's characters, matter of fact exposition, and want to see what he does with science fiction, this is definitely recommended (unlike Passage At Arms. Just don't expect it to be a quick airplane read.
The universe Cook weaves is a compelling one. You've got organic military vessels that are nevertheless non-sentient. Starships travel through space on strands of the Web, which turn out to harbor a deeper secret. The war against methane breathers comes with deeper intrigues. Planet-side, the feudal structure of the milieu provides us with a key source of human intrigue. Just as interesting, cloning is an option and is frequently used, and used imaginatively by the author. Yet all this is done without long expositions. It all just happens inside the text. Cook is the master of the brief sketches and dialog that brings out character, and he uses that in this novel in spades. As you might expect, there are no plot-holes here. Everything makes sense if you've been paying attention, yet the surprises are genuine. It's also interesting that the science fictional world portrayed is one where technology is more or less static, and has been for thousands of years, so one military force (guardships) could be designed for immortality without the risk of obsolescence.
There are flaws in this book. The big one is that there are too many characters for you to properly care about, and the important characters aren't fully high-lighted, so if you're going along rapidly you might have to go back and re-read a passage when one reveal or another happens. Cook also flips between nick-names, titles, and real names all the time, which could be confusing, especially since the character cast so so large. All this combined together to make an unusually long (by Cook's standards) book means that the reading gets too dry at times and I had to take breaks. It took a long time to finish this book.
Nevertheless, if you're a fan of Cook's characters, matter of fact exposition, and want to see what he does with science fiction, this is definitely recommended (unlike Passage At Arms. Just don't expect it to be a quick airplane read.
Friday, September 23, 2011
Location Still Matters
This year's been interesting as I got invited to several startups either to talk or to give advice. Usually, I try to mix it with another visit if it's in the city, so I don't make the trip to San Francisco just for one thing.
One of the fascinating things is that San Francisco has a pretty active startup scene, but many of them are hurting for engineers. After talking to several startups with ambitions of growth but who can't seem to hire decent engineers no matter what, I'm coming to the conclusion that the more technically challenging your startup, the more important it is that you be in Silicon Valley, rather than being able to locate elsewhere.
Why is that? For technically challenging problems, you want people with a decent amount of experience doing the engineering. I'll take an example: Facebook managed to get Jeff Rothschild to lead its engineering team fairly early on. Jeff, by the way, doesn't get nearly enough credit for making Facebook as successful as it has been. It is doubtful that Facebook would have been able to recruit and retain Jeff if it was in San Francisco rather than Palo Alto. The same probably would have gone for Google's Jeff Dean and Sanjay Ghemewat. For whatever reason (people tell me it has a lot to do with schools), parents prefer living in the South Bay. I've lost count of the number of people I know who moved to the city when they were single and childless, and then moved back down south once they had a kid.
The result: if you want to grow past your first 50 engineers or so, you'll either have to settle for a less technically competent population, or you'd have to move south. What's surprising to me is how things I wouldn't have expected to be technically challenging turn out to be such. For instance, I would have guessed that Twitter wouldn't need Google-quality engineers, but that turns out not to be true.
This doesn't mean that San Francisco startups can't be successful and make lots of money. For instance, AirBnB and Zynga will be incredibly successful. Zynga has a famously low technical bar, and one of my friends came back from an interview saying that being the smartest person there wasn't enough even if it did make her rich. Obviously, being in Silicon Valley is also no guarantee that you'd be able to attract technically competent employees (Friendster was in Mountain View, for instance). But by and large, I've been amused to watch Cloudera move steadily south (from Burlingame to San Mateo and now Palo Alto). By the way, I don't think Zynga's wrong to have a low technical bar: there's no need to pay for top-end talent if your problems don't need top-end talent to solve it.
Many designers have argued to me that design talent is easier to get in San Francisco. I'm not a designer, so I don't really know, but let's say I give you that point. The problem is, to realize your design, you probably need only 1 designer for every 10-20 engineers. And of course, Apple is right in Silicon Valley, and whatever you might say about Apple, you can't argue that their design is inferior.
Ultimately, if you're a startup, think carefully about what your business is. If you never need more than about 50 engineers, I think San Francisco is fine. If you believe you're really in the media business, San Francisco's probably better (be very careful, though --- Yahoo! thought it was in the media business --- that turned out to be false!). But if your startup idea needs a sizable number of Google-quality engineers to succeed in the long term, you really should be in the valley.
Now the real puzzle to me is that there should be far more startups in the Berkeley area than they are. They've got Cal, which has a strong computer science department, so recruiting for engineers should be no problem. My guess is that the city of Berkeley does not view startups in a friendly fashion, and it would be very difficult to find cheap space in the area. Inktomi (founded by Cal professor Eric Brewer), for instance, famously moved out of Berkeley (to Foster City) as soon as it had to scale.
One of the fascinating things is that San Francisco has a pretty active startup scene, but many of them are hurting for engineers. After talking to several startups with ambitions of growth but who can't seem to hire decent engineers no matter what, I'm coming to the conclusion that the more technically challenging your startup, the more important it is that you be in Silicon Valley, rather than being able to locate elsewhere.
Why is that? For technically challenging problems, you want people with a decent amount of experience doing the engineering. I'll take an example: Facebook managed to get Jeff Rothschild to lead its engineering team fairly early on. Jeff, by the way, doesn't get nearly enough credit for making Facebook as successful as it has been. It is doubtful that Facebook would have been able to recruit and retain Jeff if it was in San Francisco rather than Palo Alto. The same probably would have gone for Google's Jeff Dean and Sanjay Ghemewat. For whatever reason (people tell me it has a lot to do with schools), parents prefer living in the South Bay. I've lost count of the number of people I know who moved to the city when they were single and childless, and then moved back down south once they had a kid.
The result: if you want to grow past your first 50 engineers or so, you'll either have to settle for a less technically competent population, or you'd have to move south. What's surprising to me is how things I wouldn't have expected to be technically challenging turn out to be such. For instance, I would have guessed that Twitter wouldn't need Google-quality engineers, but that turns out not to be true.
This doesn't mean that San Francisco startups can't be successful and make lots of money. For instance, AirBnB and Zynga will be incredibly successful. Zynga has a famously low technical bar, and one of my friends came back from an interview saying that being the smartest person there wasn't enough even if it did make her rich. Obviously, being in Silicon Valley is also no guarantee that you'd be able to attract technically competent employees (Friendster was in Mountain View, for instance). But by and large, I've been amused to watch Cloudera move steadily south (from Burlingame to San Mateo and now Palo Alto). By the way, I don't think Zynga's wrong to have a low technical bar: there's no need to pay for top-end talent if your problems don't need top-end talent to solve it.
Many designers have argued to me that design talent is easier to get in San Francisco. I'm not a designer, so I don't really know, but let's say I give you that point. The problem is, to realize your design, you probably need only 1 designer for every 10-20 engineers. And of course, Apple is right in Silicon Valley, and whatever you might say about Apple, you can't argue that their design is inferior.
Ultimately, if you're a startup, think carefully about what your business is. If you never need more than about 50 engineers, I think San Francisco is fine. If you believe you're really in the media business, San Francisco's probably better (be very careful, though --- Yahoo! thought it was in the media business --- that turned out to be false!). But if your startup idea needs a sizable number of Google-quality engineers to succeed in the long term, you really should be in the valley.
Now the real puzzle to me is that there should be far more startups in the Berkeley area than they are. They've got Cal, which has a strong computer science department, so recruiting for engineers should be no problem. My guess is that the city of Berkeley does not view startups in a friendly fashion, and it would be very difficult to find cheap space in the area. Inktomi (founded by Cal professor Eric Brewer), for instance, famously moved out of Berkeley (to Foster City) as soon as it had to scale.
Thursday, September 22, 2011
Span of Controls
Coincident with the launch of Startup Engineering Management, I'd been asked to help out at a few startups, two of which were Obvious and PlayMesh. A common question that came up at both places was: What's the appropriately wide span of control in management.
I believe the answer to that question is: "It depends." If you look at industry wide span of controls, they're somewhere around 6 to 1. That is, every 6 engineers will have a manager. If you examine that carefully, however, what you'll notice is that this arises typically in larger corporations. In those corporations, what's happening is that aggressive go-getters who don't get promoted will quickly leave, and the only way to retain such people is to give them management positions long before they're ready. (An alternative is to set up a separate engineering ladder, which was advocated as far back as The Mythical Man Month. That doesn't work as well as its advocates will have you believe) Effectively, at large corporations sporting a 6:1 engineer/manager ratio, what you are doing is training engineering managers on the job, where the manager is essentially still expected to perform individual contributor duties in addition to doing management.
At well-run startups where most engineers who are brought in do not need a lot of coaching, the appropriate span of control is closer to 20 engineers. At that level, the manager can't do a lot of coaching, but more importantly, he can't possibly do any micro-management, which is irritating if you've hired high performance engineers. Essentially, the manager has to lead by setting direction, not provide management or mentoring at the task level. That doesn't mean he can be non-technical, because you need to be capable of understanding detailed software/hardware architecture in as much as it affects your product. To give an extreme example, Wayne Rosing in his early days at Google had all 100 engineers directly reporting to him. Having participated in those structures before (as described in An Engineer's Guide to Silicon Valley Startups), it was extremely exhilarating, and yet Wayne (and Bill Coughran) always knew what the problems were and how they could help every time I came to one of them with one (very often, the way they helped was to send a one word e-mail: "Approved.").
If you're promoting engineers into management positions who have not managed before, you will need to be closer to the industry 6:1 ratio. However, if you're hiring a manager from outside, your bar needs to be a lot higher: they need to be able to handle a span of control of 20:1. Many startups do not hold incoming managers to that standard, and therefore end up with poor management. I'll give you a concrete example: Facebook does not hire managers from outside, because they've discovered that the practice does not work. However, they do hire directors from outside with some degree of success (though less so than with directors who were promoted from inside), and one reason for that success is that most directors hired from outside have already proven themselves capable at the 20:1 ratio.
At the tech lead level, however, you probably will still need the 6:1 ratio. But tech leads are by their nature not going to provide the full range of management functions.
Is there a way to short cut this process? Yes. One of the best tips in Startup Engineering Management is actually one that came from Yishan Wong: when hiring engineers, try to look for engineers who've managed before and are willing to come back as an individual contributor. This lets you promote from within once you need managers, and also gives you managers that don't consider management an more important job than engineering.
One interesting note is that these numbers are extremely similar to what the U.S. military uses in the army: a squad leader commands a group of 8, and a platoon commander commands three squads for a group of 24. The squad leader is very much like a tech lead, and the platoon commander is the lowest level officer in the army. While you might argue that military jobs aren't as cognitively challenging or creative, I'd counter that you should be also much more demanding in your recruiting process than the military, hence the similarity.
I believe the answer to that question is: "It depends." If you look at industry wide span of controls, they're somewhere around 6 to 1. That is, every 6 engineers will have a manager. If you examine that carefully, however, what you'll notice is that this arises typically in larger corporations. In those corporations, what's happening is that aggressive go-getters who don't get promoted will quickly leave, and the only way to retain such people is to give them management positions long before they're ready. (An alternative is to set up a separate engineering ladder, which was advocated as far back as The Mythical Man Month. That doesn't work as well as its advocates will have you believe) Effectively, at large corporations sporting a 6:1 engineer/manager ratio, what you are doing is training engineering managers on the job, where the manager is essentially still expected to perform individual contributor duties in addition to doing management.
At well-run startups where most engineers who are brought in do not need a lot of coaching, the appropriate span of control is closer to 20 engineers. At that level, the manager can't do a lot of coaching, but more importantly, he can't possibly do any micro-management, which is irritating if you've hired high performance engineers. Essentially, the manager has to lead by setting direction, not provide management or mentoring at the task level. That doesn't mean he can be non-technical, because you need to be capable of understanding detailed software/hardware architecture in as much as it affects your product. To give an extreme example, Wayne Rosing in his early days at Google had all 100 engineers directly reporting to him. Having participated in those structures before (as described in An Engineer's Guide to Silicon Valley Startups), it was extremely exhilarating, and yet Wayne (and Bill Coughran) always knew what the problems were and how they could help every time I came to one of them with one (very often, the way they helped was to send a one word e-mail: "Approved.").
If you're promoting engineers into management positions who have not managed before, you will need to be closer to the industry 6:1 ratio. However, if you're hiring a manager from outside, your bar needs to be a lot higher: they need to be able to handle a span of control of 20:1. Many startups do not hold incoming managers to that standard, and therefore end up with poor management. I'll give you a concrete example: Facebook does not hire managers from outside, because they've discovered that the practice does not work. However, they do hire directors from outside with some degree of success (though less so than with directors who were promoted from inside), and one reason for that success is that most directors hired from outside have already proven themselves capable at the 20:1 ratio.
At the tech lead level, however, you probably will still need the 6:1 ratio. But tech leads are by their nature not going to provide the full range of management functions.
Is there a way to short cut this process? Yes. One of the best tips in Startup Engineering Management is actually one that came from Yishan Wong: when hiring engineers, try to look for engineers who've managed before and are willing to come back as an individual contributor. This lets you promote from within once you need managers, and also gives you managers that don't consider management an more important job than engineering.
One interesting note is that these numbers are extremely similar to what the U.S. military uses in the army: a squad leader commands a group of 8, and a platoon commander commands three squads for a group of 24. The squad leader is very much like a tech lead, and the platoon commander is the lowest level officer in the army. While you might argue that military jobs aren't as cognitively challenging or creative, I'd counter that you should be also much more demanding in your recruiting process than the military, hence the similarity.
Friday, September 16, 2011
Startup Engineering Management gets .mobipocket and .epub
One of the workflow changes I made when publishing Startup Engineering Management was to use Adobe InDesign instead of Microsoft Word or Open Office. It's more cumbersome, given that it's an entirely text book, and it makes proofing hell, but the new version of InDesign actually makes it somewhat straightforward to produce EPUB and Mobipocket files (via Calibre).
The result: you now get the book in all 3 formats (PDF, EPUB, and Mobipocket) when you buy it. If you've bought the book and want it in other formats, please let me know and I'll rectify the situation.
The result: you now get the book in all 3 formats (PDF, EPUB, and Mobipocket) when you buy it. If you've bought the book and want it in other formats, please let me know and I'll rectify the situation.
Thursday, September 15, 2011
Independent Cycle Touring in Europe: The Presentation
Independent Cycle Touring in Europe
View more presentations from Piaw Na.
If you've been following this blog, you know that I've been giving a series of presentations at REI about Independent Cycle Touring. I hadn't put up the slides before because they were under revision all the time (especially between presentations things would change), but now I think I've gotten it stable, so those who're interested can view it.
If you're in the Bay Area, the last two presentations are September 19th at Saratoga, and September 29th in Mountain View. Registration is free, so show up and see the slides in full resolution! In addition, I'll always provide pre-flight entertainment for those who show up early. The reception to these presentations, no matter the size of the crowd, has always been very positive, and you can't beat the price.
Now Shipping: Startup Engineering Management
My latest book, Startup Engineering Management is now shipping.
Until now, all my books have been relatively independent of each other: there's no reason to believe that one person would buy An Engineer's Guide to Silicon Valley Startups and Independent Cycle Touring at the same time. The topics are very different, and you're unlikely to be in the mood to read one book or the other.
However, folks are likely to want to read Startup Engineering Management right after (or before) An Engineer's Guide to Silicon Valley Startups, so for the first time, I've provide one single page shopping cart where you can buy any (or all) of the books on one page. As a bonus, if you buy $50 worth of books (any 2 books), I'll provide free shipping. Obviously, this only applies to paper books, as electronic copies always have free shipping.
Incidentally, I recently met with both Obvious and PlayMesh to discuss engineering management, and the feedback on the material that we discussed (which all went into the book) has been very positive. There are other reasons to read this book even if you're not going to be a manager, and I'll get into that in the future. Watch this space.
Until now, all my books have been relatively independent of each other: there's no reason to believe that one person would buy An Engineer's Guide to Silicon Valley Startups and Independent Cycle Touring at the same time. The topics are very different, and you're unlikely to be in the mood to read one book or the other.
However, folks are likely to want to read Startup Engineering Management right after (or before) An Engineer's Guide to Silicon Valley Startups, so for the first time, I've provide one single page shopping cart where you can buy any (or all) of the books on one page. As a bonus, if you buy $50 worth of books (any 2 books), I'll provide free shipping. Obviously, this only applies to paper books, as electronic copies always have free shipping.
Incidentally, I recently met with both Obvious and PlayMesh to discuss engineering management, and the feedback on the material that we discussed (which all went into the book) has been very positive. There are other reasons to read this book even if you're not going to be a manager, and I'll get into that in the future. Watch this space.
Sunday, September 11, 2011
Review: The Lost Fleet: Beyond the Frontier: Dreadnaught
I've been buying all the previous Lost Fleet novels on Kindle mostly because they were priced right, and written pretty much as airplane fodder. You don't have to think very hard, and it's a lot like eating candy: you won't get overfull, and you can eat a lot of it at a go. The books are relatively thin, and you can easily zip through a couple of them at a shot.
Campbell's publisher has decided that Campbell's (aka John G Hemry) popularity means that they can price his books as a hard cover, so Dreadnaught, which begins a new series now spots the cover price of $15.82 (and a Kindle price at $12.99), which puts it easily out of the impulse buy range.
Unfortunately, in length, plot, characters, and interest, this is pretty much the same as any of the previous novels. We have John Geary confronting impossible situations in his fleet, making quick decisions that allow him to escape nicely as background problems escalate. There's a cliffhanger at the end, but most of the book can easily be zipped through like the airplane fodder that Campbell's so good at delivering. Nevertheless, the series is getting a bit old, and the reveals are starting to feel like they're deliberately drawn out to milk the series for all its worth.
Not recommended. Wait for the entire series to come out, or check it out from the library if you must.
Campbell's publisher has decided that Campbell's (aka John G Hemry) popularity means that they can price his books as a hard cover, so Dreadnaught, which begins a new series now spots the cover price of $15.82 (and a Kindle price at $12.99), which puts it easily out of the impulse buy range.
Unfortunately, in length, plot, characters, and interest, this is pretty much the same as any of the previous novels. We have John Geary confronting impossible situations in his fleet, making quick decisions that allow him to escape nicely as background problems escalate. There's a cliffhanger at the end, but most of the book can easily be zipped through like the airplane fodder that Campbell's so good at delivering. Nevertheless, the series is getting a bit old, and the reveals are starting to feel like they're deliberately drawn out to milk the series for all its worth.
Not recommended. Wait for the entire series to come out, or check it out from the library if you must.
Saturday, September 10, 2011
Charts and Tables from Independent Cycle Touring
One of the things I wanted to do but kept forgetting to was to extract all the charts and tables from Independent Cycle Touring and put it in one document so readers could easily print out copies and use them for packing or planning trips. I finally got around to doing so and you can now download all checklists and tables.
Tuesday, September 06, 2011
Review: Girl Genius Omnibus 1
Girl Genius has won the Hugo for best comic several years running. While they have everything on the web, it's much faster to read comic books on paper, so when my local library had the book I picked it up.
Humor is tricky. For instance, some people find fart jokes funny, others not so much. Some find zany characters like Rumiko Takahashi's Ranma 1/2 to be great, I personally characterize it as: "her idea of character development is to add more characters."
Unfortunately for me, Girl Genius falls into the latter category. The philosophy is to just keep adding more characters in the hopes that you'll find something funny somewhere. You could approach Girl Genius as a serious story, but that doesn't work very well either. The plots are unbelievable, and while there's a long running plot, most of the time you get just one gag after another, without a lot of plot exposition. There're also plenty of digressions that seemingly add nothing to the story. I say seemingly, because of course something might turn out to be relevant a few books later, but I haven't got the patience (nor do I necessarily want to spend the money) to run out and buy the books or click through the web pages just in case there's a pay off in the future.
All in all, if you like Ranma 1/2 or love lots of gags, this is the comic for you. For everyone else, I'd suggest paging through the first few pages to see if it grabs you.
Humor is tricky. For instance, some people find fart jokes funny, others not so much. Some find zany characters like Rumiko Takahashi's Ranma 1/2 to be great, I personally characterize it as: "her idea of character development is to add more characters."
Unfortunately for me, Girl Genius falls into the latter category. The philosophy is to just keep adding more characters in the hopes that you'll find something funny somewhere. You could approach Girl Genius as a serious story, but that doesn't work very well either. The plots are unbelievable, and while there's a long running plot, most of the time you get just one gag after another, without a lot of plot exposition. There're also plenty of digressions that seemingly add nothing to the story. I say seemingly, because of course something might turn out to be relevant a few books later, but I haven't got the patience (nor do I necessarily want to spend the money) to run out and buy the books or click through the web pages just in case there's a pay off in the future.
All in all, if you like Ranma 1/2 or love lots of gags, this is the comic for you. For everyone else, I'd suggest paging through the first few pages to see if it grabs you.
Sunday, September 04, 2011
Review: Big Bang Theory Season 3
I saw episodes at random times, mostly on the N1. This is the season that made Jim Parsons a major star (or rather, the critics finally agreed that he wasn't a fluke), and it shows. Nearly every episode is hilariously funny, and the writers take pains to get all the details of geekdom correct.
The season even ends with a cliff-hanger! All I can say is, I don't usually watch TV, but this series will have me watching every episode I can get my hands on. The Stan Lee episode definitely had me laughing out loud while sitting on a train. Highly recommended.
The season even ends with a cliff-hanger! All I can say is, I don't usually watch TV, but this series will have me watching every episode I can get my hands on. The Stan Lee episode definitely had me laughing out loud while sitting on a train. Highly recommended.
Review: Jack of Fables Vol 2-4
While Fables keeps going from strength to strength, Jack of Fables was for me, a bit of a dud. I read the first 6 issues but it didn't compel me to spend money, so I checked Vols 2, 3, and 4 from the library to see if got any better.
The story has to overcome several problems. First of all, Jack himself is an incredibly unsympathetic character. Secondly, the problems encountered in Jack of Fables aren't all that interesting. You get impatient with the character's inability to see the obvious, and one would think that with immortality, even the most insipid personifications would eventually realize that his capers are repetitious and his continuing attempts to get rich never end well.
The art is good, but not so good that you can forgive the relatively lame stories. The introduction of the literals also draw a yawn, which is one of the many things that made Fables 13 boring and silly.
The mystery of why Fables was so much better was solved when I met Willingham, who said he handed over Jack of Fables to Matthew Sturges, because he felt that Matthew deserved a break. Well, Sturges' talent isn't in the same caliber as Willingham's, and it shows.
This series is only worth checking out from your local library.
The story has to overcome several problems. First of all, Jack himself is an incredibly unsympathetic character. Secondly, the problems encountered in Jack of Fables aren't all that interesting. You get impatient with the character's inability to see the obvious, and one would think that with immortality, even the most insipid personifications would eventually realize that his capers are repetitious and his continuing attempts to get rich never end well.
The art is good, but not so good that you can forgive the relatively lame stories. The introduction of the literals also draw a yawn, which is one of the many things that made Fables 13 boring and silly.
The mystery of why Fables was so much better was solved when I met Willingham, who said he handed over Jack of Fables to Matthew Sturges, because he felt that Matthew deserved a break. Well, Sturges' talent isn't in the same caliber as Willingham's, and it shows.
This series is only worth checking out from your local library.
Review: How To Train Your Dragon
At WorldCon, there was a panel entitled "The Real Revenge of the Nerds", where the theme was the recent spate of movies where the hero is a nerd and indeed gets the girl. How To Train Your Dragon would be exhibit #2 in that discussion. Exhibit #1 properly belongs to The Social Network, not only because it single-handedly raised CS enrollment nation-wide, but also because the antagonists, the Winklevosses, are classic good looking athletes.
The story revolves around Hiccup, who's the lone weakling in his village whose only hope of achieving social acceptance is to kill a dragon. When he finally gets a chance, he finds that he's too much of a wuss to do so... and to say more would be to spoil the story.
The animation is so-so, though the animators have cleverly avoided the uncanny valley. What's great is that our hero doesn't succeed through brawn: he succeeds through a combination of clever engineering, intelligent observation of critters, and ultimately, with kindness. To say that there is a total lack of such examples in typical children's movies (especially with male protagonists) would be under-stating it. In fact, it's the heroine of the story who supplies the brawn.
What's more, the protagonist sacrifices something real at the end of the movie in order to achieve his results. While everything does end well, the sacrifice makes it feel real in a way that recent Pixar movies (for instance) do not.
Highly recommended if you're a nerd.
The story revolves around Hiccup, who's the lone weakling in his village whose only hope of achieving social acceptance is to kill a dragon. When he finally gets a chance, he finds that he's too much of a wuss to do so... and to say more would be to spoil the story.
The animation is so-so, though the animators have cleverly avoided the uncanny valley. What's great is that our hero doesn't succeed through brawn: he succeeds through a combination of clever engineering, intelligent observation of critters, and ultimately, with kindness. To say that there is a total lack of such examples in typical children's movies (especially with male protagonists) would be under-stating it. In fact, it's the heroine of the story who supplies the brawn.
What's more, the protagonist sacrifices something real at the end of the movie in order to achieve his results. While everything does end well, the sacrifice makes it feel real in a way that recent Pixar movies (for instance) do not.
Highly recommended if you're a nerd.
Review: Why We Get Fat
I've pretty much ignored all the Paleo/Atkins/Low Carb diet craze the last few years, and Cynthia recommended Why We Get Fat as a way to see what it's all about.
Taubes has a good writing style and a lucid, clear argument as to why conventional diet and exercise doesn't work:
Yet a few questions have answers that aren't very satisfying. For instance, why are the Japanese skinny? They eat plenty of rice (as do most Asian countries), and when you visit Japan, you're not going to see a lot of fat people around. Taubes says that these countries don't drink a lot of soft drinks, which is true, but a trip to your local Japanese supermarket sees plenty of sweet drinks. I'm not sure that this book holds the complete story: there's a lot about nutrition that we don't know.
Then of course, there's the assertion that exercise doesn't work. That one's weird, since I certainly know plenty of people who's lost weight from exercise. In any case, I found the book interesting as far as being an introduction to what all this high-protein/high-fat/low carb craze is about. Recommended.
Taubes has a good writing style and a lucid, clear argument as to why conventional diet and exercise doesn't work:
- The poorest people in the world don't eat a lot of meat but get fat anyway.
- The hunter-gatherers that exist today eat as much fatty meat as they can get their hands on.
- Carnivores are lean while Hebivores are fat.
- Insulin has been shown to be the agent converting sugars to fat. Having a constantly elevated level of sugars basically floods your body with insulin and therefore eliminates your ability to burn fat.
- The Atkins-type diets have been shown in some studies to reduce weight faster than other comparative diets.
Yet a few questions have answers that aren't very satisfying. For instance, why are the Japanese skinny? They eat plenty of rice (as do most Asian countries), and when you visit Japan, you're not going to see a lot of fat people around. Taubes says that these countries don't drink a lot of soft drinks, which is true, but a trip to your local Japanese supermarket sees plenty of sweet drinks. I'm not sure that this book holds the complete story: there's a lot about nutrition that we don't know.
Then of course, there's the assertion that exercise doesn't work. That one's weird, since I certainly know plenty of people who's lost weight from exercise. In any case, I found the book interesting as far as being an introduction to what all this high-protein/high-fat/low carb craze is about. Recommended.
Thursday, September 01, 2011
An Engineer's Guide to Silicon Valley Startups now on the NOOK
Note that as with the Kindle version, this is the first edition. I have no expectation of significant revenue, but the BN store front was easy to use, so it didn't cost very much time.
I'm not expecting a Mac version. The iBookstore requires owning a Mac, which I haven't done since 2009 (and even that Mac ran Windows since I found myself repeatedly booting into it in order to run Quicken, etc).
I'm not expecting a Mac version. The iBookstore requires owning a Mac, which I haven't done since 2009 (and even that Mac ran Windows since I found myself repeatedly booting into it in order to run Quicken, etc).
Long Term Review: Garmin Edge 800
(Please also see First Impressions)
I've now lived with the Edge 800 for over 1700 miles, including quite a bit of hiking. The unit has survived a tour of the Alps with rain and plenty of sweat. A few notes:
I've now lived with the Edge 800 for over 1700 miles, including quite a bit of hiking. The unit has survived a tour of the Alps with rain and plenty of sweat. A few notes:
- The unit's pairing with the cadence/wheel sensor is great. The only time I've seen problems with speeds being inaccurate is if the magnet is misaligned and hits the wheel sensor instead of zipping past it. When that happens expect to see speeds of 100mph or more. The cadence magnet slips easily, but is easily solved if you tape the magnet to the crank instead of relying on the zip-tie.
- Battery life is good. At 15 hours, you can expect 2 full days of touring on a complete charge if you forget to charge it one day. The battery drains at the rate of 5% per hour if the unit is not routing, which in practice means 20 hours. With routing, the drain is around 7% per hour.
- Routing is the same was other Garmin units, though sometimes address searches can get wonky.
- The unit really does work with full fingered gloves. This is due to the display technology, which also means that button pushes on screen are sometimes clunky. That's not a bad thing.
- In tunnels the wheel sensor pairing works well. In particular, Phil, who had the same unit, had his unit confused in tunnels and locked up, so I'm not sure how optional the wheel sensor is. A reboot solved the problem.
- Unit uploads are fast!
Review: Air Berlin
This year was the first time we flew Air Berlin. If you're a cyclist, there are only three viable airlines to Europe if you wish to bring your bike. Air Berlin, Air Canada, and British Airways. On British Airways, bikes fly free, but you have to fly through London Heathrow Airport, which many people hate (I've never had an issue with London Heathrow, but nightmare stories abound). On Air Canada, there's a $50 each way, which is reasonable, but they're not always the lowest cost carrier.
Air Berlin is almost always the lowest cost carrier, and they have a bike policy that's extremely friendly to cyclists: sign up for the topbonus Service Card, and you can carry your bike (at up to 32kg!) on any number of flights you take with them. The annual fee is 79 EUR, but in addition to unlimited bike carriage, you also get free early checkin for flights the night before, and an increased baggage allowance. You also get to make seat reservations (which is apparently a paid sevice). That makes it a good deal.
Good deals are useless if the airline loses your bike the way US Airways does. I'm happy to report that Air Berlin has excellent customer service. The staff is always courteous, and usually goes beyond the call of duty to get things done for you. Air Berlin schedules flights the way Germans schedule trains. That means connections are very closed together and you will find yourself in customs wondering "How the heck am I going to clear customs and make my next flight within 50 minutes?" Wonder of wonders, the German customs at Dusseldorf (Air Berlin's hub) are incredibly efficient and provided you don't dilly dally you will make your flight. We lost no baggage, and things were mostly on time. I can therefore recommend Air Berlin to cyclists wishing to bring their bikes to Europe and back.
Air Berlin is almost always the lowest cost carrier, and they have a bike policy that's extremely friendly to cyclists: sign up for the topbonus Service Card, and you can carry your bike (at up to 32kg!) on any number of flights you take with them. The annual fee is 79 EUR, but in addition to unlimited bike carriage, you also get free early checkin for flights the night before, and an increased baggage allowance. You also get to make seat reservations (which is apparently a paid sevice). That makes it a good deal.
Good deals are useless if the airline loses your bike the way US Airways does. I'm happy to report that Air Berlin has excellent customer service. The staff is always courteous, and usually goes beyond the call of duty to get things done for you. Air Berlin schedules flights the way Germans schedule trains. That means connections are very closed together and you will find yourself in customs wondering "How the heck am I going to clear customs and make my next flight within 50 minutes?" Wonder of wonders, the German customs at Dusseldorf (Air Berlin's hub) are incredibly efficient and provided you don't dilly dally you will make your flight. We lost no baggage, and things were mostly on time. I can therefore recommend Air Berlin to cyclists wishing to bring their bikes to Europe and back.
Subscribe to:
Posts (Atom)
