# How to Run Effective 1-on-1s With Your Engineering Team
Engineering 1-on-1 meetings are the highest-leverage management tool available to startup leaders - and the most consistently misused. Most founders either skip them entirely ("we're too small, we talk all day") or run them as status updates, which is the one thing they should never be.
A 1-on-1 is not a status meeting. Status can be communicated asynchronously. A 1-on-1 is the protected, regular space where an engineer can tell you things they would not say in a group setting, where you can surface problems while they are still fixable, and where you build the kind of trust that determines whether people stay and perform at their best.
I have a consistent process I recommend to every technical leader I work with. It is not complicated, but it requires discipline to protect the time and ask the right questions.
The Cadence That Works
Weekly 1-on-1s for every direct report. Thirty minutes is usually sufficient for engineers who are in a good place. An hour is appropriate when someone is working through something difficult or when there are significant decisions to make together.
Never cancel. Rescheduling occasionally is fine. Canceling - especially at the last minute - signals that the 1-on-1 is not important to you, which signals that the person is not important to you. Engineers notice.
No agenda from you. The 1-on-1 belongs to the engineer, not to the manager. You should not be leading the agenda. You should be facilitating the conversation the engineer needs to have.
This one point consistently surprises founders. They come to 1-on-1s with a list of things they want to cover - status updates, upcoming work, company news. That is not what the time is for. The status updates can go in a written update. The upcoming work can be discussed in sprint planning. The company news can go in an all-hands. The 1-on-1 is the one place where the engineer gets to set the agenda.
Questions That Surface Real Problems
The questions you ask in 1-on-1s determine whether you learn anything valuable. Most managers ask questions that produce safe, surface-level answers. These questions are better.
"What is the biggest obstacle you are running into right now?" This is different from "how is the project going?" It specifically asks for problems, not status. Engineers who are asked "how's it going?" say "good." Engineers who are asked what their biggest obstacle is will name it.
"What are you working on that you are excited about? What are you working on that feels like a grind?" This two-part question surfaces engagement issues that would otherwise be invisible. An engineer who says everything is a grind is a flight risk. An engineer who has nothing they are excited about is a retention problem.
"Is there anything you are worried about that we have not talked about?" This is a catch-all that invites disclosure. Many of the most important things engineers know - concerns about team dynamics, code quality problems, personal situations that are affecting work - come out in response to this question rather than any direct question about those specific topics.
"What could I be doing differently that would make your job easier?" This question requires courage to ask and to receive. Some engineers will give you polished, diplomatic answers. Others will tell you something specific and useful. Either way, asking it signals that you want feedback and that you are not fragile about receiving it.
"What are you learning right now? What do you want to be learning?" Growth conversation. Missing this in 1-on-1s means you will be surprised when an engineer leaves for a role with more learning opportunities.
The Questions to Avoid
Questions that produce status-report answers rather than real conversation:
"What did you work on this week?" - this is a standup question, not a 1-on-1 question. "How is [project] coming along?" - this is a project review question. "Are things going well?" - this question's implicit answer is always yes.
These are not bad questions. They are bad 1-on-1 questions. They belong in project discussions and status meetings.
Format and Documentation
Take notes during 1-on-1s, even brief ones. Not because you are auditing the person, but because the things said in 1-on-1s are important and easy to forget when you are having them with five people per week. Engineers notice when you remember what they told you. It signals genuine engagement with their concerns.
A simple 1-on-1 note structure: date, key concerns surfaced, action items (for both of you), follow-up on previous action items. Does not need to be more than five to ten bullet points.
Follow up on action items. If an engineer tells you that the deployment process is causing them stress and you promise to address it, you have created an obligation. If you follow up on it, you have built trust. If you do not, you have actively destroyed it. Engineers keep score of whether you follow through on things you say you will do.
The action items cut both ways. If an engineer commits to something in a 1-on-1 - having a conversation with a colleague, writing documentation for a system, exploring a technical approach - note it and check in at the next session. This is not micromanagement; it is accountability that the engineer themselves created by naming the commitment.
What to Do When You Hear Something Difficult
The most valuable 1-on-1s are the ones where an engineer tells you something you did not want to hear. They are unhappy. They think a technical decision you made was wrong. They are struggling with a colleague. They have been offered another job and they want to think through whether to take it.
The instinct to manage or redirect is strong when you hear these things. Resist it.
The productive response is always: ask more questions before offering solutions or defending decisions. "Tell me more about what's making you unhappy." "What would need to be different for you to feel good about staying?" "What is it about the other opportunity that is appealing?"
You rarely get the real information on the first answer. The first answer is the polished version. The second and third answers, drawn out by genuine curiosity, are where the real situation lives.
If you cannot address what you hear - sometimes you cannot; runway is limited, decisions are made - be honest. Engineers respect "I hear you, I can't change this right now, and I want to be transparent about that" far more than they respect managed deflection.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr