Lessons That Don’t Come Cheap

Engineering and business lessons that you cannot afford not to learn.

As a software engineer, consultant/contractor/freelancer, founder, and early employee at a few different startups in the last few years, I’ve learned some really difficult lessons. Some are general life lessons; others pertain to business, and some are about how to be a professional. These are hard, painful lessons to learn that don’t come cheap. They are the kinds of lessons that you can only learn by doing. Some of them are cliches, yet I had to learn them the hard way. Others are things that I never saw coming but knocked me down pretty hard.

1. Don’t be sloppy about business. Don’t work without first signing a contract. Don’t sign a contract without first signing a stock options agreement. Don’t work without a work permit. Don’t verbally agree to something that you aren’t willing to put in a signed contract. Know the laws, best practices, and what are reasonable expectations. Consult advisors if unsure. Consult advisors even when you are sure. Actually, consult an advisor especially when you are sure. Being sure is a dangerous thing. Consult more than one advisor. Learn how to explain a story without bias so that you can get unbiased advice from your advisors. Be careful not to mix up ranting and explaining.

2. Startups are meant to serve their founders, followed by their investors, followed by their customers. Startups do not serve employees; employees serve startups. Startups are generally a bad deal for the first employees. They don’t pay well; you won’t get much stock; there is a lot of risk, stress, and sweat. If you get lucky, they can pay off for employees, but the odds are against you. There is a much higher initial risk for founders but they get such a high payoff during an exit that its probably a much better deal for them.

3. Keep your friends and family close. Really close. It’s easy to get consumed by being ambitious and have little time to put towards maintaining close friendships. Be careful; you will fall hard and when you fall you need really strong relationships to catch you. You need friends that you can trust and that are legitamtely looking out for you and your interests. You will be working with people that are very, very invested in their own interests sometimes at the expense of your own interests. You must counter-balance this by surrounding yourself with people that know your worth, remind you of your worth, and insist on looking out for you.

4. Take care of your friends. Work hard to earn your friends’ trust. Trust is possibly the most important aspect of any relationship with anybody ever. True for romance, true for marriage, true for starting a company. Business needs to be done on paper, in contracts, but the vast majority of business is done through trust. By the time you get to using paper and court systems, things have gone seriuosly wrong. Don’t get to that point. Communicate, set clear boundaries, and don’t work with someone that you don’t trust.

5. Don’t be afraid to say no. If you are asked to do something unethical, say no. If you are asked to do something unreasonable, say no. If you are asked to meet an impossible deadline, say no. If you are asked to deploy code that is not ready for production, say no. Part of being professional is holding your work to a certain professional standard of quality. It is your professional duty to be aware of all of the risks and implications of what you are building. If you are not comfortable with something, don’t do it. Find somebody that is comfortable with it. If you build something and it has a defect that kills or injures someone, you will have to carry that burden for the rest of your life. Software might be virtual but it controls physical systems that have real world outcomes. Just because you are not behind a wheel doesn’t mean you aren’t driving something. Google “software engineering disasters” and you will find a long list of accidents that were caused by a mistake in code. A software engineer is a real engineer.

6. You won’t get rich as an employee. In capitalism, *the* way to get rich is to own capital. If you don’t own capital, you can’t get rich. If you make good money, use it to buy capital. If you don’t make good money, make sure you own part of the capital that you are building.

7. Being a leader is hard. Really hard. It requires people to respect you. If the team that you are leading doesn’t respect you, then you can’t lead them and you might as well step down. As someone that reports to a leader, it’s easy to forget that they are a human and prone to error. It’s easy to forget how much responsibility and risk lies on that leader’s shoulders. It’s easy to blame them for everything that goes wrong. It’s easy to throw them under the bus in favor of increasing your own power. Leadership doesn’t just happen overnight. It happens gradually. People don’t give you respect overnight. You have to earn it gradually. Some people have no respect for anybody. These people don’t belong on a team in the first place. They will undermine a team. Throw them off the team as fast as possible.

