Category Archives: technology

Posted on
by

A friend passed along these notes from the panel discussion on quitting your perfectly good job to do your own thing. Some useful tips and takeaways in there.

  • Bryan Mason
    • Left Adaptive Path in August
    • Put on full day conference on quitting your job
    • Worked for Twitter for a while, when their payment check cleared, he went to work on his own stuff.
  • Ryan Freitas
    • Worked for Adaptive Path
    • Quit and went to work for Plinkey
    • Quit and started his own company
  • Chris Sacca
    • Worked for Google, head of special projects initiative
    • Quit and went to work for lowercase capital
  • Laura Mayes
    • PR
    • Two years ago founded Kirsty (digg for chicks)
  • Unemployment at 10% in california, 8% in NY
  • Things to do to quit
    • You have to resign – you have to write a letter, and sign it.
      • Otherwise, you can’t do stuff like cobra.
    • Get copies of all your agreements
      • Invention Assignment (your company owns everything you did)
      • No Poach
      • Non-compete
      • Confidentiality
      • Equity Agreements
    • Finishing Strong
      • People only remember the last few things you did. So for good references, make sure you are doing well before you leave.
      • Leave on a good note, good vibes. They may be giving you business later, you may need the relationships later.
    • Define your own happiness. Don’t let other people define it with their expectations of you. For Chris Sacca, everyone else thought he had the best job in America. And he listened to them, and let their expectations cause him to stay in a job he didn’t like.
    • Setting a price: you need to define what you need. Is it a year’s salary? Do you have a backup plan? Do you have a backup for your backup for your backup?
  • Do you own your own ideas? Code? Design?
    • If you did it on your own equipment, own email, own time, you should be OK. (This is not legal advice.)
  • What is your definition of success? What do you want to achieve?
  • Do you need a full business plan or do I just jump in?
    • Sometimes people do a full business plan, and it all goes out the window as soon as they launch.
    • Sometimes people get to a year, and it’s not really going anywhere, and then it is time to reevaluation where you get to.
  • People spend little time on thinking about vision up front and too much time on thinking about tactics.
  • People talk, talk, talk, and they need to just do, do, do. There is such a cost of inaction. Don’t write a document, just write the code. You can have an idea on Friday, and build a prototype over the weekend.
  • Lowering your personal burn as low as possible. It gives you more choices. “The best thing I ever did was move from a house to a loft. In a loft all your shit is visible, and you think oh shit, how did I get all this shit.” sell your car, don’t buy shit, and you will have more choices. You need to plan more when you are financially constrained and don’t have as many choices.
  • Sometimes main job and side job are complementary, and sometimes totally separate, and both have pros and cons. Neither one is always better.
  • You need to have play time. If you are working at home, maybe you make the difference by changing your clothes.
  • “Your inbox is a todo list in which anyone else can add an item and steal your time” –> stop living out of your inbox, and live out of your todo list.
  • Starting With Others
    • Write everything down
    • Plan for a) Failure, b) Success, c)Mediocrity
    • Have a clear exit plan if one o fyou wants to leave
    • Find a lawyer, a CPA, an advisor (who knows stuff you don’t), and a bank. (Chris Sacca says put all this out of your mind. Good products get built when you can focus on a good product. Figure this out later.)
      • If you are looking for a small amount of capital, the people you talk to, whose interests will probably closely align with your own, will happily introduce you to their network of providers.
  • If you need money, ask for advice. If you need advice, ask for money. If you need a job, ask for coffee.
  • When do you need some kind of entity…
    • Having a company adds legitimacy. Instead of being judged based on one individual and their resume, it is taking more seriously.
    • But you can just do a doing business as (DBA), you don’t need to form a corporation…if it is just one person. But can have value when there are multiple people.

