Management responsibility is one of those strange things where the moment you get that job, you've spent your whole life usually doing something other than that job, and you now have to jump into this with no training to do what is often the most uniquely demanding job you've ever had prior to that. And the moment you move to management from whatever you did before, often programming, but, you know, whatever else, you're likely reaching for an entirely unique set of skills compared to your previous job. And managing finances is one of those universal things that managers across all

previous job. And managing finances is one of those universal things that managers across all types of organizations just have absolutely no preparation for. And, hell, most managers don't know how to manage their personal finances, let alone that of an organization. So, for the sake of this video, I'm just going to talk about what it costs to run the finances of the dev team, not the broader company or organization or agency. We'll assume that somebody else is either giving you a budget or they're asking you to make your desired budget to make your dev team work.

We'll assume that somebody else is either giving you a budget or they're asking you to make your desired budget to make your dev team work. So, when we're thinking about budgets for development teams, usually, even though you want to know the overall cost, the biggest questions around how much each developer costs to employ, not things that are shared across all the developers. So, we're usually trying to imagine, for every single employee, every single developer, what is the total annual cost to employ this person? As you can probably guess, salary is the largest part of that number, but there 's also other costs that scale up and down based on the number of developers

As you can probably guess, salary is the largest part of that number, but there 's also other costs that scale up and down based on the number of developers that you have and we'll cover those later. You're likely coming at these questions from either one of two perspectives. First, you might have a budget. If so, you're going to try to figure out the ideal arrangement of your team that matches that budget. So, go take a look at the earlier video about the ideal structure of dev team, figure out how to build a team that fits that structure within your given budget.

figure out how to build a team that fits that structure within your given budget. Or the second option is, you may have been assigned to build a team and you need to know how much it'll cost. And usually, it's not just build any team, it's usually build a team and we have a general sense of what we're talking about. So, again, just put together a team based on what we talked about before that makes the most sense in your general range. Combine that with what we're about to talk about with all the various costs of employing developers and then you will have a number or a range to provide.

Combine that with what we're about to talk about with all the various costs of employing developers and then you will have a number or a range to provide. So, either way, let's walk through the various costs that comprise this cost to employ this developer this year number. First up, salary. The highest cost on any development team is going to be salary. And unfortunately, I can't tell you what a reasonable salary is for your roles because it varies so heavily across different roles, different skill levels, different areas of the world. And so, it's just so unpredictable that I can't tell you what your specific

different skill levels, different areas of the world. And so, it's just so unpredictable that I can't tell you what your specific salary cost can be. But I can help you think about it a little bit and think about how salaries are going to impact your budgeting and your team building. First off, first thing you need to do is figure out what reasonable developer salaries are for your needs in your specific organization, in the geographic location and/or the remoteness that you're allowing. This is going to take those things into consideration and many other things, like are you looking for front end or back end or full stack?

This is going to take those things into consideration and many other things, like are you looking for front end or back end or full stack? What is your front end stack? What's your back end stack? What overall ability level do you require? You can have those different bands, those different roles, but you can go up and down within the roles. And are there any edge case skills? They have to know Kubernetes, or they have to be Microsoft experts or whatever. And also, think about the benefits that you offer.

They have to know Kubernetes, or they have to be Microsoft experts or whatever. And also, think about the benefits that you offer. That can have a pretty big impact on the salary cost as well, what other benefits are they getting or not getting? There is no easy formula I can give for you here. I wish I could, but you are going to need to do your own research here. But I can at least tell you, get started researching in Glassdoor, and also look at other companies in your general arena who list their salaries and their job postings. And some do this because of the kindness of their hearts.

and their job postings. And some do this because of the kindness of their hearts. Some do this because it's illegally required, but either way, that information is out there so you can do some research on there. I can tell you at least, in the United States, salaries tend to be grouped along a couple kind of different bands or groupings of them. So you've got brand new developers, they're straight out of college or they're straight out of bootcamp. You've got entry-level developers, which are sometimes differentiated from brand new because they might have a year or two of experience.