8. Don’t try to make up for other people’s shortcomings. If they can’t pull their own weight, move them into a position where they can succeed or fire them. Otherwise you will begin to fail at your own responsibilities and become another person that can’t pull their own wait too.

9. Eat well, get enough sleep, take a step back from what you are working on often, and maintain good relationships with people that care about you and that can relate to you. These friends will tell you what you need to hear when you need to hear it, they will keep you sane in hard times, and they will notice that you are stressed before you notice it yourself.

10. Mind other people’s business. Don’t be afraid to ask them personal or touchy questions. Worst case, they say they don’t want to tell you. Best case, you learn and deepen your relationship. If you are afraid to push the limits of the relationship then it won’t grow and you won’t learn your boundaries. When someone is unhappy, stressed, needs help, or in any such situation, don’t hesitate to pull them away from the situation and try to help. They might fight you for a minute, but sometimes you have to rescue a friend from going down a wormhole. Sometimes they want to go down the wormhole. Sometimes you have to let them learn their own lessons the hard way. But don’t let them learn the lesson without first trying to help them avoid going down that path. When they come to their senses and realize they were going down the wrong path, they will be happy to know that you tried to help them and that you cared.

11. Being cavalier in a situation that is stressful for someone is a good way to destroy their morale. In tense moments, it’s important that everybody at stake is on the same wavelength. One person cannot be cavalier while another is intensely stressed or focused. You might think you are breaking the tension or providing comic relief but someone who is under a lot of pressure may feel abandoned and resent you.

12. There are not bad people, just bad situations. Even an honest, dedicated, person of integrity can be made to look like a villain in the wrong light. Good people do not do bad things; they just get themselves into bad situations. Sometimes there is no good solution. It’s important to know your boundaries and look where you are going so you don’t land in one of these situations. Your integrity will be tested in difficult situations; be careful to keep a level head and do the right thing in these situations, no matter how difficult they are.

13. If you are a leader, don’t put your head down for even a moment. You have to look out for your team and be careful not to lead your them down the wrong path. It might be tempting to try to fill in for someone who is not pulling their weight or to put your head down and focus for awhile. This will come back to haunt you later. Keep your head up, your eyes open, and don’t let your guard down. If you are in a position of leadership and you are expected to write code, make sure that you never, ever, ever make coding your first priority. Leading the team is your first priority. Listening to your team, making sure they have everything they need, making sure they have clear goals that they are able to achieve, and that they are motivated to achieve them is your first priority. The moment you put yourself or your code first, you’ve made a big mistake. If you are raising money, the same thing is true for you. You might think that meeting an investor or reviewing a term sheet is your number one priority. It’s not. Your team is. Don’t ever even once think that it’s more important to put fundraising before listening to your employees’ needs.

14. If you feel like something is wrong, say something. Don’t put it off. Make it a high priority to fix it. Things can get out of hand faster than you’d ever imagine. Be proactive about keeping them on track.

15. Don’t throw someone under the bus. If someone is doing something wrong, talk to them directly first. People love criticism and feedback, but being publicly ridiculed is not the way to provide feedback. This is a fast way to make enemies. People work hard to earn respect, recognition, and pride. These are very strong intrinsic motivators. Publicly calling someone out destroys their ego. These should be used as last resorts or if someone has done something morally wrong.

16. Don’t set people up for failure. Set them up for success. Give them all of the tools that they need to do their job, give them the motivation they need to do it, make sure they know beyond a shadow of a doubt that you are looking out for them and their interests and listen very closely to what they say. Read between the lines; sometimes people don’t come out directly and say something. Sometimes you have to dig. Sometimes you have to play therapist. Make sure they are not bored with their work. Take the time to understand what motivates them. Give them something they can achieve but don’t make it obvious that they can achieve it. Everybody likes to “find out” what their capabilities are and push their limits. Set ambitious goals for them. People quit when they are bored, not when they have too much to do.

17. Be humble. Find out what you don’t know. You will never know what you don’t know, but there’s no limit to the list of things that you know you don’t know. Never lose the mindset of being a student. Always be listening and learning. Never be afraid to admit that you are wrong. Remember that the upside to being inexperienced and asking a lot of questions is setting yourself up to become very experienced very quickly.

