2021: Daring to dream and grow

If you already explored what we have done in 2020 (here), you already know that we achieved way more than we planned for and that we evolved a lot as a team, and as a “working machine”.

Planning the future is not an easy task. There are lots of unknowns (looking at you, 2020) and uncertainty, lots of trade-offs between being nimble and deliver what’s expected, and way more questions than answers.

However, I’ve always heard that the future belongs to those who dare to dream it so if you dare, join us in this adventure! Together, we’ll crack the challenges that 2021 will throw at us.

The challenges of growing

One of the things we validated during 2020 is that multi-disciplinary teams achieve a greater level of autonomy. When they are not distracted by an extra scope, they are a force of nature when it comes to delivering. When we talk about multi-disciplinary, we are not only referring to Backend and Frontend, but also to Quality Assurance and Product, at least. For that reason, we now know that the recipe to scale our teams is to replicate the successful model we have today. However, that replication alone is not a guarantee of success.

The reason we want to grow our team is that we want to deliver more, with (at least) the same pace we were delivering before. Many times, more people doesn’t mean more work delivered. There are different challenges when scaling from 12 to 30 or from 30 to 60, and so on. That said, in order to keep the pace, we need to be aware of some challenges that we are already foreseeing.

#1 Preserve the social side

We can’t grow the team if we don’t take care of the team we already have. We try our best to keep everyone engaged, but 2020 was a challenging year when it comes to social events. We know already that this challenge won’t disappear so easily in 2021, but at least we are aware of it. We will keep creating more opportunities and events like the Hacktoberfest 2020 to allow everyone to have fun together, learn and discuss topics that aren’t work-exclusive.

#2 Pipelines run time

In 2020, we introduced pipelines, which was a major achievement for the whole team. Now, we rely heavily on them every day. Lately, we have seen that pipelines run time is getting longer and longer, as more tests are added to it. With the team growing, we expect the rate of tests added to grow significantly as well, making it worse.

There are some things we can do to improve the pipeline speed:

• More parallelism for running each pipeline, which means that we will be throwing money into the problem;
• Move towards unit testing instead of integration testing;
• Use an in-memory database (SQLite) to run integration tests instead of Postgresql;
• Break the monolith. That doesn’t mean microservices! It means that we should move our code to a more Domain Driven Design architecture, in order to run only the relevant test suites.

#3 The culture of learning

For us, learning is the backbone of every team. There is nothing more powerful than a team of restless people, eager to learn new things and share them with others. But you can’t enforce the culture of learning on people, you have to feed it in order to make it grow, which is a challenge by itself.

When we started our “Internal Learnings” back in 2019, we were 8 people. At that time, these sessions were a “safe space” for anyone to present a topic to others. Currently, with a team of 30 people, that “safe space” might start to seem a bit daunting to some. It is probably time to rethink a new version of our internal learnings. Moving it to a more “area focused” approach (the Mobile team is already doing it), and then launching an internal cross-functional conference once in a while might actually be a good solution!

We also learned that giving visibility to people on what’s happening is a good approach to increase response. Having a well-organized calendar with possible events for the team to participate in might help raise awareness for the topic. Pet projects, engineering roadmaps…. although it’s still not clear exactly what and how to do these kind of initiatives, we do believe that creating the space for it is going to be a huge motivational boost to keep everyone on the learning path.

#4 Monitoring

Monitoring was the area we lacked the most in 2020. We had some tools implemented, but we didn’t push for the ownership of those tools. We tried to implement Prometheus, and we ended up abandoning it. We finally settled with Elastic at the end of the year.

If we want to shift our mindset from reactive to pro-active, keeping our system and application under the team’s responsibility is key. We need to start by implementing processes so that our SRE team is on top of system health, and our functional teams gain ownership of the application metrics.

Having monitoring tools alone won’t fix the issue. Defining specific goals is a great way to steer the team towards the direction that we, as a company, want to follow. Each team should have its own key metrics to focus on. And while these are not yet defined, one thing is certain: our clients will always be a priority to all of us.

#5 Infraspeak Network

This has been a dream of ours for a long time, now. 2021 will be the year that will take us where no one has gone before. We will connect the maintenance world, and it’s going to be huge (stay tuned!).

Past experiences showed us that this won’t be a ride in the park, but we also learned where the problems lie. The first thing we need to do for a project like this is to lay down exactly what needs to be done, to identify the problems we had in the past, and to create a team to start brainstorming about solutions.

Along the way, we will probably need to rethink our permissions system, and how we output data based on the user requesting it. We will have to create/adapt our infrastructure to accommodate this idea of connected entities, and we will have to make important changes in all our clients, web and mobile.

