243. How to Work with Developers: A Guide for Non-Technical Leaders

If you're a non-technical founder or leader, you might find developers frustrating to work with.

(They also think the same thing about you)

Developers resist quick changes, seem annoyed by status meetings, and always want the most expensive equipment.

That's not because they are prima donnas.

This episode will explain why developers work so differently from other professionals, and show you how to create communication systems that work for both business and technical teams.

Listen to learn:

• Why a "5-minute change" actually costs 2 hours of developer time
• The hidden costs of cheap equipment that hurt your bottom line
• How to structure meetings to maximise development speed
• Practical communication strategies that get results

Resources mentioned in this episode:

https://paulgraham.com/makersschedule.html

Timestamps

00:00 Introduction

001:10 Developer Mindsets

02:55 The Importance of Sprints

06:10 Managing Developer Interruptions

09:04 The Maker vs. Manager Schedule

11:59 Hiring and Equipment Considerations

14:50 Effective Communication

18:05 Developer Productivity

21:00 Conclusion 

For more career & tech lessons, subscribe to Tech for Non-Techies on:

• Apple
• Spotify
• YouTube
• Amazon Podcasts
• Stitcher
• Pandora

FREE COURSE:

5 Tech Concepts Every Business Leader Needs To Know

Growth Through Innovation

If your organisation wants to drive revenue through innovation, book a call with us here.

Our workshops and innovation strategies have helped Constellation Brands, the Royal Bank of Canada and Oxford University.

Transcript

Sophia Matveeva (00:00.439)
If you're a non-technical founder or a business leader, you might find developers extremely frustrating to work with. They resist quick changes, they get annoyed by status meetings, and they always seem to want the most expensive equipment. And today's episode is going to explain why developers work so differently from other professionals and what you can do as a business leader to balance developer productivity with business needs.

Welcome to the Tech for Techies podcast. I'm your host, tech entrepreneur, executive coach and Chicago booth MBA, Sophia Matheova. My aim here is to help you have a great career in the digital age. In a time when even your coffee shop has an app, you simply have to speak tech. On this podcast, I share core technology concepts, help you relate them to business outcomes, and most importantly, share practical advice

on what you can do to become a digital leader today. If you want to have a great career in the digital age, this podcast is for you. smart people. How are you today? Today we are going to cover how to work with developers. I learned this the hard way because I don't come from a technical background. And for those of you who don't know me, my name is Safiya Matheva, the CEO and founder of Tech for Non-Techies.

an education company that helps business leaders thrive in the digital age. And so obviously we want to work with developers in an effective way. And for that, we need to understand what it is that they do and how they do it. And also we need to understand basically what's reasonable for them to be annoyed about and what's unreasonable. And I know this the hard way because I transitioned from working in finance, I worked in private equity in London, got my MBA at Chicago Booth.

And then I started a tech company as a non-technical founder. So I had to learn all of this the hard way. And since then I have advised hundreds of startups, guest lectured at London Business School, Oxford University and so on. So basically I've learned how to work with developers, what to do and what not to do as a founder, as an advisor, as an investor. And so these are hard-worn lessons. So the first thing that I want you to know about is that developers actually do have

Sophia Matveeva (02:26.17)
different minds. Honestly, this is actually true. So I was sitting at a dinner party next to a psychiatrist the other day and she told me that people with a very mathematical, very kind of engineering brain, they are actually very different and psychiatrists, psychologists really have studied that difference. So it is a different mindset. Wonderful, but different. So if you're a non-technical person, say you're in the business side, you know, maybe you're an MBA like me.

and you've had to work with a CTO or a technical lead, you might sometimes feel like you are speaking to basically a different kind of creature. That is basically sort of true. And I think the best way for you to understand coding is think about it like writing a really complex novel. You know, those novels that have lots and lots of different characters and there are several different storylines and the storylines all intertwined together. So a developer has to kind of

