Authority and Responsibility in Early Startups

Four months into joining the company, I have effectively been granted all the system permissions. I can control and modify everything necessary for development, including backend, frontend, AWS, Git, apps (Play Store, App Store), web, and databases.

Recently, I accessed the company’s AWS server to develop and deploy an authentication proxy that wraps around the backend. I modified the apache conf to assign a subdomain to the proxy port. Everything was fine up to this point, but

a bug occurred due to a mismatch in the npm version. To fix this, I needed to run an apt update, but the problem is that this is a production environment. If something goes wrong, it could jeopardize the company. I’ve had more than a few experiences where poor dependency management in production led to crashing my home server, so I’m very cautious.

In fact, such issues can be resolved with container deployment. My home server is entirely set up this way. By setting the necessary dependencies in a Dockerfile, it operates only within that container. In hindsight, the company’s system is more vulnerable than my personal home server.

The more authority you are given, the heavier the responsibility that comes with it. I want to create technical challenges and good systems at the company like my home server, but from a long-term perspective, such technology can become more difficult to manage. For a startup, it might be better to manage legacy systems well rather than adopting technology that cannot be sustained.

However, if you only manage legacy systems, the team’s productivity will decline. An organization without technical challenges is bound to fall behind in competition and fail to embrace new changes. Ultimately, you have to do both. You need to manage legacy systems while integrating new technologies and constantly experimenting. This spirit of challenge is a crucial factor that drives startup growth.