www.peopleimages.com has launched – this is how it happened!

My thoughts on how I experienced being a photographer venturing into IT, equipped only with a high ambitions and a good idea. Not all good!

www.peopleimages.com is out of beta as of today! Two years of project management, 5 developers, 2 designers, 1 front-end developer and we have finally arrived at a live www.peopleimages.com. In this post I will elaborate a little on how it has been for me (a photographer, a non-IT guy) to learn how to project manage and execute a fully fledged IT project and launch a direct sales platform.

If you have a photographer friend, an artist colleague or somebody that you know who wants to launch an IT project, this is definitely the article you should show them. And preferably before they do step into IT! I will share everything I wish I had known two years ago when this project was just a dream consisting of a pile of random notes.

First I have to face a couple of facts. Let me be honest: This project has not been easy and from the very go-ahead I underestimated the time it would take (way too much), the effort it would require on my part, and all the small unforeseen problems that arrive while building a good website. But if you put these things aside and look at the outcome… I made it, and I don’t regret it one bit because the journey of getting here was all worth it.

My first lesson learned:

Managing IT teams – a whole different story!

My first lesson learned was in regards to management. Today I run what is probably the largest photography producing business in the world – at least when it comes to the amount of staff, as we can count more than 100 full time employees. However, managing six IT guys would prove to be more time-consuming and more difficult than managing my entire business. I knew from online blogs that people in general have a huge tendency to underestimate what it takes to launch IT projects. “It’s just a homepage. How hard can it be?” was the mistaken belief. Being new to IT, I believed I would suffer from the same flaws in my own thoughts about the project, and I was absolutely right. I took the project too lightly.

IT projects are by far the toughest projects to manage, because unlike other projects, most IT projects are complex in ways far beyond areas that you have knowledge on, and sometimes can be so complex that nobody has the complete overview. In photography, I would manage staff mostly based on having the most experience and so on. When I was in the military, it was the same. I would teach and earn respect based on skills. IT is completely different. How do you judge if the programming is done well, when you don’t know any programming yourself? How do you estimate the appropriate timeframe for a task, when you have no idea of what that task involves? How do you know when a person is being too laid-back and must be told to work harder? All the tools that a normal manager can use to direct a project are inaccessible to an IT manager that is not a developer themselves. And if you believe they are not important, then consider the most successful IT projects in the world. They were all started, maintained and thought of by programmers themselves. Google, Facebook and Windows are no exceptions to this rule.

I had to learn the difference between knowledge-driven leadership, and being a manager of something I did not know anything about. It cost me a lot measured in time, in mistakes and in money. Two times we had to rebuild the entire site because we found fundamental flaws in the architecture and framework that would not allow the site to be as fast as was required, or would result in the site having too many bugs down the line. We arrived at these dead ends because of me listening to the wrong people, and not having asked the right questions, while at the same time managing the project too loosely.

Very few people will tell you to your face “this will not work” or “we need to delete 1,000 hours of code work because it will create bugs.” Especially not if they are hired by you. So you have to learn to push for it, you have to really make sure you paint the picture clear enough for your team to be able to employ their knowledge in the areas where you don’t have any. This is the only way to manage such projects, and because of the very nature of how you need to go about this, they are much more personal and demanding than normal projects.

More than a year ago I posted a blog post that we were looking for new developers for a project we where building.

I got this “expert” comment from a programmer reading the post:

“Hi!  Noticed you guys got interested in creating your own solution! How nice! But seriously, do you think that non-professional staff (you do photography, not web solutions) can effectively handle such a challenge? Moreover, the way you put the task requirements.. PHP(!), parse-rss-feed-and-put-title-into-database… You made me smile! Look, the ancient ages are over. If you really want to setup something significant, please get in touch with us – stockmediaengine.com. We specialize in (micro)stock solutions, we can offer you to spawn new project based on our platform, or we can develop everything from scratch. And it definitely won’t be PHP. We use RoR”

The comment is still on this blog,  but I don’t want to post his name here. The most interesting part of this comment is that had I listened to him, and built my site on RoR (Ruby on Rails), I would have had a much bigger problem, because RoR programmers are scarce out there, which means that a simple procedure such as finding a new developer to join the team would have been nearly impossible, or at the very least extremely difficult. It could have killed my project completely, and as you can see this is definitely a guy with strong opinions, who wanted to convince me I was doing something really bad that I would come to regret later. That’s why you need some degree of knowledge yourself, so you can decipher when “advice” is actually more promotional and if dealing with your own developers, when the advice is based more on comfort and the habits of the developer, and is not the best solution. (The “I love my own code and my way of doing things”-mindset is a well-known condition that many programmers suffer from).

