Former MySpace Exec. Explains How Experience Can Be an Impediment to Success
Mark Jung, former chief operating officer of MySpace, made an intriguing comment in this iinnovate podcast about how experience in an outdated marketplace can impede your success today, where the factors for success may be based on different rules.
The interviewer asks Jung, "If you were an MBA student today, what kind of opportunities would you be looking for?" Jung says:
It's a great time, frankly, to come out as an MBA student. I think it's a huge opportunity to come out as a graduate student now because specifically traditional skills, traditional organizations, independent of their size and the assets that they've built, are in many ways obsolete. Which means no one really has a competitive advantage.
Whether you have 30 years of experience, or you're a fresh MBA grad with two days post graduation, you're on a level playing field. And I actually would argue for the fresh grad, you're not encumbered by what has made you successful in the past. So you're going to take more risks, you're going to do things different. You're going to try an experiment in areas where experience for other individuals will be an impediment — no that doesn't work, that can't work, I wouldn't do that. That's never worked. Those kinds of statements are based upon assumptions and conditions of marketplaces that existed twenty years ago in media or distribution that do not exist today. (8 min. mark)
In other words, what was true 20 years ago in the marketplace may be false today. If you're making decisions based on successes you had in a 20 year old marketplace, those experiences can hinder your success in today's marketplace.
How is this relevant for technical writers?
What traditions were successful 10-20 years ago that might be unsuccessful today? I've thought of a few, but since I wasn't in the industry 10-20 years ago, I have to speculate.
- Users want to consume help material, not write or add to it.
- Users prefer books they can peruse, and they read sequentially.
- On a project team, it's the tech writer's role to write all of the documentation.
- Nobody reads help instructions on a small device like a phone.
- Word and RoboHelp are all the tools you need to produce great documentation.
- Newsletters are an effective way to keep your users informed.
- Users need detailed instructions for even basic tasks (such as printing or navigating a help file).
- You need only know a few core industry standard programs to be a technical communicator.
- The documentation you produce must cover the application's entire functionality.
- You cannot give away software for free and expect your company to make money.
- If you make a screen demo, you must use caption blurbs rather than your own voice. If you want to use voice, it should be someone who has a deep, rich, professional-sounding voice.
- Technical writers shouldn't interface with users; that's for the marketing and PR departments.
- Documentation should always be packaged and shipped with the product.
- All software should come with a free, complimentary manual.
- The documentation ends when the project ends.
- If something is free, it can't be good or reliable.
- Letting angry users comment publicly on your product, even including their comments in the documentation, can tarnish your company's reputation and scare away potential customers.
- Tech writers must be located near the SMEs to write effective documentation.
- Technical writers write, developers develop, Q&A people test, and project managers manage.
Let me know if you can add to this list.