307. How to lead a development team when you're not technical

You're paying for developer time. But you can't evaluate the work yourself. So you're left wondering — are they actually building, or just going through the motions?

Most founders figure this out the hard way. In this episode, we break down the framework that lets you lead technical teams without being technical — and why trying to implement it alone often fails.

Key takeaways:

• The invisible accountability trap: Why hours-driven management doesn't work (and why output-driven does).
• The Monday morning meeting: The exact structure that keeps developers accountable without micromanaging.
• Prioritization as a business skill: How to make tradeoffs — understanding that building feature X means NOT building feature Y.
• Technical oversight: Why having a senior engineer validating your developers' work prevents expensive mistakes — and how we act as that advisor for you. 

The implementation gap

Knowing this framework and actually implementing it with your team are two different things. Without someone technical validating your developers' estimates, you won't know if they're being realistic.

Without someone who's done this before, you won't know how to troubleshoot when things go wrong.

Lead your team with confidence

If you want to set up this system properly — or fix it if you're already struggling — book a call with us. 

Our CTO will validate your developers' estimates. Sophia will help you run the meetings.

We'll help you avoid the expensive mistakes along the way.

Book a call: https://calendly.com/sophia-matveeva/new-meeting

Timestamps:

• 00:00 - Introduction: How to manage a technical team without being technical
• 02:34 - Output-driven vs input-driven management
• 04:51 - How to run your Monday morning developer meeting
• 07:13 - Come with sketches and designs, not just words
• 09:27 - Real example: The video feature trade-off
• 11:50 - Why junior developers won't tell you about trade-offs
• 13:30 - Building your prioritization framework
• 14:11 - What is a sprint and how to use it
• 17:30 - How to know if developer estimates are reasonable
• 20:30 - Summary and closing

Free AI Mini-Workshop for Non-Technical Founders:

Learn how to go from idea to a tested product using AI — in under 30 minutes.

Get free access here: https://www.techfornontechies.co/aiclass

Follow and Review:

We’d love for you to follow us if you haven’t yet. Click that purple '+' in the top right corner of your Apple Podcasts app. We’d love it even more if you could drop a review or 5-star rating over on Apple Podcasts. Simply select “Ratings and Reviews” and “Write a Review” then a quick line with your favorite part of the episode. It only takes a second and it helps spread the word about the podcast.

Listen to our podcast on:

• Apple

• Spotify

• YouTube

• Audible

• Pandora

Transcript:

[00:00:00] Sophia Matveeva: How do you manage a technical team if you're not a developer yourself? Well that's what we're covering on today's episode.

[00:00:10] Hello and welcome to the Tech for Non-Techies podcast. I'm your host, Sophia Matveeva. If you're a non-technical founder building a tech product or adding AI to your business, you're in the right place. Each week you'll get practical strategies, step-by-step playbooks, and real-world case studies to help you launch and scale a tech business without learning to code. And this is not another startup show full of jargon, venture capital theater, or tech-bro bravado.

[00:00:42] Here we focus on building useful products that make money without hype and without code. I've written for the Harvard Business Review and lectured at Oxford, London Business School, and Chicago Booth. So you are in safe hands. I've also helped hundreds of founders go from concept to scalable product. And now it's your turn. So let's dive in.

[00:01:10] Hello smart people. How are you today? Today's episode is based on the discussion we had at the CTO QA, I think three weeks ago now. So today we're focusing on a really big problem that a lot of you are going to face, actually all of you are going to face if you're going to create a tech product, which is okay, how do I work with developers? And I'm not a developer and I don't understand how to set them tasks. And also I don't know if they are actually doing what they're supposed to be doing or if I'm paying them and they're just kind of sitting around and doing nothing. So this is what we're going to focus on today.