Lots of work to be done! However, in the end, we’re pretty sure that we will have something unique, from which our clients will surely get a lot of value from. In the meantime, we will learn a ton and have loads of fun doing it!

#6 Documentation

“Lack of documentation” was the most common complaint among our team, when we got together to review the year. And although this is true, we actually got better at it during 2020. We started producing our first ADR’s, RFC’s, workflow diagrams, process documentation, etc... and the standardization we introduced into the codebase also helped new team members to have an easier onboarding, even remotely.

Although the lack of documentation is, indeed, a reality, (and that is not, unfortunately, something new), it will only get worse if we don’t tackle it asap. On the other hand, “lack of documentation” is very vague. It can have different meanings for different people: Is it business logic? System architecture? API documentation? All of them?

The plan is to start by defining exactly what do we mean by “lack of documentation” based on one question: “What kind of documentation will be useful to us, at this point?”. After identifying what we need, we will have to change the processes in order to incorporate documentation, since it should not be any different from writing a test or creating a pull request.

#7 Modularized codebase

Our current API architecture (monolith) has served us well so far, and we hope it continues to do so while we keep refactoring it to a more Domain Driven Desing approach. Having code separate into Domains have many advantages:

• Clearer code base, easier to understand by new team members, even with poor documentation;
• Easier to see boundaries and connections between domains. This will open the door to thinking in a different architecture in the future;
• Fewer conflicts;
• Faster pipeline if domain is self contained.

In regards to our web client, its architecture is already way closer to a component system, but it’s not there just yet. We should start our first POC during the first quarter, to learn if our idea of creating separate repositories for each layer of the application is actually good in the long run.

Having independent frontend components will allow its reuse in other web applications, like Infraspeak Direct and Infraspeak Operations, which is great for maintainability and evolvability.

With respect to the legacy codebase, the Android team is the one having the hardest time for now, but they are moving towards a completely decoupled architecture. It will not only make it way simpler to implement new features, as what happened with Gatekeeper, but will also open a huge door: having modules that could be used by both Android and iOS devices!

#8 Quality

In 2020 we got to confirm another important thing: quality is also speed. We speed up because we have fewer bugs. The teams are less distracted, allowing them to focus on the current scope. And we get to speed up because we have dedicated team members just to assess the quality of what’s being produced.

We learned a lot about our QA team, processes, and objectives during 2020, and we now have a clear path for 2021. We will mainly focus on developing our E2E tests on Web and Mobile. We should start with our most common use cases (our “Golden Paths”), and once the framework is set in place, we should expand to new and existing features. With the growth of the functional team and implementation of X-Ray, we will also focus on test case creation.

Our QA team has ambitious goals for 2021, and spreading knowledge about automation should be a great challenge to everyone. We are very curious to see everyone’s evolution!

#9 KPIs

Another great learning is that giving visibility over our KPIs to everyone helps ensure that everyone is aligned and and aware of our top priorities. In order to improve that visibility, we launched our Engineering Dashboard. It served us well for some months but, due to process changes, it is now obsolete. This means that we will need to create a new one in 2021.

In terms of KPIs, 2021 will be very similar to 2020, with some refinements and additions. We will start the year with 3 main KPIs

• Lead Time for Stories and Tasks (refined)
• Lead Time for Critical+ bugs
• Operational Costs (refined)

and 4 secondary

• Total Costs
• Pipeline Run Time (new)
• Change Failure Rate (new)
• Open bugs (Major+)

These 7 KPIs focus on 3 different areas: Quality, Speed and Costs.

It’s never enough to remember that KPIs are used to collect insights, make changes, and measure the impact of those changes. They are a powerful learning tool and they allowed us to learn a lot about our teams and processes during 2020.

Moving forward together

Wrapping up, these are our challenges and dreams for 2021. As it is normal when we’re daydreaming, some details are foggy and incomplete, but that’s OK. The main purpose of each dream is to inspire us, to make us believe that anything is possible.

We know that 2021 will be challenging, but we also know that we have a great team, that will surely enjoy dealing with all the challenges that this new year will bring us. In 2020, we proved we are capable of a world-class execution. In 2021, we’ll keep rising the level, while we create room for learning and tackling down big Engineering challenges.

Last but not least, let me tell you that everything we did so far was built on top of a culture of feedback and transparency. We believe that everyone has the responsibility of building and shaping the company’s future, and we are opened to different ideas, bolder inputs, and unpopular opinions. That said: we are much pleased to hear all your thoughts and feelings about what’s coming ahead!

— If you wish to be part of this great team and help us fulfill this vision, we have 20+ openings at the moment for the Engineering & Product Team.