When and how to micromanage(inc.com)
inc.com
When and how to micromanage
http://www.inc.com/magazine/20091201/when-and-how-to-micromanage.html?partner=fogcreek
7 comments
Regarding the wifi issues, if you're running a tech conference and it has to have great wifi, we're recommending Mariette Systems. I know them through Cliff Skolnick, who used to be involved in wiring up community wifi networks (and was a founding member of Apache). I think it's amazing that you could get someone with that much experience to wire up your conference. It's much better than the low-level IT guys that normally show up (or worse, the remote phone IT support).
Here's their website: http://www.mariette.com/Mariette_Systems.html
And an article TechCrunch did on them: http://www.techcrunch.com/2009/09/20/techcrunch50-had-intern...
You'd think this would be a solved problem by now, but judging by the number of conferences that have bad experiences, it is not.
Here's their website: http://www.mariette.com/Mariette_Systems.html
And an article TechCrunch did on them: http://www.techcrunch.com/2009/09/20/techcrunch50-had-intern...
You'd think this would be a solved problem by now, but judging by the number of conferences that have bad experiences, it is not.
Mariette Systems solved the problem for TechCrunch by using primarily WIRED internet access, not WiFi, and the cost was absolutely breathtaking.
The ServerFault thread that followed that incident about wifi at conferences has become the encyclopedia of how to make it work, so look there if you need a more detailed answer than "spend a lot of money hiring the guy who knows all the secrets." :-)
http://serverfault.com/questions/72767/why-is-internet-acces...
The ServerFault thread that followed that incident about wifi at conferences has become the encyclopedia of how to make it work, so look there if you need a more detailed answer than "spend a lot of money hiring the guy who knows all the secrets." :-)
http://serverfault.com/questions/72767/why-is-internet-acces...
Joel, that's interesting. I've seen them do just wifi and they serve two of our cheaper-seeming customers--so I wasn't under that impression. When you say breathtaking, can you put that into context for me? All conference vendors seem to charge breathtaking amounts (I once paid $220 for electricity in order to plug in a monitor for two hours). Is this breathtakingly-high-for-independent-show-organizers or breathtakingly-high-for-even-major-shows?
Also, what did you use at BoS? I thought the wireless there was good.
Also, what did you use at BoS? I thought the wireless there was good.
I'll go ahead and recommend ANY vendor for bringing in a providing WiFi for a conference. If you're doing any sort of tech-heavy conference, you have to assume that the venue's internet traffic will at least double, will be of a different type (more than just light email and web browsing, etc.) and that their infrastructure isn't designed to handle it.
When you're dealing with high concentrations of users on WiFi, your first worry isn't IP addresses (and honestly, with 1918 ranges, if you need to worry about IPs, you've got bigger problems), and it isn't available bandwidth. The very first problem is going to simply be client associations with the APs. Each AP can only reasonably manage so many connections, and a high concentrations of users makes it that much more difficult to partition the traffic.
A good BS filter will be to add a 0 to the number of people you expect to be in attendance, and ask the company "So what architecture would you use to support this?" If they mention mesh or T1 (unless they start talking about multiple bonded T1s and rattle off numbers), thank them for their time and leave. If they mention wireless uplink (or backhaul), ask what sort of throughput can be expected. If they don't give a hard and fast number (or reasonably small range) thank them for their time and leave (one caveat, if they list rates they've seen in other setups but they vary quite a bit, they're good).
The thing is, the problem has been solved, and can be taken care of. But it takes a couple of network engineers and enough planning to pull in a circuit just for the event. And that's assuming all the equipment necessary is on-hand. One month lead time would typically be pushing it if you need to pull in a large circuit or it's an exceptionally large event (1000+ people). Any less lead time than that and it's not the company to blame, because some parts of the setup have external dependencies that the company cannot speed up.
When you're dealing with high concentrations of users on WiFi, your first worry isn't IP addresses (and honestly, with 1918 ranges, if you need to worry about IPs, you've got bigger problems), and it isn't available bandwidth. The very first problem is going to simply be client associations with the APs. Each AP can only reasonably manage so many connections, and a high concentrations of users makes it that much more difficult to partition the traffic.
A good BS filter will be to add a 0 to the number of people you expect to be in attendance, and ask the company "So what architecture would you use to support this?" If they mention mesh or T1 (unless they start talking about multiple bonded T1s and rattle off numbers), thank them for their time and leave. If they mention wireless uplink (or backhaul), ask what sort of throughput can be expected. If they don't give a hard and fast number (or reasonably small range) thank them for their time and leave (one caveat, if they list rates they've seen in other setups but they vary quite a bit, they're good).
The thing is, the problem has been solved, and can be taken care of. But it takes a couple of network engineers and enough planning to pull in a circuit just for the event. And that's assuming all the equipment necessary is on-hand. One month lead time would typically be pushing it if you need to pull in a large circuit or it's an exceptionally large event (1000+ people). Any less lead time than that and it's not the company to blame, because some parts of the setup have external dependencies that the company cannot speed up.
"At the top of every company, there's at least one person who really cares and really wants the product and the customer experience to be great." In my experience that person is rarely at the top.
And this article seems to be a clear example of this. "Ryan" seems clueless and "Greg" seems to be the go-to guy.
And this article seems to be a clear example of this. "Ryan" seems clueless and "Greg" seems to be the go-to guy.
I got a similiar impression from watching a few Carsonified vids, off course one has to be careful with judging too fast. I wonder why Joel wrote the articel that way? He s basically saying in public: Ryan screwed it up but I could wing it because I memorised my speech.
I hope I didn't create that impression. Carsonified was an equal partner in the event. It was the first time for both of us. We learned a lot. They learned a lot. I made plenty of mistakes, too (at one point I actually forgot my own passport and had to fly across country to pick it up so I could go to Toronto). We're all newbies in this conference business.
Carsonified had never done conferences before?
Not a series of ten conferences in ten cities, running every other day. Most of the cities on the DevDays tour were new to them.
So you basically took a UK company, used to organize large events that span several days a few times a year (and only in UK and a few handpicked US cities), with a lot of preparation time, and let it organize a fast-paced series of events every other day in a number of different US cities they've never been to? Sorry, Joel -- I really respect Ryan and his team (although I can't grieve over Mel Kirk's leaving), but here's your fifth why right there, if you ask me.
Whenever I hear of the 5 Whys method, the first thing that I think of is...
Why 5? (no pun intended considering this thread is about wifi... oh dear).
But seriously, why 5 specifically? What if you need 6 to get to the root of the problem?
Why 5? (no pun intended considering this thread is about wifi... oh dear).
But seriously, why 5 specifically? What if you need 6 to get to the root of the problem?
It's a rule of thumb: you typically need >= 5 whys to get down to a reasonably useful response.
From the article, you could stop at pretty much any point in the whole 'why does our video suck' chain:
"One problem in Austin was that we couldn't switch video fast enough. Why? Because we were using a cheap switch purchased at an office superstore."
At that point you could've said "Ok, let's not buy crappy switches in future", but you would have missed the better solution (don't do things half-assed at the last minute)
From the article, you could stop at pretty much any point in the whole 'why does our video suck' chain:
"One problem in Austin was that we couldn't switch video fast enough. Why? Because we were using a cheap switch purchased at an office superstore."
At that point you could've said "Ok, let's not buy crappy switches in future", but you would have missed the better solution (don't do things half-assed at the last minute)
Actually, the Five Whys isn't about finding a solution, it is about finding the core problem. I don't think that Joel's example is a good one, because after four true layers of problems it abruptly jumps to a solution, with absolutely no reasoning why this particular solution would be the best one, while leaving deeper issues just to keep the number of Whys at five.
The correct Five Whys process would continue past five questions, and end in something like "because the team is not prepared" or even "the team doesn't have enough experience with organizing events"; something that could be solved by, among others, preparing a checklist.
The correct Five Whys process would continue past five questions, and end in something like "because the team is not prepared" or even "the team doesn't have enough experience with organizing events"; something that could be solved by, among others, preparing a checklist.
Isn't the rule the degree of oversight required is importance-of-task/trustworthiness-of-person?
And if you want to minimise oversight you need to avoid untrusthworty people and/or give them unimportant (but still useful) work.
And if you want to minimise oversight you need to avoid untrusthworty people and/or give them unimportant (but still useful) work.
Why can't this just link to the original article?
Which is an ok article, and might be better summed up that when you are dealing with an unknown quantity, you should treat them as an unknown quantity and /not/ trust them to do their job properly. Which is fine and reasonable and possibly common sense.
I just don't understand why this article required two levels of indirection.
Which is an ok article, and might be better summed up that when you are dealing with an unknown quantity, you should treat them as an unknown quantity and /not/ trust them to do their job properly. Which is fine and reasonable and possibly common sense.
I just don't understand why this article required two levels of indirection.
It looks like somebody already fixed that.
When I link to my own articles on Inc.com, I redirect it through my own site because I want to track how much traffic I'm sending them. Every year when they're considering whether to renew my contract I remind them of this. (For the record, it averages 40,000 direct clickthroughs per month)
When I link to my own articles on Inc.com, I redirect it through my own site because I want to track how much traffic I'm sending them. Every year when they're considering whether to renew my contract I remind them of this. (For the record, it averages 40,000 direct clickthroughs per month)
Ok, I put the partner argument back into the link, so you'll still get credit for the traffic.
To make sure we upvote it because its from Joel.
The author tells how he stepped in using the "5 whys?" method. I recall reading that Jeff Bezos used to do the same thing at some point.
This article, however, is not really a justification of micromanagement. Joel Spolsky suggests that you can't trust technical people who you didn't hire to do their job properly. I wouldn't call this micromanagement.
This strategy is important in any situation in which you are forced to let a technical person from another company do important work for you, and you or someone you know and trust has that expertise. For example, if you are a medical professional, and your mother is sick at the hospital, it is advisable that you carefully monitor her treatment by nurses and doctors, to make sure every little thing that they do it okay. Since you probably did not hire these people, and probably don't work with them, you can't trust them. So watch them like a hawk.
On the other hand, if you hire and train someone at your company but still cannot trust them to do their job, then you should re-examine your hiring process.