Episode Description

In this episode Thanasis and Dimitri talk about how to scale your tech team.


Dimitri [00.00.10]: 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 items. I’m Dimitri…

Thanasis [00.00.22]: …And I’m Thanasis.

Dimitri [00.00.26]: And you’re listening to Listen-Ship-Repeat, this is episode Number 7. In this episode we will talk about “How to scale your tech team”.


Dimitri [00.00.45]: How are things Thanasis?

Thanasis [00.00.46]: Alright! Lots of things going on. Next week I’m traveling to Athens giving a talk on freelancing for top tier developers, high end contractors, how the market operates, how you can do it..

Dimitri [00.01.02]: I’m sorry to interrupt you, it’s episode 7, not the other world. Episode number “007”. Okay, so you’re going to Athens, yeah..

Thanasis [00.01.15]: Greece.js meetup, everything javascript there.

Dimitri [00.01.24]: Okay, what are you talking about there?

Thanasis [00.01.25]: I talk about, like I said, high end contractors. So, I’ve already done multiple presentations in regards to freelancing and I have covered all the basics on how to get started and rise your way up and this is the final chapter, let’s say, in those series.

Dimitri [00.01.55]: Cool! For me it’s towards the end of the year, I’ve been doing the usual reflection staff about how it all went and it’s been good so far, but maybe next time, before we get into our main topic, we’ll discuss about what we’ve achieved for 2017, throwing that out there.

Thanasis [00.02.22]: That would be awesome, 2016 was very bad for me, I mean it was a make or break year and everything broke, multiple times.

Dimitri [00.02.33]: For me it was okay. Actually it was one of the few times that I followed through some of those resolutions that we make. I really wanted to start writing stuff on the internet and I did that. Actually I joined the gym a couple of weeks ago, which was the twilight of the year, but I kind of made it and I’m looking forward to what next year will bring. So, what are we talking about tonight?

Thanasis [00.03.08]: In this 7th episode..

Dimitri [00.03.13]: Yeah, in this 7th episode, we’re talking about how to scale your tech team and before we get into what that actually means in detail, it’s important to point out what’s the turning point on when to scale your team.

Thanasis [00.03.36]: The “When”.

Dimitri [00.03.37]: So, you’ve built something, you’ve hired your first team members perhaps, you’ve build your first product, it’s out there and maybe you are contemplating that. Maybe you’re contemplating when to actually begin, so I would say a good turning point for that would be when you’ve achieved product market feed. What that means, is that you’ve built something that satisfies a market need out there, people are using it and based on that you’ve achieved a customer base, revenue, sales and money coming in. So, maybe you’re funded or maybe you’re making money, so it’s at a point where you want to be able to say, okay, I’ve built something which doesn’t satisfy my vision 100%, so I have to scale my team, build my team, get more people in here, in order to realise that vision.

Thanasis [00.04.50]: Sorry for interrupting, just a small note here, the reason you want to do that when you have achieved product market feed and be rest assured that you are going to understand when that comes is because, at that point you know the exact direction you want to take. Before that you are experimenting you are testing the water, you are trying things out. Once you have nailed this and you know exactly where the market is and how to exploit it..

Dimitri [00.05.25]: Maybe you have pivoted a couple of times, too.

Thanasis [00.05.28]: Right, so you don’t want to pivot with a heavy load right?

Dimitri [00.05.31]: You are at a good place basically. In my point of view, product market feed is a great stepping stone to really launch into the future.

Thanasis [00.05.41]: And of course, the funding factor, that you have enough funds in the bank or a “promised” income, expected income rather, to be able to support that scaling. You cannot fall short in the middle of the way.

Dimitri [00.06.02]: Absolutely! So, once you’ve reached this milestone in your operation is there anything you should pay special attention to?