Quote: Managing 6 IT developers was more time-consuming and difficult than managing 100 people.

My second lesson learned:

I am definitively a perfectionist – no doubt about this! Or maybe I should rephrase and call myself “a selective perfectionist”. What I mean by “selective” is that there are things I care about a lot, and other areas where I am not a perfectionist at all. This is a trait I share with many other artists – being perfectionistic, proud, critical. This is a problem when managing IT projects, because it will cause you to neglect some areas, while focusing all your energy and efforts on others.

Quote: For a perfectionist to ever create anything great, you must be able to say “Stop – Enough with the details!” and settle with the less attractive option.

I can tell you that I have user-test results lying around with feedback on about 5 different types of landing pages, about 10 versions of the sidebars in the right side, and a similar amount of global design changes to the whole site, which we did not only discuss, but actually ended up building.

The problem is that you become paralyzed by perfectionism or critique. This phenomenon is very well-known in photography, where some artists will do one exhibition a year or even fewer, because they become so self-critical and self-aware that they end up not doing anything at all. They know that having something out there with your name on it that you don’t like yourself will bring upon you a great punishment – in your own mind. The misconception is that other people don’t see it like this, and it becomes a thousand times better having been able to create “something” than not having taken the final step at all.  I had to learn to say “enough is enough”. Sometimes the smaller and easier solution is the right one, because the time it will take you to arrive at the bigger and better one might simply not be worth it. A this is a very difficult type of decision-making for a perfectionistic mind, but one you have to learn when doing IT projects. This one was hard for me!

My third lesson learned:

Advice…. Or not? My next clear lesson learned concerns expect advice. Being a novice in the field of IT, my first choice was naturally to seek the advice of the more knowledgeable. In a similar fashion, I probably get about 50 emails every week from young photographers who want my advice. During the five years I’ve done business, I have answered every single one of them. In my own way of course, which sometimes has meant saying “your portfolio is exceptionally bad and your attitude is terrible, get over yourself and shoot more personally. Create a story, one you believe yourself!” It became a bit of a hobby for me, and although it would often take a lot of my time and even though it may have been tough occasionally, I have never given anybody a complete turndown. I always left a door open for them, and a few honest points regarding areas where I believe they could improve.

Now I suddenly found myself in a similar position: At the mercy of other people’s goodwill and, to my discouragement, I found out that other people knowledgeable about IT certainly did not take the time out to answer any questions. Even when coming from the world’s top selling photographer, ranked among the most influential of this decade, etc., etc. (I used all the fluff I could in those emails I send out) it did not matter one bit, and I received kind, short replies “So sorry, don’t have time” or none at all.

People that were successful in building an online business certainly did not want to share how they did so. So I was left with nothing but newly hired staff developers and some colleagues that I knew had been relatively successful online, and I had to try to extract some sensible advice from them.

It did not go well at all. My basic lesson from this experience, which took place during 2008-2009, when I was planning and designing www.peopleimages.com, was that if you want expert advice that matters you will have to get it from yourself.

Quote: Forget the “experts” – the best advice comes from yourself – a re-educating yourself.

So I started to renew myself. Researched like a madman. I became especially fascinated with SEO, where the internet at that time (with no penalty from google as today) was flooded with overly-optimized sites, artificial link building and basically poor, but high-ranking sites. If you followed my blog back then, you will have noticed a few keyword-heavy blog posts, and a lot of link building going on in the background. As you can imagine, I almost always push things to the extreme. So I went SEO crazy on my blog, and it was ugly, but back then it worked somewhat. I got about 24,000 likes on my facebook page, and another 6,000 followers on twitter during that period. But the total effort was unstructured, noisy, and something my readers would grow tired off in the long run. The problem was that I listened too much to “expert advice” on what would be good SEO, but forgot the original reason why people would visit my blog. Because of good articles.

It ended up nearly killing my drive to blog, and I stopped writing for about a year. My final conclusion was that listening to “experts”or “IT consultants” was crap. Useless at best, time-wasting nonsense at worst.