[00:01:50] And there is an invisible accountability trap and one of the people on the CTO QA brought this up. So the person, by the way, he's listening to this, so hello. It is wonderful to have you as a listener. Have you left a review yet? You know who I'm talking about. If you haven't yet left a review, I hope this guilt trip is going to get you to do it. Anyway, right. So this particular founder has been working on his tech startup for a little while. And he first hired one set of developers and that didn't work out. So then he hired another set of developers and that's going much better. So learning by doing. And that's essentially what you're doing, especially if you don't have access to Tech for Non-Techies. Anyway, so one of the things that he's worried about is that he is paying these developers for 40 hours of work per week. But because he's not a technical founder, he can't tell, okay, I'm paying for this amount of time. Are they actually working all the time?

[00:02:34] Output-driven vs input-driven management

So am I getting what I'm paying for, essentially. And so what we discussed is that you don't want to look at input driven management, you want to look at output driven management. So the thing is, if you're not technical, you can't evaluate the work, you can't look at the tech, you can't look at the code because you don't understand the technology. So accountability becomes a black box. So you either try to micromanage, which really you can't really do, or just trust completely blindly and not take a leadership position, which you know, if you're the leader of a company and also you're paying for the stuff to get done, that's not a good idea.

[00:03:14] And there is this natural instinct to worry for founders and think, what am I paying for? Am I getting what I'm paying for? I'm gonna give you a framework that I use, but I just want you to know that this is tricky because, for example, there are senior developers who are very, very good and they could essentially take a lot less time to create something than somebody who's a bit more junior. So in the world of developers, you really are paying for quality. So some of the top developers that I know, they could get things done very, very quickly. So just think about, okay, what kind of level of expertise am I getting? But even then, you still have no way of really telling what they have created if you don't understand the code.

[00:03:58] The solution is basically not measuring hours, it's measuring output. So basically, what have they actually created? What features have they created? What have they improved? What has actually happened in the product? And yes, some things are going to be invisible, like changes to the algorithm, changes to the back end, changes to, you know, cleaning up technical debt, but some of it is going to be really visible, like literally, you have a new feature, you have a dashboard, whereas you didn't have a dashboard before. So this is essentially what I would want you to get to.

[00:04:51] How to run your Monday morning developer meeting

The thing that I'd want you to do, the way I have structured it before is essentially you just have a Monday morning meeting. You know how you have a normal Monday morning meeting at work? Well you could do that with your developers. So essentially this is how you lead that Monday morning meeting. You come to the meeting prepared with ideas for things that you want to have created. So it could be a feature list. It could be, okay, here are some changes that I want to make to our content algorithm. Or our users have complained about this feature being really slow and really clunky. I want to take out some of the steps to, I don't know, create a new document. Or I want to make sure that uploading something becomes faster. So basically you come in with a bunch of feature requests.

[00:05:36] And the ideal situation is that you have already prioritized these feature requests from a business point of view. So you already thought that, okay, if we create these features, we're essentially going to make more money. Or if we create these features, we'll have higher retention. And if we have higher retention of our customers on the product, we'll get more data. And then we can use that data to make more money. So ideally, you would have already thought about why these features matter, not just from a user experience point of view, but also from a financial point of view. How is creating this thing going to help you either raise capital? And, you know, capital raising is often to do with retention rates, or how is this going to help us make more money by literally just charging more or having more customers.

[00:06:22] So basically you come with your set of desires to your developers and you give them your set of desires. But you tell them that this is not directive. So make sure that you're having a dialogue. Make sure that they know that you're not coming with just this list and saying, just do this. You're literally coming to them and saying, this is what I would like to create. Now let's have a conversation about the trade-offs and about the cost of actually creating this stuff. So every Monday morning, sit down with your developers, spend about one or two hours on this Monday morning meeting. I usually used to spend about 90 minutes. Have your prioritized list of features and work that you want to get done. These should be business priorities, not technical priorities, because you don't know what the technical priorities are. You could say things like, I want to create email notifications. Or I want to add more mobile notifications, or I want to add more information to our user profile. So basically be quite specific. And honestly, the more specific you are about what you want to get done with your developers, the better.

[00:07:13] Come with sketches and designs, not just words