You've got entry-level developers, which are sometimes differentiated from brand new because they might have a year or two of experience. And they're probably not super professional, but they've at least done the job before. You usually have some kind of a mid-developer scale. And mid-developers are usually folks who have been doing this for two, three, five years. They're good enough, but they're not leading teams. And then usually, there's the senior developers. And seniority is not always just about time.

And then usually, there's the senior developers. And seniority is not always just about time. It's often about, you know, familiarity with the tech stack at a more expert level. It's about ability to lead teams. Also, it's about time. It's even sometimes about how much have they devoted their lives to this particular tech stack versus being generous. It's a lot harder to be a senior developer when you're a generalist. And then above that, you get the CTO level folks. And those are usually you.

And then above that, you get the CTO level folks. And those are usually you. They're usually people who are at leadership levels and you're probably not going to be hiring them because, again, they are you or they're people you're working together with. Each of these bands have a general kind of like range of salaries, they'll expect. But again, there's still a whole bunch of exceptions and caveats and variables that configure those. Even just down to the, are you working at an agency versus a product company?

that configure those. Even just down to the, are you working at an agency versus a product company? Huge shift between those same roles in each of those. So, figure out what those salary bands are in your area and your tech stack and all these other pieces and then figure out the roles you want to hire. Or if you would prefer, you know, you figure out the roles you want to hire based on how much those roles cost. When we first started to tighten, my first development hire was someone I spent a lot of time pouring into. And this is in part because mentorship is super important to me.

a lot of time pouring into. And this is in part because mentorship is super important to me. But also because even if I wanted to hire a senior developer, we couldn't afford one at the time. And it was actually quite a while before we could afford to hire a senior developer. Our first several hires were all people who I kind of helped into the industry. And, you know, we, they weren't all brand new, but none of them were at senior level either. So at some point, you're going to have the salary part figured out.

level either. So at some point, you're going to have the salary part figured out. You're going to figure out who are we hiring and how much should we pay for them. And you're going to understand the basics of at least salary. So after salary, what's next? Well, next is the physical hardware developers need to do their jobs. So I'm talking at minimum a computer, but this often includes a desk, monitor, chair, headphones, keyboard, mouse, the whole shebang. In general, you're going to want to have a guideline for what computer devs get

chair, headphones, keyboard, mouse, the whole shebang. In general, you're going to want to have a guideline for what computer devs get and how much it can cost. You may just have one fixed configuration they get or maybe a few fixed options they can choose from. And you're going to do the same for every other item they'll be purchasing and also a spec for when they do or don't get each of these items. Finally, you're going to have a general guess of how frequently those items will be replaced per developer. And that will help you do cost predictions, but it'll also help you decide how

will be replaced per developer. And that will help you do cost predictions, but it'll also help you decide how to respond if your dev team asks for upgrades. So here's what we do at Titan. First of all, for every item, we only buy it if it's needed. Do you have a machine that can do the job when you start here? Then use that for now and we'll buy you a replacement when it's time. Same for a desk, a chair, keyboard, mouse, whatever else. Second, we don't have exact items they have to purchase, but instead, general guidelines in a general price range.

Second, we don't have exact items they have to purchase, but instead, general guidelines in a general price range. So for computers, for example, we say it's a Mac laptop that should last at least three years as a daily driver, web development machine. And we have a max cost associated with it. But within those guidelines, the employee can configure it to their liking. For other equipment, we have different guidelines. We'll buy a $100 keyboard, but not a $500 clicky masterpiece. We'll help get a desk, but there's a few trusted brands that we think give us a good balance of quality and cost.

We'll help get a desk, but there's a few trusted brands that we think give us a good balance of quality and cost. We'll buy a chair, but we encourage everybody to get one of a few higher quality brands, but then get them refurbed or office resale. And then third, we do have some general expectations for these items' longevity . For example, for laptops, three years is a safe minimum, although we hope we get quite a bit more out of them. Disks and chairs, monitors, keyboards, mouses, mice, mouses. We hope they last longer and we use this information to expand our

