I often want to teach something I just learned. This may not be great for the people learning from me (sorry guys!). But I love to share the cool things I’ve learned from others.
For example, a year after I become a technical manager at a large corporation, I started offering management workshops to aspiring leaders on my team. This was the first time I had been formally managing people, though I had a strong passion for it. I consumed classes, breathed in books & blogs, and met with experienced managers to better learn this craft. I also made a lot of mistakes along the way, and took note of each painful lesson I learned.
Before each workshop, I crafted a lesson plan. I picked a central topic, researched various opinions & approachs for it, and related a personal story of how I’ve seen or tried to implement it. Feedback from the attendees shaped what I taught in subsequent classes, though I loosely followed an overall outline too.
My first few workshops probably sucked. I like to think that they got better over time. I hope they did. My management skills improved though, from both having to think about and explain various topics, to hearing suggestions from the attendees. Ironically, even though I was the one teaching, they ended up teaching me a lot too.
Later, I started offering general business workshops for my entire team. I thought I could make each software engineer more effective by helping them understand the motivations behind the actions of our business leaders.
At that time, I wasn’t formally in any kind of a business role. I was still a technical manager. But I dealt with product, buisness development, and marketing teams often enough to get a sense of their motivations and ways of thinking. That, and I consumed classes, breathed in books & blogs, and met with experienced managers too. This helped a lot when I took roles as a product manager and product director later in my career.
I may not have been the best teacher, but hopefully I imparted my teams with some useful knowledge. For myself, these experiences have been incredibly enlightening. I thought I was the teacher, when in reality, I was really the student.
Let’s say you’ve found a potential cofounder. Life is great, you got your cake!
But, no. Life, alas, is not always that easy.
There are certain personality traits that are necessary for a cofounder. Without these, your cofounder may not survive the early stages of your startup. Sometimes the exhilaration of finding a cofounder is so great that people don’t consider whether or not the cofounder will truly make a dependable and reliable business partner.
In other words, “Are you interested?” shouldn’t be the only question asked. I’ve seen colleagues inadvertantly do this. Heck, I’ve inadvertantly done it too.
So what other questions should be asked to determine an effective cofounder?
Passion & personal interest
“Are you interested? Do you genuinely care about this market, these customers, and this solution? Will you still care about it in 2-5 years or more?”
“Do you know the risks involved in starting a company from scratch? Have you done this before? How comfortable are you with risk? How comfortable are you working with no salary for the forseeable future?”
“How comfortable are you with frequent change? Would you be willing to change the entire business model if we discover our current idea will not work?”
“What is your communication style? Can you communicate effectively with a wide range of people? How do you resolve conflicts? How self-aware are you? Do you have leadership skills?”
“Can I trust you? Do you trust me? How do we really know we can trust each other? Do you keep your word? Are you reliable? Are you a self-starter? Will you follow through on your responsibilities?”
Complementary talents & skills
“What talents and skills do you have that I don’t? Are your skills competent enough to help prove this business model and create a minimal viable product? Are your skills competent enough to hire great people?”
“Do we get along? Does your personality and communication style mesh with mine? Could we travel together on a 6-hour flight, then a week-long hotel stay, without strangling each other? How about working almost 24/7 for several years together?”
These aren’t questions that should be asked verbatim. Find a way to have cofounder candidates share past experiences that illustrate these traits. It’s easy for someone to say, “Yes, I am comfortable with startup risk,” but much harder to demonstrate it.
Some of these traits, such as complementary personalities, are even harder to assess. Determinnig such a fit takes time. Social activities is one good method of doing so. Go get a meal together and chat about non-work topics. Put yourselves in an environment that’s relaxed, so your true personalities emerge. Ideally, you’d also find an environment that’s highly stressful (like an actual startup is) to get a more accurate account. But doing that is difficult, not to mention uncomfortable.
It’s hard enough to find someone willing to be a cofounder. Finding one that is a good match for you significantly narrows the pool. However, the wrong choice can be catastrophic. This is not a decision to be taken lightly, nor in desperation.
Finally, be aware that your first choice may be wrong. If so, and you truly believe your cofounder is not a good fit, it’s my belief that you should get rid of him/her as quickly, yet respectfully, as possible. There’s no room for the wrong people in such an early-stage company.
Steve Jobs has the art of the keynote down. Part Silicon Valley, part Hollywood, he’s able to enthrall audiences not just with desirable products, but with the right market timing, anticipation building, mood setting, even the stage lighting. Impressive stuff.
Here’s a collection of his product launch keynotes, in case you ever need some inspiration.
1984: The Macintosh
1998: The iMac
1999: The iBook
2001: The iPod
2004: The iPod Mini
2006: The MacBook
2007: The iPhone
2007: The iPod Nano
2008: The MacBook Air
2010: The iPad
The full keynote is broken up into 10 parts. It’s a bit much to embed all 10 parts here, but if you want to view them, you can see them on YouTube: part4, part5, part6, part7, part8, part9, & part10.
Since I have a technical background, I get about one offer a month to join some engineering team, or to be a technical cofounder. Active software engineers probably get two offers a month or more.
If you’re a non-technical entrepreneur in Silicon Valley that’s out of college now, it can be tough to find a technical cofounder. But it’s not hopeless. While it might be easier to find a cofounder in college, there are some ways you can increase your chances post-college as well. Here’s how.
Work for a company that is known to have great engineers. Be a great product manager, marketer, or whatever your role is, and foster deep connections there. When I say deep, I don’t mean going around broadcasting that you’re looking a technical cofounder. I mean finding like-minded people and fostering geniune friendships. Or, at least, solid & respectful working relationships. Also, do a kick-ass job in your role. If you’re known as a sharp individual, others will more likely want to follow you.
I was lucky enough to have worked for Yahoo! (YHOO) in its second act. The dot-com bubble had just popped and amazing talent was all over the market. I was able to hire phenomenal software engineers and grow a strong team culture. Many of us have said we’d love to work with one another again. Although most aren’t in a place to be startup cofounders for financial reasons, I now have access to a large talent pool once I can offer a salary. With all the funded startups that are unable to hire, that’s a huge ace up my sleeve. And for the engineers that did want to become startup cofounders – wealldid.
This is a relatively slow method, however, depending on how quickly you can connect with someone. But such a connection can be long-lasting and meaningful.
Learn to write code yourself. Then go to hacker events and developer meetups. Or even contribute to an open source project. The development community is a friendly one (for the most part) and you’ll often find many people eager to help you out. You can earn the trust of other developers fairly easily if they see you willing to do this. Also, you’ll be able to speak their language.
This can be a difficult journey for some. You may have almost no interest or little patience in programming. That lack of motivation can make this method fairly time-consuming. But if you’re able to hack it (no pun intended), there are a ton of free resources out there for you. From Codecademy and Try Ruby, to free programming books and freeonlinecourses. If those don’t work, pay for a programming course at a local college or workshop. Sometimes having a human being who can answer your questions can help.
Be an inspirational champion for an cause. This works if your passion and business idea is not just by pure profits or trends, but by serving the community and the world in a greater way. Get yourself involved in various organizations & volunteer groups and be a recognized leader. Build up your personal brand both offline and online. I know of one charismatic individual who’s done this on Quora, Twitter, and through various guest blog articles. He doesn’t have a technical background, but you can just feel an aura of eventual success around him.
If you’re not an extrovert, you may find this option somewhat of a struggle. Building your reputation online might be easier in that case. But to really attract good people, you’ve got to go to various meetups and events as well. Build your networking skills, not in a swarmy way, but in a geniune way. Take Toastmasters classes if you need public speaking help. Offer free help & advice to others; sometimes you’ll find that kind of generosity come back to you.
The common denominator of all these tactics is building meaningful relationships with others through proof of your abilities and talents. I’ll trust you more if I’ve worked along side you, seen you try to write a web app yourself, or know you to be an inspirational leader in your field.
I thought it was all so hilarious. Sucker for cheesy geek humor I am. So naturally, I tweeted it. (I wonder if that word is going to make it into the dictionary one day.)
A bunch of friends chimed in withmoreCSShumor. While my geek funny bone was being thoroughly tickled, my pattern recognition bone wondered, “Is csshumor.com available?” And indeed, it was!
I purchased it, installed WordPress as a quick & dirty CMS, set up some random theme, and invited some friends to submit more CSS humor. I got a bunch. Most notably, nine from the generously hilarious & prolific Groxx, who would later submit a total of thirty-one entries to date. It’s enthusiastic users like this that make small projects such a pleasure. Eventually, I redesigned the UI and made it mobile-friendly.
And that’s how CSSHumor.com got started. As Gary Larson once said, “I don’t know how interesting any of this really is, but now you’ve got it in your brain cells so you’re stuck with it.”
From the technical aspect this is well done because it shows the power of CSS. From a designer’s point of view it is quite far from perfect. The icons look weird and the active state looks quite uninspired with only showing an inner shadow.
The icons don’t bother me as much, but the active state could certainly use a rev or two. Here’s my attempt at a revised active state. Building this solution required me to swap out Red’s use of em units for px units, so I could alter the padding of the active state to give it an “activated, pressed down” look. It’s not quite perfect, but feels better than an inner shadow to me.
“How the heck do I find these people? I need more of them TODAY!”
I consider myself damn lucky to know a strong network of great developers. But no, you can’t hire them. Practically all of them have fantastic jobs already. The rest are starting their own companies.
So instead of turning this network over to these hiring managers, I’ve been telling them how I found the developers in the first place. Here’s what I told them.
First, it helps that I was once a developer too. My programming skills have waned quite a bit, but I understand the programmer mindset and lingo. If you don’t have such a background, have a developer be a part of the technical recruiting team, either as an evangelist & advisor, or full-time member. They’ll be able to communicate with potential candidates better than non-developers can.
Next, craft an enticing job description that includes your technical vision describing how you’ll accomplish the overall vision of the organization. Developers care about the success of the organization because they want to be a part of something great, but I’ve found that the technical vision is the important part. Just stating that the developer will work with XYZ technologies isn’t enough. Draw them in with the team’s true underlying goals, such as creating a new company-wide architecture, inventing a brand-new product, or building a new framework that will be open sourced later. This technical vision has to sound immense enough to be daunting, yet exciting enough for candidates to say, “Holy crap, I could never do that myself; I need to be a part of the team that will do that!”
If you don’t have a technical background, ask your developers to help you write the job description. In my experience, many will give you a so-so job description. They won’t include any of this visionary detail. To cull it out of them, ask your developers to describe the most exciting parts of their jobs. Then ask your technical architects and senior developers about their grand technical vision. You can take this material, edit it for clarity, submit it back to the technical contributors for a sanity check, then publish it as your official job description.
Third, search through typical developer hangouts. Github. StackOverflow. Various StackExchange sites. Hacker News. Developer mailing lists. Developers’ blogs. Developers’ Twitter accounts. There are dozens upon dozens out there.
Ask your developers which communities and blogs they frequent. Visit each of those sources. If it’s a blog or Twitter account, check out who they link to, who they respond to, who they mention, who they write about, and who they quote. Blogrolls and Twitter lists can be especially helpful. Not all of these people will be interested, or even qualified, but they make up the peer group of your target audience. Through them, you’ll be able to find lots of promising candidates.
For the online communities, it’s important to pay attention to their rules. Some frown upon job listings, some welcome them, and many now have job boards. Use those job boards. For an extra bonus, keep track of the number of candidates coming from each, the number that get interviewed, and the number you actually hire. Not all communities are created equal. Some will give you a better return than others. You can use this data to focus your searches in the future.
Fourth, identify which candidates are worth interviewing. Like I said, not all will be qualified. If you have a technical background, you can look through their public code or ask for code samples. If not, have the developer on your team help you. The goal at this step is to identify who is at least worth a phone call. Your organization’s procedures may differ, but I generally prefer code samples first, phone call second, in-person interview last. All of this is possible within a week or two if you hustle, depending on the speed of the candidate’s responses.
There have been times in which I’ve sent candidates an at-home exercise too. If you do this, make sure the exercise looks fake enough that the candidates don’t think you’re trying to get free work out of them (and, it should be said, DON’T try getting free work out of a candidate) – while at the same time make sure the exercise effectively tests for the skills you seek.
I should note that this entire process is time-consuming. It is not for the faint of heart. I had a busy schedule while doing all of this hiring, but I made it a priority anyways. Other tasks had to fall off my plate. In my humble opinion, investing time into an effective recruiting process is worth it if you want to find great developers. And having fewer great developers on your team will give you a lot more bang for your buck than lots of mediocre developers.
There’s this philosophical exercise where you write your own eulogy, then use that as a model of how to live your life. By laying out your life’s goals first, you can better structure your life to reach those goals.
For example, if you want to be remembered as a good parent, reconsider ditching your child’s baseball game for another hour in the office and prioritize your child first. If you want to be remembered as a generous person, give generously to charities and those in need. Etc etc.
The same can be said about a startup.
I believe it was David McClure who I heard say the words, “build it backwards” during some startup conference. He talked about starting with a vision, then going backwards to build the business, the team, the offerings, etc.
That’s not quite the same as a eulogy, of course. Writing a eulogy for a company doesn’t make as much sense as for an individual. Instead, how about writing the About page for your company five, ten, twenty years from now? Or a Wall Street Journal article describing your company’s impact on the industry, your customers, and perhaps the world.
From that page or article, think about the steps needed to get you to that end goal, that vision. Then use that as the high-level steps for building your startup backwards.
And, as an extra bonus, consider writing your own eulogy too. It can be an intriguing and thought-provoking exercise.