Wednesday, December 28, 2011
As we approach 2012, a new question is driving how I examine the world I work in: Does traditional Web performance still matter?
Seems drastic and will raise the ire of more than a few folks I know, but it is a valid point of discussion. The entire Web performance industry needs to look around and determine how they got where they are and what the world will look like in 5 years.
The "Web" as it was defined when I started in the industry was simple - browser and page driven, with a growing focus on delivering services to visitors. Now, there is no definition of "Web" that can encompass everything that can be used when talking to companies. And in many cases, if asked, companies may not fully understand how customers interact with their online properties on a daily basis.
I used to be able to say what determined fast Web performance. Now, the simple answer is irrelevant, replaced with the reality of "It depends". Fast is completely dependent on what is being done, when and where is it happening, how things being done, and who is driving the way it is is done.
I am issuing a challenge to the entire Web performance industry: Step back and and ask yourself if we are asking and answering the right questions for the companies we work with.
If we don't find out now, in 5 years it won't matter.
Sunday, September 11, 2011
I don't know where we were (probably near Tahoe) when the plane made a hard and very sudden turn away from the direction we should have been traveling in. All the passengers on this mostly empty flight (remember those flights?) seemed to get a quizzical look on there faces. This turned to concerned looks on our faces when the pilot came on the intercom to announce that the flight had been diverted to Sacramento in response to a "National Security request".
Through the remainder of the short flight to Sacramento, it was clear that the flight attendants were visibly shaken (it was a United flight) and were having a hard time holding it together. Professional to a fault, they graciously brought me an extra yogurt when I asked. I had no clue.
The landing in Sacramento, an airport that was just barely long enough to accept a 777, is one that I remember to this day. As soon as the wheel touched the tarmac, the brakes screamed and reverse thrusters howled, the pilots trying to bring a "heavy" plane to a stop on a runway that was nominally rated for the beast they were bringing in.
We were still unsure what had happened, but the few of us who had the limited Web available on our phones were reading very conflicting and inaccurate news items. The flight attendants asked us to put them away, but for once they were doing it for optics, knowing full well we wanted to know what was going on as much as they did.
Outside the windows, planes of all stripes and sizes, from airlines I had never heard of or only seen in the air on approach to SFO. And clearly, there were two problems.
- There were no gates for us to pull up to.
- When we pulled to stop, the ground crew looked at us with dazed looks, going "How the hell do we offload a 777?"
We finally staggered off the plane, via a 60s style airplane ladder. By this time, the flight attendants were crying and holding each other. It wasn't until later that I realized that they had all lost friends on the planes.
After this process, the few of us streamed into the Sacramento terminal, headed for the baggage carousels. It was then that we saw the first tvs.
The line of passengers briefly stopped in shock. A few of them peeled off to the bar, where it was clear that the drinks were on the owner. The rest of us grabbed our bags and shuffled out of the terminal.
I called my wife and got through to our house on the second or third try. My mother-in-law, who was visiting, picked up the phone. I said I was alright, and asked to speak to my wife. SJE picked up and I told her I was on the ground in Sacramento and I was alright.
She was clearly confused and asked why I was calling. Our youngest was only a few months old, and sleep was at a bit of a premium. I knew she would have had no clue, and told her to go turn on the tv. Five minutes later, she called back and, in a clear but very stressed voice, told me that she was going to come and get me.
By that time, I told her that it was completely unnecessary. By an act of organization that has amazed me and endeared me to United until this day, they had arranged for a bus to come to the Sacramento terminal and take us back to SFO.
The bus ride was surreal. Completely quiet, except CNN radio. No one spoke. No one spoke on cell phones. We were all processing what we thought had happened, as CNN Radio tried to do the same.
The bus arrived back at SFO, making us some of the few who at least got back to where we had started our day. We gathered our bags, and shuffled off to wherever we were going to go. In an eerie silence.
Coming down the stairs from the top level of the airport, I saw the pandemonium at the ticketing counters as thousands of people desperately sought a way to get somewhere - home, away, flee. I was lucky. I got to go down to the arrivals area and wait.
I was picked up by SJE about 20 minutes after I got off the bus. As we headed home, south on 101, we watched a lonely aircraft descend out of the crystal blue (ok, it's the Bay Area - gray brown) sky. It was clearly one of the final flights to land at SFO that day. The 747, a plane from one of the major Asian national carriers was a glorious sight as it approached. But then we noticed the frightening parentheses that summed up the day - this glorious feat of engineering was bringing its passengers in accompanied by two F-16s.
We heard the roar of the fighters peeling off as the 747 put its wheels down behind us. And, as we drove, the great silence began.
Monday, September 5, 2011
If you take the personal perspective of Web performance pain, the risk not finding the real problem, the true cause of the pain.
Talking to customers at all levels of organizations has shown that when you ask "where it hurts", they can tell you exactly what they want you to work on. And once you solve that problem, you get another person from the same organization with a different pain coming to you, complaining that you have ignored them.
A whole-organization focus is required when working to solve a customers Web performance pain. And it starts by asking questions of everyone in a company, not just the one who came to you for the initial diagnosis. Different groups at different levels have different questions.
Here's a (very basic) list of some of those that you should be prepared to answer as you work to diagnose a company's Web performance issues.
- How am I doing against my competitors?
- How does performance affect my revenue?
- If I want to use the Web for more revenue, what do I need to do to make it work?
- How does Mobile deliver what I need?
- How much will it cost me to deliver the necessary Web performance?
- What is critical for me to deliver now, and what can I delay until the next budget cycle?
- How do I ensure that Web performance issues don't affect revenue?
- Are my partners helping or hindering us?
- How do I get Marketing to the table to understand the technology boundaries we have?
- How do I effectively use the Web without alienating customers with slow performance?
- How do I ensure that our design is delivered appropriately to both fixed-Web and mobile users?
- What parts of the site are customers unsatisfied with due to performance?
- Do my promotions scale to handle the surge in customers?
- How do I get Operations to understand that delivering new experiences with leading-edge technology is critical for us to be successful?
- I spend most of my time on troubleshooting conference calls. How can I reduce this drain on my time and resources?
- My team spends most of its time trying to correlate data between 5 different systems. Help!
- The latest design is putting a massive strain on our infrastructure. Didn't anyone test this on the production servers before it went live?
- I know that we need to take a load of our servers, but I don't know how to choose a CDN. What do I need to do?
- Man, I get a lot of alerts. How do I tell which ones I need to care about?
- This sure looks like a problem. How do I show the appropriate folks that this issue is their responsibility?
- Most of the time, the issues I investigate are with one third-party. Who is responsible for fixing this and does it really affect customers?
- I get bonused on fast MTTR. How can I figure out what the problem is faster?
In the sections above, notice that none of the questions need to be answered with product descriptions. Companies are desperate to understand not how other companies deployed the latest Kazoo to solve their Waka-waka problem, but how they made life easier and more manageable.
Coming to the customer with an open mind and a listening ear is the new hallmark of Web performance.
Tuesday, July 26, 2011
In the world I work in, customers bought a product or a tool. The purchase is driven by a desire to solve a problem or prevent a problem from appearing in the first place. It was a point solution, a single point of entry into an organization and added a very limited amount of value to a siloed compartment of an organization for a limited period of time, before the next shiny toy came along that purported to do the same thing, only better.
Economies of scale be damned, full inefficiencies ahead!
Companies that sell platforms, or have begun to to consider doing more than just paying lip-service to the word, look at the world with a different filter. The customer is seen as a holistic entity, as complex as any patient who comes to a doctor for treatment. If two people come to a doctor with the flu, they don't always get the same treatment, as the one patient may be sent home for rest and the other rushed to hospital because their compromised immune system means the flu will kill them without specialist care.
The best platforms are those that are focused on one to three key aspects of customers business or way of doing business and provide a unified way to perform these 1-3 functions. The customer should not be forced to go to completely different places to use each tool on the platform.
Platforms have unified flows, and customers can expect that using different parts of the platform will be easy to learn, as they all work the same way. An example of a bad platform is Microsoft Office. When you go to the File Menu in a Microsoft Office product, you know that regardless which product in the suite you are using, the same items will be there. Where Microsoft Office fails as a platform is in the way that the rest of the menus and actions are not unified, with Powerpoint behaving differently from Word, which are both different from Excel. Microsoft Office is a the case study of history is getting in the way of ease of use, of standalone products loosely linked, like cheap knock-offs of Lego™.
Platforms are truly extensible. If a customer needs an additional component of the platform, it can be enabled (after the appropriate business negotiations) in minutes.
Platforms need to allow simplicity when needed and complexity where required. While a 10-person company and a 10,000-person company have different needs, the same platform should be able to support these needs. Salesforce.com is a classic example of this - in their world, they don't care what the size of your company is.
And, platforms have to guided by product management teams, to have a shared vision. Product management has to enforce a strong adherence to the core values of focus, unity, extensibility, and complex simple complexity. A product management team that lacks the leadership to drive these values will produce a broken platform
How does your platform compare against this checklist?
Monday, April 25, 2011
GPS has stopped working. Maps tell me that even the Dragons don't come out this far - I saw a few Dragons in cheap suits selling insurance to travellers on the edge of this territory; should have been a clue. Even the people who have better maps than I do are leading expeditions into uncharted sinkholes and rivers that are "in the wrong place".
There is no way to fully map what is going to come next. There is a general plan, usually a back-of-the-napkin-map from a dive bar in the last "town" (interestingly enough, drawn by a dragon in a cheap suit). Sometimes there is even a guide (for many expeditions, the guide is a one-eyed, deaf jungle-dweller who communicates via a language of spit and arm movements). In the end, it's up to your cunning and intelligence to avoid a death so embarrassing, your ancestors will need to changes their names.
So, in order to bring order to this trackless territory, I have begun to lay down some simple rules, ones that will help me keep the jungle madness at bay.
A full calendar does not mean an effective day. The last 10 weeks have seen me in meetings up to six hours a day. Most of the meetings were not for extracting information from customers. Some fell into the Kafka-esque "debrief on the project status meeting so we can update the project plan and prepare for the next project status meeting" family.
And I am not alone.
Customers I work with are often in so many meetings that must be attended personally that the only time to get work done is in meetings. If you're wandering around the trackless wilds spending all your time updating the map, tracking the menu, and inventorying the clean socks, when you look up from your work, you have missed the point of the trip. Or worse, realize that in the minutiae of the "important" stuff, you have reached a place that you can't get out of without losing a good chunk of your expedition team.
So, why did you bother coming? Showing up is only 10% of being successful. Paying attention is the real 90%.
Guess what? Other people can help you do it all. Guess what? You're not the only person who can count socks.
I have become very good at delegating, for reasons that are good, under circumstances that were questionable. You came on this expedition with a team. Use it. There are people who can do the things you think only you can do. This frees you up to do the things that you are good at, like avoiding the impassible canyon (unless your team is big on a diet of bark and spider eggs).
And maybe one or two of the sock counters will show promise by projecting the date of clean sock exhaustion and suggesting that a route to clean water be prioritized for everyone's foot health. This means that they could help take over some of the map-reading so you can collect those bug samples you're after.
Delegating work does not mean you are failing. Delegating work means that you are succeeding in maintaining a focus on what's important.
Every day is a learning experience. I am so far into uncharted territories for myself right now that the map isn't even helpful at figuring out where I came from. All I know is that new challenges pop up every day, and learning from them helps me get by and press forward.