If you want to really nail this, and if you're listening to Tech for Non-Techies you're the kind of person who really likes nailing it, the way I would do it is literally come with sketches, come with designs. You can either work with a UX designer to do this or if you're just generating ideas, literally just use something like Lovable to just generate some screenshots of your ideas. Generate some screenshots of things that you want to get done. And explain, literally explain like this is the thing that I want to get created. This is why I think it's more useful. Then you bring it to your developers. You say to them, you kind of explain to them that this is your wish list rather than this is your dictatorial point of view of things that must get done. And if they do not get done, people will get fired. So I want your developers to understand that you're going to have a conversation.

[00:07:58] Invite your developers to ask you lots and lots of questions because, number one, even when you think you're being super, super clear about what you want to get created, there is so much room for misunderstanding. Honestly, like when you think that, okay, this picture can only mean one thing, actually to somebody else, it might mean something different. So be really clear about what you want. And then say to them, given that this is the wish list, what can we create within the constraints that we have? So what can we create? What from this wish list can be created given the size of our team? You know, you might have two developers working for you part time. So given your constraints, what can we create? Also ask about the cost. So there is the cost of actual, you know, time for paying your developers. So obviously they have to work on a feature for two weeks straight. That's a bigger cost than them working on a feature for one week. So the developer cost. Also ask them, are we going to have to incur any cost in terms of buying new tools or storing more data? So basically just ask them, what are the costs of creating this stuff?

[00:09:11] And then you will start understanding trade-offs.

[00:09:27] Real example: The video feature trade-off

I'll tell you a story actually from my own example. In our B2C product, which was a consumer app where women could take photos of stuff that they wanted to wear and buy and get feedback from professional stylists and community, I remember there were some users who really asked for video. They're like, we really want to take videos of the outfits or the stuff that we're thinking of buying and then get feedback. And I thought actually this makes sense. It seems that the world is moving towards video and this was pre-TikTok. So yes, let's go and do that. So I put that on the features list when I came to my developers. And the developers kind of nodded, but then the CTO said, well, we could do this, but if we do this, that means we can't work on any of the other features that you said you wanted because this feature, you know, embedding video and putting that into our algorithm and analyzing the data from that video, it is going to be such a big fat task. It is literally going to take us ages. It's going to take us a couple of months to do everything that you want this video to do. So if this is what you want to happen, you just need to understand that all of the other features that you want to have created, they're not going to happen. And so tell me what is most important? Is it the video or is it the other stuff?

[00:10:36] And as I looked at it, I thought, yeah, well the video stuff is really important, we should definitely do that. But there were just some basic kind of hygiene things that we needed to get done. And I realized, okay, let's get what we've already got on the list done first. And once that's done, we can get to the video feature. So this basically is a really, really good example of how you discuss priorities and trade-offs with your technical team. So it is not up to you, I would not expect you as a non-technical person to look at the back end and say, yes, this is definitely the kind of change we want to make. And then, you know, stroke your chin knowingly. No, that's not what I would want you to do. You are speaking like a business person. What do we as business people understand? We understand time, we understand budget, right? So when you're literally saying, okay, if I'm going to create these features, what is the time cost? What is the cost in terms of data, in terms of features? And can you give me an outline of these kinds of costs for the other features? So then you can decide essentially which features are the cheapest and fastest to make, but which features are going to help you reach your business aims quicker.

[00:11:28] So literally the conversation you're having is you're asking business questions about trade-offs and your developers are helping you understand that. And through this conversation, if you start doing this, this is a really, really good way to actually understand what your developers are doing and to learn about tech and to really become a leader. Because it's through these kind of prioritization conversations that you start hearing things that basically start making sense. You start understanding why one feature takes longer to build than another.

[00:11:50] Why junior developers won't tell you about trade-offs