Posted on
by
This session was Guy Kawasaki interviewing Chris Anderson, Wired Editor and author of The Long Tail, on the economics of FREE!, Anderson’s new book.
It was Chris Anderson’s first book, The Long Tail, that got me started down the path of how to tackle providing customer technical support using Web 2.0 principles, and I have no doubt that FREE! will be similarly influence. (I also had the privledge of interviewing Chris Anderson in 2007 on how The Long Tail relates to the printing industry.)
Pardon the raw notes format. I needed to get these notes online before my next trip.
  • Two big questions: How would Twitter create a business model? How would Chris fix the NY Times?
  • Twitter
    • The old way was: advertising, raising more money, exit strategy
    • The new way is to make money now
    • Is it going to be consumers who pay for Twitter, or advertisers who pay?
    • Pay for visibility…
    • Twitter has decided to be open, and let other companies create value added clients, which means those other companies are monetizing Twitter, but twitter doesn’t.
    • Free and premium product?
      • You don’t want to cripple the free product too much
      • You don’t want to charge too much for premium
      • 5% will become premium users
      • How do you create that premium version of the product without crippling the free one?
      • It’s hard to do this free/premium when there are lots of competitors: Facebook would love to steal microblogging away from Twitter.
  • If you could redo anything about Wired, how would you do it over?
    • Wired was launched in 1993
    • The question at the time was “if you are so wired, why is this magazine on paper”
    • Paper can sometimes add value. For long form, well design formats, the print medium adds value. There is an online version for instant access.
    • Books have value
    • Guy: Are you going to have a free version of your book FREE?
    • So many versions…web version of book, ebook, audio book (unabridged and abridged), the paper book (hardcover and softcover). Stuff with no marginal cost should be free: the digital versions. The stuff with marginal cost, costs something.
      • So you give away the digital stuff for free, to increase your reach.
      • Some percentage of the people who love the free one will buy the paper one, because the paper one adds value.
    • Chris’s publisher is Hyperion, who is a subsidery of Disney. They are allowing him to publish some stuff for free.
  • Which is harder: to achieve popularity or to monetize popularity?
    • To monetize
    • Each one of us has to figure out our own way to monetize popularity.
    • If you are a speaker, you may want a speaking gig. If you are a professor, maybe you want tenure. If you are an engineer, you want to establish reputation so you can get a job.
    • The music industry is thriving in all regards except the publishing part: the selling of disks. The problem is a misalignment of what the artist and publisher needs. The artist is agnostic about where they make money.
    • Publishers want to sell books, and authors want to sell themselves. The publisher needs to be aligned with what the author needs. Could you do a 360 for book? Could the publisher represent you as a speaker, take an equity stake in any spinoffs.
  • 20th century free was the razor and the blades, the
    • The products have real cost, and you need to find a way to cover that cost
    • This is essentially a marketing gimmick
  • 21st century free is digital bits
    • There is no marginal cost. It is truly free.
    • When they introduce radio, they tried to figure out how to pay for it.
      • The British had a tax on radios to pay for the stations.
      • The U.S. ended up with advertising
    • The media advertising model is what has been extended to most of the internet: it’s google adsense.
    • Freemium is the new model: you give away 90, 95, 99% of your product, and charge for only the most premium features.
    • If you can convert 5% of your users to paid, then you can make a profit. If you get to 10%, you’re making a lot.
    • 37signals talked a lot about the benefits of charging your customer. Read what they have written. They have free products, and they have premium products. You need to start up with these two different things, not start only with the free model. If you do that, and introduce a paid version two years later, then you violate a social contract with your users.
  • What can we learn from China on capitalism. They have no intellectual property.
    • We can learn a lot from china.
    • If you do not make your product free, then piracy will.
    • Competitive markets will drive price down to marginal cost.
    • The chinese pop star will release a CD, with the expectation that it will be pirated. Piracy creates distribution and celebrity, and celebrity allows the pop star to get singing gigs, advertising gigs, etc.
    • Wall’s Drug gives away free ice water. People would go out of the way to get the free ice water.  Starbucks could potentially give away free coffee – if they could get the right conversion rate.
  • Why is free so much more powerful than one penny or 25 cents?
    • “The penny gap”
    • When we see a price, then we go through a cognitive “is it worth it?” flag. The transaction cost of the evaluation is what becomes the blocking thing. When something is free, then we don’t go through the valuation process at all.
    • In the physical world, you don’t want to waste physical resources like food or hospital beds, so you do want to charge a nickel to stop the waste. In the digital world, waste is fine, so free is good.
  • Upcoming generation…
    • A 5 year old will internalize neutonian physics when they learn how to catch a baseball.  When a 10 year old goes online, they quickly internalize the free economics: of course it is free.
  • Does anyone think less of something because it is free?
    • No one thinks less of Twitter or Facebook. They evaluate based on utility, not price.
    • But comparing Office versus Google Docs: utility comes first, and Office can do a lot that Google Docs can’t. the decision is primarily a utility one, and not a price one.
  • Are people more motivated by loosing something they have or not getting something they want?
    • People are more motived by negative things on general.
    • But what you want will loom large.
    • Marketing is all about getting you to want something, but before you can try it, you have to buy it.
    • For free, the marketing is that you’ll probably like it, so why not give it a try, and if you love it, then maybe later you can buy. And you’ll be happy paying.
  • Questions
    • We have an online survey product, it is a freemium model, and all of our competitors have freemium models. We did a survey of customers, and when they come to the site, they have a negative connotation: it is fishy that it is free.
      • You are too similar to something that people are using to paying for. So people have an expectation, and cognitive dissonance.
    • We have an economic crisis here. Do you have any suggestions for our country?
      • From a consumer perspective, when you have no money, free is a very good price.
      • It’s broken the advertising model, because CPM have dropped off. It is driving more companies toward freemium model.
      • In Latin America, they are used to companies vanishing, banks failing, governments toppling, but it isn’t threatening to them. You focus on your family, you have a house, and food, and it’s all good.
    • Luxury brands…
      • You can get Guy Kawasaki for free on Twitter, or you can pay $50,000 to get the custom talk.
        • You can’t get the high premium without the mass popularity
      • China is the largest market for pirated luxury items, and the largest market for true luxury items.
    • How can you compete with free?
      • It depends on user expectation: if they expect to pay $5,000, then free will not meet their expectations.
      • Microsoft has been competing with free for 30 years.
        • They had to convince people to pay for software in the first place.
        • They had to compete with unix, with linux, with open source.
        • They are not selling a product, they are selling support, and security, and confidence.