This black-and-white thinking would not last long however, and I came to accept a modest internal change of mind: There are two extremes to avoid. The worst possible extreme is to completely disregard experts, and try to do everything yourself. That will end up costing you a lot of your time, and the end result will not be at the industry standard, although you spent an extreme effort getting there. The other extreme is not to take the time out to re-educate yourself, and simply blindly depend on hiring expensive IT consultants, as we have seen so many big companies do, and just place the project in their hands – we need a website, fix it! Pushing it away as something that somebody else needs to take care of and they don’t need to learn anything about.

A gradual re-education of yourself so you know enough to understand the scope of the project, understand the advice better and are able to ask the right questions is the revised medium I would advocate. Then, you will be able to – with your own mind at work, knowing your business the best anyway – serve yourself the final and best conclusions, and most importantly being able to say that you got there by yourself. Because, after all, you know your business and where you want to go. It sounds trivial, but actually it’s not, because you end up disliking or discarding the final product. The moment an expert starts explaining something and you find yourself lost, that’s when you need to start asking stupid questions.

My fourth lesson learned:

Instinct matters! You’re right; your niece, who’s only five years old, is right; and your grandmother is spot on! The last big lesson learned was about usability and instinct. If these people can’t use your site instinctly and don’t understand it after a little time spent online, there is something fundamentally wrong and things must be changed. Every such change of something already created will upset a team of IT workers. It feels terrible for them because they spent the last week coding it, and now they have to watch as it is being discarded.

Even the best developers or designers can’t make excellent design that is perfectly understandable from the moment it is created. You work yourself blind in the creation process, and don’t see the small things that somebody who has never seen the site before will spot right away. It’s not bad code. It’s not poor in any way. It is just how the process works.

Developers will often argue, however, that had they just had a good enough plan from the go-ahead they would not have to discard work now. I will go against all blogs, advice and project management idioms and claim this: “Don’t listen to that!” A tight project plan ends up just becoming that…tight… a rigid structure that you hold on to with many small impractical errors. There is only so much you can plan from the start, and often if you plan too much, the final product will reveal many small mistakes that you could not have foreseen when the tight plan was created.

Programmers loves detailed planning, and most other people do too, but great interaction design was never arrived at from the very first go-ahead. It is, by its very nature, an experimental process and you will find yourself often arriving at the best solutions when you start using the interface yourself. The only problem is at this point somebody has already had to build it and be ready to discard it.

As a project manager, you have to put your foot down here. Bad design is such a crucial and fundamental problem on the internet today, and you must make it clear that if the design solution is not working, you will have to start over. It is as simple as that. If your instinct tells you that something is not working properly, go back to the drawing board.

Discarded! Again and again.
Remember I said earlier that we discarded the whole site two times and had to start over? Most people would consider that a total flop, a loss in all ways, but it ended up getting us closer and closer to having a thorough understanding of how the site would need to be programmed and how the interface should work. Because of this, in our third attempt to build the site we would be able to do a very minimalistic design and a very minimalistic code, which would give us a very fast and simple website. The problem was that there was no way we could have done this in the first two versions, because we simply did not have the experience ourselves with the site we were trying to build.

Quote: “To get the experience you have to build it, and to perfect it you have to be willing to destroy it”

In reality most things can be done as gradual modifications: small changes and new ideas that end up shaping the final design. But sometimes you hit dead ends and have to do a complete refactoring of the entire site. My final conclusion on usability and listening to your instincts is about nurturing a mindset. An acceptance of change, and to replace a rigid plan with flexibility. That by preparing an IT team to face the facts, and accept that that we will have to change our minds many times to arrive at the best solution, is the best management strategy you can employ.

Many aspects will have to be redone based on user feedback, and this overrules comfort, favoritism and work already committed. Prepare the team for this from the first day, and prepare your architecture of the site to be as flexible, scalable and simple as possible if you want to avoid dead ends.

The Launch!

Preparing for the launch event, I had a 6 min live TV spot lined up on the launch date in front of 1.5 million viewers. I was extremely lucky to get this pitched to the editor in such a way that they ended up running the story. But when it actually was about to unfold I was more nervous than I have ever been prior to any interview. I only had about 15 hours of sleep the last week before the launch, and had ready to go live at 8am in the morning with 4 hours of “airplane sleep” – and, naturally with all the stress, I fell ill the day before the TV spot. It was simply madness, but it had to be done and it had to go well.

It is a relatively known fact that IT projects are the most unsuccessful of all startups, and that only about 5% actually end up making it to a live website. This however should not stop anyone from trying, but it should remind you to equip yourself with a lot of realism, so you actually end being one of those in that 5%. In an environment that as competitive as IT, you can’t afford to miss a single strike of good luck. This next story is about just such a strike of luck, or actually about being unlucky – you decide.