18. The corollary to #17 is knowing when to be confident and standing your ground when you believe in something. If you have an opinion and believe in it, stand up for it. If you give in and let someone who you don’t agree with take the lead, and they turn out to be wrong, you might find yourself at fault for doing something that you didn’t even agree with in the first place. Speaking from experience, that hurts. If you have a strong opinion, make sure it is known, stand your ground when necessary, and be ready to admit your are wrong later.

19. Do not build something until you understand it. If you can’t understand it, then you should definately not build it. If you build something that you do not fully understand, bad things will happen. Do not trust whoever is telling you what to build. Always challenge them and and think critically about what you are being asked to build. If you don’t have a good idea of how you are going to design something, investigate further instead of waiting until you get there. It will come back to haunt you when you realize that it’s more complex than you thought it would be or doesn’t fit with the way you’ve started building your project.

20. Do not burn bridges. You will run into people again, and again, and again. People talk. Opinions about you will spread. Do not make enemies. Do not be afraid to piss people off, but do not give them reasons to hate you either. Do not screw people. Never threaten someone’s money or reputation. If you have to exit a project in an unideal circumstance, put it down gently and make sure the person in charge of the project understands why you are leaving.

21. Do not work with people that don’t understand the execution of their business. If someone is willing to learn, then this is an exception, but you will have to get good at teaching. If they are using software to build their business, they need to understand how to build software. They don’t have to be a programmer but they need to understand the fundamentals of managing software projects. They need to understand why adding more manpower to a technically complex project does not make it go faster and they need to understand that planning, specifications, and testing are part of the process. They need to understand why they cannot change the project’s requirements halfway through the project. They need to understand why “adding a button” is not always as simple as just “adding a button”. They need to understand that software engineering requires time spent improving the quality of the code and reducing technical debt and that this is a necessary part of building a software-based company even though it does not directly result in visible progress on the product.

22. Hire generalists. The first employees at a startup should be generalists. Startups suffer from higher churn rates than more mature companies, so it’s extremely important that there be more than one person on a team who is capable of working on any given piece of code. There should not exist projects that only one person on the team is qualified to work on. This is a recipe for disaster and increases the risk that code will have to be thrown away and rewritten. Each project should have a single owner and maintainer who is responsibile for the integrity and quality of that code, but they should never be the only one that is capable of working on their project. Large companies can afford to hire multiple specialists and large teams with adaquate redundancy in skillsets. Startups cannot.

23. Leadership is important. The friends that I’ve seen launch successful startups have had good leadership. This is a huge commonality that I’ve noticed in successful startups.

24. Different projects are different. This seems like an obvious thing to say, but sometimes it’s really not. Different projects have different requirements, skillsets, and require dramatically different approaches. It’s taken me by surprise how different an approach projects have required from each other. For one project it might be completely acceptable to take an agile approach and occasionally lose a piece of data. Another project may require a more traditional planning and specification writting phase with a waterfall approach. In some situations a company cannot afford to lose a single user while in others users are practically disposable. One project might be realistic for a beginning programmer in a dorm room while another might require a team of 100 Ph.Ds. What’s also been surprising for me is how simple projects like to camoflauge themselves as complex projects and complex projects like to camoflauge themselves as simple projects. What might initially seem quite simple can turn into a monsterously complex project and what seems quite complex can sometimes be surprisingly simple. This is why it is so important to think through the requirements and specifications of a project before building it — even if you don’t actually end up sticking to them.

25. Focus on working efficiently. Sometimes it helps to be a little bit lazy and to keep an emotional distance from your work (but be careful not to have apathy). Set a goal for how you will implement something taking into account quality and features, then do the minimum amount of work necessary to get it done. Separate user interface design from functionality in order to avoid the temptation to continously tweak something to make it better — that is not engineering, that is art. Work in small chunks: 20 minute pomadoro cycles each day split into 2 week sprints working at a maximum of 5-6 hours per day writing code is a good ideal to aim for.