keep all of those different characters and all of those storylines and they have to remember like what each character's motivations are. That's kind of what they're doing, especially when they're building some kind of complicated software, especially this is the case for really smart back end developers. And the thing is in a novel at the end of the day, if a writer forgets a bit of the storyline and we've all seen it on some series when like there is a little bit of inconsistency,

It's kind of annoying, but it's not the end of the world. Whereas with developers, if they basically forget, you know, the equivalent of a storyline, so they forget something that they've written before, if a bit of code that they're writing today doesn't match with what they had created maybe a month ago, the whole system could basically stop working. So this is why developers have to basically do deep work and doing deep work.

is often very different to what managers do, to what business leaders do. And so they have a different mindset and they work in a really different way where essentially they are building very complex mental models, which they then translate into code. And that requires deep uninterrupted focus. That requires deep work. So

Sophia Matveeva (04:47.787)
Imagine if you're not technically never worked with a developer before, but you want to understand this because you would have a great career in the digital age. You can imagine a writer. Let's imagine J.K. Rowling. Lots of us have enjoyed her work. So J.K. Rowling couldn't have created the whole Harry Potter universe if she was being interrupted every half an hour. Right. She really needed to imagine this whole world with all of these different characters.

that required deep work and concentration and getting into the flow state. And that is basically what really great developers have to do to create the amazing technologies that we are using today. So how do developers work? Generally, nowadays, developers work in what's called sprints. And a sprint is usually kind of a two week time period. And within that two week time period,

You all agree on what the developers are going to do. So essentially, you and the business team and the developers and the designers get together, you discuss what they are going to release. You have your desires as a business team, what you want them to release. They then have a look at those desires and they basically tell you what's realistic. And they basically commit. They say that in these two weeks, we are going to work on these features.

I don't let's say you're making an app and in a two week sprint, they might work on the login page, the profile page, the forgotten your password page, and maybe some of the same, maybe a bit of the matching algorithm. I don't know that sprint is getting kind of big actually. So they say within those two weeks, we are going to deliver these things. And basically what you have to do as a business person is you just have to leave them alone. Like within those two weeks.

Don't say, can you add this bit? Can you also do this? And I know this the hard way because I basically used to do that because when you are on the business side, like let's say you work in marketing or you work in sales, you get new information. Like say you're working on a marketing strategy in the morning and then you go to an afternoon panel discussion of marketing strategies and you hear about a new strategy that somebody in a different company is doing and you're like, this is really cool.

Sophia Matveeva (07:09.111)
We want to add bits of that strategy to what we're doing. You will then, literally when you get back to the office, you will tell your colleagues that I heard this new thing. This sounds pretty cool. Let's add it into our strategy and try it out in the next couple of weeks. You can do that on the business side. And when I have tried doing this with developers, I literally nearly caused like revolutions in my company and like not good revolutions, actually rebellions, the better way because

Developers will be like, hang on a second, but we've got our list of things that we had agreed for the two weeks. And now you, you are the CEO, you're coming in and just telling us this random stuff. Do you want us to leave what we're doing? And if you don't, then what are we supposed to do? And the thing is that developers leave what they're doing and they've built something half built. You can't release it. So basically rule number one, developers work in sprints. If you're a business person, do not.

Interrupt those prints. Do not go and say, I've seen this thing. I've had this idea. Can we just stick it into this sprint? Like control yourself and wait for the next sprint. So responding to quick requests basically is something that developers absolutely hate and it is for good reason. So let's like imagine that the features are kind of like buildings. So let's say they are building a feature and it's like half built.

If you then say, I'll like leave the hat and do my quick request thing, this features have built. So it means that it can't be released. It's like half of the building is built. Like the walls are built, but there is no roof. So it can't be sold. Nobody can occupy it. And that's basically a complete and utter waste of time. And a waste of time is a waste of money and developers are expensive. So this is not something that you want to wait. So no quick request. The thing is there are.