Thanasis [00.06.14]: A lot of things. But let’s get some notes on the disadvantages of scaling a team. A very good analogy that I found which works well with this is everything naval. Consider a fast speedboat which is agile, fast, has very high 10 degree, can do a 180 in seconds and the more people you put on that boat and the boat gets larger, the more momentum you gain and the harder it is to turn, the harder it is to develop speed, the harder it is to stop and look around. You start to gain momentum, so a fully loaded tanker can require up to 5 miles to come to a complete stop. That’s something you’ll need to consider, you are going to stop being flexible and you are going to gain momentum and push on towards a very specific direction that you must know that must be taken.

Dimitri [00.07.29]: True! In real terms what does that mean; it’s very easy if you with just one or two people to go back to the drawing board, but if you are five or ten people and so on, it’s extremely difficult, because you have to communicate that.

Thanasis [00.07.43]: Right, every cross direction is going to require a month to perform, versus days.

Dimitri [00.07.48]: Okay, I don’t know exactly how that worked with empirical evidence , but I’d be curious to see if somebody would turn up with a mathematical formula that takes as an input the number of people and it outputs the time something would take.

Thanasis [00.08.04]: Not sure exactly if something like that would work, but, you know..

Dimitri [00.08.13]: I wouldn’t call it exponential though, I would say it’s fairly linear. I’m just pointing that out, so don’t be discouraged if you have to pivot because at the end of the day what does product market feed means, it’s not something that you can sit back and relax, a competitor might come up with something better that you and you might lose that, it’s not here forever, so you might have to do it. So, don’t be discouraged if you have to, all I’m saying is that it will be more difficult when you’re first starting out.

Thanasis [00.08.46]: That’s right. So, let’s examine what scaling you team means and we have broken it up into three main categories. The first one is from 1 to 5 people, this is more the hands on process by the CEO and the CTO, there are no established procedures. We have discussed this in depth in previous episodes of ours on how to start your tech team, how to set it up, so we’re not going to dive much into this category.

Dimitri [00.09.33]: We might reference the episodes in the show notes, because honestly I can’t remember what the episode was, but check out the show notes and it will be there.

Thanasis [00.09.40]: Right. Second category is from 5 to 10 and this is the part where the company starts to need the first processes and procedures on interviewing and onboarding. As the new developers come in they need to start getting oriented with the code base, you have to have some kind of interviewing procedure, because if you have to hire 5 developers you are going to need to interview at least 30 or 50. So, this is a very special period in the life of the company scaling up from 5 to 10, basically from a very small team that used to work with ad hoc communication and everybody was in the same room or even remote, but they were really close and everything they built, they built together, so they would understand the stack completely, so it’s the next highest category that we’re talking about. So, the third one is from ten people onwards and then of course you will need very well established procedures, interviewing, onboarding procedures, probably bootcamps, educational courses, or whatever. This is actually what we are going to dive in.

Dimitri [00.11.05]: I have a question for you; Ten people onwards, is there an upper limit or is it, like to infinity?

Thanasis [00.11.11]: Well, I guess we could put a limit up to 50, because upwards that number, things get even more part of an organisational universe.

Dimitri [00.11.27]: It’s not a question to scale then, you are basically into running a big business.

Thanasis [00.11.33]: Yeah, it’s running a big business and the procedures the procedures that you have established in the 10 to 50 people are the ones that are going to be used, to multiply that times hundred.

Dimitri [00.11.47]: And you might have divisions within the company that might be popping up.

Thanasis [0011.49]: Right, yeah. You are going to have proper divisions you are going to have a char.

Dimitri [00.11.54]: Okay, so we are going to be saying stuff like, how to scale from 10 to 50, which probably makes sense if you are listening to us.

Thanasis [00.12.03]: So, the important factor here for us to see is the transitioning, isn’t that right Dimitri?

Dimitri [00.12.12]: Yeah, it exists as a tiny specific point in time, you have to do it once and I like to see it as something, I mean I’ve brought it down to a couple specific things that are happening. When to scale and how to scale is actually this transition and from my experience. I find that when you are in the early product market feed stages everybody is doing everything. You might be doing multiple things, you might - as a developer - find yourself to be doing stuff that aren’t inherently your role, if you are a designer you might find yourself to be doing commits on the front end for example, a CTO doing other stuff other than putting the team together or hiring people.

