I originally published this on the StartupResources.io blog. You can go there to subscribe to my weekly newsletter of startup tools, articles and advice.
I was recently asked by a founding team I know, how to go about hiring a CTO. They are experts in a significantly deep domain, but need a technologist with them to build their company, ideally one with a background in the same domain.
So far, they’ve been outsourcing technical work, but they’ve realized that this is not be the best approach.
How to find your CTO co-founder
In my opinion, for any type of startup where you are building something new, that has not existed in the world before, it is best if you are able to hire a full-time technologist into a CTO type of role, as a partner or co-founder. Without working extremely tightly (in the same room, even) with the person who is building the nuts and bolts of the product, you always lose some of the innovative magic that comes from different disciplines all aligned on building a product.
Of course there are times you can’t do this, e.g. if your budget does not allow it or if the company only needs input from a technologist for a limited amount of time, in which case it can make sense to outsource. If this describes you, you might want to talk to my botwhich can help you decide where to outsource from. But if you’re in a situation where it makes sense to bring on a full-time technologist, one who can build your product and steer the technical vision, do it.
When you already have expert knowledge of a deep domain in the founding team, here are my recommended approaches to hiring a CTO, in order of preference:
#1: It’s all about your network
Take a good look at your existing network. It’s quite likely that you can think of a handful of the brightest technical people who you already worked with within the domain.
Work up the courage needed to pitch your idea to them, even if it seems like they are very comfortable right where they are and you think you might not have a chance of wooing them over to a tiny startup. You never know what they will say.
#2: It’s still all about your network
If you can’t hire from your network, it’s still exceptionally likely that someone in your network, who you’ve worked with in your domain of expertise, knows some ideal candidates.
Your next step is therefore to go deep on your network: Make a list of several folks in your existing network who are likely to know a lot of potential candidates, for example folks who have long experience from multiple companies either in your domain or in closely related domains.
Now, pitch to this list of people. You’re not trying to sell them on joining your company, but you need to convince them of your company’s worth well enough that they will be OK making introductions to valuable people in their network.
Once you have your introductions, it’s time to set up interviews. Since these are folks you either already know or were recommended by people in your network that you trust, the first round of interviews should mostly focus on personality fit, enthusiasm for the mission of the startup, and so forth.
#3: Traditional recruiting
You can try using a recruiter, and/or you can advertise the position, i.e. recruit the traditional way. I don’t necessarily recommend this approach, but if you do decide to try it, then it is higher on the priority list than #4, below.
The major issue with this approach is that there is a much higher chance of making a bad or mediocre hire. A bad hire can spell death for an early stage startup, and it can take months to recover from a mediocre one.
#4: Hire for potential if you can’t get proven experience
The last approach I can recommend is to lower the bar a little bit, and hire a person with less experience but a ton of potential. This is someone you might not be ready to put in a CTO role yet, but who you could see filling a CTO role within a couple of years. Someone smart and driven and very enthusiastic about what you’re building.
You might hire this type of person as a full co-founder who takes a bunch of risk with you and gets a good share of equity, or you might hire them more as an “employee number one,” paying them close to market rate for their experience level and giving them a good amount of stock options.
This could be somebody straight out of university, or somebody with a couple of years experience under their belt. It’s probably not going to be somebody who is already an expert in your domain.
The trick with this type of hire is, one of the more experienced folks in the founding team will need to take on more of the project management and product management than if you find a full CTO type of person. This type of hire will focus almost exclusively on the technical side in the early days, although you are hoping they can grow into handling more areas and becoming a domain expert over time.
I’ve witnessed first-hand how this type of hire can become a full-fledged CTO over time, so don’t sweat it too much if approaches #1 and #2 don’t work out for finding a CTO for your new company, just repeat them to find a more junior person who you are convinced is very talented and highly enthusiastic.
You need a bullshit detector
In the situation described above, the current founders are not technical. Whenever you’re non-technical and are hiring for an important technical role, it’s very important to get the help of an experienced technical person you trust to act as a “bullshit detector” for whoever you’ve short listed. Ideally you would get somebody you trust, who would be a fit for the CTO position (but who isn’t available or willing to join a startup), and ask for their time to do 2-3 technical interviews once you’ve done the first round of interviews.
Use your network
Dig deep in your network
Do traditional recruiting only at your own risk
If you can’t find a CTO as experienced as you’d like, find somebody with the potential to become CTO down the line
Get a trusted, experienced technologist to act as a bullshit detector
The $0 Subscription Startup Stack — Part 1 of 3: Build something and run it
I’ve been building a SaaS startup for a couple of years now, and one of the things I noticed after a few months of operation is that all those small subscriptions I had for various things needed for the operation of the startup really start to add up. We have enough revenue now that those subscriptions don’t matter so much, but there was a time when they were a burden, particularly since we were bootstrapping.
I got to thinking whether it would be possible to build a startup stack with $0 in monthly subscriptions, and after putting together a list of the various tools we’ve been using, and looking for replacements for some of them where you can avoid the monthly subscription, I figured that this would be quite doable.
In this series of three articles, I’ll cover the different areas most startups need some help with, and list tools and approaches all of which have no fixed cost per month. Most of these are completely free, at least up to some decent level of usage, although some of the alternatives I list are zero subscription in the sense that you pay no fixed monthly fee although you do pay a small fee per usage.
Some of the services you use early on have high switching costs. I’ll try to point out tools that are like this, and give my advice on cases where I feel it may be good to invest some money early on to get you on the appropriate tool from day one, rather than having to spend a lot of time switching later.
I’ve spent almost 11 years doing startups (and almost 10 years leading technical projects at Google), but my recent startup experience is primarily from building a SaaS startup, so I’ll be able to provide the most relevant advice on categories of tools used by such startups. Many of the same tools apply to any type of startup, and I’ll also try to cover a few specialized tools other types of startups need, e.g. e-commerce startups, but I’m not an authority on those.
This first article of three will focus on tools you need to build a product and run it. The second installment will focus on how to get your product in front of your users, and how to make sales. The third and final installment will talk about all the other things you need to run a successful business: Accounting, customer support, billing, legal, financing and more.
Let’s dive in, shall we?
Ideation and Validation
Startups typically start with an idea. In this section, we’ll explore some tools and approaches that can help develop your idea, validate it by getting it in front of potential users, and more.
I recommend pitching your idea to potential customers very early, and very often, to avoid building the wrong product or service. Even if you think you’re all for this idea and will do super early pitches to real decision makers at potential customers, take my advice: Whatever the earliest you would feel comfortable with pitching a customer would be, do it twice as early, and do it twice as often as you planned to before reading this paragraph. Here are some tools to help you.
Showing your potential customers a mockup of your product can be a great way to get early feedback. Having a rough design for your user interfaces ready will make it that much easier to explain your vision and get actionable feedback.
The cliché here is that your first mockup should be hand drawn on the back of a paper napkin is actually pretty close to how rough your early mockups should be before you start talking to customers.
Once you get a bit further, sketch-like mockup tools are all the rage. I use Balsamiq, which is a great tool, but it doesn’t have a free version except for a free trial. NinjaMock, which has been featured right here on StartupResources.io for a while, uses a similar style of sketch-like mockups and they have a free plan; the only catch is that your projects on this plan are public.
A similar tool with a different type of free plan is Moqups. Their free plan lets you have just one project, with up to 300 objects.
Another type of mockup is what’s called a design prototype, and looks a lot closer to a finished product although with no functionality behind anything. A very popular tool for this is InVision, and they have a free plan that lets you work with a single design prototype.
Remember, don’t just build your mockups and prototypes. Get feedback from your team or friends and colleagues in the same industry, iterate on your mockup, then go out there and get it in front of potential customers for more valuable feedback.
Your first quite-a-few go-arounds of getting user feedback should be done completely manually and by interacting with real people directly.
The way we did this manually at my startup, CrankWheel, was first to pitch to potential customers, and then as our product started being closer to usable, to do hallway testing. Hallway testing is when you grab people from the hallway and ask them to try to achieve some goals with your product or service while you step out of the room, but maybe record their interactions to see what they get stuck on and why. How to do this could be the subject of a whole separate piece; if you’d be interested in a piece on that, email me to let me know.
Once you’re slightly further advanced, you’ll probably want to use some tools.
A very neat tool is Peek, which lets you get a 5-minute video of a person using your website or app (along with their comments while using it), for free. If I recall correctly there are some limits on how often you can do this, but it’s a very useful service nonetheless, that UserTesting (a very useful but pretty expensive service) uses as a teaser of their full set of paid services. If you can afford them, great, they seem to be a leader in this space, but most startups starting out can get by with hallway testing instead, as briefly described above.
Another great resource is UsabilityHub. They have a $0/month plan and as long as you invite your own testers, using their platform to run tests on that plan is completely free. Using testers from their network is a pretty reasonable $2.50 per test.
I’ll also sneak in Stuart Brent’s UserInput.io. There is no free plan, but no subscription either — it’s pay per use. This could be an alternative to UserTesting but at a much lower price point.
Business Model Canvas
This is less of a way to validate your idea, and more a way to ensure that you’re thinking about the various different angles that might need validation. The Business Model Canvas is a very simple framework for putting a startup idea down on paper and understanding how it’s different, how it will make money, how you will get it in front of customers, and more.
You don’t really need a tool for this, there are lots of free templates you can download and fill in, but if you want a free and simple tool, you could try Canvanizer.
Validation from Investors
One good way to get often quite insightful feedback on your idea is to create a pitch deck and/or demo for it, and show it to some angel investors or VCs, and maybe apply for some accelerators. Even if you don’t get funded or accepted to an accelerator, you should most often get valuable feedback.
I would only recommend doing this if you are actually open to taking in outside funding, or joining an accelerator. You don’t want to burn any bridges you might want to cross in the future by making people feel like you wasted their time.
This section focuses on tools you need to develop digital products. I realize not all startups are built around a digital product, but most have at least a website, which sort of qualifies.
It used to be you would need to pay lots of money for software libraries that you were going to use to build your product on. Those days are gone, with open source providing a free implementation for an incredibly wide range of things. Hooray! So what is left? Well, it turns out, quite a lot.
You may need to find and hire folks to work on developing your product. Maybe you’ve got this covered yourself, or through your co-founder(s) or close contacts that you can recruit, but maybe not.
You need a safe place to keep everything you’re developing, track versions, keep track of bugs, and so on.
You also need to manage your development project, get your product tested, and more.
Let’s start with a couple of tools to help you recruit talent, if you need it.
If you have local talent available and vetted by yourself or somebody you trust, that is often the very best way to start. Perhaps they are willing to work for some sweat equity, or even join up to become a co-founder.
If you’re not in a position to find the very best local talent, you may want to look online.
If you don’t have much time to spend and are willing to pay for the value you get, I would recommend Toptal. They have programmers, designers, and even finance professionals who can help you, and they hire only the top 3% of everybody who interviews with them, and they expect and enforce a high level of quality. There’s a no risk trial period so if you’re not happy with the person they find for you, you don’t have to pay.
If you have more time and are able to take a chance on trying a few people before you find the right fit, then check out Upwork. I’ve been able to find some good talent there at a good rate, but be advised that you may need to work with a few people before finding a strong talent and a good match in terms of ease of working with that person.
Obviously, neither Upwork nor Toptal are free, but both of them qualify for this article as there is no fixed subscription fee — rather, they are collecting a part of what you pay to the talent you hire through the platform.
Developing your product is a project that can sometimes get really complicated, with lots of moving parts and many people involved.
My favorite tool for the cat-herding involved in project management is Asana. It’s like a perfect to-do list that you can categorize, tag, prioritize, and the best part is that it does collaboration really well. Asana has a very generous free plan for up to 15 users in a team.
Taking a slightly different approach to project management, a lot of people really love Trello. Instead of being based on the concept of a to-do list, the base concept feels more like boards on your wall with sticky notes where you can move sticky notes between boards. If you’re doing something like Kanban (we actually do this in my team but we use a real wall and sticky notes…), then it’s a pretty perfect match. Like Asana, they have a very generous free plan with an unlimited number of users and boards, but lacking some features you may end up deciding to pay for.
You need your code in a safe place, off-premises, and you need to be able to go back to any older version of your code. Choosing a cloud service built around a revision control system is the best way to achieve this, and these days the only revision control system I’d recommend you use is Git.
Bitbucket by Atlassian fits the bill. It’s built around Git and it is free for teams of up to 5 developers. I haven’t used it personally but Atlassian is a solid company that’s not going anywhere, and I’ve heard people speak well of Bitbucket. That said…
Your source code repository is one case of a system that has very high switching costs, so I would choose carefully here. My company uses GitHuband we’re very happy with it; if you’re doing open source it’s kind of the industry standard (and it’s free if you only work with open source projects, no proprietary code). If you’re incorporating open source projects hosted on GitHub into your product, it makes it pretty easy to work with those.
Any feedback on Bitbucket vs. GitHub from folks who have used both? I’d love to get your comments.
I mentioned issue tracking in relation to GitHub above, so let’s tackle that next.
You need a place to write down problems that are found in your product, to assign them to people, track whether they’re new, fixed, have been verified as fixed, reopened, etc.
One way to do this for free is to track your issues in your project management tool, e.g. Asana or Trello, both of which I mentioned above. They’re not specialized for this, but can do the job.
Both Bitbucket and GitHub have simple issue trackers integrated. This is probably the way to go to begin with, for most startups.
Switching cost caveat: If you have a fairly large and complex product, you may be better served by going with a more feature-rich issue tracker right off the bat. There are full-featured open source issue trackers available such as MantisBT, Redmine and the venerable Bugzilla, and if you host them yourself, there is no subscription fee, although I’d recommend using a hosted version for peace of mind and simplicity. There are also products such as FogBugz which some people swear by.
Quality Assurance / Testing
The basics of quality assurance aren’t that complicated, even though the work is challenging, especially to find the most elusive bugs. For much of what you need to start, you don’t need any tools aside from your issue tracker and a documentation tool such as Google Docs:
For as much of your functionality as economically feasible, create automated tests to cover this functionality. This helps a great deal to avoid bugs creeping in later, and is a key component of Continuous Integration, which I highly recommend. I say “as much as economically feasible” because for a startup in the early stages, you may be better off spending more time on manual testing and less time on automation, until your product is a bit more mature. Early stage products tend to change a great deal, which gives you less time over which to amortize the setup costs of the automated tests, whereas manual testing has close to zero setup cost, with the downside that the per-test cost is high.
Have a written description for how to test your product, i.e. steps to take to run through all the basic test cases that will cover most of what your product does. Google Docs or any other documentation system is good enough for this.
Create a test matrix of the different platforms your testing should be performed on. Depending on your product this may be a set of browsers and different versions of their browsers, or it could be a set of operating systems and different versions of those. In your test matrix you can specify which
When your product is tested, it should be done based on the written test description, as well as exploratory testing outside of what’s in the written description to try to find new defects in corner cases. For any new or changed features, you should also ask for hints from your developers on what they think might break or need a particular emphasis in testing.
Any time you find an issue, register it in your issue tracking system and decide how to prioritize it, when to tackle it, etc. Your issue tracking system can help with this, for example you can break your releases down to milestones (for example once every 2–3 weeks) and determine which bugs to fix immediately and which bugs it may be OK to defer a little bit. This depends on their severity and how many users they may impact.
Any time you find an issue that you would not have detected using your written test description, take a step to make sure this or similar issues do not come back in the future. Add an automated test that would have caught the problem, or add a test case to your manual test description that would have made the problem obvious in routine testing.
Your initial testing can be done by you and your core team, but I would recommend having a separate person doing quality assurance pretty soon after the ball gets rolling. For one, it’s a somewhat specialized role and folks with experience in it will find more bugs than those without, and for another, you and your development team will become blind to defects in the product, and will do less creative exploratory testing. As for development, I would recommend Toptal if you want to be sure you get a great team member without having to try several times, and if you’re more budget conscious and have more time, you should be able to find somebody on Upwork, but you do need to be willing to take that time and may end up spending a fair bit of money to try a few freelancers before you settle on somebody for the long term.
One key tool that I always recommend for quality assurance of web-based applications is BrowserStack. It lets you run literally hundreds of different browsers on both desktop and mobile platforms right in the comfort of your browser. They used to have some of their features free, but no more (unless you have an open source project) — so I looked around for some alternatives for the $0 Subscription Startup Stack.
One alternative is Browsershots, which is completely free and supports a range of browsers. It doesn’t provide live testing though, only screenshots of your site across multiple different browsers and versions (this is the same service BrowserStack used to have for free).
Another that is now part of my toolchest is the Blisk browser, available for Windows and macOS, which does emulation of multiple devices so that you can view your site for quality assurance, and in fact for development as well. Their free version includes some of the devices they support, and you can upgrade to get more.
Now that you’ve built a product, what about running it? Most digital products need to be hosted somewhere online. Many require functionality such as email, SMS, telephony, and more, that you’re better off buying from a Platform as a Service rather than building and running those functions yourself. Finally, you will need to understand how your users use your products in order to be able to improve it, and for that you need product analytics. Let’s explore each of these areas in turn.
There are several levels of hosting you could go for. The simplest and least expensive level is when you have a simple static page. The next level after that is when you need your own dynamic back-end but can make do with something like WordPress, in which case you need a shared web host. Finally, if you are running a complicated digital product, you will likely want your own custom backend that you might host in multiple geographic locations. In all cases, you may want to use a CDN in front of your site to speed it up and decrease load on your servers.
Static site hosting
My recommendation: If you can build your site as a static site, you should do so. Especially if you’ve got some coding skills. You can do this even with fairly complicated sites that accept user submissions, might have a blog, and more.
For static hosting, I would recommend Netlify, which is simple to use and has a generous free plan. This is what I use for StartupResources.io, which is a static site even though we have various forms you can submit (more on how to do that in the next installment in this series). You can either simply drop a folder on your Netlify deployment in order to upload that folder as a new version of your site, or you can integrate Netlify with GitHub to continuously publish any branch of any repository as soon as you push to that branch.
Another good alternative is GitHub Pages which is built into GitHub, so if you’re already using that it may be a very convenient alternative. I use this for the CrankWheel marketing site and it works really well.
There are many free and easy static site builders that you can use to make a static site feel more like WordPress. For example, when I write a blog article for CrankWheel, I’m basically just writing a Markdown file; no HTML or CSS. The static site builder that I’ve used and can recommend is Jekyll, which takes a set of source and configuration files and builds the static files that get served up for your site.
For non-developers out there, you can still use static sites. Ask your web developer to set up the initial site using e.g. Jekyll, and then use a tool like CloudCannon so that you have a visual, web-based editor for creating and editing blog posts and such.
Many companies offer shared hosting of WordPress and such. I need to do my research on this before creating a full comparison review, but Bluehostcomes highly recommended by many folks I’ve spoken to. While it’s not free, you can sign up for as little as $3.95 per month using this link, and you get more than $150 in advertising value with Google AdWords, Bing and other leading advertisers, which is more than you’ll pay for the first 36 months.
For the most complex needs, you’ll want a cloud hosting provider. There are times when you might want to set up a virtual private server (VPS) rather than do cloud hosting, but in my opinion for almost any reasonably complex product, the ability to grow without switching providers is going to be very important, so I’d recommend going with cloud hosting.
I’ve primarily used Amazon Web Services (AWS), and I’ve had a very good experience with it. I’ve also heard good things about Microsoft Azure (it’s not just Windows — you can run Linux on it too). The most important criteria for a provider to me would be that I have to trust that they will stay in business and won’t cancel any of the platform services that I’m relying on, and both of these companies qualify.
Neither of those are free for serious usage, although both offer a free tier to get you started. However, as a startup you can apply for significant credits with both of them. With Amazon’s startup program, you can get up to $15,000 in credits that are valid for 2 years (even more in some cases), and with Microsoft’s BizSpark program you get up to $150 of cloud services per month for free (along with many other benefits), and up to $12,000 if you qualify for BizSpark Plus.
Content Delivery Networks (CDNs)
A CDN is a great way to reduce the load on your servers, and in some cases can also provide redundancy and protection in case of a distributed denial of service attack (DDoS). If you haven’t already heard of CloudFlare, then you should check them out. Just head over to their site and click Signup, and you’ll be able to add a site for free. Their free plan is quite generous and includes a basic SSL certificate for your site, caching, and various other goodies that can speed up your site. They take over as the nameserver for your DNS. Setup is really easy. I use this for multiple sites.
Platforms as a Service (PaaS)
Transactional emails are those emails your system may send on account creation, password reset, confirmation of orders, shipping updates — the emails your customers definitely want to receive independent of their preference in terms of marketing email.
Don’t set up your own mail servers to send transactional email (and definitely not marketing email — but that’s for our next installment).
Use a service like Amazon SES (Simple Email Service) for sending email. They have a free tier for up to 62,000 messages per month, and pricing after that is not expensive — $0.10 per 1000 messages. I use this for CrankWheel and it’s rock solid, although it doesn’t have all the bells and whistles of Mandrill (now part of MailChimp), Mailjet (free for up to 6,000 messages a month) or Mailgun (free for up to 10,000 messages a month).
A key issue with transactional email is deliverability, a.k.a. not getting your email marked as spam. Once you’ve got your basic setup for transactional email, use the free tool MailTester to get hints on how to optimize for deliverability.
Do you remember life before the Internet? There used to be these things called telephones, which people would use to talk to each other, and a bit later there was this thing we now call a feature phone where you could send short text messages (SMS), it was like Facebook Messenger only without the GIFs.
It turns out, for many products, the ability to integrate with the telephone network or to send text messages can be extremely useful and effective. We use this at my startup to enable sending text message links to screen sharing sessions, and it’s great because it works on all phones.
The platform I recommend for both telephony and text messaging is Twilio. It’s been around for a while, and I’ve personally witnessed text message deliverability improve quarter over quarter for the last couple of years.
If you’ve ever run a webserver or a custom server, you’ll know how useful it can be to view server log files to diagnose problems.
There is a really useful class of services out there that allows you store logs from all of your different servers and machines in one centralized place, visualize them, query them, and create alarms based on them. I very much recommend setting this up if you have a complex product.
The solution I’ve used is Loggly. It’s a solid product, and it has a free tier that will be suitable for many startups.
There are significant switching costs for a product like this. I sometimes wish I’d gone for a metered product like LogDNA, which is priced per usage, rather than going with a plan-based product like Loggly, where I’ve had many months where we were on a plan that was significantly too large for us. I haven’t tried them, but they promise lower rates than Loggly, and much faster queries, which is an area where Loggly doesn’t exactly shine.
If you have a complex product, read this section. If you just have a static site or a WordPress site, wait until the next installment in this series, where I’ll talk about marketing analytics — that’s all you typically need for a website.
Usage analytics are important so that you can see where your users are having trouble, compare retention rates between versions, and more.
Many of you have probably heard of Mixpanel, which was the pioneer in the space of usage analytics, finally making it easy for small startups to track user churn, behavior funnels and more. They have a solid free offering.
The alternative that I recommend is Amplitude. They were first to offer a generous free plan, and although their free plan today allows fewer events than Mixpanel’s free plan, I can vouch that the free version of Amplitude is very powerful and lets you visualize and analyze a ton of stuff regarding how your users are behaving.
We’ve covered ideation and validation, product development, and operations in this installment of The $0 Subscription Startup Stack.
The next installment will cover sales and marketing — how to get your product in front of your prospective users, and how to make revenues from them.
The third and final installment will cover other stuff you need to build and run a startup — customer support, billing, legal, funding and more.
I hope you’ve enjoyed this installment. I’d love to hear your feedback, just email me.
Want to receive content like this, along with weekly useful tools for startups, straight to your inbox? Sign up at StartupResources.io
For the last three summers, I’ve participated as a mentor in the Startup Reykjavik accelerator programme. Today, I was honoured to be voted by the 2014 alumni as “mentor of the year” for last summer’s programme.
I was asked to give a short speech for the occasion, for the mentors who are participating in the Startup Iceland accelerator this summer. I gave the speech in Icelandic, and it is available in its original form here. What follows is an English translation:
I’d like to say a few words about what it is like to be a mentor, and in particular about being a mentor in the Startup Reykjavik accelerator, which I’ve participated in from the start.
I know many of you are experienced mentors, from Startup Reykjavik or elsewhere. For those of you who are getting started, it might make sense to talk a bit about what it is like in practice to be a mentor for Startup Reykjavik.
Usually, the way it has worked, is that at the beginning of summer, you let the organizers, Klak Innovit, know what dates you are available, and they will book mentor meetings with most or all of the ten teams participating in Startup Reykjavik.
You then meet each team individually, get a short presentation, and try your best to give them some useful feedback based on this first encounter. You follow this up by deciding which teams you think you could and would like to help, and this often ends up not being more than one or two teams per mentor. Of course, it can take several meetings before the mentor-mentee relationship clicks with one or more teams.
After this initial process, your communication is more directly with the teams you are taking under your wing, to organize meetings or use other communication tools. But at the start, it’s great if you can meet as many teams as possible, to be able to make the best selection.
Often, you can help a team in a quick way, for example by making connections for them within your network, even if you don’t intend to take the team on as a mentor. This is another reason to try to meet all the teams, or as many as possible, at the start, even if you don’t expect to be able to be an effective mentor for particular teams.
In addition to the organized meetings, Startup Reykjavik has several open events such as barbecues where you can meet and chat in an informal setting. These events are tremendously useful as a venue for helping a few teams outside the ones you are mentoring in an informal way, and to get to know the teams well enough to pick one or two to mentor. I strongly recommend that mentors show up for these events. Apart from being very useful, they are a lot of fun.
In fact, I think more opportunities for informal meet-ups between the teams and the mentors would be great. Some of these could be more low-key than the barbecues, for instance just an afternoon to grab coffee at the Startup Iceland offices. The informal events are one of the best ways to create personal relationships that can last much, much longer than the 10 weeks the accelerator is ongoing.
Once you have established a mentor-mentee relationship, I’m pretty sure that it’s largely a question of personal style which modes of communication are suitable. All of the classical modes are available, such as meeting in person, using the phone, email etc. I’m willing to bet $10 that some team this year will use Slack to communicate with their mentor. Any takers on that bet?
For my part, I’ve found it most useful to engage in real-time communications with my mentees, either in person or over the phone or via Skype. While email and instant messaging can be great for follow-up or for classical management, being a mentor is not being a manager. It is much more about reading between the lines, seeing how your mentee is feeling, and hearing from the tone of their voice what it is that really worries them or that they’re unsure about.
This brings us perhaps to what it is fundamentally to be a mentor to a mentee. Is it like the relationship between a teacher and a student? I don’t think so, because a teacher usually has significant control over the path the student must take.
In my opinion, a fundamental tenet is that as a mentor, you must let your mentee take their own decisions, choose their own path, and shoulder all of the responsibility for their choices. When mentoring an entrepreneur, you must let the entrepreneur be the entrepreneur and remain firmly in the driver’s seat; the mentor should never assume that role.
I think a mentor should also expand the mentee’s horizons both outwards and inwards. Outwards, by pointing out other paths that could be taken, and possibly recommending one path above others, even though your mentee should always make the final call. Inwards, by helping the mentee recognize their own weaknesses or unscrutinized basic assumptions that might be hurting their decision making or prioritization.
First and foremost though, a mentor is someone who shares their experience in a meaningful way. Experience that could have come about from making their own mistakes, or possibly from being challenged by a mentor in their past. Any kind of experience counts, as long as it has bearing on what your mentee is doing or going through.
This is why it’s best to find an individual or a team that is working on something that you truly have insight into, something where you have meaningful experience you can bring to bear. Relevant experience and a strong desire to help the person or team in question is what makes us great mentors.
Let me end with a thought for all the mentors here. It’s a well known fact that investors, unfortunately, have a strong bias to invest in teams composed of entrepreneurs that remind them of themselves. This has meant that for example in the US, teams composed of white males from privileged families who studied at Ivy League schools, have had a much easier time getting funded than other teams.
Can we all join together to not let the same thing happen when we choose teams to mentor? Everybody, or at least most people, has unconscious biases that they’re often not even aware of. To reduce the impact of these unconscious biases, we can be mindful of how and why we are making our decisions, and try to consciously nudge them in a direction that hopefully reduces the impact of our biases.
I therefore encourage all mentors to pay special attention to teams composed of individuals who are different from themselves. That way, I think we will all learn more.
 The organizers of Startup Reykjavik have since informed me that there will in fact be quite many informal events, almost one per week. Yay!