Entrepreneur Tips and Discussions

Some things I have learned as VPE/CTO in my career so far that I think it will be most useful to you if you own or are about to start a startup.

I have been a very active reader in this community, I have noticed some things that many seem to have an issue with, but it became more clear during this month when I started looking for a new position as Vice President of Engineering in startups. So I’m writing this.

**(Please note that the content written in here is solely based on my experience as, and have proven to be very successful, specially with teams working remotely)**


Understand a few things.

* **Understand that you will have to sacrifice your time.**
* Other than usual corporate jobs, working on your startup will require more than your 9 to 5 work. Of course you can work that way, or even less, but you will have a really hard time trying to succeed in the market you are trying to target when other startups are putting 10-15 hours a day.


* **Understand that you might push your loved ones (or those close to you) away.**
* If you are putting the extra amount of hours on your idea, you will realize that you won’t have much time to spend with those close to you. Specially your girlfriend/boyfriend.
* **Personal example**: during my first startup, I was leading a team of 38+ people and would work 15 hours a day on average. During that period of 2 years and 7 months, 3 girlfriends told me they couldn’t continue dating me as I would see them only a handful of times per month.


* **Understand how hard leading a startup is.**
* Running a startup in a competitive market feels ***like you are in a knife fight in a prison yard***. If you are a weak leader, your startup will be weak. Not just physical strength, but mental strength too and most importantly, your strengths/skills in leadership and negotiation.


* **Understand that you need the most excited people to work with you, on board with you.**
* This might be confusing, so let me explain. When you are recruiting your co-founders, if their answer is not “**FUCK YESS!**” then its a no. Co-founders are the basement of your startup. You and they are the foundation on where your startup is built. If the thought of working with you and your startup doesn’t generate a response of **FUCK YESS!** then it it should be a no. Don’t waste your time dealing with someone that kinda wants to add value to your start-up.
* This also can be applied with advisers and investors.


With that being said, here’s some things you can apply to your start-up.

* **Goals and Objectives**
* Always have goals and objectives for everything you want to develop. Lacking objectives and goals will make developers disorganized and they will lose interest in the development very quickly.
* Having goals helps to maintain developer presence and keep them busy with their own tasks. It cements the path for a goal-driven development for the future.
* Having long-term goals without small goals and objectives in between will lead to the exhaustion of the developers involved. (This is risky and can break the development and push your team apart)
* Objectives should be specific, measurable and have a short time frame. Their purpose will be to achieve your goals.


* **Deadlines**
* By setting a deadline, it gives the people involved a sense of urgency, which makes all the members more productive. It also allows newer members a way to prove themselves and be useful.
* Deadlines should be strict but reasonable. Their purpose is to help you reach your goals and objectives, but they shouldn’t be final. As everyone can get caught up with life and can’t reach them in time. If that happens, then try to understand what was the reason for their delay, try to be affectionate with your developers. See if you can help to reduce their stress or work overload. They will recognize this and love you for it.


* **Manifesto and your start-up virtues & spirit.**
* Write your start-up manifesto to specify your company’s intentions, motives or views. This way you can attract like-minded people and form a stronger bond with people working with you.
* Know what the spirit and the virtues of your start-up are and apply them. You will create a better work environment for your co-workers, and they will love you for it.


* **What, Why and How**
* Always know **What** you want to do, **Why** you want to do it, and **How** you will do it. This will make your vision stronger, and make you be seen as a strong leader who knows where he’s leading the team in the long run.
* Simon Sinek has a very good video about this. (Not sure if I’m breaking Rule nr.2 with this, but please let me know if I am so I can edit it out).


* **Mentor your people**
* When mentoring people, don’t show them how they can do it, but help them to understand the issue better, and how they can solve it.
* If you are mentoring a group of programmers/developers, **NEVER** give them the solution in a plate, but instead try to appeal to their solution solving skills with ideas on how they could do it, and let them figure it out. You might be the best programmer in the company and the solution is easy for you, but they won’t learn it good that way. Teach them how to solve the problems, not how to write the code for it, as you can find many things online who have a better solution on how to fix your bug, but they more than often, don’t teach your developers how to figure out the solution is.
* Personally, I would hire someone who is a 3/10 programmer/code writer, and a 8/10 problem solver than a 8/10 programmer/code writer and a 3/10 problem solver.


* **Never micromanage your development team.**
* Just don’t please, you won’t be helping your developers.

I could write in this on-and-on for days, but I think these are some good examples.

Hope you had a good read.



**A.B. BTEK**

View Reddit by BTEK9View Source

15 replies on “Some things I have learned as VPE/CTO in my career so far that I think it will be most useful to you if you own or are about to start a startup.”

I have two cents to add:

1. If you develop an app that IS NOT ready to be marketed or pitched to investors.. fix it before hiring on more to the team. Don’t be stubborn, be open to criticism from your team. Age isn’t a justification either. Just because a member of your team is younger and has insight doesn’t mean they’re any less credible than your elder team members.
2. Don’t under-micro manage your developers either… there are a lot of scammy people out there that can and will take advantage of the opportunity which will cost you a LOT of time and money.

I’m also a CTO/VPE/technical co-founder, here are a few things I’d note/add:

> Mentor your people

My favorite way to do this is to give people the space to run with their ideas *if you have the ability/time/etc to do so*. Nothing teaches someone like trying it their way and seeing it fail. No matter how much you sit down and explain it to someone, the impact isn’t the same. However, sometimes sitting down and explaining it to someone does save a lot of time. So its a situational thing.