Thanasis [00.13.10]: As CTO you are actually writing code.

Dimitri [00.12.11]: It’s been know for CTOs at the level we’re talking about, getting in there, know and then. But definitely you want to see the CTO of a company writing code for example, just as an example. So, the focus has to narrow, you are the founder and it’s your responsibility to focus on what the role is really about and be focused on that in order to carry out the vision, right? So, you are going to do a bit of everything or wearing multiple hats, to a single hat. I’ve seen that sometimes, that might be a pushback for some people, because they might have to give up responsibility but the bright side is that, if you work in a startup and you are starting to scale you are not really giving up, you are giving up on the one side and you are picking up a lot of stuff on the other side as your responsibility will be going up on the domain you are working on. Once you’ve established that and I don’t think it’s black magic to establish that, it’s just communicating that to your team and letting them know about what’s going to happen in the future, that the company scales and this is what we need to do.

Thanasis [00.14.46]: In Classical business literature, this is called the “Change Management - Managing Change” and all classic rules apply, communicating-communicating-communicating, this is what it’s all about.

Dimitri [00.15.01]: You are probably saying communicating as a running thing in this podcast, I think we’ll be talking about it a lot and the reason for that is that this is what makes stuff work better. It’s like an invisible force, you don’t really notice it when it’s there, but as soon as it goes away, stuff don’t work out and that is the number one point of focus I think.

Thanasis [00.15.27]: Right! So, let’s dive into the actual stuff, how to scale your team in more practical terms and let’s see who will scale it, right? The primary responsibility lies on the founder or the cofounder or the CTO for that. So, like you said in the transitioning to scale thing for that person is to actually start letting go and understand the importance of delegating and understand that as the team grows that person, let’s say the CTO, will have to code less over time and their job will transition from a programmer to a project manager. That is something the CTO will need to understand and act like it. We’ve seen many cases were CTOs didn’t have leadership skills or didn’t want to give up coding and as a result the whole team got hurt, the velocity slowed down, developers weren’t getting the proper specs they should be getting, which is the CTOs job to ensure. This mentality shift needs to happen within the organisation for every single person in order to work correctly.

Dimitri [00.17.05]: And once you’ve done that, once you’re on your way to doing that, we talked about methodologies in the last episode, we talked about realising goals and objectives, so I encourage you to go back to that and listen to it if you haven’t. But for now, you are scaling your team, people will be coming in, you’ll be growing your operation and you need a methodology in order to be able to build your road map, estimate your tasks, have a clear way of communicating these tasks and realising these tasks. Once you get all these right in the team, everyone has a clear picture of what they need to do and what needs to be done. Also, formal ways of communication process, make sure there are clear cut defined channels of communication. You can do that with the use of tools, for example if you are opt for the Kanban methodology and you are using Trello it’s probably better to have all communication go through that, so it’s documented, people are notified, conversations happen within, so even people who are not directly involved can have an idea of what’s going on and they can go back and check it out at some point in the future, because it will be documented correctly.

Thanasis [00.18.39]: Right. So, if you remember from our previous episodes on the methodologies, we were giving some slack on the early stages, now this is the point where you need to get serious about it and have very well established rules and procedures so that every member of the team knows where north and south is and how to operate within the environment of this company. Now, the next thing speaks to how less agile you are going to become and this is because you are going to establish some long term road map and since you are now talking to a team of up to 10 developers or maybe more, everybody needs to have an eye on the long term so they can properly tool and prepare their infrastructure for tomorrow. I mean, giving ad hoc short term task doesn’t really work if you want to go for long term and scaling your team is that you want to go for long term.