Posted on
by

While at SXSW, I picked up a copy of What Would Google Do?, the new book by Jeff Jarvis. As I usually do, I opened to a random page inside, and started reading. I laughed out loud at something on the part, and I heard someone say “I love when someone does that.” I looked up, and saw Jeff Jarvis.

We got to talking, and he asked what I did. I told him about my role at HP, and how I’m trying to expand everyone’s mindset that for customer support, we have got to look past just social media and into the realm of implicit feedback. We chatted some more, and I ended up buying the book.
Only later did I realize that it was Jeff Jervis who caused “Dell hell” by posting on his blog about Dell’s poor customer service, and which totally turned Dell around and got them heavily involved in social media. Of course I knew all about Dell’s history, I had just forgotten the name of that one key individual who started it all: Jeff Jarvis.
I highly recommend his book. I’ve got enough annotations and folded pages for few dozen blog posts. I will mention one right now. Jeff Jarvis has finally explained the term platform in the context of Web 2.0 in a way that it become very concrete for me. He writes:

Google has many platforms: Blogger for publishing content, Google Docs and Google Calendar for office collaboration, YouTube for videos, Picasa for photos, Google Analytics to track sites traffic, Google Groups for communities, AdSense for revenue. Google Maps is so good that Google could have put it on the web at maps.google.com and told us to come there to use it, and we would have. But Google also opened its maps so sites can embed them. A hotel can post a Google Map with directions. Suburbanites can embed maps on their blogs to point shoppers to garage sales. Google uses maps to enhance its own search and to serve relevant local ads; it is fast becoming the new Yellow Pages.”

Contrast this to a site like Yahoo: Yahoo creates and aggregates content to create a destination. Google doesn’t create content, it creates a platform for others to create, share, link, and network their own content. Jarvis writes, “A platform enables. It helps others build value. Any company can be a platform…. Platforms help users create products, businesses, communities and networks of their own.”

Posted on
by

As reported by VentureBeat, HP announced an almost unbelievable blogger campaign, in which they boosted PC sales 10% by giving away just 31 PCs to key bloggers:

HP, one of the country’s biggest computer companies, is boasting that it boosted its PC sales by 10 percent in May after it leveraged the blogging community to promote the launch of one of its computer systems.

All HP did was give away 31 new HDX Dragon computer systems to 31 influential members of the PC blogging community, so that the blogs could give them away in a competition among their readers. The bloggers went nuts. They made videos of the systems, wrote up engaging posts and cross-linked to each other — all of their own accord. The publicity this created spurred an increase in sales, according to Ballantyne. Since the bloggers were credible to their readers, and they were talking about the HP systems on their sites, the readers went out and bought systems even if they didn’t win one in the competitions.

The results?

[D]uring the blogger competitions, sales of the Dragon system shot up by 85 percent compared to the average monthly sales of the three months before hand. More impressively, overall HP PC sales grew 10 percent higher in the U.S. than the company had forecast, as HP PC systems overall got more publicity from the Dragon campaign. Visits to HP.com increased by 15 percent.

Posted on
by

In an article on Web 2.0 adoption, Ann All cites a few pieces of evidence that Web 2.0 adoption is slowing or even falling into disfavor:

In my post about a slowdown in IT hiring, I cited an InfoWorld item that quotes M. Victor Janulaitis, CEO at IT staffing research company Janco Associates, as saying that the sluggish economy has halted Web 2.0 investments. Demand for Web 2.0 technologies has “atrophied,” says Janulaitis, after “a slight increase in demand” earlier this year.
Indeed, Web 2.0 deployments likely fall under the discretionary spending column at most companies, and thus are prone to elimination as tech execs look to cut IT spending. As a Goldman Sachs analyst put it, execs are “searching for solutions with a high and fast ROI,” a criteria mostly lacking in Web 2.0 technologies.

Ann also writes:

But check out the Robert Half numbers of CIOs taking a pass on technologies: tagging software (67 percent), blogs (72 percent),wikis (74 percent) and virtual worlds (84 percent). ZDNet’s Dignan expresses surprise at the lack of love for wikis and speculates that maybe they are popular among in-the-trenches types such as software developers and project managers but not among CIOs.

I think that Ann and the sources she quotes are missing the elephant in the room: employees are adopting these technologies whether the CIO wants them to or not. Professional blogs and professional social networking tools are still on the rise, and don’t depend on internal IT resources. Likewise, wikis and community tools are available from hosted providers, usually for free. All it takes is one enterprising person from marketing to start a customer community, or an enterprising developer to start a wiki. 

When social media tools are hosted internally, I’ve witnessed over and over that they start as skunk works projects, below the radar of official IT. So the CIO may not endorse Web 2.0 tools, but company employees will adopting them both inside and outside the company firewall. In fact, the biggest risk that a CIO may cause by not adopting Web 2.0 technology in an appropriate and timely fashion is the exodus of implicit and explicit company confidential information outside the firewall.
And regardless of what the company may officially do, and what employees may unofficially do, of course a company’s customers can and will adopt Web 2.0 technology on their own.

Posted on
by

I posted about the nine practices of high performance teams. None of the practices are particularly difficult, so why do so many companies seem to stifle the kinds of productive behaviors they want?

I believe that corporate environments suffer from productivity killing practices that seem minor when viewed individually, but which have a multiplicative effect when combined. When I say a multiplicative effect, I mean that if you have three items, each of which halve productivity, the result is 0.5*0.5*0.5 or just 12.5% of the original productivity. What this means is that if you have many items which adversely impact productivity, the multiplicative effect is really what matters most, not the individual effect of each item. For example, if you have 5 items, each of which reduces productivity by a relatively small 20%, the cumulative, multiplicative effect is still quite large: 0.8*0.8*0.8*0.8*0.8 = 32% productivity.

Given just how important productivity is to the health of a business, it is sad just how many productivity killers corporate environments suffer from. Here’s the list:

  1. Failing to identify and take action on most important objectives: (50%)
  2. Excessive effort and time to get commitment to needed projects: Classic under-capitalization (50%)
  3. Failing to capitalize on expertise, interest, and capabilities that exist: (25%)
  4. Failure to rapidly iterate: having long cycles of planning, production and then release. (25%)
  5. Information silos: Being unable to easily find the right people, information, documentation to get done what you need. (10%)
  6. Cancelled projects due to overcommitment of resources: (10%)