Disks and chairs, monitors, keyboards, mouses, mice, mouses. We hope they last longer and we use this information to expand our understanding of the average cost per year of each developer, because we can now say how often we're going to have to replace each of these pieces of equipment and what's their general average hardware cost going to be per year. In the end, it is our goal to make sure every developer has everything they need to be productive and work in a healthy ergonomic workspace without going just hog wild and throwing money at every new hire. It's always a balance.

just hog wild and throwing money at every new hire. It's always a balance. And of course, you'll also need to pay for software for developers, but it's actually less than you would think, considering the fact that we work on computers all day and program computers. With software, it's very similar to hardware. We just want to say what software do you need in order to do your job? But for most of our devs, we're literally just paying for a table plus or some other database access software and some kind of an IDE and a lot of them even use a free IDE, maybe some plugins here or there.

other database access software and some kind of an IDE and a lot of them even use a free IDE, maybe some plugins here or there. And that's really it for the majority of the developers. And your needs may vary. I know in the past, we've paid for testing tools, responsive design tools, creative suite items, and more. But right now, literally, most of our folks want, you know, PHP storm and table plus, and they're happy. Now, outside of the software, individual developers use on their computers to do their specific development work. We also pay for quite a few centralized software as a service type platforms

do their specific development work. We also pay for quite a few centralized software as a service type platforms that our team uses. Of course, there's those that are company-wide that we happen to use in the development team. That's things like Slack and Harvest and Zoom and Google Suite and Airtable. They are not developer-specific. Everybody else is using them, but you still have to add another seat to them for each developer. Then there's also dev-specific services. Interestingly, most of these services, while you're paying for a seat for each developer, the service itself is

Then there's also dev-specific services. Interestingly, most of these services, while you're paying for a seat for each developer, the service itself is actually more used for deploying to a product or running a project rather than specific and necessary to that developer. So, again, these are more like services everybody uses, but you buy seats for each programmer like GitHub, exception trackers. We use Laravel, so we've got subscriptions to Forge and Envoyer and Cloud and Nightwatch, and you've got things like TypeSense, Mailtrap and Grok. Tools of the trade that are a functional part of doing our day-to-day development work, whether as a part of development, as a part of staging or as

Tools of the trade that are a functional part of doing our day-to-day development work, whether as a part of development, as a part of staging or as a part of production, but usually a little bit more attached to the team or the project and just buying seats versus buying a copy of this software for each developer. And as I'm sure you can guess, AI services are also an increasing cost. So you're going to want to add, basically, add another seat on GitHub and Zoom and Dropbox and Slack and all these other tools as a part of your total metric for how much does it cost to hire a new developer for a year. When I think about other recurring costs we incur per every developer, the top

for how much does it cost to hire a new developer for a year. When I think about other recurring costs we incur per every developer, the top one that comes up after this is usually educational stuff, like courses and books and subscriptions to education sites like LaraCasts. We want to make sure our developers have access to the highest quality training material so they know how to stay up-to-date on everything that is important to their job with us. And the cost of this training doesn't come close to the amount of benefit we get from having devs that are up-to-date on all the latest and greatest. Part of bidding building upper devevs is not just these training resources but

get from having devs that are up-to-date on all the latest and greatest. Part of bidding building upper devevs is not just these training resources but also sending them out to meetups and conferences, and I cannot begin to tell you the positive impact it makes to send a developer to a good conference. So first, we learn better in person than we do on YouTube, and I wish that wasn 't the case, but it's just something about being around people and connecting with them and getting excited about them, doing the same thing that just makes what you learn stick better. Second of all, your devs are going to build professional networks at conferences, and these are valuable to them for their careers, which we care

Second of all, your devs are going to build professional networks at conferences, and these are valuable to them for their careers, which we care about because we're good people and good managers, but it's also valuable for the company or the organization to now have a direct connection to folks all around the world doing the same work, half of whom probably are creating and maintaining packages that we rely on every day. And third, your developers represent your organization at these conferences, and there's no better way to meet potential candidates for your company than at a conference. So, set a budget for ongoing education and for conferences every year, and your

