Working at a Startup is an exciting opportunity for developers eager to build from scratch, pitch new/crazy ideas, and be part of a scrappy team that is looking to solve complex problems. Even though developers at startups are one of the most valued assets, it is also known that no all developers match their needs and expectations, and in some cases their work structures. In this blog post, we worked with our CTO, Victor Baumann, to share some tips on how to be a successful developer at a Startup. Welcome!
First things first, we want to introduce Vic, our CTO, a Swiss software engineer – passionate about music and mildly alcoholic beverages – with 15+ years of experience across multiple industries, living in Bogotá, Colombia since 2016. He joined our group to lead the tech department of one of our ventures, Vincu, a recruitment platform that leveraged data and algorithms to deliver highly matched candidates.
After 4 years in the role and the closure of Vincu at the beginning of the Pandemic (shit happens in entrepreneurship), Vic transitioned to Aflore to help their technology team grow and tackle the necessary product adoption to the new reality and eventually to Polymath as CTO with one single goal; to improve engineering across the group. This means defining the development strategy for future ventures, working along existing ventures to understand obstacles and provide quick, efficient, and innovative solutions, and overall build a stack of solutions that allow the healthy growth of our portfolio and our group.
developers at startups: How to get started?
I actually ended up in this career sort of by accident. During all of my early adolescence, my goal was to become an industrial designer, interior architect, or concept artist but unfortunately did not pass the entry exams for the art schools, mostly due to a lack of perseverance and focus at that age.
Since I always liked dabbling around with computers and having done some minor programming on my own, becoming an application developer felt like a decent second choice to have some career to get started and maybe later pivot away from.
Only after having been programming for a while, I fully became aware of its creative and craftsmanship aspects as well as the enormous potential of code, to create almost anything I can imagine with little more resources than a computer. Which was especially impactful, since my family was economically struggling at the time.
How did you get to Polymath?
I never could have cared less about the job title on my business cards – the true luxury of being a software engineer is that you can have tremendously satisfying work and an excellent middle-class life without needing to grind up inane corporate ladders and turning into more of a politician than developer.
Based on this, all my career changes were based around continuous personal reflection, whether most of my day to day work is satisfying and interesting, whether I’m working with people that I feel we can advance together and whether the output of my work is actually useful to someone or beneficial to society. If I’m not happy with any of the above I first try to proactively induce change within the place I’m working at by proposing changes, learn about other areas, and involve myself in them or eventually if not viable, looking for somewhere else.
For the first 10 years of my career I went through different roles in a wide range of industries and types of companies; from backend to frontend to full-stack, worked for small, bootstrapped companies, large corporations as well as NGOs, government, and as a freelancer, and in different industries such as information management, marketing, journalism, and real estate. After this, I wanted to have a change in the environment itself, since I got a bit burned out in Switzerland for various reasons and started looking for opportunities in Latin America where I have extensively traveled before.
Polymath and its ventures called my attention, due to its focusing on strengthening the middle-class, which promises to be working on tackling systemic and societal problems at their root instead of putting pretty makeup on broken things. Nonetheless, I was very skeptical starting out, because everyone has bold claims on their website claiming how they are going to change the world, so I was curious if they could back up all the talk with actions.
And well, here I still am, 5 years later having worked with different ventures and now recently in my current role as CTO.
What are you trying to build at Polymath Ventures?
In such a highly dynamic and unpredictable environment we are working in, I do believe that agile software development is fundamentally the soundest way to build products and solve people’s problems. The main issue with it, as with other buzzwords like Lean, DevOps, CI/CD, etc. is that collectively in the industry we have almost forgotten why those exist, what real-world problems they try to solve, and how. Instead, we are often stuck dogmatically following rituals and wielding tools like magic wands expecting miracles to happen. They must work, right? We spent tons of money on books, certificates, and consultancy services that say so. Everyone says they are Agile, few actually approach problems in an agile fashion.
So instead of just having them as checkmarks for presentations for investors, continuously challenge ourselves to actually use those tools to actually generate value.
Having seen many times over that, what makes or breaks a project is not what technologies, architectures, or processes are used, not whether there are some brilliant visions, but the teams ultimately executing on it, the culture they create, and whether there is an environment that fosters their success. If you don’t have the teams that bring the right mix of skill and mindset, that enjoy working and growing together and are allowed to do so without being buried in bureaucracy, everything else is futile.
And lastly, working hard, solving difficult problems, and having fun, and enjoying are not mutually exclusive. Of course, it is not always possible to make everyone happy all the time and every job, including mine, has aspects that are unsatisfying but need to be done. But if the people don’t find pleasure and actually care about what they’re working on and who they are working with, we will not get anywhere.
As a CTO what do you look for in potential developers for Polymath?
Of course, for any position, depending on the seniority level, the problems the company is facing and the stage they are at, there is a certain technical hard skills threshold a candidate needs to pass. But those skills alone are not worth much. Beyond the bar, every technical skill that might be missing can be obtained on the job. So additionally, developers should show the following mindsets:
- Reflectiveness. Probably the most common way I have seen people stand in their own way of personal progress is thinking they have learned everything there is to learn, that their way of doing things is the best way to do things. Problem is, you are at best approaching a local maxima and should never stop exploring different ways, listening to other people, and understanding where you are or you eventually will get stuck.
- Team player and communication. You don’t need to be an extrovert at all and wanting to chit-chat or party with everyone all the time. But no lone ranger, no matter how skilled will solve the problems we are facing in isolation, it requires a team across various functions that can communicate with each other efficiently and effectively.
- Pragmatism. There is a huge tendency in the industry to start with a solution instead of a problem. People getting attached to certain tools and want to apply them to everything no matter what. If all you have is a hammer, everything starts looking like a nail. You often end up, instead of solving the problem, having a problem with another abstraction on top, which will soon turn into two problems. Instead, think about the problem and the context you are in and it will lead you to simpler, much more maintainable solutions.
- Adaptability. The saying that requirements will change in the future is inevitable is not coming from some startup hipsters in Silicon Valley or because business and product people can seemingly never make up their mind, but it is inherent to the field. There is a reason why agile and iterative programming concepts, under different names, started emerging in the early 70s from the first generation of software engineers. Instead of fearing or trying to avoid it, embrace it. Build things in a way so that they are easy to change in the future without breaking everything or starting from scratch, understand which parts of the system are more likely to change than others to architect accordingly, and avoid unnecessary complexity whenever possible. But also push back on people that want to change things without a proper justification. Always ask why before doing something.
What are your three most important recommendations for developers at Startups?
The biggest advantage of working in an early startup or small company is that you can wear many hats, be involved, learn about and shape every aspect of the company. Here is what we have learned about developers at startups.
- Learn about every aspect of the company. What everyone is doing, the pains they are facing, who the users are. This might sound uninteresting and not related to the profession at first, but without understanding the domain and the users you will not be able to design an adequate system. The only way to ensure what you are building is simple and not a pain in the ass to maintain, is by involving yourself from the beginning of the design process. Don’t be just a code monkey turning specifications into code.
- Be proactive. See the company, the team, and processes like software, something malleable that can always be changed and iterated upon. If you are unhappy about something, the fastest way to change it is just to start doing so. Talk to people, propose solutions, and prototype. Don’t wait for someone else to solve it for you and if necessary don’t wait for the approval. You might have heard that it is easier to ask for forgiveness than for permission. Of course, don’t just recklessly cause pain for others for personal gain.
- If you are not Google you are not Google. While it is very tempting and might look very good on the CV, to use some of the same tools and techniques like the large tech companies that operate at a planetary scale, they are almost never the right choice to start a new project due to the immense amount of baseline complexity, overhead and maintenance cost they add to the system. The reality is that it is a whole lot harder for a product to grow to, say a million users than it is from a technical perspective to scale up to be able to serve these as long as it is decently engineered. It is extremely unlikely that a startup fails because of a tech stack choice not being scalable enough. Care about the productivity and adaptability of the team, instead of worrying about users you don’t yet have.
As you build your path as a successful developer at startups, you must consider multiple factors in the equation; what do you want to build, why do you want to build it and whom do you want to join to make it happen. When you join a startup, you are not a regular employee, you are a team member with the ability to craft the future of the company, so getting in sync with the purpose is our best advice for your next career move.
Developers are key members of the Polymath team. We build digital solutions, so we need a stellar team of developers capable of challenging the traditional structures, curious enough to invent new solutions from scratch and with limited resources, and driven by the excitement of building.
At Polymath, it is not just about your experience, background, or specialty, we care about your way of thinking and your proven technical abilities. So if you are looking for your next challenge, or are just exploring what is around you, take a look at our developers opening.