genuine emergencies. And sometimes you genuinely have to basically say, know what guys leave these half built things because we have to deal with something right now. There are emergencies, but they have to be real emergencies, not the CEO had a great idea. Like they actually have to be high priority emergencies. For example, the system is down. That's an emergency that has to be fixed.

Sophia Matveeva (09:33.631)
Or we've had a cyber attack. That's an emergency. Leave whatever you're working on. Figure that out. Or maybe a major customer has had some sort of big problem. Like, I don't know, they can't log in. They've got a bug in the system. Something isn't working for one of your biggest customers. Okay, that's a priority. So real emergencies can break the sprint. But if you're having a real emergency like every other sprint, then something is going terribly wrong.

Or you don't understand what a real emergency is. So do not interrupt developers during the sprints and be strategic about what you put into the sprints. Basically think in two-week increments when you're working with developers. That's the thing. Then really just be careful about interrupting the developer's work day. I know we just talked about not adding new things to the sprint. Now I'm actually talking about

developers day. So Paul Graham has a really good essay on this and it's called the maker schedule versus the manager schedule. So for those of you who don't know, Paul Graham is basically Silicon Valley royalty and he's the co-founder of the Y Combinator and that's like the most famous accelerator in the world. That's where Airbnb came from. It's where, anyway, lots of other startups. So you can Google him. So here's a big deal.

And he's got this really famous essay. I'm just going to quote from it. And then we're going to talk about, what do you actually do? And also I have linked the actual essay in the show notes. I really, really do recommend that you actually read it. Anyway, so Paul Graham says, there are two types of schedule, which I'll call the manager schedule and the maker schedule. The manager's schedule is for bosses, basically, so people like you. It's embodied.

in the traditional appointment book with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default, you change what you're doing every hour. And that's definitely true for me as the CEO of a global training business. Most powerful people are on the manager's schedule. Yay. It's the schedule of command. God, it makes me feel very important when I read that. But there's another way of using time.

Sophia Matveeva (11:59.179)
That's common among people who make things like programmers and writers. They generally prefer to use time in units of half a day at least. So the maker is, they're thinking in half a day at least. We, the managers, we're thinking in one hour increments. So what Paul Graham says is that you can't write a program well in units of an hour. That's barely enough time to get started. So when you're operating on the maker schedule,

meetings are a complete disaster because a single meeting can blow a whole afternoon by breaking it into two pieces, both of which are too small to do anything harding. And each type of schedule, Paul Graham says, works fine by itself. Problems arise when these two things meet because most powerful people operate on the manager schedule. They're in a position to make everyone resonate at their frequency if they want to.

But smarter ones restrain themselves as Paul Graham, if they know that some of the people working for them need long chunks of time to work in. So I actually discussed this yesterday with a very senior and extremely well paid developer who has been a CTO and startups that have had access, basically somebody who really knows what he's talking about. And when I say I'm making an episode for TechVan and Techies on how to work with developers, what are the key things you would want the audience to know?

And he started talking about meetings. He's been a CTO of companies that have been, as I mentioned, sold to massive corporates. And he said the worst thing that leaders can do, especially CEOs, is basically put in meetings halfway through chunks of your time. I'll tell you what he means. So if he starts working at like 9am and then the CEO schedules a meeting for 11am, basically he says, well, there's kind of no point for us, back end developers.

starting to work on something really difficult between like nine and 11, because we just won't have time to really get into it. And also realistically, developers, as we mentioned, they have a different mindset. They have different talents. So essentially things that you are good at as a business person, often they're not good at, but they're really good at things that you're terrible at. So let's respect that difference. So for example, this developer I was talking to yesterday, he said, know, for you, it's

Sophia Matveeva (14:21.391)
probably really easy to create a presentation. And honestly, for me, I often create presentations like last minute. I generally know what I'm going to say. And then just at the last minute, I put the slides together and then I go and I talk and it's fine. And it works. This is what I'm good at. It says that for developers making a 10 minute presentation, it's so outside of their comfort zone. It's so outside of what they are good at doing, that actually a really