a conference. So, set a budget for ongoing education and for conferences every year, and your team might not use it all, but I would definitely budget it as if they will. Finally, we are landing on the goodies. You have to make sure to budget for these because it's so easy to leave them behind, but they are so valuable in developer happiness. This is especially true for raises. I'm hoping your parent organization already has this managed, but if not, the cost of raises on top of employees often making six figures can spiral out of control if you have not planned for it in the first place.

making six figures can spiral out of control if you have not planned for it in the first place. In the health that you make your workplace, the longer people stay, the more raises they get, and you don't want to stop giving raises, of course, but you need to know ahead of time that you can afford to keep giving them for your team or you're going to be in bad shape. Bonuses also are usually a company-wide thing paid off of profits, so I'm hoping that's managed by your larger organization and you don't have to think about that right now. So that leaves treats.

about that right now. So that leaves treats. Now, whether or not treats are a part of your corporate culture, I strongly recommend you build in the occasional gift, pizza party, special side dinner, team onsite, or whatever else into your overall budget. Look for moments to brighten a team member's day, to tell the whole team you appreciate their hard work on that difficult week, or to give a specific hard- working dev some kind of kudos. It really goes a long way. And if you can't, I'd also recommend setting aside a portion of your budget to sponsor community initiatives in your tech stack.

And if you can't, I'd also recommend setting aside a portion of your budget to sponsor community initiatives in your tech stack. And this might mean buying pizza a few times for your local meetup, sponsoring your community's conference, or giving back to a community-led diversity initiative. And I'd also recommend setting aside a portion of your budget to financially support the work of open-source project maintainers your team relies on. No one has more power than you to show the work of these maintainers as a foundational part of doing business and to reward them for that work. Okay, so at this point you have a general sense of the average annual cost of

foundational part of doing business and to reward them for that work. Okay, so at this point you have a general sense of the average annual cost of employing each developer. Most of managing your team's finances works around ensuring those costs fit within your budget. So once you have this information, it actually all seems kind of simple, right? Like, what makes it complex from here? Well, this is not the only answer, but it's definitively complex when there is a mismatch between your team size and your budget in either direction. Maybe your budget shrank since your original team size was created. Maybe your

a mismatch between your team size and your budget in either direction. Maybe your budget shrank since your original team size was created. Maybe your budget stayed the same, but everybody's salaries, or maybe even just the cost of hardware and software, went up. Or maybe you're being asked to increase your team, but you know this increase may be temporary, or you're being given more budget, but that budget is not quite enough to bring on another developer. What do we do in all of those scenarios? So we've always already talked about hiring and firing in previous videos, so that at least gives you kind of the basics of what it looks like to make your

So we've always already talked about hiring and firing in previous videos, so that at least gives you kind of the basics of what it looks like to make your team bigger and smaller. But there is another tool in your tool belt, contractors. And this could be individual contractors, individuals who are working part-time or full-time for you, or even all the way up to agencies like Titan. Either way, contract labor allows you to scale up your staff temporarily rather than permanently. And this might be temporarily until this budget surplus runs out, or temporarily until you can find the right person to work full-time in this

And this might be temporarily until this budget surplus runs out, or temporarily until you can find the right person to work full-time in this position, or temporarily until the budget increases again, because right now it 's not enough to support an entire new employee, but you could bring in some contract worth. In each of these scenarios, you can break off chunks of your development work and pass them to a trusted outside dev or team, and use that remaining budget to get great work done. Now I run the finances of my entire company and have for a few years, and as far as I can tell, these are really the only factors I have to contend with

Now I run the finances of my entire company and have for a few years, and as far as I can tell, these are really the only factors I have to contend with financially that are unique to running a dev team. You've got salary, the equipment and software to do the job and the services that support it, education and conferences and meetups, treats, bonuses, raises and sponsorships. And if you can build these things into a basic spreadsheet, you've got basically everything you need to manage your team's finances.