And this is a really, really good way for you to gain this skill set, which is going to help you thrive in your career today. And your developers are basically going to be teaching you. The thing is, a lot of developers are really, really bad at teaching business people about what they're doing and the trade-offs of what they're doing. That's just unfortunately just a thing that they're just really not very good at a lot of the time. People who are good at it, they tend to rise up to CTO level because when you are in the C-suite senior management level, a lot of the time you're not coding at all. Or even if you are writing code, the thing that you are like kind of the secret sauce of the CTO is the yes, the tech strategy, but also actually working with the business side to align the tech strategy with what the business side wants. So generally, developers who are really good at explaining what they're doing to business people, they are basically really, really senior. So if you're working with a dev shop and maybe they are quite junior people, which is fine, that means that they can code, but that means that it won't enter into their mind to talk to you about trade-offs and to say to you, if you do this feature, you can't have that feature. It just might not ever occur to them. This is why you have to take the lead and you have to talk about trade-offs and you have to talk about prioritization.

[00:13:00] So why do you need a prioritization framework? Basically, without one, you will say yes to everything and you won't be able to understand the trade-offs.

[00:13:30] Building your prioritization framework

So here are some questions for you to ask as you are creating this framework. So question one, what would your users miss if it didn't exist? So what would your users miss most in your product if it didn't exist? Or what's the most risky assumption that we have about our product? If you understand that, then you can start basically creating features to de-risk that. Another question, what is stopping customers from signing up right now? You're probably gonna have a bunch of hypotheses. Maybe you'll have five different reasons why you think this is true. You could create a bunch of features to try to basically make that situation better. And then this is how you basically set your priorities. You think, okay, if we create this bunch of features, then more customers will sign up. Or if we create this bunch of features, we will de-risk our product. Or if we create this bunch of features, our customers are going to love our product more and therefore recommend it to their friends.

[00:14:11] What is a sprint and how to use it

So when you have this list of features, you go to your developers and you say, given everything on this list, what should we build next from your point of view? And together you decide what goes into the thing that is called a sprint. So if you've never heard what a sprint is, you know, in the tech world as opposed to in the running world, a sprint is basically a set of work that is done within a set period. Let's say you decide to build three different features and it's for a photo sharing app, just because we all know what photo sharing apps are like. So you decide that in the next sprint there will be a photo feature, a photo liking feature, and a photo comment feature. So photo share, photo like, photo comment. And you agree with your developers that this is going to be done in a set period and a sprint is usually two weeks long. So in those two weeks, these features are going to be created.

[00:15:06] What ends up happening is that at the end of the two weeks, these features should be created. If they are not created, you basically need to get an update about why that didn't happen. So, did they run into some sort of problems? So, this is what I mean about output driven management. You actually don't really need to care about whether they're working 40 hours a week or not. You need to care about is your product moving forward or not. So a sprint is basically a set amount of time for a set number of tasks.

[00:15:36] What you should not do, and I learnt this the hard way, what you should not do is go in halfway through the sprint and be like, yeah, can you also make this other thing? Because basically that means the developers' estimates go completely wrong. They really, really don't like it. And also in general, when you're speaking to your developers in your Monday morning meeting, discussing what the feature priorities are and what should go into the next sprint, they basically give you an estimate and they say, okay, I think that is gonna take me two sprints to create this feature. So they basically give you an estimate of their time. Once they do that, it is gonna be super unfair of you to be like, yeah, can you also do this other thing? Because then they're just gonna be like, okay, well, I'm already doing this thing. The code is already half written. But because it's half written, we can't release something that's half baked, like it needs to be fully created.

[00:16:28] So if I drop it now and I move to another task, that's context switching, and essentially nothing is going to get done or things are going to get done much, much slower. So when you commit to a sprint, just hear the word commit there, right? So like you're literally giving your developers a set of tasks that are going into a two-week section of time. Just be patient. I know that there'll be times when you're like, yes, but I really need this feature. I'm super super desperate for it.

[00:17:30] How to know if developer estimates are reasonable

So when you're discussing feature development and what goes into the sprint, your developers are going to give you estimates about the time that it will take them to create things. At this point, you might be thinking, hang on a second, but how do I know? Like if this developer is telling me that it's going to take two weeks to make this thing, but you think this thing is super simple, like it doesn't seem fair, it doesn't seem right. Basically, sometimes you're just gonna be wrong because you don't understand what needs to be done on the back end and basically the developer's right. But you're still gonna be really nervous. So I'll tell you what I've done and I'll tell you about what we're doing for our clients now.