Easy presentation might take them a whole morning of stress and then they're stressing about the meeting. They're stressing about this presentation. They're not doing anything. And you as the manager, you don't even know that basically by asking them for a quick presentation or status update at 11 AM, you have basically taken an entire morning of this really expensive person. So what this developer said to me, actually it's what Paul Graham also says.

is that if you are going to have meetings with your development teams, make sure that they are stacked one after the other. So your mid-level developers, first of all, you shouldn't be having too many meetings with them. Like you should just leave them alone to write code. Maybe have a weekly meeting with them. You don't need to have too many. But if you're dealing with CTOs and technical leads, yes, it is understandable. You might want them to meet investors. You might want them to meet senior teams and so on. The thing is the CTO,

also needs to do deep work. And if you are putting in meetings, basically kind of at random points in the CTO's day, you are completely destroying their productivity. So what you need to do when you are scheduling meetings with senior developers, make sure that they go on after the other. So you have one at nine, have one at 10, have one at 11, then leave them alone. And then the rest of the afternoon, they're doing deep work. What developers love most.

to make the most productive is when they basically have very large chunks of time without meetings undisturbed. So the more meetings you put in, the more you're destroying their productivity. And also in those meetings are basically every hour or every two hours. It's very unlikely that those developers are actually working in that one or two hours. Hope this makes sense. Okay. Honestly, just read Paul Graham's essay.

Sophia Matveeva (16:42.761)
If this doesn't make sense or if you don't believe me, it is generally a good essay. Now, another thing I want to tell you is that to work well with developers, essentially what I'm saying to you and you know what the senior developer told me, was like, tell the managers to leave us alone and to not have too many, not to basically try to micromanage us because they can't. But then I said, okay, but.

How do the managers know that developers are actually doing what they're supposed to be doing and not just dozing off and you don't know, watching selling sunset. That actually is probably not a very developer show. Something that I sometimes indulge in. Anyway, so what he said was that actually you need to hire the best developers you possibly can. Don't try to save money on hiring the cheapest developers. Basically get the most expensive developers you can possibly afford. Now why is that?

It is because the gap in productivity between a very good developer and even a mid-level developer can be like 15 times. So a good developer can be 15 times more productive than somebody who basically uses the same coding language, but they're just not at their level. 15 times more productive. Now, this is just not the case for most other professions. Like the level...

There isn't this massive variance. Like this massive variance isn't standard. Yes, you have some people who are just like absolute geniuses, but that's not standard in terms of developers. It's quite normal to have somebody who is massively more productive than somebody else. So try to go for those people because essentially what I'm saying is that expensive developers are often worth it. So what have we learned so far? We have learned that developers have a

fundamentally different mindset. They are different people, which means that what's easy for you is not what's easy for them. So if you think that getting them to make you a quick 10 minute presentation is going to be super easy for them because it's super easy for you, like you need to know go over that because of that is not true. Developers work in sprints. These sprints are usually two week chunks of time and do not tell them to do new stuff within that chunk of time.

Sophia Matveeva (19:03.487)
wait for those two weeks to end to basically put in new ideas into another sprint, unless there is a real emergency, but it has to be a real emergency like a cyber attack or something like that. Do not put meetings at random times in the developer's time because developers need basically really long chunks of time in order to fully concentrate. Now I mentioned right in the introduction that developers want really expensive equipment. I mean,

Who doesn't? I want really expensive everything. Like I have expensive face. Here we go. But for developers, it does actually make sense. For me, it doesn't. So what some CEOs think, you know, if a mid-level developer says I need some sort of really expensive computer, let's say like if a developer says I need this most expensive Mac, the CEO might be like, hang on a second.