Dimitri [00.19.50]: So, maybe it’s time to look into how to hire your first product manager, who will be running your team from now on, releasing the road map. So you need people with technical ability, experience with working at a startup which is trying to scale at this stage, not just a tiny typical startup, but the one that’s from me product market feed stage and onwards, so they are near the market, they know the competition, they have some sort of familiarity with at least one development methodology and have worked on that. So, depending on your scale, “how many of those guys would you need?”. I’ve seen these figures been thrown around like 80/20 ratio, but I can’t really back that up with my own experience, so let’s say less than that. When we were searching I saw a few and this kind of like an average, but I don’t think it’s just for startups, or great startups, or scale startups. It’s basically from your small business to your cooperation.

Thanasis [00.21.19]: That’s right. So, when starting out and you are basically going to do your first hire of your product manager, right? That product manager is going to handle the whole team, so it’s not uncommon to have a single product manager for up to 10 people. The second will come on how you will divide your teams and your product managers, is going to be entirely organisational and based on your industry thing. The questions that I want to ask you Dimitri is, how would we evaluate a product manager.

Dimitri [00.21.53]: Okay, they’ll have to hire them if they so far know the market and know the competition and have some sort of demonstrable product vision in the past, some sort of portfolio of stuff they’ve worked on. It doesn’t have to be world class or anything, like all these unicorns that are out there, but it would be nice if they could demonstrate stuff that they’ve worked on. They would definitely have to be loving what they’re doing, a hundred percent.

Thanasis [00.22.30]: Yeah, I guess that goes for everybody. Let’s put a note here to dive into this on another episode, like what are the required skills and so on.

Dimitri [00.22.43]: Well, communication for sure, the recurring theme. You know, sometimes they say that also the product is the CEO, so they’ll have to drive the development of the product, guide the people, define the tasks, make investigations, come up with product features and realise the vision.

Thanasis [00.23.17]: Yeah, it’s a very sensitive subject and there are a lot of things to be said here, so let’s move on and promise that we are going to revisit that in the future.

Dimitri [00.23.26]: Sure! So, you are bringing people on board, it’s great to come up with a hiring policy or a list of things that you’ll have to make people go through in order to join. So, at this stage, definitely a personal interview with a founder, definitely a technical interview with you developer who became the CTO. For software development roles, a tiny assignment or what I’ve seen a lot recently, I actually know people that have gone through these, a boot camp. This is a more light scale product which might take a few days and could potentially be something of a feature that you’ll integrate into your product later at some point and that will have a nice taste if it is paid. So, assignments are for a few hours and it is like, get back to us when you have a link to the repair so we can run what you’ve done and check it out and review it or a boot camp which might be able to spend some time with it since they will be giving you a lot of their precious time that they’ll have to be paid for that.

Thanasis [00.24.55]:Right! I see that we have taken this kind of backwards, the interview with the founder, of course this should happen last, as it’s the most important one because this is the founders pick for the company’s culture. So, that is what is going on on that specific interview, because up to that point everything is strictly technical, assessing the technical abilities of the candidate, but the founder interview is about company culture, the kind of people you want to have onboard. Now, you talked about assignments and bootcamps, but I have mixed feelings about that and let me explain. One of the things that I want to suggest for a higher degree of success in your search for candidates is to give a salary range, which is very important because as we’ve explained in previous episodes there are multiple ranges of developers and what you perceive as a senior might be different from what is actually perceived as a senior in the market and likewise an intermediate and a junior. The thing that makes the difference here is the salary range and this is a yearly salary range. There’s a big difference if we’re talking about a thirty thousand per year salary range, which would be something that somebody in poorer countries would take as a yearly salary at their early stages and the salary goes up to six figures and everything in between. I’ve seen typically Europe is at a 70% compared to what the US offer and all of these things make a difference and position you at the right market segment and what it will actually do is save yours and the developers time, because no matter how you right, no matter how you describe what you want, the bottom line is what you’re willing to pay for that, right? You will have better results if you come out with that and this is what I’ve seen happening in most well established and well operating companies and this comes in connection to the assignments and bootcamps. As I’ve been in the job market for the past months, what I’ve seen in the many companies now are going to the habit of thoughing you an assignment before having the chance to talk to anybody and I find this to be a bad practice for a number of reasons. Firstly, it’s showing that you are not respecting the developer’s time, a developer that is looking for a job might have to perform ten to twenty applications at a time and that is how this is done, it’s not something that is bad or you want to find dedicated people. This just doesn’t apply, it’s not something that is going to happen. If you are looking for a job, you are going to make multiple applications and if each one of those applications require you to pay up front two to six hours of work just to fill out an assignment this doesn’t really work. It’s important to find the right ratio and way to do assignments versus having the first interview so that both parties can understand what the other party is looking for and see if there’s a match before the developer commits to solving an assignment. Now, one other thing, of course we’ve mentioned that before, I’m just going to skim it through quickly, is to check their reputation and their references of each candidate as a part of your interviewing process and we’ve analysed that in a previous episode on how you hire, you have to check out their whole social cloud, Twitter, Facebook, their technical cloud, GitHub, Stackoverflow and as a CTO you’ll know what to look into.

