The rise and fall of a startup, and what I learned as a developer

The story of Octerra is one that is sometimes exciting, sometimes bitter, and unfortunately, very common. I worked at a startup from its conception through its end, where our funding ended up falling through, and there are a lot of things I learned in the process. Even though I consider myself a junior developer, I was able to walk away with important lessons on what makes a team really work, how to approach conflict within a small team, and why intentional culture is vital to building a company worth working for. What's it like to be a junior at a startup? Is everything on fire all the time?

I originally worked for StudioNow, which is the sort of "parent" company that spun out Octerra. You can read more about that here. I already knew the team when I joined, and felt extremely comfortable joining as a junior. The company had a track record of hiring junior developers and promoting within, so I knew what I was getting into. About 8 months in, it was announced that our entire tech team would be spinning out of StudioNow and creating a new startup around the SaaS platform that we created. While it was exciting, it was sort of nerve-wracking too. Most of the devs on the team knew what could happen as a startup (you could hit it big and get rich quick and work at one of the most exciting companies to ever exist, or you could crash and burn and lose your job, or anywhere in-between), but I certainly was less than prepared for the bumps in the road that we ended up going through.

Working at a small company as a junior typically means one of two things: you touch literally every part of the software, or you sit and fix bugs. Fortunately, I worked for a boss who passionately believed in the former, so I was thrown into the fire (with plenty of teammates to bail me out when I needed it). I highly recommend that you thoroughly vet the team that you're interviewing for if you're in this position, so you know what kind of role they've cut out for junior developers. Though it's not ideal for everyone, being thrown into the deep end with a teammate for a life raft was exactly what I needed. I learned so many different things about the technologies we were using, the deployment and release lifecycles, the DevOps side of things, and how the business worked as a whole. It's important to ask up front what kinds of things you'll be doing as a junior developer on a small team, and what they will expect from you after your "training wheels" period. If you know that the team around you will always be available to help you when you're stuck, you're in a good place for learning.

What happens when you run into a disagreement with a coworker on a small team?

I learned very quickly at Octerra that conflict in small teams can ruin productivity and efficiency. It's vital that the team works well together in order for everyone to continue working side-by-side, and pairing on things on a day-to-day basis. I had great examples on my team of people who would arrive at different solutions to the same problems, or sometimes even the same solution but a different path there…and they were always able to solve it quickly and painlessly. I learned that if you run into an issue with a teammate on the topic of code, it's imperative that remember that the conflict is with the code itself, and not the person. If someone doesn't like your solution, it's most likely not going to be because they secretly don't like you. Remember that conflict in the code is simply two people with differing levels of experience and exposure, coming to two differing solutions. Try to understand what your coworker is saying, and why they feel that way, and do your best to make your case to them. In the event that I couldn't come to an agreement with my coworker, I would usually bring in a different teammate to get their opinion. Pairing on something doesn't have to mean "two" (technically, it does, but stay with me here)…you can work code problems out with all of your teammates if that's what it takes. Our team was constantly whiteboarding things that we couldn't immediately agree on, and it ended up working every time.

Can company culture really impact your efficiency, your codebase, and your product?

Full disclosure: I've only worked as a software developer for about two years, and during my time I've been at 2 companies. I haven't experienced working for a large company (the largest, the parent company of the startup mentioned in this article, was around 40 people). However, our team of 16 employees was incredibly cohesive and the way different departments communicated made things flow extremely well. From the very beginning, the team leads were very open to hear what kinds of traits and habits we wanted to value in our company. Our entire team bought into our culture because, in my opinion, it started at the top.

We valued honesty, teamwork, constructive and detailed feedback, kindness, being openminded to new suggestions and solutions, and always being available for questions or to help each other. Another key item was the belief that we should always be learning and growing, both personally and professionally. Every person in the company from the most junior developer to the CEO of Octerra was always available for anyone to come in and ask questions, or get clarification, or to provide suggestions. No idea was laughed at, and no team member was left out. If you wanted to learn about that thing that was happening on the other side of the codebase, you could jump in at any point.

By having a team that truly believed in each other and our product, we were able to get new features out the door almost immediately. We were able to surpass our goals for the iteration a lot of the time, and we were able to keep the feedback loop open for everyone. If someone had an idea for how point stories differently, we tried it. If it didn't work, we quit doing it the following week. If someone wanted to learn about a certain technology by taking on a bigger chunk of a problem, even though it would probably take longer, we were all allowed that ability. I learned so much working for a team that let me dive into anything and everything, and value that experience high above anything I've learned on my own.

---

Give your developers the ability to jump in where they're needed AND where they're interested. Be ready and willing to have tough conversations with teammates if it means you'll be more efficient and happier in the long run. Have an honest conversation with your team about culture and what everyone thinks is most important. Keep the feedback loop open between everyone in the company if you can.