I was inspired by Matt Stauffer’s talk on Laracasts about building development teams. Matt has been running Tighten, a Laravel agency, for many years and has a lot of practical experience. After watching his lectures, I decided to write my own version - combining his ideas with what I’ve learned working as both a developer and a team lead. This is part one of three.
The real foundation is not the code
When most people think about building a development team, they think about technology. What stack? What tools? What processes? These things matter, but they are not the foundation.
The foundation is people.
I’ve worked on teams where the tech was great but the culture was toxic. Nobody talked honestly. Problems were ignored until they exploded. The best developers left first, because they always have options. What remained was a mess.
And I’ve worked on smaller teams with average tools but a healthy culture - where people trusted each other, spoke up when something was wrong, and actually wanted to do good work. Those teams built better software.
So before you think about hiring, before you think about process, you need to think about what kind of place you want to build.
Define what you stand for
You can’t hire the right people if you don’t know what “right” means for your organization.
This doesn’t have to be a formal exercise with consultants and workshops. But you need some clear answers to basic questions: What do we value? How do we treat each other? What behaviors are rewarded here, and what is not acceptable?
At Tighten, Matt Stauffer’s company, they came up with simple but concrete values. One is “cancel hustle culture” - they don’t want people working 60-hour weeks and ignoring their families. Another is “weird means interesting” - they actively want people with different backgrounds and experiences. Another is “you’ve already made it” - meaning you don’t need to prove yourself constantly. You’re already good enough.
These aren’t just words on a wall. They guide hiring decisions. They guide how managers talk to people. They define what gets rewarded.
In my experience, teams that skip this step end up with a culture anyway - just not an intentional one. Usually it’s whatever the loudest or most senior person on the team happens to value. That’s a risky default.
Culture comes from the top, but it travels through managers
Good values at the leadership level mean nothing if they get filtered through bad managers.
A good manager advocates for their team. Not just agrees with everything the team says, but genuinely represents their interests - including when it’s uncomfortable. A good manager tells leadership when a deadline is unrealistic. A good manager fights for their developers when leadership doesn’t understand why technical debt matters.
When I was a developer, I’ve had both kinds of managers. The difference is enormous. A bad manager makes you feel like you’re being watched, not supported. A good manager makes you feel like someone has your back.
One useful question when evaluating a potential manager: would you personally want to work for this person? Would you trust them to represent you fairly to their boss?
Integrity is not optional
There’s a pattern that happens a lot in tech. A company talks big about work-life balance, flexibility, trust. The CEO is the “good boss.” Then something gets difficult - a deadline, a funding crunch, a hard quarter - and suddenly all those promises disappear.
Matt Stauffer uses a useful definition of integrity here. It’s not just about being moral. It’s about being consistent. Like the hull of a ship that has integrity: it’s the same strength everywhere, no weak spots.
Don’t promise things you won’t keep when it gets hard. If you say “we don’t work weekends,” mean it even when the client is pushing. If you say “we’ll never do surprise bad news in reviews,” then don’t.
Developers, especially good ones, are watching this closely. They’ve usually been burned before. The moment you break a promise under pressure, you’ve lost something that’s very hard to get back.
Radical Candor: say it kindly, say it now
One of the most recommended books in the tech management world is Radical Candor by Kim Scott. The idea is simple: say the truth, and say it with care. Not brutal honesty. Not silence to avoid discomfort. Something in between.
On good teams, people give feedback quickly and directly. If something is going wrong, it gets said - not six months later in an annual review. If a developer made a mistake, the lead talks to them about it now, not after it becomes a bigger problem.
The original title of the book was “Compassionate Candor.” That tells you what it’s really about. Being direct is not the same as being harsh. You can tell someone their code is not good enough and still be respectful. You can disagree with a decision and still be professional.
In practice, this means setting the expectation from day one: we talk about problems early. We are kind, but we don’t pretend things are fine when they’re not. Leaders model this behavior, and then expect it from everyone.
The team structure that actually works
Now let’s talk about how to organize the people once you have them.
There are many possible structures. Big frontend team, big backend team. Matrix organization. Flat teams. But based on my experience and what Matt Stauffer describes, there is one model that works consistently well for most teams up to a certain size.
Small, full-stack teams.
The basic shape is: one CTO or director of engineering at the top. Under them, several small teams of two to three developers each. Each team has one technical lead (sometimes called a senior or lead developer). All developers write code. All developers review code.
Why full-stack instead of separated frontend and backend teams? Because separated teams create friction. Every feature that needs both backend and frontend work has to be coordinated between two teams. Timelines get longer. Communication overhead grows. Small things take twice as long.
When everyone on the team can touch both sides, a small feature can go from definition to production in days, not weeks.
Why small teams? Because in a small team there is no hiding. Everyone knows who is doing what. You know your teammates well. You know who to ask for help. In larger teams, you get bureaucracy, unclear ownership, and people falling through the cracks.
One important rule: no more than one junior developer per two experienced developers. Juniors are valuable - they bring fresh perspectives and they are the future of the industry. But they need guidance. If you overload a team with juniors, you overwhelm your senior developers, who spend all their time managing instead of building.
Two types of leaders every team needs
Each small team needs at least two types of leadership - and these can be the same person, but often work better when separated.
The technical lead makes architectural decisions, defines code standards, reviews the most complex pull requests, and is the go-to person for technical questions. This person doesn’t have to be great at client communication or project scheduling. Their job is technical quality.
The process lead (at Tighten they call this the project manager) handles meetings, timelines, task tracking, and communication with clients or product owners. They might also do light UX work - wireframes, diagrams. Their job is making sure the work flows smoothly.
At the top of the engineering organization, you need someone who is both technically competent and has enough organizational power to fight for the team. This person needs to understand what technical debt is and why it matters. They need to be able to walk into a leadership meeting and explain why the team needs two weeks to fix infrastructure instead of shipping new features - and be believed.
Hiring: build your reputation before you post the job
The best time to prepare for hiring is before you need to hire.
Be visible in your community. Go to conferences. Contribute to open source. Speak at meetups. Write about what your team is learning. Be a good employer so that your current developers say good things about you.
When you are known as a company that treats developers well and does interesting work, good candidates come to you. You’re not starting from zero every time you open a position.
When it’s time to write a job posting, be specific and honest. Describe what the actual job is. Separate must-haves from nice-to-haves, and keep the must-have list short. Write like a human being, not like a recruitment bot. Use real language.
Also share salary information and benefits as much as possible. Developers have learned to be skeptical of job postings that hide compensation. Transparency here is a signal of the broader culture.
For screening: don’t do everything yourself. Have someone check that applications meet the basic requirements. Then you personally review the remaining candidates for personality, experience depth, and fit. Get it down to 10–20 before the first call.
For interviews: keep it practical. Ask about things that are close to real work. Reading existing code on a call is fair. Making someone write an algorithm on a whiteboard that they’d never do in the actual job is not. The goal is to answer one question: can this person do the work we need, in a reasonable environment?
Always send rejection emails. Even to people who didn’t pass the first screen. It’s basic respect, and it costs almost nothing.
Promote from within when you can
When you have an opening in a leadership role, the first place to look is your own team.
Someone who has worked with you for two years understands your codebase, your clients, your culture. They already know what you value. Promoting them sends a message to the rest of the team: there is a path forward here. You can grow.
Hiring leadership from outside can work, but it is slower and riskier. That person has to learn everything from scratch.
The short version
Building a good dev team starts with deciding what kind of place you want to build. Then it’s about hiring people who fit that vision, organizing them in small full-stack teams with clear leadership, and creating an environment where honest communication is normal and people feel safe.
Everything else - the tools, the process, the technology - works better when you get this part right.
In Part 2, we’ll talk about how to structure the actual work: code processes, task management, and why estimates are usually a bad idea.