Episode Description

In the first episode of Listen Ship Repeat, Thanasis and Dimitri talk about team composition on the early stages of a startup.

Episode Notes

Episode Transcript

Dimitri [00.13.00]: Are you an entrepreneur? A designer? A developer? Never before has it been easier to get your new venture off the ground. Whether you’re just getting started, or have already begun your journey, you’ve come to the right place. In each episode we will dive into a new challenge, breaking it down into simple digestible terms. I’m DImitri.

Thanasis [00.00.30]: And I’m Thanasis

Dimitri [00.00.31]: And you’re listening to Listen-Ship-Repeat and this is episode No.1

Dimitri [00.00.46]: Hey there Thanasis, so we’re finally here! Our first episode!

Thanasis [00.00.50]: Yeah, finally! I’m so excited. We’ve been organising this for quite some time. Right?

Dimitri [00.00.55]: We have, yes! So what are we going to be discussing today?

Thanasis [00.01.00]: Today we’re going to be talking about team composition. You know… How many people you should have at each different stage of your Startup, starting out as an idea and then moving on up to Series A funding and beyond.

Dimitri [00.01.20]: Awesome! Let’s tell to the people that are listening to us a little bit about ourselves. So, Why don’t you introduce yourself Thanasis and tell a bit about you and what you’ve done.

Thanasis [00.01.33]: Alright, so I come from a technical background. I’ve been in the high tech industry for over 20 years. I’ve started and resolved many startups on my own and worked for other startups as well. Currently, I have been doing contracting for the past 5 years, remotely, mostly in CTO capacity roles in startups, taking them from 0 to 10. In the background I have been running my SaaS business, my startup, for the past 2 years and hopefully we’re going to have the chance to talk about that later on. What about you Dimitri?

Dimitri [00.02.05]: Same, high tech background. I’ve been working for startups for a while now, more than 10 years. I’ve also founded my own startup, I used to have a gaming startup for the iOS, one of the first that appeared for casual games. I used to work on that for a couple of years, it was a bootstrapped, self funded startup. Later on I went to work for a freelancing marketplace, where I founded the mobile app arm of that company. I was a lead developer on that and also product leadership until we brought that to market. Most recently, I’ve been working lead development roles, and currently I’m working for a shipping startup, as a lead mobile developer. So that’s pretty much it!

Thanasis [00.03.17]: Alright, so I didn’t define my role. My main expertise today is on “Node.js”, I’m primarily a back end developer, although I lay my hands on front end applications. So lately I love React, we’re gonna have the chance to talk about that too. Now let’s talk a little bit about the scope of the podcast. Dimitri, what’s the idea here?

Dimitri [00.3.46]: We’re are gonna be discussing about what issues a founder might be running into, when they would like to begin a startup business on the internet. The way I like to see it, is the operations of your podcast and the analogy I’d like to make is to view the startup operation as a production line, perhaps. At the beginning your production line is the conception of what you’re making, your product and what you have. Along the production line you are enriching your product experience and at the end of the production line you have the complete product, which you will be able to finally and happily ship it to your customers and I’m sure they’ll love it.

Thanasis [00.04.30]: Awesome,Yeah! We are great podcast fans, both of us, we’ve been listening to podcasts for many years. The idea here is that we are talking about startups from their technical approach and not from a marketing standpoint, there are more than enough podcasts around that subject. We are exploring the technicalities of a startup from our point of view as lead developers, as very specialized developers and to that extent we want to explain to non technical founders the challenges that come with starting up. So, this podcast is primarily directed at non technical founders that want to have a good understanding of the environment they are going to get into, the market, the industry and of course developers and CTO’s can benefit as well by listening and exchanging ideas on architecture and how we approach stuff. So, your input to whatever we’re saying is always welcome to that end.

