My Journey From Small Startups To SSENSE: Transitioning to an Enterprise-Scale Tech Company
Introduction
In software development, you cannot escape the recurring debate between choosing a small startup or siding with bigger tech companies. Is the learning rate effectively higher in small startups? Do you really have more mission-critical responsibilities at small startups? Do they offer you more autonomy and the chance to make a more meaningful impact? This article does not aim to cover every argument and list all the pros and cons in relation to this matter. Rather I would like to present my experience and highlight a few notable points.
The Common Worries
For almost 8 years, I worked for small tech start-ups with fewer that 20 developers. Last April, I joined SSENSE as a software developer and have been working in the tech department since, along with around 120 tech professionals.
Rightfully so, before my first day at SSENSE, I was excited to join the multidisciplinary workforce comprised of extremely talented developers. I was also very eager to work with the microservices architecture of a modern tech company. However, I was a bit nervous about joining what to me was a ‘big’ tech company. Here is what I feared the most.
A Difference in the Software Developer Role
In my previous work experiences, I became accustomed to autonomously handling a wide variety of tasks beyond software development like basic DevOps and SysAdmin tasks, a little bit of database management, architecture, etc. I knew that even if my title read “Software Developer”, my day to day work would be filled with a lot more than software development. Adaptability and autonomy are always highly valued in small startups, but what about enterprise-scale tech companies? I feared that the possibility of having specialized experts for every domain would make my generalist profile irrelevant.
The Prospect of Less Autonomy and Narrower Responsibilities
I had no experience in companies larger than 20 employees. I did not have any clue about how organizations were structured at mid-sized to large companies. I imagined very well-defined roles with clear boundaries and a lot of processes to run well-oiled machines. I was afraid of having to follow a lot of processes and having a less meaningful impact.
A Potentially Reduced Learning Rate
You might already be familiar with the notion of small startups being better for learning due to their focus on cross-functional work and autonomy. The idea of being confined to a very narrow domain within a specific project at a large organization was also disconcerting for me.
Overcoming the Skepticisms
Having worked at SSENSE for a while now, my reflections on these discussions are as follows:
Agile and Scrum Methodology
Nowadays, Scrum and Agile methodologies are widely adopted, regardless of the size of the company. At SSENSE, as was the case in my previous jobs, my agenda is filled with Agile meetings such as ‘Grooming session’, ‘Sprint planning’, ‘Sprint retrospective’, ‘Stakeholders demo’. And the roles are the same too. You can find roles such as: product managers, tech leads, scrum masters, and application managers. As a software developer, your role and your work routine can be very similar, irrespective of the size of the company.
To dive deeper into the tech department’s organization at SSENSE, have a look at this interesting article by Fabien Loupy, our Senior Director of Product Management, Engineering, & UX.
To get a feel for how the Agile methodology is applied at SSENSE, please read this article written by our Scrum Master (and Agile Facilitation guru), Osama Al-Eryani.
Wondering how to apply the Agile methodology for data science? This article by Graydon Snider, a Data Scientist at SSENSE, is for you.
Microservice Architecture
At SSENSE, we work in a microservice ecosystem. To me, it is a real opportunity since in small startups, the setup and monitoring cost of a microservice architecture is often too high, and monolithic systems are often preferred.
As a software developer, working with a microservice architecture has many benefits. The one benefit I want to stress here is that it offers relatively good functional isolation. Once the contract of the microservice you’re working on is well defined, you are fairly autonomous in the implementation, maintenance, and monitoring of the microservice you’re responsible for. Even in a tech team of around 120 people working on more than 17 microservices, the isolation works pretty well. As a software developer, you can focus on a reasonable amount of code and have a meaningful impact within the organization. Code quality, test coverage, logging, monitoring, maintenance, and documentation, all fall under your responsibility. Of course, there are guidelines prescribed by the architects and technical directors, but these are flexible enough to offer you a lot of responsibility and learning opportunities. In particular, at SSENSE you are responsible for the roadmap of your services.
Interested in learning more about how architectural decisions are managed at SSENSE? Our software architect Hugo Pelletier explains the process we went through here.
The Inner-Sourcing Initiative
An interesting point about companies with several teams is that they can simultaneously undertake several projects, each of which might be addressing a different problem with a different tech stack. However, often due to a lack of communication, mismanagement, or poor policies, the visibility of these projects are limited to very few people. As a software developer, you often have access only to projects within your scope of action. If you want to see projects handled by other teams, you’ll often need to follow some special protocol to request access. This can deter intellectual cross-pollination, collaboration, and cross-functional exposure.
In order to address this problem, companies now adopt inner-sourcing practices, by means of which a code-base owned by a certain team might have contributors external to that team. At SSENSE for example, every tech project is listed, documented, and the code source is available to everyone. As a software developer, you are encouraged to participate in projects outside your scope. You can review code, contribute with pull requests, and see how others tackled a specific problem. It is a great way to learn.
Career Management Processes
Personally, what I have found most destabilizing during this transition has been the career management process. In my previous job experiences, after a short evaluation period — basically once I gained the trust of my colleagues and management — I was granted significant autonomy. Only when a new job opportunity became available, or when a reorganization was due, did we sit down to discuss new roles and mobility prospects.
In fast growing companies, due to the abundance of career opportunities and available positions, the mindset is different. You are encouraged to proactively define where you want to go. SSENSE facilitates this through the Career Management Program, by means of an Individual Development Plan. This starts by defining your role, responsibilities, domain expertise, team, etc. Your manager then helps you define your objectives, prepare you for future challenges that you’ve identified, and look for a position that best fits both your goals and your skillset. You are then encouraged to ask your colleagues for anonymous feedback to help you grow in the right direction. Moreover, there are in fact more processes than I was accustomed to, but when adhered to, these can help structure your career mobility and be very rewarding in the long run.
Individual Development Plan
It is a common notion that the learning rate is higher in startups than in bigger companies. It is true that if you work in a start-up with limited means, you are often asked to work in unfamiliar domains with very limited expertise, and you are often expected to train yourself. And, in general, it is also true that in bigger companies, you can count on the support of experts that can handle specific tasks for you. However, in larger organizations, you often have more resources to work with, experts to support your development, more business cases to understand and study, and the opportunity to work on different projects over the course of your career.
In fact, I would argue that the learning rate is not correlated to the size of the company but rather to its rate of growth and its policies regarding training, employee development etc.
What I appreciate at SSENSE is that learning is highly valued. There are several projects within the Tech department aimed at fostering growth, such as:
- SSENSE University: An internal program consisting of workshops and lessons on specific subjects, some technical and some business related, conducted by domain experts within the organization. There are approximately two or more sessions per week, and these are accessible to all employees for free.
- The Inner-Sourcing Initiative: As discussed in the previous section, this initiative allows all software developers within the organization to access and contribute to the documentation and source code of every project. As mentioned earlier, this is a fantastic way to accelerate your learning curve.
- Internal Mobility Program: Each tech team has a specific responsibility which can be technical or business related: data engineering, data science, recommendation engine, compliance, checkout, finance, etc. If you are interested in learning technical and business aspects handled by a specific team, and if there is room for one more developer, there is an internal mobility program that allows you to easily switch teams. This internal mobility program is further facilitated by the inner-sourcing initiative. Before jumping into another team, you can check out their work and processes.
- Regular performance evaluations: Feedback on your work, objectives, and performance are regularly provided to you by your manager. Your manager is also there to help you define objectives and achieve them. They are available to find a position that best suits you and your skillset, and to ultimately help you grow.
Pragmatic and Transparent Processes
Working in a tech department with a lot of people requires some increased organization with guidelines and processes, more than what you might be used to at smaller scale companies. I’ve learned that these are a necessary prerequisite to building high-quality solutions. There are processes to manage and regulate software quality (testing, monitoring, QA environments), production deployments, application monitoring (logging, data management, etc.), and more. These processes are designed in a way that is easy for developers to accept and adopt. To ensure this, processes are tailored to be:
- Pragmatic: You cannot be asked to deliver a high-quality software without having enough time to spend on building a robust design, implement tests, going through proper QA phases, etc. You also cannot apply the same quality standards to infrequently used legacy projects and critical projects with up-to-date stacks.
- Transparent: Everybody needs to understand the goal of each process along with how and why they have been put in place
- Contestable: Flexibility is required in order to allow room for improvement. It is possible, as a software developer, to challenge a process, and propose improvements.
Conclusion
It is a major challenge for mid-sized to large tech companies to get every developer on the same page in terms of quality, procedures, conventions and efficiency. Nowadays, a lot of technical and managerial solutions exist to address these problems:
- Agile and Scrum methodologies help to get things done smoothly
- Microservice architectures allow for structural isolation and precisely defined integrations between different services and squads.
- Inner-sourcing initiatives improve both code quality and developer engagement
- HR processes such as an individual development plan helps define structured career tracks and mobility programs.
- The transparency of information increases process adoption and improves logistics
Even if you have no experience working for a tech company, some of the larger ideas presented can be applied to a variety of fields. Nowadays a lot of solutions are adopted regardless of the size of the company. The work environment changes but the role of a software developer can essentially remain the same.
Editorial reviews by Deanna Chow, Liela Touré & Prateek Sanyal.
Want to work with us? Click here to see all open positions at SSENSE!