Posted on
by

There’s a tremendous amount that’s been written about high performance teams. I’ve studied high performance teams as part of my graduate work, read about them as part of my professional career, and had several experiences with high performance teams in the workplace. Reading and studying about high performance teams has the unfortunate effect of making them seem quite complicated, when in reality, there are just a few practices that go a long way towards creating a high performance team.

My experiences have been in the realm of software development, but these practices should apply to other areas as well.

  1. End the day with a debrief meeting: At the end of your workday, take the time to meet and recap what’s happened. Who has accomplished what? Who ran into problems? What were those problems and what can be done with them? The end of the day is typically a time when everyone’s brain is tired, so it usually isn’t a time of great creativity. But it is a time of getting it all out of the table. Part of getting it out on the table is to share problems and successes to that people can sleep on those ideas.
  2. Start the day with a planning meeting: After a good night’s sleep, and with a clear understanding of where everyone is, the morning planning meeting serves to plan out the events of the day. Who will work on what? What coordination will be needed? Who will pair program together? What novel solutions to current problems came to people while they were in the shower? What are the critical few objectives that should be accomplished today? The morning planning meeting is typically upbeat, high energy, and quick: 20 minutes to 40 minutes (max) will serve to plan out the day in great detail.
  3. Start the week with a high level planning meeting, and end the week with a high level debrief: Just as the daily meetings serve to highlight the critical objectives for the day and develop a plan to meet those objectives, the weekly meeting serves the same function, but at a macro level. What are the business objectives to work on this week? What is the plan to accomplish those objectives? What problems meeting business objectives did you run into? This can take as little as an hour on Monday morning if objectives and a path forward are very clear, and as much as four hours if they are not. (But this is time well spent, as it ensures that the rest of the week is highly productive.)
  4. Have a simple, shared system of documentation: It might be a wiki, a Google group, a whiteboard, or a Sharepoint (make sign to ward off evil empire), but almost every high performance team will have a simple system of documentation that ensures the most important information is easily accessible and up to date. This will typically encompass at least the business objectives, the daily plan, the build environment, the architecture plan, and integration points documentation. Too much documentation is overwhelming and a time sink, too little documentation and people are repeatedly searching for the same stuff or wandering aimlessly. Personally, I highly favor wikis if you can get one in your environment. Tips for wiki adoption.
  5. Create a culture of personal responsibility: In a high performance team, everyone should feel comfortable doing whatever is necessary for the success of the team regardless of what the official scope of their job is. In fact, they should feel not only empowered to do whatever is necessary, but ethically compelled to do whatever is necessary. One day, the most helpful thing I might do is stay heads down developing my code. Another day, the most helpful thing I might do is go get lunch or coffee so that someone else can stay heads their developing their code. One day I might be developing a high level architecture, and another day I might be hand-editing every row of a 3,000 row Excel spreadsheet. (Yes, I did that.) The point is that regardless of skills, code ownership, or perceived importance, what is important on any given day and on any given part of the project varies, and flexibly adapting to this is critically important.
  6. Be social: The team that laughs together and plays together shares a bond that goes beyond mere workplace acquaintance. Those weekly and daily meetings are a time for people to bring all of who they are to the table. Getting lunch together is a great way to be social and create pockets of more innovation: what work lunch doesn’t at some point come back around to work topics? One of my teams had a practice of taking off every other Friday during the winter to go snowboarding. It was our motivation to kick butt Monday through Thursday so that we could go enjoy a day of snowboarding with a clear conscience. (Oh, and what did we spend hours talking about while snowboarding? Work, of course.) An actual conversation with our manager when we decided to do this:
    Us to Manager: “We’re all going to take Fridays off to go snowboarding.”
    Manager to Us: “You can’t all go snowboarding on Fridays, there will be nobody here to handle things.”
    Us To Manager: “You’ll be here to handle things.”
  7. Optimize decisions for fun: Obviously snowboarding, team lunches, and coffee together are both social and fun. But other decisions that take place can also incorporate fun into them. Silly as it may seem, but choosing the operating system, programming language, development environment, build tools, database engine are all technical decisions that have implications for how interesting and fun team members find their work to be. Sadly, in large companies these are decisions that are most often made either on the basis of perceived technical merit, or more often, based on existing corporate strategic alliances. A team that is excited to use a new language or development tool can, as a function of that excitement and passion, be ten times more productive than they would otherwise. Whereas, the technical differences in productivity are often quite small. So optimize those decisions for fun and interest, and you’ll get more productive and passionate teams.
  8. Avoid negativity: Few things can be more destructive to a team than negativity. Complaining and trying to place blame are huge time and energy sinks. If there is an issue, then the focus should be on fixing the issue. Not detailing the issue out, not trying to figure out who caused the issue, not belabouring the pain that it has caused. Only on trying to figure out what to about it. In fact, if you have a chronic complainer on your team, one of the best things to stop the complaining is simply to ask the person, when they bring a complaint to you, “What are you going to do about it?”
  9. Have at least one person who likes to work nights and weekends: Every high performance team I’ve been a part of has had one person who works nights and weekends. They just can’t seem to help themselves from staying up half the night to work. This isn’t a choice I would make myself, and I wouldn’t ask people to make that kind of a sacrifice. But if you just happen to end up with one person like this on your team, it will make all the difference. While everyone else is resting and getting their creative juices refilled, that one night person will have: fixed that build problem, solved the defect no one could find, figured out how to use the new GUI library, optimized the performance of the database, found a cool new IDE, and brought the build documentation up to date. And the next day everyone will “oooh” and “aaah” over what they accomplished. Be very nice to this person and buy them lots of coffee and chocolate.