The reason I had had so few hours of sleep was that the launch was leaked to the media three days before our original launch date was set, and it was posted on the front page of the biggest newspaper in Denmark. Here is an excerpt from the article.

This gave us an immediate problem, because the site was not yet live, so for every minute the article was out there we would be losing thousands of curious visitors that would end up on a page telling them that they were not authorized to access the site. A nightmare for a newly launched site, because a traffic event like that constitutes one of those chances you simply cannot afford to miss.

At 1am in the morning that day (a little more than an hour after the leak), I sat my entire team down at a table in my private home in Cape Town, with the rest of the team on Skype conference calls. As we sat around the kitchen table, it became quite clear what we had to do. We had to launch now. Not in in three days. Not tomorrow. Now.

Every teamleader went through an emergency list of known issues that they knew would have to be fixed before the launch, and laid out estimates on how fast they could do them. It was a madly ambitious idea to launch right away, but we knew we had to do it, and to make matters worse it was in the middle of the night. We set up what would be our launch command central in the middle of my living room. We used foldable tables, hooked up laptops to all the screens we could find, and to keep us motivated we live streamed google analytics so we could see how many visitors we were actually missing out on every minute. The visitors were certainly coming in, and quite a lot of them, but there was nothing to see on the site yet. It was closed off to the public, and was painful to watch.

Our curator was still proofreading and sending text bits and changes to our frontender, our designer was still doing finishing touches to the landing page, our payment system did not have a receipt/download page, the log-in/sign-up was not ready and our flagship feature, the time-exclusive license, would not make images auto-disappear for the period the buyers wanted them for themselves. These were but a few of the problems we experienced. At the same time, we began to see people actually attempting to hack us, and try to gain access to the closed-off part of the site. We were able to fight it off, but it was intense.

In the course of the first few hours, the first issues were fixed and were ready for testing. A few more hours went by, and more issues were ready, and some were even closed/completed. As we were approaching 6am, the visitors were slowing down because of nighttime, and we knew we would have to be live and ready before the morning news at 7am. During following 30 minutes the final issues were closed, and for the first time in two years the site was now open to the public.

It was a big moment, seeing the site actually live. It was scary in a way, and from being an atmosphere full of update calls, skype calls between testers and developers, and constant talking, the room went completely quiet for the first time. We all just sat there, exhausted and looked at the screen. The first visitors arrived. They never knew they were the first, but they were.

I will never forget this night when everything came together, and we could launch the site three days before deadline in one night. It was one of the most exhausting, but still interesting events I have ever been part of, and I would not trade it for the world. I found out something else as well. Something quite astonishing: I have a fantastic team. An unbelievable group of people that are extremely dedicated. At one point around 4am I looked around and counted that there was not one member of the IT crew (including periphery team) that was not awake and working like crazy. Even the guys in other time zones were online and going at it 100%. And as it turned out, which we did not know at that time, it would continue like this for three more days to make sure all the small details on the site were perfect. People would take time-outs of 8 hours in order to sleep, some would literally sleep around the house. Even my CEO of the Cape Town department, who was in charge of Checkout Quality Control, worked through that first night, then went to work at 9 am, worked a full day, and slept for the first time the following night.

I think that from the go-ahead when we started the peopleimages.com project, we had a style and way of going about things that got the team used to going that extra mile. I would challenge them again and again if their solutions were not excellent, and I think they quickly realized that this was not a normal 9-5 kind of job. We had to say goodbye to some team members because of this, but the efforts paid off, because when panic struck and we had to do the impossible, they were ready… and we made it.

My conclusion after all of this is simple: Most people are more than willing to become the best they can be, but you have to demand it and give them the opportunity!

Talking to my team afterwards, they were actually extremely happy to have been part of something so crazy and intense. “It’s why we became developers”, they would say. “It’s then that we know what we are made of” and “it’s a story to tell.” By demanding the best you might just get your wish come true.

I really wish I could have time-machined myself back two years to have been able to read a couple of these paragraphs. And with the working weeks hitting 70+ hours, with managing the www.peopleimges.com project on top of training our new team of 12 photographers, I would have liked to have been told this:

IT projects are hardcore! Madness, crazy working hours, and insanely interesting at the same time – but it’s worth it – keep going!

Remember. I wish I had known these things when I was starting out my IT project, so do your ambitious friend a favor and send this article to them! 🙂