There's no reason for a mid-level developer to have a computer that's more expensive than mine. Now, that is stupid. That is not true. I'm going to tell you why. So as a CEO of my company, what do I use my computer for? Using it to make this video and write emails, make presentations. Really? Like I can do some stuff on spreadsheets. That's pretty much it. I don't need super strong computing power.

For developers, they actually do need this computing power. So for example, what developers have to do is they basically write code and then they put it into a compiler. So they need to compile that code. That basically means that they need the code that they written to run through the system to basically for that system to check, does this code work? The computer needs to work out, do I understand this code? Does this code make sense to me? For this task, in order to compile code,

This is a complex computing task and it takes a long time. So this senior developer that I spoke to, he said, okay, well, in this engineering company where he worked, he would write his code and then he would need to put it into the compiler and the compiler would take 15 minutes to basically check the code. And within that 15 minutes, this developer couldn't do anything. He literally couldn't touch his computer because his computer was like,

Sophia Matveeva (21:28.459)
working super, super, super hard to check this code. So this person is, as I mentioned, really experienced and extremely well paid. So if they basically can't do something for 15 minute chunks of time, this is serious. Now let's imagine that he needs to compile his code four times. So let's say four times, which is doing this for easy math. So he needs to compile his code four times per day.

That is literally a one hour of lost productivity for an extremely well paid person. And within those 15 minutes chunks of time, he can't do anything. Like what can he do? Check his phone and go on Reddit. That is basically what he's going to do. And you as the business leader, as a business, you are paying for that. And the developer can't be to blame because he literally can't use his equipment. So now let's think. If you could buy another computer.

That means that it takes this developer 10 minutes rather than 15 minutes to compile that code. Shaving off five minutes per session is going to be a significant cost impact. But this is not how business leaders and procurement departments think about it. They're like, oh, you know what? This laptop is $4,000 and our CEO is happily using a one and a half thousand dollar laptop. There's no reason why you need something this fancy and as expensive.

Stop complaining. Well, actually this is complete nonsense because computers that can actually compute well and work fast, they basically shave off a lot of development time. And so that means that they actually add to the bottom line. So if you didn't understand anything about compilers and all of that, that's totally fine. The only thing I just want you to understand is that get the most expensive developers you can, that you can afford. Do not scrimp on paying developers and

Also, get them the equipment that they want. Because generally, the reason why they want fancy equipment is because they want to be able to do good work and they want to be able to do fast work. Your interests as the business leader are directly aligned with theirs because they don't want to sit around and do nothing whilst their computer is literally just huffing and puffing and doing some work. You also don't want that. So buy them the expensive computer, for God's sake. Now, a final thing.

Sophia Matveeva (23:49.531)
As we mentioned, developers need long chunks of time to basically sit there by themselves and write code on their expensive computers. So when you do quick interruptions, like when you have an idea and you just want to pop around and be like, Hey, how are you doing? I've got this idea. They absolutely hate it, but you also have to communicate with them. So what do you do? So here are some practical communication guidelines.

And these work for developers, also anybody on this maker's schedule. So number one, the rule of writing. So instead of knocking on their door and being like, Hey, how are doing? I've got an idea. Do you have five minutes? Do not do that. Put requests in writing so you can use email, you can use Slack. Do not expect them to have their notifications on because they should be doing deep work. So requests and writing and in communication that are basically not going to ping and disturb them every single time. Also.

prioritise things. So in my experience, when I would tell developers like, okay, let's do these features and these features, and I've had this idea and that idea, everybody absolutely hated that because they'll be like, well, we don't know what we're supposed to do. all of these features not going to fit into one sprint. What is it that you want from us? What you need is the priority system. You need to prioritise. Okay. If you have all of these ideas, which ones are the most important?

This is really where you need to link your business strategy to your product strategy. And this is something that we actually teach companies to do. So if you want to understand how to do that, then obviously call us. But anyway, the priority system, you need to label things as urgent emergency, only if they're a real emergency or normal priority, or we need to do this in the next three months or one month. So rule of writing, rule of priority.