Dimitri [00.05.51]: Okay, then. So let’s look at the overview of what we’re discussing tonight. You mentioned before the prototype, the funded stage and the Series A. If you’d like to say a quick point for each of these stages, Thanasis and then we’ll move onto the specifics and the analysis of each individual stage.

Thanasis [00.06.15]: Right, so when we’re talking about team composition we have to specify the stage in which the company is and let me be clear about team composition, this is the team that you’re going to hire so we are approaching this from a financial perspective considering the expenses that are going to incur by building a team into different stages. These stages are pretty broad, but I think that everybody can relate to them. The first one is the prototype stage where you build something scrappy that is a proof concept of what you’re saying, so that you can convey your message. The second stage is when something that what you’ve build has convinced somebody enough to fund you are now in the struggle for product market feed with your product. Once you have achieved product market feed, you are then in the grow stage, which means that you have also secured a series A round of funding. So we have these three distinct stages throughout the life of a startup, of course there are always exceptions and different paths, but more or less these are the three stages a startup has to go through.

Dimitri [00.07.50]: Okay. In addition to all these there are staff that apply to all stages. Let’s talk about that.

Thanasis [00.07.57]: Yeah, right! So there are some things that everybody should be aware of, if they are already not. For instance hiring developers is extremely hard and becomes even harder as the demand grows more than the university skills offer, so there is a very big deficit there, in talent and that is something that you should be aware of, that you should take under consideration and understand that this changes your position, let’s say your marketing position or how it will work for you to build the team that you want. To that end, you will have to make a very lucrative offer to attract developers and this, I have to say has become harder than ever as developers have gone through startups for the past five to ten years that we are experiencing a second golden age after the 90’s in the “.com” industry. Many developers have gone through the startup grind, working many hours for very low salaries with ultimately no reward - because let’s face it, having a startup succeed is one in a thousand chances - so for the rest 999 companies that developers worked for they probably didn’t have a good experience. So you are going to have to play that flout a little bit stronger, a little bit better in order to attract the kind of talent you will need to build your startup.

Dimitri [00.09.47] True! Actually a great point about the universities, I haven’t looked at a syllabus in a while, but the way staff comes in and out of existence constantly I’ll be very curious to look into that, exactly what they’re doing these days in schools and universities. In addition to what you said about the startup experience, I’d like to mention, hiring developers is hard like you said. One of the things that you will be dealing with is turnover, people coming and going. If you build a good enough culture and you keep your people happy enough you won’t have to deal with that phenomenon, but nonetheless from my experience even in the best environment people tend to move on. Some people tend to panic with that or don’t know exactly how to handle it. I just say it’s a reality that you have to deal with, it’s part of the process. So in that case don’t panic, try to captivate and document the culture so people can hand over the staff easier. Treat them well, if you treat them well enough they probably won’t leave in the first place, but if they do, they might give you ample time for notice and replacement. I’ve certainly been that person in my career so far, there’s a plus side to that, building relationships, building a network, as you never know when you will run into each other again in the future.

Thanasis [00.11.35]: Yes, absolutely! Roles do change overtime, you might be a CTO today but you never know in five years how things come, what life holds for you. Even Though, it seems like an old brainer you have to be a nice guy, because this is what you are going to receive as a behaviour, unfortunately this isn’t always the case and here is something non tech founders, people that are coming into the industry, have to understand. Developers, tech people, marketeers, support, everybody are inside the technology, they are highly networked people, they constantly communicate, they blog, they tweet, they use the leverage of social media. So, if you are anything other than a kind, good, fair person and boss it is going to show, it is going to be talked about and the community is smaller than it seems. That brings us onto the culture that you are going to captivate, and this is something that bonds down to you, your character. This is something that you have to be working on constantly in order to be able to pass it on to your first, second third highers. Let’s face it, the choices in personnel as your first, second, third highers are your choices and they are going to play a very significant role in the company culture. For example, if you grow up to one hundred people, the first five or ten people are the ones to pass on the light to the next ninety people, so everything really starts with you.

