How Your Architecture and Infrastructure Can Make (or Break) Your Team’s Productivity

JASON LENTON All right. Hello, everyone. And I am super excited to talk to you today about being productive by default. And what I mean by that is I want to talk about how the architecture you choose for your team and the infrastructure you put it on can make or break the productivity of your teams.

I've got a lot of ground to cover in seven minutes. So let's get right into it. First of all, our primary goal as a company is to ship value to customers quickly. The way that we succeed as a company is to produce something people want and get it to them fast so that we stay competitive and so the people want to continue paying us for our services. And teams want to ship. By default, teams want to get things out the door. It's very fun for us to see things go live.

So what stops a team from shipping? There are a few things that we're not going to talk about today like building a foundation of trust and making sure you're taking care of your people. I'm going to assume that you are doing that work because if you don't do that work, none of the advice I'm going to give you today is going to mean anything. But assuming you've got that in place, let's talk about your infrastructure. If your infrastructure and processes are frustrating, if they are fragile, if they are slow, if you have to go through a whole bunch of hoops and gatekeepers and checks and different teams and you're only able to deploy once every few days or maybe even every few weeks, that is very frustrating, fragile, and slow. You may have actually seen them talking about this but there's a good chance they've been using the acronym FFS, frustrating, fragile, and slow. Complexity is a lot of what leads to these frustrating, fragile, and slow systems. We are trying to do very complex things with our code and our apps but if we're not careful, that complexity starts to turn into sprawl and bureaucracy and that fragility. Let's talk a little bit about how complexity can affect the team. So first of all, complex system is going to slow down a developer. If a developer has to ask for permission to do part of their job, if there are things in the front end that require them to move into the middle tier or the back end and they have to ask for permission from a back end developer or wait on a DevOps engineer or start looking for other teams to take care of pieces of the work. It's going to slow them down. If you've got teams that are working in complex systems, you start to develop knowledge silos. You've got this problem where a team is going to be working on something and they're the only ones who know how it works. And worse if that team has someone who's the only one who knows how it works, that means that the entire team can get stuck if one person is out. That's no fun. It creates a lot of pager duty. It makes it hard for people to go on vacation and it's hard to create autonomy. Complex systems also slow down companies. A key cause of bureaucracy is complexity.

If your systems are fragile, you start to put processes in place to control that. And if you put those processes in place, it can lead to your entire company becoming much slower. As things get slower, people are going to start slowing down on their deployment velocity because they don't want to go through that process. They'll put more and more changes into each deployment. That means each deployment gets bigger, and therefore more fragile, which means more things break.

Decoupled front-ends reduce complexity. Now your front-end developers get to be front-end developers. If you are decoupled and deploying to the cloud, you suddenly don't have a whole bunch of DevOps steps and managing node servers and figuring out how Docker and Kubernetes work for front-end deployment. You get to build a front-end, deploy it to Git, and CI-CD takes it live because it can be deployed with low risk to a CDN. Pre-compiled front-ends are going to reduce fragility. There are fewer moving parts. There are fewer servers being used in production. There are less things to break, which means that you can control that risk. It also allows you to do things like create immutable deploys, where each compiled version of the front-end is its own folder. So you can quickly roll back if something goes wrong with one click. That's a huge benefit.

Teams can just go live once they get a PR review instead of having to wait days or weeks for other teams to go through the process. And serverless functions reduce boilerplate. If you need to do something, like make a privileged API call, a lot of times this would fall into this middle tier, where it's hard to assign that to the back-end team, because it's an API that's only used for the front-end, and it touches data from multiple back-end teams. So it's not clear who owns that, and a lot of times it will fall to the front-end team. If you use serverless functions, now your front-end team is not dealing with Node and setting up proxies and setting up Docker and Kubernetes. They're just able to write some JavaScript and deploy that and get that privileged API call that they need to make really quickly. The big benefit of all this is that you don't have to think about servers, you don't have to think about DevOps, you don't have to think about rollbacks, you don't have to think about scaling, you don't have to think about caching, any of that. All your front-end teams need to think about is shipping. And that's why this model, by choosing an infrastructure that is giving your teams the ability to focus on just the front-end, that is letting them focus on just the bit that they're actually experts in, and letting them remove all of those extra dependencies, and that extra complexity that sneaks in when your front-ends become too complex. That is what makes teams really, really productive. And what that means for us at Nellify, for example, is that you can deploy to production not just daily, but multiple times a day. This is the Nellify app, app.nellify.com. It's not a marketing site.

It's not a marketing site. It's not a one-off property. This is the absolute core of our business. And our front-end team is able to deploy as soon as a PR is merged, four deploys within the span of about five hours, six hours. That is an incredible velocity for a production team.

And that's not irregular. We see this happen to teams that adopt the Jamstack all the time. And I think that it's something that will be just as successful if you bring it into your team. If you want to build a culture of shipping, you need to create the architecture that supports it. And that's really, really important.

Because if you put an architecture in that is frustrating, fragile, and slow, your developers are going to be frustrated. They're going to see things break and they're going to be slowed down. They can't ship as fast as they want.