This is the final part of a three-part series on building development teams. I was inspired by Matt Stauffer’s Laracasts talk, and I’m combining his ideas with my own experience as a developer and team lead. In Part 1 we covered culture and hiring. In Part 2 we covered code process and task management. Now let’s talk about the day-to-day reality of managing developers, handling the budget, and dealing with the rest of the company.
Managing developers is not the same as controlling them
When people first move into a management role, a common mistake is trying to stay in control of everything. They want daily updates, detailed time tracking, sign-off on every decision.
This approach has a cost. Good developers hate being micromanaged. They want to do great work and be trusted to do it. When you micromanage, the best people leave quickly - they always have other options. What remains are people who are comfortable being told exactly what to do. That’s not a team. That’s a dependency.
Managing developers well is mostly about creating the right conditions. You hire good people, you give them clear goals, you remove obstacles, and you stay out of the way while they work. Your job is to support them, not to supervise them.
Onboarding: the first weeks matter more than you think
Before a new developer’s first day, make sure they have everything they need to actually start working. A laptop that’s set up. Access to all the systems. A clear understanding of where documentation lives.
On day one, don’t just walk them through HR paperwork and then leave them to figure things out. Assign them to a real project early - even just as an observer at first. Let them pair with an experienced developer. This is the fastest way to learn how the team actually works, not just how the handbook says it works.
Two practical things that make onboarding much smoother:
First, a technical handbook. Not just company values and holiday policy, but a real document: here’s how we set up a local environment, here’s our branching strategy, here’s what a good pull request looks like, here are the tools we use. This document should be maintained as the team evolves.
Second, a quick path to doing real work. The longer a new developer spends reading documentation without writing code, the more disconnected they feel. Get them committing something - even something small - in the first week.
One-on-ones: the most important recurring meeting
Every developer on your team should have a regular one-on-one with their manager. Weekly is ideal. Biweekly if necessary.
The one-on-one is not a status meeting. You’re not asking for a progress report. You’re creating space for the developer to share what’s on their mind - what’s blocking them, what’s frustrating them, what they want to learn, where they want to go in their career.
Good questions to ask:
- Is there anything making your work harder than it needs to be?
- What are you trying to learn right now?
- Is there anything you want to try that you haven’t had a chance to do yet?
- Is there anything you think I should know but might not?
Listen more than you talk. Take notes. Follow up on things that come up. If a developer mentions the same problem three times and nothing changes, they’ll stop bringing problems to you.
Supporting developer growth
Developers need to keep learning. The technology changes fast, and someone who isn’t growing is slowly falling behind.
Some practical ways to support this:
Access to learning materials. Books, video courses, subscriptions to platforms like Laracasts. Make it easy to expense these. Don’t make people fill out a form for a $30 book.
Conferences and meetups. Sending a developer to a good conference does more than give them new information. It connects them with other people in their field. They come back energized and with new ideas. They also represent your company - and if they speak at a conference, that’s even better for your reputation.
20% time or equivalent. At Tighten, developers get 20% of their time to work on things outside of their assigned client work. Writing a blog post, building an open source tool, experimenting with new technology. This is valuable both for the developer and for the company’s reputation in the community.
Pair programming. Not just as a training tool for juniors, but across all experience levels. People learn from each other. A senior developer learns from a junior’s fresh perspective. A junior developer learns from a senior’s experience. It also spreads knowledge across the team, which reduces dangerous single points of failure.
Twice a year, have a more structured conversation with each developer about their career goals. Where do they want to be in two years? Do they want to move into a lead role? Do they want to specialize? Do they want to eventually build their own product? Understanding this helps you support them in a way that is actually meaningful to them.
When things go wrong
Good hiring and a healthy culture reduce performance problems, but they don’t eliminate them. At some point, something will go wrong with someone on the team.
When you notice a problem, address it quickly and directly. The longer you wait, the bigger the issue becomes, the more resentment builds on both sides, and the harder the conversation gets.
Start with a direct conversation. Explain what you’ve observed. Ask for their perspective. Nine times out of ten in a healthy culture, the developer is already aware of the problem and willing to work on it together.
If the problem is serious enough, or if you’ve had the conversation before without improvement, it’s time for a Performance Improvement Plan (PIP). A PIP is a structured document with:
- Specific behaviors that need to change
- A clear timeline for improvement
- Concrete steps the developer should take
- Regular check-in points
A PIP given in good faith is not a trick to fire someone. It’s a genuine attempt to help them improve, with clear expectations so everyone knows where they stand. If they improve - great. If not, at least you were fair and transparent about the process.
When you do have to let someone go, do it clearly and without delay once the decision is made. Have all the access revocations ready. Have paperwork ready. Be respectful but direct. Long, drawn-out endings are harder on everyone.
The difference between firing and layoffs matters: firing is because of the person’s performance or behavior; a layoff is because the role no longer exists. If you’re laying someone off through no fault of their own, give as much notice and severance as you can, and actively help them find their next position.
Celebrate when things go well
Don’t only show up when something is wrong.
When a developer does great work, say so. Not just in an annual review - right when it happens. A specific, genuine acknowledgment costs nothing and matters more than most people realize.
Public recognition is also powerful. A dedicated Slack channel for kudos, shout-outs in team meetings, mentioning someone’s contribution in a blog post or at a conference. Developers often work in relative invisibility. Helping their work be seen is a real gift.
When the team goes through a difficult stretch - a hard delivery, a bad production incident, a stressful crunch - acknowledge it afterwards. Sometimes a team dinner or a small gift or just a message saying “that was hard and you did well” is exactly what’s needed.
The real cost of a developer
If you’re responsible for a development budget, here is a useful exercise: calculate the total annual cost of employing one developer, not just their salary.
The main components are:
Salary. The largest cost by far. What you should pay varies a lot by role, experience, location, and tech stack. Do your research - look at Glassdoor, job postings from similar companies, and salary surveys in your specific area.
Hardware. Laptop, monitor, keyboard, chair, headphones. You don’t need to buy the most expensive version of everything, but you should buy good enough. A developer sitting at a bad desk with a slow computer is not being careful with your money - you’re just making them less productive.
Software. IDEs, database tools, design tools, AI assistants. Less than you’d think, but still real.
SaaS tools. GitHub, Slack, Zoom, exception trackers, deployment tools, project management software. Add up a per-seat cost for each tool and multiply by the number of developers.
Education and conferences. Books, courses, conference tickets, travel. Budget for this as if they’ll use all of it. They might not, but you want them to have the option.
Raises and bonuses. Plan for this in advance. If you build a team and hire people at salary X, expect that number to increase over time. If you haven’t budgeted for raises, you’ll either have to underpay people who’ve been with you for years, or you’ll face uncomfortable surprises.
Equipment replacement. Laptops don’t last forever. Budget for replacing hardware every three to four years per developer.
Add all of this up and you have a real number - the annual cost of one developer. Use this when planning team size, when deciding whether to hire a contractor versus a full-time employee, and when presenting a budget to leadership.
When the budget is tight and you need temporary capacity, contractors are a useful tool. Not a permanent replacement for employees, but a way to handle a project surge without making a long-term commitment you can’t afford.
The dev team’s relationship with the rest of the company
This is one of the most overlooked problems in software development. Bad relationships between the engineering team and the rest of the organization - product, sales, marketing, leadership - can quietly destroy all the good work you’ve done internally.
It usually comes from two places:
Developers are seen as neckbeards who only care about their tech toys. Whether or not this is true of your specific team, the perception exists. And once it exists, it leads to micromanagement, to developers being excluded from planning, to their requests for technical work being dismissed as “nerds wanting to play.”
Development is seen as a trade, not a creative discipline. Like plumbing. You hire a plumber, you tell them exactly what to do, they do it, you pay them. If this is how the rest of your company thinks about software development, you’re going to have constant conflict around timelines, scope, and priorities.
The solution, as the engineering leader, is to educate and advocate. Bring product owners to a technical planning session so they can see how complex features actually work. Speak their language when you explain why technical debt matters - frame it as risk reduction, not as “developer comfort.” Find ways to show the creative and problem-solving nature of what your team does.
And if your team actually is a group of people who refuse to engage with the business side, who only want to work on what interests them technically - that’s a real problem too. Culture and hiring choices at the beginning affect this a lot.
The engineering leader is a bridge. Your job is to represent your team to the company and to represent the company’s real needs to your team. When this works, both sides trust each other and things flow. When this breaks down, both sides retreat into silos and fight over everything.
Common mistakes worth naming directly
Looking back at my experience and at what Matt Stauffer covers in his series, here are the patterns that damage teams most often:
Non-technical leaders at the top of engineering. If the person responsible for your development team has never written code professionally, they will struggle to advocate for the things that actually matter. Technical debt, development pace, architecture decisions - these require someone who understands them from experience. The best compromise is a non-technical leader who deeply respects and listens to the senior engineers on the team.
The “superman” developer. Every team has seen this person: incredibly productive, seems to know everything, but every piece of code goes through them. The team slows down. Vacations are impossible. When they leave, half the knowledge leaves with them. This person might not be doing it on purpose - but the effect is real. A healthy team is one where knowledge is spread, and no one is a single point of failure.
Too many junior developers. Juniors are valuable. Hiring them is good for the industry and good for your team’s long-term pipeline. But if you hire mostly juniors to save money, you overwhelm your senior developers. The ratio matters: no more than one junior per two experienced developers.
The Mythical Man-Month. A project is running late. The response is to add more developers. This rarely works. New people need time to onboard, to understand the codebase, to learn how the team communicates. Adding people to a late project usually makes it later. This was documented in 1975 and somehow keeps happening.
Adopting architecture that’s too complex for your team size. Microservices are a good solution for teams of hundreds of developers working on massive systems. They are not a good solution for a team of five. Just because a large company uses something doesn’t mean you should. Solve the problems you actually have, with the team size you actually have.
Ignoring technical debt. Technical debt is real. It slows you down. It makes features harder to add. It makes bugs harder to find. If you never make time to address it, it grows until it becomes a genuine crisis. Frame it clearly to leadership: ignoring technical debt increases risk. Paying it down reduces risk.
Promising things as a manager that you won’t keep when it gets hard. This comes back to integrity. If you say “we respect weekends here,” mean it. If you create a bonus program, honor it. Your team is watching what you do under pressure, not what you say when things are easy.
Final thoughts
Building a good development team is one of the most challenging things you can do in tech. It’s not about finding a magic process or the right tool stack. It’s about creating an environment where good people can do their best work consistently.
The ideas in this series - culture, trust, clear structure, simple processes, honest communication - are not new. They’re not complicated. But they require consistent effort and genuine commitment, especially when things get difficult.
I’ve made many of the mistakes described here. I’ve been the manager who added too much process. I’ve been the developer frustrated by micromanagement. Writing these articles was as much a reflection for myself as a guide for others.
If you take one thing from this series: treat your developers like professionals. Trust them, support them, give them clarity, and get out of their way. The rest follows from there.