Dimitris [00.13.43: Nice! That gives a nice overview, so let’s move into more specific staff. So, like you mentioned earlier the first stage is the prototype stage, it’s something that is barely working. There’s a point in the life cycle of your product where the wires are hanging and if you touch it, you might electrocute yourself. If you’re making an instagram app, the heart of the ferry will function and you will have one filter. So, having said that, what you’re looking at this stage is as quickly as possible to get somebody onboard. Hire for the present, hire for now, because maybe you won’t be around in a couple of months, which is a possibility statistically as you mentioned earlier, Thanasis. This brings us onto the point that you have to hire for your immediate needs, for what you want to build now, not necessarily based on what qualifications people have. That will help you down the line and make sure that you won’t lose your long term vision, which always exists, but for now preferably somebody who has built something similar before and if not something similar, maybe something in the same market that you’ve worked on. Somebody that can start right away and build something functional, which is your prototype.

Thanasis [00.15.16]: Right, exactly! Just to add on top of that, I had many examples throughout my career where that happened. For instance, a startup that wanted to do a chatting application, which is a real-time thing and actually wanted to mix real-time video into that. It’s original job advertisement was for a WebRTC technician, which is the underlying technology that enables real-time video conference calls by just using your browser. But what they should really be looking for is a well rounded developer who could build their first prototype, because if you’re going to get that highly specialised WebRTC engineer, most likely he won’t be able to do the full up and down work that’s required for a prototype. To that extent, the advice here is that first off you’ll need to hire a good developer and secondly a developer that can deliver you the product that you need, front and back end. In the web development world we have the back end, which is the server, the service and the front end which is the application code which runs on the browser. Those are two very distinct specialties in the world of web development. However, there are people that can fluently do both and that’s the kind of people that you should be looking for in order to build your first prototype. So, since we are approaching this from an economic standpoint, for the prototype you shouldn’t employ more than one developer. Just focus on that one platform that you believe you have the most chances to penetrate, rather than going for a “I’m going to everything, I’m going to do iOS, android, windows, etc.”. This isn’t how it works, stick to a single developer, who’s well rounded and can deliver everything that you need. Also be sure that if you find a junior developer, just keep in mind that they have some kind of supervision. So if you are a non tech founder and you are on a budget, you’ll have to hire a junior developer. However, junior developers are not qualified to build an application from the ground up. They simply don’t have the experience to do that, they don’t understand the architecture, the infrastructure involved, because they simply haven’t done it enough times in their lives. As such, unless your product is something that you want to make a prototype on, through it away and then rewrite it. You want to hire somebody that knows what they’re doing and I’m not talking about a second hire, this is a part time hire, this is the outsourcing part that you should be doing. For instance you should outsource design at that stage. So, you outsource the architecture and quality of your code, of your product. You can’t redo it at a later time and I’m not talking about more than three or four hours per week of a senior developer keeping tabs and synchronizing with the junior developer that you have.

Dimitri [00.19.23]: Your senior developer, if you’re up to select one in a supervisor role, you can look at getting somebody part time and depending on how much funds you have at this stage, having someone highly specialised, highly skilled, with a high seniority level, you should probably be looking for a part time person for that. Your full time person, your single developer, again somebody that will be with you every day would be somebody with less seniority, but again it depends on how much conversation you are willing to offer and in your prototype level you are looking to hire somebody for a very short period of time. A contract for a defined period just enough to get your prototype up and running. After that you can continue to cooperate with them or switch to the other two options that I just mentioned. At this stage it will be interesting to mention where to find these people. From my experience, I work a lot with my network, which I have built over the years. I’ve certainly had roles where I went through the entire recruitment and interview process and was selected in the end, which is great and a large percentage of employment is still found like that, but I’ve also been into positions where I knew somebody and I got onboard right away. I obviously had to speak to a few people, but I had somebody vouch for me. In reverse I had great experiences vouching for other people and bringing them onboard fairly quickly because I knew them and they were great additions to the team. So the larger thing you have to consider here is, depending on where you are on your career, let’s say you’re starting out and you are on of the younger people in our audience, like you said Thanasis before, be nice, don’t burn your bridges and getting to know people doesn’t stop at the end of your current role or at the beginning of the next one, you can always tap into them. So it will always be nice to look them up when you’re first starting, at the prototype stage in this case. If you went through your network or if you don’t have a network you can also look one degree further out and find somebody that one of your contacts knows. So looking at people that you know or people that know each other and that falls back to what I said previously, if you know them you can vouch for them or if somebody that you know and you trust can vouch for them it’s pretty much the same thing and it works well.

Thanasis [00.22.46]: Absolutely, network is the most important thing, that’s what you should be building and working on from day one, the moment that you want to enter that industry. If you don’t have a network you are twenty steps behind. Also, when you are out there looking for somebody to hire and you don’t know anybody, then you only choice is to hire someone that has some kind of social proof so you can check them out, you know, their social networks, what they write, what other developers think of them and that would be your senior developer that you would hire on a part time basis as a consultant to help you hire the people that you need. The other solution is to go with an agency, but those two choices are much complex and many more things have to be said about them, which would require another episode just for that subject. So let’s move on to the next stage, which is…

Dimitri [00.24.01]: The funded or the prior to the market feed stage. It’s when your startup has just grown out off the prototype stage and you’re well equipped now, you know, staff is real.

Thanasis [00.24.12]: Right! At that stage you are building your first developer unit, so let’s stand here for a moment and explain what a unit is. We call it a vertical unit, because it employs all disciplines of web development. So, a unit is a team of five, six, no more than seven people of different specialties. You have a guy, or two, working on the back end, you have one or two developers working on the front end and depending on the product’s specific characteristics and target audience, if it is a website or a mobile application, you beef up more the front end part or the application development part. Dimitri will explain this to us a bit more. You also include in the team a designer, a person to do the QA (Quality Assurance) or you can share it between other teams so it can be a department on its own. However, it’s better if the QA is attached to the team so they can get to know each other better, they develop their own code of communication and so on. So, this is what we call a vertical unit, there are one or two developers on the front end, one or two developers on the front end, a designer and the QA. Now, if I may recall David McClure from 500 Startups, what he said is that all a startup needs is a hustler, a developer and a designer, which is kind of true and this is true for the prototype stage and that’s why you only, need one developer. The hustler is actually the CEO, that’s what their function is. You’re going to need a designer, who will give the kind of quality of design depending on the market that you are addressing. If you are a consumer product you need top of the line design, you stand no chance otherwise. If you are a B2B, depending on the market, design may not matter that much. However, having an aesthetically pleasing website always gives you extra points in whatever goal you may have. So, that’s it. I think we’ve explained what a unit is, and this is what you need to build at the product market feed stage and things are starting to get more complicated here. So Dimitri, what if we’re talking about a mobile application?

Dimitri [00.27.21]: It could be a mobile application, it could be a desktop application, it could be an embedded application and it could be an IoT (Internet of Things) application, that’s where your app developer comes in.[27.40] You’ll have to pose that against the front end developer that you mentioned earlier, Thanasis. So, we’re funded, but we’re not the richest startup there is, so you have to make that choice between the two and that always depends on the application you are building. If you feel that you can get by it with your front end web developer go that way, if you feel that you need the app developer go something native or even if you startup isn’t web related at all you can go with your app developer. Design is very important. I think you were very right about what you said earlier. You can’t have a consumer product these days, without it being beautiful, I think that’s part of the course. Now, with your enterprise app, it’s not the end of the world if it looks like, craigslist or something, which I still think it’s functional, but I think there are a lot of enterprise startups these days that focus a lot on design also. So, your designer will be making your newsletters, your landing pages, will be responsible for your redesign, your branding in case of applications that have been integrated into the app development and design process. I’ve worked with the designer very closely on a day to day basis these days. QA was brought up, often misunderstood, I see it as an important role, but definitely not something that could be seen as a luxury for some people. If you are serious about what you’re making and you want it to be at a very good level, at least when it comes out, so you’re not doing from day one, it will be nice to have a QA process. As a matter of fact, talking about CEOs, this is something that could be done by the hustler earlier on this stage, if the development skills aren’t the strongest point.

Thanasis [00.29.58]: Right! Since we’ve gone over what is a vertical unit and what team you are going to build, let’s talk about how you are going to build it. I want to point out that you cannot make jumps, you can’t go from point A to point Z, you have to grow the team naturally, you can’t go and hire five developers at once. This has to happen in a step by step process. Up until now you had a single developer, your communication was ad hoc between you two, there weren’t any procedures in place, everything happened spontaneously. However, after your second or third developer you are going to need processes, operations, like how do you onboard the new developer, it’s not as simple as “here’s the code base”, you have to introduce them to the infrastructure that has already been created, the databases the project dependencies, there are a lot of stuff and without proper documentation and checklist, this can take many days. I’ve been hired from companies with no procedures at all and it took me up to a week to set up my development environment. Whereas, if there is a checklist which is very well and strongly documented, it can take no more than three to four hours. So, this documentation has to be built, it’s part of the process of scaling your team and from here on then you start to have the issues of what we call codebase scaling and this is where the quality of the code starts to come up. If up to this point the junior developer has been unattended and has created implementations of his own imagination that nobody can relate to and they are written in a way that only the one who wrote them really understands them, then the new developers coming in are going to have a very hard time familiarising with the codebase, so they can be productive. Even though, these things may seem neglected, they really matter because at the end of the day, time wasted is money wasted and while startups may have money, they don’t have time and this is very critical. This is the moment when the decision of choosing a CTO comes, because 99% of building the operations, the procedures, the documentation, onboarding, the development operations, you know, how is the codebase by the time we finish with it, we submit it and push it to the servers it gets actually deployed on production, all of these operations and procedures are going to be defined by your CTO. If your CTO hasn’t done that before and doesn’t know how to do that, then the rest is going to be chaos and you are going to have problems, you are going to feel desperate, like there’s no solution to your problems and when things break and get fixed and break again and again, you reach to a point where you cannot move forward any longer. This is the point that you don’t want to be in, this is the point where I’ve been stressing out all along today. You cannot trust a junior developer to build your infrastructure and your product, they need supervision and this can only happen through a senior developer. If you manage to have him onboard from the beginning then he would be your choice once you have money, to choose him as a CTO. Isn’t that right Dimitri?

Dimitri [00.34.24]: It is! I will just say that like life, even a startup is a learning process. I’m sure we’ve both come up with stuff we haven’t dealt before and just because we have a certain degree of experience, maybe that allows us to navigate ourselves and learn stuff easier without “drowning”.

Thanasis [00.34.55]: Right! So, Dimitri consider this… We’ve been working for other companies right?

Dimitri [00.35.03]: We have.

Thanasis [00.35.05]: That’s our training right there and today even if we didn’t have any CTO roles or lead development roles and would go on and do it for the first time, we would have seen something, we would have some ideas of how these things work based on our experiences from the companies that we’ve worked. Right?

Dimitri [00.35.26]: True! You are hired for a role, but you always try to learn and absorb the world around you. Even if you’re not paying attention and you’ve been in an environment long enough, you will learn.

Thanasis [00.35.47]: Sorry for interrupting you, but the number one problem with juniors is their overconfidence. It’s the fact that they don’t know what they don’t know and they so confident about themselves that they are going to say you the world. You know, “Yeah we are going to do it” or “Yeah we can do it”. Have you noticed that before?

Dimitri [00.36.10]: Absolutely.. When I look in the mirror.. (Laughs)

Dimitri [00.36.13]: Despite what you’re saying, I like that confidence. That particular junior, straight out of school attitude. Thanasis, we’re mid to late 30’s. When I was at Uni, I pretty much learned everything new at Uni. The internet world wasn’t in the developed form that it is today. Junior developers these days, will know a lot of stuff, will have a lot of encyclopedic knowledge. What they lack in experience they’ve made up in..

Thanasis [00.36.55]: Stackoverflow…

Dimitri [00.36.56]: Stackoverflow, exactly or maybe they’re not happy with the curriculum at school. I’ve certainly seen situations where people take it upon themselves. I’m sure they don’t tech react or swift at schools these days, you have to get out there and learn them on your own. In this case I would say that probably one of the best things you could do at this stage is, be diverse. Approach each level separately, be as diverse in you team as possible in terms of your skills set. Look at people that don’t have a high degree of overlapping skills and great things will happen. People will complement each other much better this way. A small degree of an overlapping skill set though would try to get people easier out of a dead end before they log into their stackoverflow account. Okay, let’s move on. You’ve got your Series A really quickly, it’s your first institutional money, you’ve dealt with your high net worth individuals, your angel investors, maybe you’re bootstrapped, but at this stage you’ve convinced somebody to fund your startup.

Thanasis [00.38.39]: And that somebody isn’t just “somebody”, he is a venture capitalist. Which means that you now have at least two million dollars in the bank and what you have to do is take the unit that we’ve mentioned in the product market feed stage, take that unit of vertical engineering front and back end, the designers and the QA person and multiply it times five. Times three, times ten, I don’t know. Depending on what your runway is, the money in the bank and how long you want this money to last you. From here on, it’s a very simple equation. Money in the bank times how many things we can afford and then you can figure out how long that will take you and of course at that point you would pretty much have a very good grasp and understanding of the game, so that’s the reason why you wouldn’t want to dive too much into that stage. This is the point where the product managers are introduced for the first time. Up to that point the product manager role had been shared between the CEO and the CTO having some check and balances there between the vision of the founder and what is technically possible within a specific timespan and given the specific resources. So, from here on now, on Series A you’re going to have your first PMs, those are highly specialised people that are going to cost you even more than a developer, so consider that as well. I mean, by the moment you reach there you kind of have made it, so feel nice about that.

Dimitri [00.40.47]: Absolutely! Okay, I am going to summarise what we’ve covered tonight. Three stages until you get to what we’ve just talked about. Your very first stage is your prototype stage, with your one developer, your journey man if you may. If things went well enough you got some funding from angels, high net worth individuals and you build something that fits the market you’re operating in. Then you have five people in the roles that we briefly described earlier, from the bottom of the back end and all the way up to the designer and the QA with a front end and an app developer in the mix. Once you’ve successfully moved on to the next stage and I heartily wish that for you, you take that vertical stack of people and you multiply it, three, five, x times and best of luck!

Thanasis [00.41.54]: Yeah, right! That’s the idea here. So, thank you for listening! Excuse any mishaps, this is our first episode. We are going to get better and we hope we hear back from you, of what you think and if you have any questions.

Dimitri [00.42.06]: Yes! So send us your questions by calling us on +1 866-370-5050 from anywhere. Email us at hello@listenshiprepeat.com. Subscribe on iTunes by searching for our podcast or visit our website www.listenshiprepeat.com. If you like what you listened to, we would love to see you come back. You can leave a review for us on iTunes, the more stars the better. You don’t have to write a review. You can just give us stars. That helps our podcast be discovered much easier, as we move up in the rankings.

Thanasis [00.42.50]: Do that!

Dimitri [00.42.51]: Indeed! So, thank you for listening and goodbye.

Thanasis [00.42.54]: Goodbye.