Now let's talk about status updates. If you happen to see one of your development team walking through the office because they want to go to the toilet, the last thing you want to do is like jump on them and say, Hey, give me a status update. That's the worst thing that you can do. But you do need status updates. So basically ask them to give you status updates using asynchronous tools. Like we all have email. You can say to them, can you write me a status update at the end of the day? Okay, fine. That's useful, but

Sophia Matveeva (26:12.425)
Don't jump with them and don't ask them for random status updates. Basically, let developers update you when you're not in flow. During sprints, what you need to do is to collect all of your ideas. And in my company, we have this thing called the ice box. So you put all of your ideas into the ice box. And then when the sprint is over, you have a discussion about what ideas you're going to take out of the ice box and put into the next sprint. Also, finally, you do need to have an emergency protocol.

So you need to have a, first of in your mind, you need to have a clear definition of an emergency. You need to have one designated emergency channel. So people will know, okay, if we have a message in this Slack channel, that's where notifications will go off. That's where we will get pinged. And if we hear a ping from that channel, okay, we actually need to check everything else. It can be off. Final thing. Let's talk about crisis management. So when a company is in crisis, and actually I...

just recently saw this. There's a big engineering company that I know of and their release was like really late, like six months late. And they had customers waiting for this thing. Like this was definitely a crisis. And the management team was panicking. And I understand why they were panicking because their customers were saying, hang on, we've paid for this thing. It isn't here. What's going on? And this is a listed company. So yes, lots of stuff to panic about.

And what happens when managers panic is that they would have lots of meetings. And I have been guilty of this too. So I'm not criticizing. I get it because we kind of think, okay, we want to get things under control. We want to see like where I can help. You want to see like what you can do. The thing is when you're working with developers, as we discussed, the worst thing that you can do is to kind of interrupt them and have meetings all the time. So when you genuinely do have a crisis, just please refrain from having status updates all of the time.

because it's essentially like kids sitting in a car going, we're there yet, we're there yet, we're there yet. Okay. So yes, ask for status updates, maybe ask for a written email daily and have a weekly meeting. But the more status update meetings you have, basically the slower the crisis is going to be resolved. That is not to say I don't want you to listen to this lesson and to think, okay, well, what you're saying is basically just never speak to developers.

Sophia Matveeva (28:37.833)
pay them loads of money and give them expensive stuff. There is an element of that, but you obviously do also need to have status updates. need to share your ideas with them. But what I'm saying is that you need to do it in an ordered way. And in the business world, kind of on the business side, we're less ordered. We're more flowy. We're more like you have an idea, you read an article, you go to a meeting, you get people together. And then you're like, I had this idea. Let's try that. With developers.

You literally have a timetable and you're like, okay, on these days we discuss new ideas and we discuss what ideas are going to be implemented. On these days, we have status updates. Unless we are meeting with them in the designated times, we leave them alone. So basically business people, I love you. We do have to learn to control ourselves and developers because they're very different people and they work in very, very different ways. So conclusion, let's sum up.

hire the best teller that you possibly can and remove obstacles to their work. And obstacles include meetings, bureaucracy and cheap equipment. And understand that you're working with somebody who has a very different kind of brain and they probably have a very different kind of personality to you. So what's easy for you is not what's easy for them. So I hope that you found this lesson useful. If you have found this lesson useful, I would love it if you let me know because this kind of feels like a one-way conversation.

So either leave a comment if you're watching this on YouTube or if you're on Spotify, then you can actually just comment on Spotify or you can leave a rating. And on Apple, you can leave a rating and review. And thank you very much for everybody who's doing that. I read all your comments. You are warming my heart and it makes me very happy. So I'll be back with you next week for another lesson. And on that note, have a wonderful day and I'll be back with you next week. Ciao.