For the past 2 months and a half, I’ve been working on creating the new holiday called Day for Failure. It was the most serious and biggest project I’ve ever led. It means that a lot of things have been unprecedented for me. The fridge in my brain suffered from the input overload caused by vast amounts of lessons.
If you’re curious why I did this and what happened in 17 countries, read the blogpost. Basically I decided to pick things up and organize the lessons I learned, before they melt down at some point.
Say no to scaling a team by default
Bringing a new member doesn’t immediately translate to an increase in value on the team, if desired and expected. More often than not, the idea of engaging a new person can backfire.Unless I find a very clear reason the guy is needed for the project, I learned that I should not engage him. This includes even when the guy looks very smart and you feel like he will add lots of value up front.
Unless you’re looking for a core teammate like co-founder or co-organizer, there should be actual work to be done by the prospect. Otherwise, you will wind up creating bogus work for the guy to do; additional layer of workload and management risk. Headache ensues. I realized too late, during the project, that I should actually put long-term contribution and level of motivation above the face-value of the prospect.
I made a mistake of engaging a new member too easily and early without prudent thoughts. While the face-value of the person looked great in every sense, I didn’t check carefully if the person would be willing to dedicate minimum 4 hours to our project on a daily basis and go through hassles when things progress slowly.
I found it very difficult to take back on the announcement of the member and face this matter head-on with the person or other members. While I feel frustrated about giving unfair credits to the person, I have been giving the person unfair amount of pressure to deliver something for our project, when it was virtually impossible for him to do so. When it comes to growing a team, I learned that I should be very conservative like Mums are for their kids.
Priority is the king
As a servant of a project, you have to serve a king and always keep the king at the center of your mind. Although this might sound a bit anachronistic, it is the loyalty for the king that will save you eventually. And if you start to serve someone else, say a duke who is even more intimidating and perhaps wealthier than the king himself, you’re doomed. While this is just an analogy, this can nicely deliver the point I would like to make now. One should always keep eyes on the ball: priority of a project. Sounds easy? Well it’s easier said than done. At least it didn’t work out as well for me.
The enemy was a sense of urgency. When we were almost on 20th day of our project, one of my friends sent me an email that our website looks like “a bomb”. By then, I was thinking that our website was somewhat MVP level, and embellishing and airbrushing the website would never be our first priority at that point.
As silly as it sounds, I couldn’t stop myself working on the website. How could I have ignored the feedback of a person I care about? (yes I should have, or at least hold off until it gets more important) I ended up tinkering with the website for almost a week or so, fixing some random pages and small details that wouldn’t really matter at that point by all means.
We were supposed to focus on talking to potential partners, while keeping the website as simple as possible, perhaps with a single launch teaser page. As we were running on a tangible time-constraint, this was eating away at the odds for sucess and a clear brake on the progress of the project.
And you know what happened 4 weeks later? Not surprisingly, we were too much into getting partners this time and put even the most crucial things aside; sponsors, speakers, and venue. We almost had them all a week before the event happens. Yeah we got them all, but that was close.Even when there are seemingly urgent things to do, I learned that I should ask how much doing them at the point actually contributes to the big picture of the project.
A generalist is required (and maybe no more than one)
“Specialization is for insects.” - Robert Heinlein.
Looking back, every member had expertise skewed over particular categories. However, there were always some skill holes that weren’t so easy to fill in, given existing skill sets of our members.
While I was aware of the importance of building a team with complementary skills and tried to practice it, we had to get things done in an area where no one has experienced. For sure, those gaps had to be bridged within a limited time frame. Our team lacked design capability. (remember my friend called our website a bomb?) So I asked people around me. Two of our friends,(link) helped us with logo and poster design. I thought it was over and everything will go fine, with a happy ending. Yet there were tons of technically minor things that I couldn’t really dare to ask my friends to do. So I had to learn, for instance, how to use image-editing software, Pixelmator and Adobe Illustrator and a few others.
We couldn’t work on the project full-time. We all were doing more than 2 things then. Fully aware of this, I had to very often face situations where I couldn’t afford to ask him to fix such minor technical problems. For one, I worked side by side with him, so I knew that he was totally unavailable at that time. For another, I couldn’t well articulate the reasons the things should be fixed. (only later I could do) So I had to learn how to fix HTML/CSS problems in the way I want. Now I am capable of solving most of HTML/CSS problems although it might take surprisingly lots of time - looking up for solutions, and asking in the communities.
Some of new things I had to learn were,
-
Photo-editing software (Pixelmator / Adobe illustrator)
-
HTML/CSS
-
Web design 101 (basic usability, benchmarks, typography)
-
Facebook & Twitter management (post timing based on metrics and creating shareable contents)
-
Writing a press release & doing other PR efforts
Outsourcing is not a panacea. There are certain things very difficult to outsource to anyone outside the team, even when the person has a better ability. For instance, if the work requires a high-level of understanding in the project, it might be better to learn to get the task done yourself, due to communication risks. Of course, if the task is expected to recur and is important, then someone in the team should learn how to do it.
Someone must step forward saying “Okay I have no idea now but I will learn how to make it happen.” and deliver it. Specialization is needed, but if not a single person goes through hassles of learning new things, then there’s another limiting factor on the growth of the project.