This last week I had a chance to sit down with some seniors at GWU and talk about my experience in the exciting world of software startups. It was a fun experience and gave me a chance to reflect on my 18 years working on web and Internet based software projects. Here are a few of the observations I shared with the class:
The Job You Want Doesn’t Exist. You Have to Create it.
Every year Forbes Magazine publishes a list of jobs that didn’t exist a decade ago. If you are really planning to change the world with your ideas and technology be prepared for the fact that your job doesn’t exist. You will need to invent it. In fact you are going to have to invent a bunch of other jobs to make the business and its ecosystem emerge.
In 1995 when I graduated from college the Internet was just beginning to be a thing. I ended up getting a job as a webmaster. This was 1995. The web hadn’t even existed when I started my studies in 1991. As I started my career, this technology wave was rising. A series of lucky events placed me in the right place to catch this wave. I graduated and got a job as a “webmaster”. I’ve learned to look for these waves and that if you make yourself ready you can catch it.
The job you want on that coming wave doesn’t exist yet. When you first start doing it, people will say, “WTF?” When I told my roommate about my job as a “webmaster” he joked, “webmaster? what are you spiderman?”
You are Going Continuously Fail and Suck
I don’t mean in the baseball way where you get so many at bats but you’re a champion if you get on base 30% of the time. I don’t mean it like the classic Edison quote, “I haven’t failed, I’ve just figured out 10,000 ways it doesn’t work.” I want you to have the expectation that it isn’t going to work period. You are going to pretty much spend every day alternating between totally failing and just merely sucking at what you are trying to do. Your life will be a series of broken builds, bugs, things that were really great in theory but users hated. Eventually out of all these failures something beautiful might emerge. That failure might even become a runaway success. Even so, in ten years you are going to look back and say, “wow that was terrible.”
This point was better said in this Helpful PSA Entitled: Point/Counter-Point Should I Get a Tattoo.
Encourage Plain Speaking and Criticism
It is really hard to hear how terrible your idea is or tell a team member their idea is terrible. Even though almost every idea is terrible in one way or another. It is very easy to stand around smiling and nodding, but that really doesn’t help. When you do that terrible ideas live on. They are never forced to evolve. Worse, critics start talking behind the backs of the leader of the initiative. A terrible idea ends up moving forward but is undermined by the organization. The result of this is usually something worse than the terrible idea itself. You don’t have to be mean about it. You have to set the expectation with your team that most ideas are probably going to be pretty terrible. If an idea isn’t terrible when it is first pitched then you probably didn’t spot how terrible the idea was.
It requires a bit of a thick skin to stand up there and hear about how terrible your ideas are. Hopefully some of the critics will have helpful suggestions such as “never speak of this again” or “that might be cool if…” Don’t let those criticism over whelm you. Keep trying. Come up with other ideas, or revisit the idea a bit differently. Keep pushing and prototyping until something useful emerges from that brain of yours.
Don’t be a Jerk Every Day
Some say I still need to learn this lesson. When you speak plainly and recognize how terrible the thing you are working on is, it becomes very easy to become a gruff and nasty person to your fellow human beings. This is something to be avoided. Keep your criticisms to the writers room. Find time to reach out and bring snacks for the team. Recognize the few moments of success where even though it will likely blow up again soon; things are actually going well. Every person is going to have a different level of tolerance and general stubbornness. It is your job as a fellow human being to recognize how hard you have to push and push no harder.
Lead by Establishing a Common Purpose, Drive People Towards Mastery and Reward Autonomy
I believe that big breakthroughs usually come from small, super motivated, agile teams. Dan Pink has a great Ted Talk on the core concepts of Autonomy, Mastery and Purpose. It is very easy to break your team’s spirit. As a manager and the visionary one can easily fall into the trap of “I have this huge vision and a list of a thousand things for you to do, now go do it people.” The first thing you have to realize is that your vision is wrong. There are a few useful things in there, but seriously your idea will fail. Even if the developers manage to meet the impossible schedule, divine all of your hidden features and get everything exactly as you wanted it the first time.
If you really want to make amazing things with your small team. You have to push your team to deeply understand the customers and the overall purpose of what you want to accomplish. Then you need to encourage and reward initiative that drives towards that result. Keep your team focused on the purpose, on the broader cause. Don’t let them get too bogged down in requirements and mockups.
The Advice About “When to Ship” Is Probably Wrong
You will often hear that you need to ship early and often to customers. There is a lot of value in getting feedback from customers. Still this can be bad advice. It really depends on how your users perceive you and how you are going to manage the impact of the changes you’re making. If you throw a bunch of change at the users on a continuous basis they will go find something more stable. Change takes time for the users to absorb. You have to understand the amount of change your users can accommodate and then go no faster.
Don’t Cram Your Releases
It is always tempting to try to fill up the release with millions of new ideas and concepts. You probably have a list of things your users want and it always feels great to check them off the list. However in keeping with the last point, know that your users can only understand a few new things at a time. My favorite example of this is the launch of the iPad. All the other tablet makers lined up at CES before Apple announced it’s tablet and tried to create their own. Sprint had one that had a bendable screen. Microsoft and HP had one that opened into two screens like a book. Everyone was wondering what the iPad was going to be and there was universal derision in the tech press when it turned out to basically be a really bigger version of the iTouch. It turned out though that this was really a smart move. They made on major change (size) and left out things like a camera until users had made the leap. It would have been easy for apple to cram a bunch of other things into the iPad 1, but they didn’t. A release is a little like telling a story. If your story is too long, no one reads it. If you build a bunch of functionality that users never know about; then all that effort was wasted.
Continuously Invest in Things that Hook Your Users and/or Your Users Have to Do
You need to measure every page your the app or website. What things are your users doing often, whats their experience and how can you improve it. The team I managed working on CourseSites was always looking at the signup page. How long did a signup take. Could you easily find your institution. We wanted to grow usage of the site, so that meant we had to continuously invest in that page. Every release it gets tweaked and improved. We set goals to improve the accuracy of the data capture, and reduce dropouts.
If you don’t know how you users are using the product and you don’t know what hooked them; then it is impossible to manage the product over the long term. It is very easy to get caught up in making some flashy new capability based on some latest market buzz, but if that leads to neglect of a critical feature then you are going to suffer in the marketplace. You also need to understand that usage will shift over time. Things that were compelling a few years ago, will be dead on your site tomorrow.
Maintenance Will Be Most of Your Job
Of the course of a successful software product’s lifespan something like 90% of the effort goes into maintenance, not new functionality. Before the product goes into widespread usage you will get an opportunity to explore and innovate tons of new capabilities. Once it gets adoption, your users are going to demand continuous improvement. They may even resent totally new features because they will see it as taking away from expanding the things they like to do. Maintenance gets kind of a bad rap. People mistake maintenance for a lack of innovation. Well managed maintenance is continuously optimizing things. It is speeding up transactions, improving reliability and polish, and simplifying workflows. Consider Google search. We don’t need a totally new user interface for Google. We just need it to constantly stay on top of the changing set of information on the internet and give us the best results. Microsoft tried some really innovative things in launching Bing!. Automatic product recommendations, health advice, travel stuff. They even marketed it as a “decision engine”, not just search. However ultimately it has struggled, because those features were not the core feature and are not compelling enough to draw a user away from Google. Google has worked to maintain a slight edge on search results through regular maintenance.
If you take anything away from this essay try to remember this. There are terrible things that are useful and things that are just terrible. If you are able to make something useful into something slightly less terrible then the world is yours.