In my previous post I discussed preparing and getting ready for your “first day.” Today, we are going to get our hands dirty and move towards basic infra and the team planning that will continue during the rollout phase and beyond. In this stage I assume you already have a solid MVP spec and already have an idea about how you are going to structure your tight-knit, dynamic, hands-on team.
1. Know your enemy
Every startup has an “enemy.” The enemy can change its form. It could be new technology that doesn’t exist, real tough integrations points, a very challenging algorithm which will take you months to nail down on top of making it scalable, or It could look like a lot of other things. Once you are able to identify your specific enemy you are moving in the right direction. Your design and architecture are going to be planned around this. It will assist you to minimize surprises. You better understand it early, as your architecture and time estimation depended on it.
2. Architecture, Architecture
Architecture is the first step towards your shiny system. I won’t speak about how to do it in this post but, I can point out who you should be sharing it with. Which is, practically – everyone! Once you finish drawing it make sure you put everyone in one room for few hours and start discussing it. It doesn’t matter if your crowd doesn’t have technology background because architecture isn’t about technology, it’s about design and flow. Talking technology and patterns on this step is all wrong. Once you speak about your design, you’ll be surprised about the feedback. Even better, you will realize new things you didn’t think about. Get ready for tough times as those discussions are intense and sometimes get aggressive but that’s the fun part! Share it with colleges, with other friends, and stakeholders. Your company need to know how your overall plan is going to look like.
3. Budget planning
So you got your seed, cool! Now let’s spend some cash! Who wants new chair? Who wants a big office? not me! Remember this – Your money is running out. You woke up this morning and your money is running out. You went to lunch, your money is running out. I’m not trying to scare you or give you paranoia, there is an illusion that if you raise $1M you have all the time in the world, you don’t. The money is running out and you’re not a profitable company (not yet anyways). Be aware of it. Now, let’s be practical about how to be aware. First, know your main expense, which is your development team and…heh that’s practically 80% of your overall budget consumers. Lawyers, graphics, office expenses, and Nespresso cups won’t affect your budget as much as your development team. Let’s drill down regarding how the development team will consume your cache:
Your team will consume salaries. We’re talking about the monthly salary of developer. It could be Backend, Devops, frontend, Fullstack- it won’t be cheap. I’ll keep this content for dedicated topic but I could add offshore and outsource recruits. Anyhow, developers are the building blocks of your company and without them you won’t be able to do much.You better keep in mind that most of the budget is going to be spent on developers and it should. They are going to set the company DNA and initial success.
b. Third party services
I assume you are going to use Cloud services, at least for Dev purposes. AWS? Google? Doesn’t matter. They going to consume the most. It looks cheap it feels cheap, but hell no, once you eat with them you are busted. Best you can do is to monitor it. You upgraded your machines from small to medium. Pay attention to this fact. You are working on microservices, and you think you were able to get away with them because everything is dockerized – think again. AWS does not charge you by machine any more, they charge you by traffic and time. So, it doesn’t really matter how you spread your services. Adopt a new habit that once a week look at your monthly payment prediction (very easy with AWS) and look at where your payments are going. You will be very surprised to find some unused/oversized machines, unused load-balancers and VPC’s that nobody uses. You should get rid of it all. Dont think on production yet. Use the smallest machines and once you get to production I assume you will have client on sight. That is when you should consider upgrading your overall system. Until this happens be humble and keep your spending under control.
4. Development flow planning
There is bad habit for startups to work in ‘Jungle-Mode’. I don’t understand this. At the end of the day it will bite you and it’s going to hurt really bad. I believe that when things getting rough you should have a System! Yes – A System! One that everyone follows. A system that will help you to make order in times of chaos.
I am a big fan of flows. Flows have starting and ending points. Assume you have 3-4 developers in your team, you should create a Release Scope Routine. Call it agile, call it scoping, call it whatever you want-Just make sure you got it. I personally like short sprints and fast deliveries.
Here is an example from my work:
My personal tool for small teams (3-20 members) is Trello. It’s simple, you don’t need to configure much and it’s very effective once you get a good grip on it. You can read previous post of mine how I am using Trello.
All tasks should take 4 hours. Everyone should be aware that they need to deliver by the end of the sprint. If a task takes longer it should raise ‘red-flag’. You have two options: Divide your task into another one or add another pair of eyes. Don’t wait for the end of the race if you won’t be able to make it to the finish line announce asap. I alway instruct my teams – “Don’t wait for the last minute.” Last minute means pressure and chaos. If we have enough lead time we can re-plan the sprint or change the priorities to help each individual succeed. In the end of each sprint we are ready to plan the next one. Remember, short deliveries and small winnings are the key for showing results. The best part is the feedback, if you deliver in small parts you get feedback sooner and better insights into your work.
Infra is very wide topic. So instead of talking about how to do it, I’ll speak about what you should focus on, especially for new startups or teams. When I say infra I am not referring to the technology you are going to use or the programming language. I’m talking about the sandbox your team is going to work on. This sandbox should be planned as soon as possible. Believe me, once it’s setup you don’t touch it. In many cases this sandbox is with you for a very long time and it works well because of the simplicity. Let’s get down into the details: As I mention in my last topic (Development flow planning) I am a fan of fast deliveries and helping your team getting there.
Your team is writing the code that needs to be deployed somewhere (Dev env, stage env, etc..) Create CI/CD as soon as possible. In short, automate your teams development process. Automation could be very wide, but let’s stay focused. I don’t want to automate everything, I’m talking about basic infra.
Flow: Developer code followed by pushing his/her code into repository, under the hood the build being compiled tested and deployed. That’s it. Start from there and you already got 70% of your automation. Keep it simple, clean and work with your favorite tools (I personally like Jenkins). Once the version got into dev env it’s already on-air.
The second point of Infra I want to mention is alerts. It’s important to alert and update your team for specific events. Alerting the development team is essential if the building process fails. Updating the development team is essential for new deployments. You can use Slack, Email whatever, just make it happen. Everyone should know and be aware what’s going on in dev and share the same methodology. Don’t be aggressive with automation. Remember, you need basic things that won’t block your team while continuing to achieve your target. There is a great Russian proverb I like: “Don’t try to get into hell ahead of [your] father”. First things first: Full-fill your MVP. Once you get customers that’s a new story.
Recruiting is one of the stages you want to get over with but, it never ends. It’s a long process that always consumes efforts. You need your spartans with you for the winning. Don’t compromise. This process is challenging. But again, If you stick to a system and have pre-ordered steps you can make things go effectively. Spend 1 hour a day for gathering candidates. They are the building blocks for your future teams. The DNA of your company is determined by the first 2-7 people.
This is my recruiting flow:
Phone Interview, Personal interview, Architecture overview, Hands-on code exercise, Second interview with another colleague from your company and finally Contract proposal.
Before you start interviewing set your expectations. If you are looking for a Junior Developer know what skills you are after in your candidate. Things like growth potential or personal intelligence. If it’s Senior you should look for more experience.
A few words about working remotely. It depends on your current startup status and your current team size. If you have already recruited your core team you can start looking for remote developers offshore. Personally, in the beginning, I like my teams close to me physically. There is nothing more effective than discussing work matters in person. Especially when your project has just started. When new team members are working remotely it is challenging to create the personal connections and communication necessary. Perhaps in my future posts I will discuss how to manage remote developers and techniques to keeping them effective.
In my next post I will speak about which technologies you should keep in-house and which you should take from 3rd party provides. I will also talk about the importance of keeping your company product in loop, how to make your teams independent and how to start planning your Rollout towards your upcoming customer.