> Personally, I would hire someone who is a 3/10 programmer/code writer, and a 8/10 problem solver than a 8/10 programmer/code writer and a 3/10 problem solver.

I’d add one more dimension to this: team player. I wouldn’t hire a 10/10 programmer, 10/10 problem solver and 2/10 team player, unless the startup or job really lends itself to that. Early on, the whole company is one team, and a shitty team member is a huge problem.

> Never micromanage your development team

I think a corellary to this is don’t hire people who need micromanaging. Be confident that no matter what their skill set and level happens to be, you don’t need to be over their shoulder watching. For a startup, its a waste of both of your time.

And one more thing I’d add to this:

**Scale yourself back as you scale your company up**.

If you join a startup early and it finds success, often times growth comes very fast. Maybe you were doing day to day coding, maybe you were the primary developer and have a lot of institutional knowledge. There comes an inflection point where you need to extract yourself from certain roles and responsibilities such that you are not the single point of failure and your expertise and therefore time is not the main bottleneck to the team. At some point in time you need to be working “on the company”, not “in the company”.

Alternatively, if you’re new to this whole thing, you might find out that you don’t actually like doing some of the CTO/VPE level work necessary to grow a startup. Don’t let your ego get in the way – the right thing to do might be to demote yourself to the place you want to be and hire a replacement. Don’t let your ego get in the way of company growth, particularly since if you own stock, you’re potentially shooting yourself in the foot.

I’m a startup CTO and have been doing this startup thing for over 15 years. This post’s advice in my view is split:

Part 1 – If you are working 15 hours a day for over two years you’ve done something wrong. You have the wrong idea, the wrong team or the wrong view on what delivering value is. No one is functioning at their best working those hours and if you don’t have a good work-life balance you will be making bad choices. Don’t get me wrong there will be periods of long hours to meet deadlines or investment goals etc. It shouldn’t be the norm and if I was interviewing and that was made obvious I would wish you luck and be out the door. In the time I have work for two startups that exited to sales I got married and started a family. I walked my son to and from school every day pretty much during his primary years and I made the work fit around them. This macho, twenty-something view on building something is harmful and dangerous and frankly explains why most research shows investable founders are 36+

Part 2 – From the goals and objectives stuff down has some good advice.

As a former VPoE myself:

Great tips. One comment I would like to make regards the sacrificing your time. And I think it is an important point to make. Often you will be asked to sacrifice your time and money in situations that do not make sense. I.e., you do not have equity (or low equity) and are asked to work nights and weekends to be chief coder because the budget will not be released to hire your team. There is a difference between the hours you put in above and beyond to make things happen and completely carrying an organization.

Additionally, watch your cash flow. A lot of unscrupulous startups will want you to spend your own money. I was expected to purchase my own office furniture, software licenses, computer equipment, and even hinted that I should fund the hires I demanded: of course no equity for me. Not even a vesting cliff. Oh, and when I was booted guess who kept all my office furniture.

Now, of course, don’t go into a start-up expecting be cheated, just be conscientious your are investing your entire life and free time to make something happen. If there is not a valuable light at the end of the tunnel working corporate pays a lot more, on average.

Lastly, to the mentoring, a great tip I used to help my team. If there was some architecture or hard code bits I would do the outline myself in private ahead of time and throw it away. Then when going to the team I know how much help to offer and “gentle” nudging to direct the people. They responded really well and by being seen as omnipresent it helps further your influence with the team. If all you do is give orders they may not respect your technically and if all you do is code, someone else is the real VP.

Such a tough challenge. I would do it again in a heart-beat but I have become a lot more cautious. Now I won’t do it unless I want to hang out with the rest of the founding team and trust them.

I disagree on deadlines but not because of the rationalization. More I prefer to have my people set reasonable deadlines and use my experience and judgment to not allow fluff deadlines. Not mentioned … WIP limits. I tripled productivity and got my team to stop working weekends by introducing WIP limits (Work in Progress). My limiting the amount of work started before finished, quality skyrockets and throughput skyrockets. Especially important in the start-up world because the only effective way to reduce WIP limits is to make work smaller and smaller, thus more manageable and more predictable (see estimates) and, by being small and predictable we naturally get to iterate more to better fine tune the MVP.

Last thing, I promise, wow, great formatting and a lot of effort in a well written post. Thank you!

Thank you for sharing

I found a lot of your points to be very insightful, especially the bit “ If they’re answer isn’t FUCK YES!! Then its a no”

Expanding that to advisors and investors is genius!

Great advice

Thanks once more

If you’re ever looking for a Junior DevOps or Developer, send me a PM. Assuming you follow what you preach this is the exact environment/leadership I’ve been struggling to find in the world of startups and mentorship. Everyone wants to produce something immediately, but no one wants to foster the necessary environment to make that work.

Great post. I think you have hit the nail on the head with quite a lot of these points!

The time sacrifice is completely true. I have no idea how many people thing that building a business is similar to working in one. Work life balance will not exist for the first couple of years as your life becomes your business and vice versa.

The manifesto is also super important and something we missed in our early years. We have since built it now but the lack of a standardised set of values hurt our culture and caused material productivity issues which took a lot of time to fix.

Sense of urgency – the three words that all new businesses must have in spades.

Finally, I am sorry to hear about your relationship issues. My wife was incredibly supportive of my business but there were difficult periods. We had already been dating for quite a number of years so perhaps the impact on relationships is more acute on newer relationships.

Thanks for spending the time to write this!

Leave a Reply

Your email address will not be published. Required fields are marked *