Welcome to my professional narrative. I am André Paris, an IT connoisseur with a robust track record spanning over 12 years. In the realm of technology, I've donned multiple hats – from a fervent software engineer who relishes the intricacies of code to a strategic leader who steers teams towards excellence. My latest venture involved pioneering the IT department for an up-and-coming Mexican startup, transforming it from a fledgling operation into a paragon of success. I'm excited to unfold this chapter of my journey and share the insights garnered along the way.

Introduction

In this article, I want to share some insights about my journey in structuring a lean and successful IT team at a startup. I’ll discuss what helped me along the way, including the challenges I faced, because as we know, the path is not always easy and often requires tough decisions. My aim is to empower readers by showing that they are not alone in navigating these difficult processes and that there are numerous methods and methodologies to overcome obstacles and achieve their goals.

Firstly, it’s important to recognize that startups are typically fast-paced and subject to frequent changes. They are focused on achieving results to reach the break-even point and thereby justify the investment to ultimately realize actual profits. The experience is akin to running a marathon in the midst of a hurricane—a long and turbulent journey, often with little time to organize internally, focusing only on the essentials.

This chaotic environment is the reason many startups don’t finish the race. Organizing internally should also be seen as crucial; without it, it's impossible to fully understand what is being left behind. And when that clarity is missing, we often overlook what’s truly important for survival.

How I Organized a Successful IT Team

The Beginning

When I joined the startup, the team consisted of three developers, one product manager, and me, all working remotely. Initially, my role was to be the Tech Lead. However, in a startup environment, the job description (JD) is just a starting point, and roles often expand. At that time, we had an external company assisting with scrum organization, led by a supposed scrum master. This person would only show up for the daily stand-up, bluntly asking the developers about their tasks. Post-meeting, everyone would return to their work in silos, with no further communication.

My first task was to turn these individual developers into a cohesive team. To do this, I established an end-of-day alignment meeting with just the developers and myself. My goal wasn’t to add another daily stand-up but to foster better relationships and camaraderie among the team. In a small company like a startup, forming strong bonds is crucial; with few people handling numerous tasks and everyone always on the run, a supportive and empathetic environment can alleviate pressure and boost productivity.

This approach significantly improved the team’s mood, productivity, and engagement within weeks. We had six months to deliver a product sold to investors, and with only three months left, over 50% of the work remained. This small change made it possible to deliver the project on time with a true team.

Growing the Team Requires Establishing Processes

My next step was to professionalize as a scrum master and delve into IT governance. I began by properly implementing scrum within the team, ensuring that all scrum ceremonies were respected. Initially, the product manager would score the stories themselves, which seems unbelievable but was the case. This PM was resistant to establishing retrospectives, so I had to postpone that ceremony. Nevertheless, the developers became more engaged, seeing that their department was heading in a positive direction.

Then I started studying IT governance, exploring methodologies from the traditional COBIT and ITIL to IT4IT, a new framework designed for startups. I created excellent material and presented it to my boss. Unfortunately, he couldn't envision it within our structure, as his focus was solely on results, without consideration for these unfamiliar topics. This didn’t completely discourage me. I implemented much of this framework. Now we're talking about a startup with an engaged team, a scrum process that's almost authentic (no retrospectives 😔), and a structured governance process.

As you can see in the image above, implementing this requires analyzing and structuring many aspects of IT, from strategic portfolio management to incident management. To make this possible, I had to become a DevOps practitioner. I started by addressing the most critical aspect of our daily operations, the transition from Requirement to Deploy. For this, I set up CI/CD pipelines, then organized the cloud infrastructure, segregated environments (dev, stage, and prod) into separate accounts, established access levels, and created a process for bug resolution (you can imagine that a system built by four people over six months consisting of two web portals and a mobile app wouldn’t be perfect). Unfortunately, I haven't yet succeeded in implementing a testing culture; currently, all testing is done by the PM and COO, who aren't ready to delegate this responsibility.

The next critical step for business continuity and success was establishing the Detect to Correct process. Initially, we created a system where all errors were reported via Slack. Additionally, we had manual tests to fix errors before production deployment (thanks to the Requirement to Deploy process). However, with a freshly developed system, many errors began to surface and were reported by the operations team through Slack, which meant many were not resolved, leaving the development team disheartened by having to deal with random bugs, which often were not bugs, but rather users unfamiliar with the system.

To address this, I first created a dedicated Slack channel for centralizing these issues. Then, I established a ticketing system, and after much research, I chose Freshdesk for its excellent cost-benefit ratio. Getting the operations team to adopt it wasn't easy or immediate; it required training them, but it worked excellently. During this time, I took on the responsibility of being the first point of contact for tickets, to structure the area further. This, again, led to tremendous engagement from the developers, who became fully focused on their tasks and thought processes in architecture. Eventually, I hired two people to handle these issues.

Moreover, we implemented Datadog. With this tool, we were able to greatly enhance bug alerting, manage system latency, and develop a log system that incredibly sped up error detection, directly impacting resolution time and highlighting the importance of log systems. Thus, we resolved all the steps in this box of the IT4IT framework.

The next step was to structure the Strategy to Portfolio. Unfortunately, we did not have a very organized product team, which meant demand management was always an issue. Another important consideration is that, in a startup, the product constantly changes, and the priority of items seeks to meet customer demand. As IT, what we can do is mitigate. I introduced a bureaucracy ensuring that the product team always had their stories defined and scored (using Scrum's Fibonacci sequence). At first, we faced many problems because the product team didn't understand this; they would always change the stories or ask for activities without refinement by the team.

To clearly define demand management and refine the portfolio strategy, it was necessary to progress with the Request to Fulfill. Besides the deployment points and product measurements involved here, this also relates to the process and team management since measuring their capacity is extremely important, even for a startup. In our case, I established this with the Fibonacci scoring of Scrum. Based on this, it was possible to have an average of how many points each team delivered per sprint and create a product roadmap for the first stage.

Having consolidated this, we successfully achieved international certifications, ISO 27001 and SOC2, which I was able to manage alone, from hiring the audit supplier to implementing and making the necessary corrections. This was only possible because we had an organized IT department.

It’s also important to note that culture is something that should be valued. Throughout this process, I conducted 1:1s with the entire team, always asking how to improve IT and myself. Without the right feedback, we might never have achieved our goals.

It's essential not to forget that in a startup, we must all work together, as a team, rowing towards the same goal. These types of 1:1s should not only be done with your own team but also with all areas to improve communication between different teams. Yes, it's a difficult process because it's part of educating towards better processes, but after significant effort, I want you to know that it can be achieved.