Hiring Developers, Freelancers, and Agencies
Vetting frameworks, red flags, trial sprints, and the decisions behind every good engineering hire.
Engineering Retention: Why People Leave and How to Stop It
Engineers leave for predictable reasons. Boredom with the work. A manager they do not respect. Compensation that drifted below market. An opportunity that offers what is missing. The companies that retain well diagnose the reasons honestly and address them while there is still time to change the engineer's mind. The companies that lose engineers regularly explain each departure with a story that misses the actual cause. The diagnosis is the work.
Hiring Developers, Freelancers, and AgenciesEngineer LinkedIn Profiles That Actually Convert Recruiters
A LinkedIn profile that converts recruiters is the one that lets a recruiter quickly decide whether the engineer is a fit for their role. Clear headline that names the role and the stack. About section that reads like a real person wrote it. Experience entries that name impact, not duties. Skills section with the technologies recruiters search for. The profile is a search result, not an autobiography.
Hiring Developers, Freelancers, and AgenciesContract vs Full Time: The Tradeoff Map
Contract engineering is paid by the hour or project, with a defined scope and timeline. Full time engineering is paid by salary, with broad ownership and typically equity. Each fits a different shape of work: contract for defined projects, specialized capability, and variable load; full time for product ownership, deep context, and long horizon work. The mistake is using either for the wrong shape of work.
Hiring Developers, Freelancers, and AgenciesCompensation Frameworks That Scale Past Twenty Engineers
A compensation framework is the documented system that determines how engineers at your company are paid. Bands by level. Location adjustments. Equity grants by role. Annual review process. Without a framework, compensation becomes whatever was negotiated, which produces resentment as soon as two engineers compare notes. With a framework, the team has a shared understanding of how pay works. The framework scales the company past the point where the founder can hand negotiate every offer.
Hiring Developers, Freelancers, and AgenciesCommunication Patterns That Predict Project Success
Communication patterns that predict project success are the observable habits in how an engineer or team communicates with the founder. Clear written updates. Explicit scope conversations. Early surfacing of blockers. Honest estimates. Async first behavior. The patterns are stable across projects. They predict outcomes more reliably than the engineer's resume or rate. Most founders learn this after the wrong communication pattern has cost them a project.
Hiring Developers, Freelancers, and AgenciesBuilding a Hiring Brand as a Bootstrap Startup
A hiring brand is what the engineering market thinks of you when they hear your name. For a bootstrap startup it is the most important asset for attracting talent because you cannot win on compensation. The brand is built by what your team ships, what your team writes, and how the candidates you reject describe the experience. None of it requires a budget. All of it requires discipline.
Hiring Developers, Freelancers, and AgenciesAgencies That Win Founder Trust: What They Do Differently
The agencies founders recommend to other founders share four habits. Honest scope, weekly demos, a single named owner, and clean handovers. Every other variable, including price and process, matters less than these four. The agencies that miss on any of them tend to lose the client and the referral in the same quarter.
Hiring Developers, Freelancers, and Agencies10 Questions Every Non Technical Founder Must Ask Before Hiring a Developer
If you are a non technical founder hiring your first developer, you do not need a degree in computer science. You need ten questions that force the conversation off the demo and onto reality. Below is the list I would use myself, written from the side of the table where the work actually gets shipped.
Hiring Developers, Freelancers, and AgenciesThe Hiring Funnel for Engineering Roles: From Applied to Signed
The engineering hiring funnel is the sequence of stages from initial application to signed offer: application review, recruiter screen, technical phone screen, technical assessment, team interviews, reference checks, and offer. The conversion rates at each stage determine how many candidates must enter the top of the funnel to produce one signed hire. Understanding the funnel allows companies to identify the stages where strong candidates are being lost unnecessarily and to design each stage to be both evaluative and compelling to the candidates who pass.
Hiring Developers, Freelancers, and AgenciesWhy Most Tech Recruiting Firms Send You The Wrong People
Most tech recruiting firms send you the wrong people because their incentive is to close the placement, not to find the right match. They are optimized for speed and volume, not for the kind of slow, specific evaluation that a technical hire actually requires. The fee structure rewards the close, not the outcome, and the candidate pool is whoever responded to an email, not whoever would be best for the role.
Hiring Developers, Freelancers, and AgenciesThe Recruiter Engineer Relationship: How to Make It Work
The recruiter engineer relationship works when the recruiter understands what the engineer actually does and the engineer understands what the recruiter actually needs. In my experience watching this relationship from the technical side, the failures almost always come from the recruiter treating the engineer as a keyword match rather than a person with a specific set of preferences. The ones that work feel like a conversation between two people who respect each other's expertise.
Hiring Developers, Freelancers, and AgenciesThe Annual Engineering Review That Engineers Actually Find Useful
The annual engineering review is the most important management conversation of the year and the one most commonly wasted. Most engineering reviews are filled with competency ratings, generic feedback, and calibration theater. The reviews that engineers find useful are specific, honest, and focused on trajectory. The format matters far less than the honesty.
Hiring Developers, Freelancers, and AgenciesThe Senior Developer Test: Architecture, Tradeoffs, Communication
When I need to know whether a developer is actually senior, I do not look at the resume. I ask three questions that cannot be rehearsed: one about a system they designed under constraints, one about a decision they regret, and one about how they explain something hard to someone who does not code. The answers tell me everything the LinkedIn profile will not.
Hiring Developers, Freelancers, and AgenciesWhy I Stopped Asking Whiteboard Coding Questions
I stopped asking whiteboard coding questions because they answered the wrong question. I was testing whether a developer could perform a kind of algorithmic recall under social pressure, when what I actually needed to know was whether they could build, communicate, and make judgment calls on a real product. The trial project replaced the whiteboard and the hiring quality improved immediately.
Hiring Developers, Freelancers, and AgenciesThe First Thirty Days: Setting a New Developer Up for Success
The first thirty days with a new developer determine whether the engagement will be productive or frustrating. The developers who become valuable contributors quickly are almost always in environments where expectations are clear, context is provided proactively, and feedback is given early. The developers who take months to become productive are almost always in environments where they are expected to figure things out on their own. The difference is in the setup, not in the developer.
Hiring Developers, Freelancers, and AgenciesThe \"Project Done in Public\" Signal: A Hiring Manager's Cheat Code
A developer who builds projects in public, sharing the decisions, the mistakes, and the progress along the way, is giving you more information in a single tweet thread or README commit history than a resume will give you in two rounds of interviews. I use this signal as the first filter in any hiring evaluation, and it has yet to lead me wrong in either direction.
Hiring Developers, Freelancers, and AgenciesThe Bench Test: A Practical Way to Evaluate Engineering Talent
The bench test is a paid trial, boxed to a fixed stretch of time, that puts an engineer on a real problem from your codebase and evaluates their technical skill, communication, and judgment. It is more predictive than interviews, more honest than take home exercises, and more fair than whiteboard coding. The information it produces is the information that determines whether someone will succeed in the role.
Hiring Developers, Freelancers, and AgenciesWhy Most Job Descriptions for Developers Are Wrong
Most job descriptions for developers are wrong because they list technologies instead of problems, require years of experience that have no bearing on output, and describe the ideal candidate rather than the actual job. The result is that the candidates who make it through the funnel are the ones who are good at reading job descriptions, not the ones who are good at building software.
Hiring Developers, Freelancers, and AgenciesThe Founder Developer Communication Loop: A Weekly Cadence
The founder and developer communication loop is the weekly rhythm of information exchange that keeps the developer aligned with business priorities and keeps the founder informed about technical progress without micromanaging. The loop has four components: a Monday priority sync (what matters most this week), a midweek check in (what is in progress and what is blocked), a Friday async summary (what shipped and what did not), and a monthly retrospective (what communication is working and what is not).
Hiring Developers, Freelancers, and AgenciesThe Two Person Team: A Founder's Hiring Sweet Spot
The two person engineering team is the configuration most early stage founders stumble into and then defend forever, because when it works it is the most productive structure they will ever run. One generalist who can own the full stack, one person who keeps the project moving without writing code. That is the shape. Everything else is overhead until you have a reason to add it.
Hiring Developers, Freelancers, and AgenciesWhy You Should Never Hire a Solo Developer for a Critical Project
A solo developer concentrates risk in one person. If they get sick, take a vacation, or leave, the project stops. There is nobody to review their code, catch their blind spots, or maintain availability when they cannot. For a critical project, the savings from hiring solo are paid back many times over in the first emergency. The minimum viable team is two.
Hiring Developers, Freelancers, and AgenciesThe Three Strikes Rule: When to Let a Developer Go
I use three strikes as the frame for every developer relationship that starts to slide. One missed deadline or one communication failure is a data point. Two in the same category is a pattern. Three is the answer. The rule is not punitive. It is a forcing function that keeps me from rationalizing my way into six more weeks of hoping the situation will fix itself.
Hiring Developers, Freelancers, and AgenciesThe Onboarding Pack Every New Developer Deserves
A good developer onboarding pack is the set of documents, access credentials, and context that lets a new engineer stop asking questions and start contributing within the first week. I have been the new developer more times than I can count, and the single clearest signal of a well run company is how prepared the onboarding pack is on day one. It takes about four hours to build and saves weeks of lost time.
Hiring Developers, Freelancers, and AgenciesThe Equity Question: Should You Give Developers Stock?
Giving a developer equity is the right call in exactly one situation: when they are taking on cofounder level commitment and cofounder level risk. For everyone else, contractors and early employees included, the math rarely works in either direction. I have been on both sides of this question and the answer almost always comes down to whether the person is on the journey or just doing a job.