Dimitri [00.29.49]: So, on top of these procedures let’s have a look at what kind of people you need as part of your operation. We’ve talked about this before Thanasi and we came up with two groups of people which are by no means mutually exclusive and I’ll just have to go and say, feel free to mix and match these attributes, but let’s go through them and we’ll discuss that. So, there are definitely not mutually exclusive and as a matter of fact, let’s go through these labels altogether and go through these attributes.

Thanasis [00.30.48]: So, which are the two categories?

Dimitri [00.30.51]: We’ll go through that in the end, we’ll keep that as a surprise. So, the first category are people that can wear multiple hats, definitely can work autonomously, can take the risks and ambiguous goals and realise on their own by being proactive (decision making in the process), have track record of being able to ship continuously can mean from daily to weekly but that’s definitely high frequence if you fall within that range or every couple of weeks. So, high frequency shipping and when you’re looking at this group, check out the history and check what would work for you.

Thanasis [00.31.51]: However it is expected from this kind of people to have a high turn over as their drive is the challenge and the moment things become a routine it’s the thing that they don’t like.

Dimitri [00.32.08]: But it’s part of the founder to make it interesting, it’s the founders job to know that this is a reality and it will happen and if you have a well established set of procedures of getting people in there, you’ll be able to hack around that.

Thanasis [00.32.33]: Well, I cannot hide it any longer, this is like a quiz to our listeners. What we’ve been describing up to now is the kind of person that we would call a startup person, the startup developer and one of the disadvantages that comes with that package is that they have bigger egos and they require a special kind of management or let’s call them managing divas. Although, that varies between those people, you know, some have it a higher degree, some have at a lower degree, you might find yourself into a situation where you’ll have to manage yourself a kindergarten, but those are the people that are creative, break things, pioneering technologies. The other category, again labeling is a bad thing, however we have to have some terminology in to order to be able to communicate, is the journeyman. It is the kind of person that is going to stay with you long termly. They are very reliable but they will require higher management role from you to be able to provide better specifications in the details versus vaguely ambiguous goals. Typically you would expect larger release cycles, because these are a bit slower but reliable machines and it’s like the always producing machine and contrasting that with the startup people, the startup people have overdelivery on one week and the other week might do nothing, it’s just how they work, they have peaks and bottoms. With the journey man you get a constant rate of output.

Dimitri [00.35.04]: I actually feel a bit conflicted that we have to use groups. By no means mutually exclusive people can share these attributes and it comes part of wearing the multiple hats and mixing and matching, which is one of my own favorite things, too.

Thanasis [00.35.36]: I think that’s exactly what’s required. At the beginning, when we originally had the conversation in mind it was like black and white, but what I’ve seen actually happening in real life and in the businesses I’ve been to is that the journeymen should be a bigger percentage than the startup people, who kind of provide a line of how things should be working.