Posted on
by
In 2000, I was part of a team developing web applications. We favored open source software for the foundation of our web services, such as Apache and Linux, and widely used software such as BEA Weblogic, and the Java programming language.
Using these tools, when we ran into a problem, we could count on being able to Google the problem, and find an answer – usually within a few minutes. Sometimes the solution would be posted by another user like us who encountered the same problem and worked out a solution. On other occasions, the solution would be posted by someone from Weblogic or Apache, who would be monitoring public forums for problems posed by users, and would answer with the expertise of someone intimately familiar with the product. On the rare occasion when we couldn’t find an answer, one of us might post our problem to a relevant Usenet newsgroup. Within a few hours, we’d get a helpful response from someone else who ran into the same problem and figured out how to solve it.
Our team worked at web speeds, we were passionate and dedicated, and we loved our work. Being “in the flow” was a big part of it: you get going, you are productive, you feel productive, and it makes you even more productive.
Then, in 2001, for reasons quite unconnected to anything our little team was doing, our company forced all Java web application teams to move to a single proprietary J2EE platform. The support model changed to a typical enterprise support model. We funneled our support requests to a single support contact, they funneled our requests to the support team for the priorietary software, then the requests would get funneled to the right support or technical experience.
The pace of everything slowed dramatically. The questions we used to research and answer ourselves via a simple Google search in five minutes now took at least 24 hours to turn around. And the more technical stuff that we use to get answered via a Usenet newsgroup or web forum now could take a week or more before we got a response.
Meanwhile, productive work would grind to a halt. For engineers who were used to working on Internet time, and getting an answer commonly within 10 minutes, and in the worst case within several hours, this was the ultimate frustration. The team grew dissatisfied, productivity plummeted, and we were no longer “in the flow”. Even when their customer support finally did get around to answering our questions, no one else could benefit from it, because the problem and solution were never posted in a public forum.
The worst part of all this is that the “support” of the proprietary J2EE software was considered one of the benefits of using it by the management folks who made the decision to use it. But free, open support is far superior to paid, closed support. This is something that open source developers and users have known for years, and it is a big part of the reason why open source software has such a passionate and loyal following.
There are several lessons to take from this story:
  1. Knowledge capture and public sharing improves the support experience and decreases the work required by paid support staff.
  2. Customers inherently have a customer perspective on issues, which paid support staff lack.
  3. For a popular product, there are likely to be more customers available for helping other customers than there are support agents available.
  4. In most cases, the speed and access advantages associated with abundant information on the web far outweigh any minor benefit to be gained from one on one paid support.