Gunjan Doshi

Why cannot Microsoft beat Google on web? After all, they crushed every one who dared to compete: Netscape, Lotus, IBM’s OS 2 and the list is endless. What is it with Google that Microsoft cannot catch up. Well, the real problem is simple: Microsoft is slowly killing itself. Microsoft has become fat and lazy sitting on billions of dollars and its past success.

A small example will make it clear: Microsoft needed a startup tune for Windows Vista. A team of 20 high profile composers, sound designers, engineers and developers worked for 18 months. Kid Crimson’s Robert Fripp, drummer Pat Mastelotto, composer Tucker Martine, and Oscar-winning sound designer Randy Thom also participated. The end result: a four second startup tune for Microsoft Vista.

Now, how is Microsoft fat & lazy?
You put 20 people on a project for 18 months to come up with a 4 second tune. In this age of rapid product development, 18 months is eternity and team of 20 on a project is crowd - the communication overheads and ensuing delays paralyze a team.

A counter example: in 18 months, Youtube went from a startup in garage to the Time Magazine’s invention of the year and a Google acquisition for $1.65 billion.

You can argue that it is worth spending 18 months when that 4 second tune is going to start the day of 200 million people worldwide. I am not against investing in product innovation, market research and customer satisfaction. However, listen to the product manager of the startup tune project, Steve Ball himself admitting that common user does not really care about the tune.

Microsoft is also non-caring.

Let us figure out the investment here. The cost of 20 people over 18 months, assuming an average salary of just $50,000 is $1.8 million. Add another $200k for other expenses over 18 months and an extra $2 million for the artists. The total comes to $4 million. For Microsoft with $35 billion in cash, $34million means pocket-change. Google’s first round of funding was from Andy Bechtolsheim for $100,000.

Finally stupid:

Here is the crazy part. Along with the startup sound, 45 other sounds were created and revamped for Vista. Out of the 45 sounds, who made the final call? The final call was made by Jim Allchin, ex-copresident of the Windows Group. Here is the beauty: Jim left the company after the Vista launched. It never fails to amuse me when a team spends 18 months in research and development and then one individual who is not part of the team makes the final call.
So, Google is not working hard to keep Microsoft behind but Microsoft is working hard to keep itself trailing!

This post is continuation of previous post titled Good to Great. Hitwise released the top 20 social networking sites for February 2007. Here are the numbers:

I am happy to say that two of our four social networking sites are in top 20. BlackPlanet.com and Migente.com are at number 4 and 19 respectively for February 2007 numbers.
On a seperate note, we also launched GLEE.com. GLEE stands for “Gay, Lesbian, and Everyone Else” and is a social networking site for gays, lesbians, and everyone else. Also, GLEE.com also features our first modular ajax driven personal page product.

This is not it. In coming weeks, we will launch the next version of the personal page product across all our sites and release many other web properties. Stay tuned!

As a manager, you have a very powerful tool in your arsenal - feedback. If used properly, it can reinforce the positive and eliminate the negative.

I work in a flat organization and have over 20 direct reports. We have semi-annual performance reviews. I use these performance reviews to set semi-annual goals and assess employee performance on a higher scale. However, I do not use semi-annual reviews to give performance feedback. Most of the times, feedback is only effective if given within 24 hours of the incident. This facilitates a two-way communication as there is fresh context available. Remember, the goal is to give feedback that creates an environment of “continuous growth and excellence”.Here are my learning’s till date - some “Dos and Don’ts” for giving employee feedback:

1. Do not wait too long to give feedback. Give feedback within 24 hours of the event\incident.
2. Do not give a mixed message. Be very clear. At the end of the feedback session, employee should clearly know whether you are happy or unhappy with his/her performance.
3. Do not give feedback via email or phone. Always do it in person.
4. Do not give feedback in public. The purpose of giving feedback is to encourage growth and not reprimand. Always do it in private.
5. Do not broadcast. Keep the communication two ways.
6. Do not get emotional if the employee disagrees. The employee is entitled to disagree with your feedback. If you cannot keep your emotions in check, reschedule the session.
7. Do not just express your feelings. Back up your opinion with real concrete data.
8. Do not quote peers or other employees while giving constructive feedback. Always express your opinion.
    

“Heads must roll”,”Blow up the matrix”, “Kill the redundancies”. These may sound like action movie dialogues, but these bold statements are from the “Peanut Butter Manifesto” written by Brad Garlinghouse. Now, Brad is the Senior Vice-President of Yahoo and owns critical areas like the main landing page, mail, IM etc. It is very easy to sense Brad’s frustration in the reactive mood of the me mo. After reading the memo, I got the message that Brad had nothing to do with what is happening at Yahoo. It was all about everyone else at Yahoo. Also, it is always easy to offer guidance and advice when things are not going as expected. It is very easy to ask for massive reorganizations and ask for heads to roll. I consider this as reactive leadership.

He kept repeating that he wanted to be part of a solution and not problem. If Brad really wanted to be part of a solution and examplify proactive leadership, Brad could have lead with example and brought major positive changes in his area of control. Major positive changes do not get unnoticed. Other statement which Brad makes, “We need to exit (sell?) non core businesses and eliminate duplicative projects and businesses.” Yes, any management rookie will advise that after looking at the current state of Yahoo. Brad, how about a concrete example on how this can be done.

To me, this memo looked to me like Brad’s exit strategy from Yahoo. Time will tell - I may be wrong. At best, to me, the memo seemed written by an external consultant or a blogger.

I enjoyed reading The art of influence by Allan Holmes in the CIO magazine. Here are some of my learnings:

• Influential leaders are experts on the subject: To have influence, it is not enough to be able to just explain IT in simple terms, but a leader needs to be an expert on the subject at hand and its relationship to the business.
• Influential leaders do not limit themselves by their boundaries: Scott Heintzeman, CIO of Carlson Marketing exemplifies this by making it his responsibility to work on areas where he thinks he can help the company improve, even if it is outside his boundary of control.
• Influential leader try to remain objective by presenting facts: Peter Walton, CIO with the global energy company Hess, knew that simply stating his opinion would not convince anyone that outsourcing to a single company is a blunder. Instead, he put together a presentation detailing the latest expert opinions and case studies on outsourcing and delivering it to those managers in charge of the project.
• Influential leaders adapt their style to others’ learning style: According to Partners Health Care System CIO John Glaser, everyone learns differently, and that successful communication requires more than not speaking IT jargon. It requires knowing your audience and tailoring your message accordingly.
• Influential leaders involve people early on: According to Sue Powers, CIO for Worldspan, getting people involved early by talking and listening to them helps overcome objections, improve decision and win everybody on board.”

I got few requests to publish yesterday’s post in a easy printable format. I have created a pdf which you can now download from here.

We have four teams successfully practicing the tenets of Agile software development. We release new products and enhancements every month and iterate every week to accomplish the goals of the release. We try to remind ourselves of the good behavior. Here is the list for all the major functionalities of an agile team.

Customer’s good karma (Customers => Product Managers, Usability, QA, Member Reps)

• Always keep the end in mind: Agile software development does not stop you from having an over-arching vision. Have a clear-thought out story-board for the product. Communicate the vision clearly and continuously.
• Respect programmer’s need for zone time: Programmers need time to focus and are productive when they are in the zone. I am not saying - do not collaborate. Establish the right balance between collaboration and annoyance.
• Establish crystal clear priorities for programmers: Programmers hate multiple, confusing priorities. Make the priorities and the problem at hand very clear.
• Do your homework before the iteration: You are supposed to have completed the following before the iteration planning meeting:
  • Clearly thought-out goal for the iteration
  • Clearly defined stories for visual design, front-end and programmers. Each story has
    • Has a clear specific objective.
    • Has a clear acceptance criterion.
    • For programmer stories, have story tests ready before the iteration plan.
    • When working on new products, provide interaction and flow diagrams like the paper prototype or wireframes.
• Do not fudge too much with iteration plans: Do not change the scope once the iteration plan is finalized. No new features must be added to the iteration plan mid-stream.
• Insist on having weekly demos: Before a new iteration begins, customers demo the last iteration. Customers work proactively with the programmers to accept most of the stories before the next iteration begin.

Programmers’ good karma:

• Think of customers as partners: Before you start working on a story, understand the customers’ vision. Advise the customer teams on better approaches and designs. Once you finish the story, update the customers and gather feedback.
• Communicate early: Do not wait till the end of the iteration or release to communicate any issues or risks. If you find something that change your estimates inform your project manager immediately.
• Do not say no when asked for help: You do not have to help them now. But, make sure you make an attempt to help whenever you have time.
• Update the plans: Update the plan with your estimates and the status of the story at least once every day.
• Respect business’s priorities: Business may have a different agenda than yours’. Focus on continuously delivering business value.
• Do not cut corners
  • Keep practicing test-first development and refactoring.
  • Chant the “do not repeat yourself” mantra.
  • Signup for tasks that no one wants to sign up for.
  • Integrate frequently and continuously.
  • Run all the tests before committing your code.
  • Do not ignore a broken build.
  • Do not ignore architecture.

Project manager’s good karma:

• On-time delivery: Own the iteration and release schedule and on-time delivery
• Keep meetings short: Yes, Agile software development teams have lot of meetings. Please keep close tab on them.
• Mitigate risks: Have regular team meetings to discuss risks and come up with solutions to mitigate risks.
• Control issues: Bring any open or closed issues and identify a clear owner to solve the issue.
• Regulate changes to the plans. Keep the plans upto date.
• Do not ignore the non-programmer needs: Keep the visual and front-end teams are ahead of programmer teams by at least two weeks.

Consultant Coach’s good karma:

• Customize to the needs: Learn to customize the process to meet the goals of the business and company culture. If the company culture makes having weekly iterations difficult, have two week iterations instead.
• Listen more, learn more: A real effective coach is a good listener and learner. Do not rush to enforce your learnings on the teams.
• Learn to say ‘no’: It is better to say ‘I have not done this before. Let us solve this together’ than to make up an advice for the team.
• Do not play favorites: Yes, there are some people who do not like Agile. Do not ignore their ideas or concerns and promote people who support your ideas.
• Facilitate Respectfully: Guard and restore the self-respect of participants.
• Know when to back off: As teams start adopting Agile and take more initiatives, learn to back off. If needed, let them make mistakes and learn from their mistakes.

Internal Coach or Technical lead’s good karma:

• Coach Resolutely: It’s tough work, especially if you are being compared to an external consultant coach. Have patience and you will be accepted more. Do not give up.
• Keep sharpening your technical skills: I strongly believe to be an effective coach, you need to be player. If your technical skills are rusted, sharpen it everyday.
• Keep key players and management in the loop: Do not get carried away with your authority. You still have a boss and other important players. Keep them in loop.

Upper management’s good karma:

• Do not expect miracles: “I spend so many dollars and nothing happened”. Adopting Agile software methodology is just the beginning, teams have to customize it to see results.
• Avoid the temptation to be date-driven: “Now, go get it done” bravado is changed to “Let us see if I can change the scope to meet the date”.
• Do not be in a rush to roll it fast throughout the company: After initial success, you may be eager to roll out the process throught the organization. Please make sure you understand the implications of it before rolling it out.
• Make sure you really understand Agile before talking about it: Now that the teams are agile, you want to go and talk about it to your friends, other companies.