Dimitri [00.36.19]: Maybe we should do an episode of hiring startup people in the future. What do you think? Cause I get the feeling that there are a lot of things that we could say here.

Thanasis [00.36.29]: So, let’s move forward as we have covered the how to scale part, what it is in regards to the hiring policy that you need to have, now let’s look at the other part. You have hired your candidate, now they’re employees of the company, it’s their first day at work, they show up, 9.00 am and now what do they do? So, this is an issue of onboarding, you need to have a very solid onboarding policy to be able to minimize the onboarding time and minimize it from multiple weeks to possibly a single week, right?

Dimitri [00.37.16]: A single week, definitely lot of low hanging with the group, right? That’s how you can get through it rather quickly, so what have we got?

Thanasis [00.37.24]: So, the most expected thing to do is to have a checklist, that is going to be operated by the onboarder, whoever that is, might me the CTO or someone else and that is the checklist of what needs to be done when a new person comes into the team. So, that starts from the very basic staff, like create their email, accounts in whatever dashboard or service is required, maybe Github access, Google Drive and so on. You know, onboarding into the team in very practical terms, so that they have access into everything. That is the list you can do and it should be completed as early as possible. Next advice, is to have a Wiki, which is basically your documentation, your onboarding documentation and in that wiki you are now starting to explain in more specific terms your development environment, the stack, the technologies that you are using, which will have to be installed on the local machine so that the new developer is going to be able to develop. List of all these, provide step by step guides as to have the developer’s local environment built, so that he will be able to be productive as soon as possible.

Dimitri [00.39.03]: And you can start with something simple that covers the basics and everybody will contribute in building that, so it will be meaningful and comprehensive.

Thanasis [00.39.17]: Something that I find very practical here is to task the new recruits with the task of having them improve the onboarding documentation themselves. As they run through it and they discover gaps and questions come up, make it their responsibility to update all the docs so that the next person that comes in has an even easier time. One thing that I find particularly useful is to create screencasts and this is something really simple to do, especially for OS.X. If you are on a Macintosh, which most developers use today, you just open quicktime and start recording your screen and your voice, so you basically open up your own local dev environment and start showcasing, showing around the developer as you move through the folders, the different services, the different scripts that you are using, how you deploy code and all that. These clips shouldn’t be large, I mean 20 or 30 minutes large and multiple of them. So, let’s talk about databases, let’s talk about how we do API, anything that needs addressing and a simple document might unveil the exact meaning, so you should do a screencast. Have you ever seen a screencast, Dimitri?

Dimitri [00.41.01]: Yeah, I’ve seen a few of them, not as part of the onboarding process, but I have definitely watched several on youtube or something.

Thanasis [00.41.15]: Once you do a couple, then it becomes really a habit for you, it becomes very easy, I mean everything that I want to explain, I just pop out Quick time and start recording and convey my message entirely. That’s pretty much it. One last note here, is to have some kind of ritualisation like docker, but this is a very advanced topic and if you decide to go for it you would have all the better information by your hand so that doesn’t end as far as onboarding goes.

Dimitri [00.41.54]: So, I think we have covered everything. Really quickly, what have we talked about today, very important, keep in mind when you begin the scaling process. Be aware of all the pitfalls that surround that and be mindful on how to transition and establish a formal communication process or semiformal in order to bring people on board, and once they are onboard try to welcome them as well as possible. With that , I’d like to say, please send us your questions or remarks by calling us on 8663705050 from anywhere or you can email us hello@listenshiprepeat.com, subscribe on iTunes by searching for our podcast, feel free to go in there and drop us some stars or a review if you want, this helps us climb up higher in our respective categories and helps us make more episodes. Our website www.listenshiprepeat.com and you can also find our transcripts there. So until next time, thank you for listening tonight and from both of us, Goodbye!

Thanasis [00.43.01]: Bye, bye and happy new year!