Before joining DAI’s Center for Digital Acceleration (CDA), I worked in the software development industry. For the majority of my 15 years in this field, I only worked for tech companies whose main business model was building software. To successfully build software, there are multiple practices and skills that companies need. These skills are, for example, agile methodologies and good coding practices (such as patterns and documentation) that often vary from company to company and the type of technology used. Other practices include daily meetings and specialized resources for each phase of the software development process. In addition, there are roles such as back-end developers, front-end developers, DevOps, scrum masters, graphic designers, UX designers, and more! From this, you can see there is a lot that goes into making even a small web application. But, what I have just described is the experience of working on very large teams that only make software, which is very different from work within CDA’s Products team.

Eduardo Gonzalez is a Senior Software Developer for CDA's Products team and is based in Costa Rica.

Difficult Transitions

As you can imagine, arriving to a small, three-person development team at a company like DAI—not a software-centric company—was challenging for me. I missed the processes that I was used to. I missed having a large team where different roles were highly specialized. I tried to implement software development-specific ideas, but some of them were just more difficult or too impractical to implement on such a small team building smaller products. I felt confused and wondered why this transition felt so challenging. It took me some time to realize that not all the methodologies that I used to build software would be relevant in this environment and that not all software needs to be developed in the same way.

The CDA Products team is more focused on solving many highly variable problems, problems whose solutions usually involve support on a web application. Often, the application is not the main focus of the problem a project is trying to solve, but a pivotal tool to help the project achieve larger goals. Data, charts, graphs, and forms to capture data and content are more important than any other functionality. There is also a common theme among the solutions CDA creates for projects and common issues to be solved, so we don’t have to build a solution from scratch every time and can rely on open source solutions to deliver products that help make projects more efficient and productive.

Switching Gears

At a tech company, if you are a developer like me, you focus mostly on one thing: making code with quality. You can take enough time to have an elegant code solution, and you can take even more time to review that code with your coworkers to be sure it is according to the coding company standards, but at DAI there is a bigger picture to the work we do. My role expanded to include engaging with stakeholders to figure out what needs they have and what problem they want to solve. Once the solution is identified, rapid development is the standard request, and usually, it is a complete solution, not just a minimal value product (MVP). I also give support to internal solutions that my teammates will use while mounting and maintaining servers as needed.

I have learned a lot of things since I have started at DAI two years ago. I moved from a software-focused solution role to be more open to all kinds of solutions that may not even need software or an internally made software solution where I can provide advice to projects to achieve the best possible outcome to deliver on their goals.

All of this is to say that at DAI, my team relied on me to expand my role and use my 15 years of experience to help the small team deliver high-quality products in a demanding environment. It has been an eye-opening experience. From the roles and responsibilities that I laid out at the beginning of this post, I have now taken on perhaps 90 percent of them at CDA. Now that CDA Products has grown far beyond just three team members, implementing software-specific team management practices is more practical than ever and beginning to take shape. New team members are taking on more specialized roles and can deliver higher quality outputs. With this in mind, I look forward to leveraging more of my software development experience as the team grows.