[00:18:10] So what I did is I got a super senior developer who used to work at Meta to basically become my tech advisor. And I basically paid him in equity options rather than cash, in equity options in the company. And what he would do is he would literally review everything that the developers were doing and he would essentially review what the developers were also promising. So he wasn't writing the code. He wasn't working on the technical things. He was basically saying to me, yes, this looks reasonable. No, this isn't reasonable. I will talk to them about why this thing is taking so long, because maybe they are making some mistakes or maybe they're just not explaining themselves properly to you. So this really worked very well for us, but I understand that getting somebody to work for you, basically who's a really super senior engineer, might not be available straight away for everybody. This is a good thing for you to kind of aim for. I think having a good, very senior technical advisor who has some equity in your company or has some sort of incentive to help you grow, I think that's a really, really good long-term goal.

[00:18:51] But what I don't want you to do is basically just go around looking for people who you think are senior and handing them equity in your company because once somebody's on your cap table, this is really, really serious. You basically can't get rid of them. So you want to basically kind of get to know each other over a long period of time. So whilst that is a great goal to go towards, what I would suggest before you reach there, have a technical person who is not on that team, who is not on your development team, basically just advise you on the results of your Monday morning meetings. They can either help you prepare or they can help you understand the trade-offs or they can help you basically review what your developers are saying and say to you, yes, this estimate is correct, or this estimate doesn't seem right to me, but it could be that they're correct. Just ask them these clarifying questions.

[00:19:48] We are actually now offering this service at Tech for Non-Techies because as you might have heard last week, we've now got a CTO working with us who is helping our clients to really understand how their products are being built and to really question developers to make sure that basically you are getting what you pay for. If you would like us to have a look at your product, if you'd like us to really help you understand whether your technology strategy and your business strategy are aligned, then I highly recommend that you just book a diagnostic session with us. And then from there we can help you decide what you need to do next. So if you want to book a diagnostic session, book a call in the show notes. There's a link to book a call in the show notes. And by the way, it's called a sales call, but it's not going to be like the super hard sell. It's going to be more about understanding what is it that you want, what are your problems, and then seeing whether we can help you or not. If we can help you, we'll tell you what that's going to look like. If we can't help you, then we will give you some ideas about what you can do instead.

[00:20:30] Summary and closing

Okay. So to sum up what we covered today, even if you are not technical, if you are paying the bills and it is your idea and it is your venture, you are the leader. So you need to take a leadership stance. So you are creating the Monday morning meeting, you are leading the Monday morning meeting. You're coming to that Monday morning meeting with a bunch of features that you have already prioritized for yourself from a business point of view. When you come with those priorities to your developers, you basically need to understand the cost. Cost in terms of time, how long will it take them to create this thing? And cost in terms of money. Will there be extra storage costs? Will we need to buy a bunch of new tools? And so on. The developers are going to tell you what the costs are. And based on that, you literally do a cost-benefit analysis of the features that you want to get made. This is how you lead a technical team without being technical.

[00:21:38] And my bit of advice that I want you to remember is having a senior experienced engineer who is not part of that team, just helping you in reviewing those decisions, helping you understand what questions to ask, helping you really refine your priorities list. This is going to be a really, really great skill set for you to learn. Not only so you can save money and make sure that actually your developers are doing what they're supposed to be doing, but also this is the kind of skill set that you want to learn to be a really successful leader in the digital age. Because a successful leader in the digital age, whether you're creating your own venture or you are working in corporate innovation, that person is going to be able to work with the CTO, work with the CFO, and work with the CMO, right? So you need the marketing skill set, you need to understand the finances. And you need to understand how to collaborate with technologists. Which is why if what you're listening to today has you thinking this is really good, I definitely want to do this, I highly, highly recommend that you book a call with us so we can actually help you implement what you have learned today. Okay. On that note, my dear smart person, I shall love you and leave you. Have a wonderful day, and I shall be back in your delightful smart ears next week. Ciao.