Managing Developers is HARD
I've been a software dev for a long time. I've also been running my own software company for a few years now. This is important information because of why I do these things. I am a sofware developer because I love learning. I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested. Why start a software company then? That puts me in the role of manager rather than developer. The truth is simple. I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development. That's not to say none of them have done a good job, but no one out there seems to be doing a great job.
A lot of companies get this part right. Software developers are different from other employees. The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction worker. But they are employees, which means they must be managed too. Software development is brain work. Everyone says this, but no one acknowledges what it means. Maybe I can get the point across with and example.
I was working my first .NET job years ago, and I was still learning how to code .NET. I was capable of coding other things, but I was still getting a grasp on the complexities of the Visual Studio IDE, something that takes months to years depending on the developer. A random manager (not the development manager) came up to me and asked me to create a bunch of folders on a shared drive. He sent me an excel spreadsheet with over 1k folder names. I pondered how to do it and gave him an estimate of 5 hours as I tried to figure out how to write a program to manage file systems in .NET. I started creating a complex application and learning about how the code could be used to manipulate the folders and how to import the list of folder-names from excel. After an hour, the development manager called me over and showed me how dumb I was being. He showed me a quick Excel trick (that I knew) to add extra columns with other content, (specifically the mkdir command from the windows command line) then copy pasted it into a command prompt and pressed enter. I immediately used his idea for the larger list and had the project completed in 5 minutes.
Developers are tasked with jobs that other people don't know how to do. There are usually 100 ways to do the task. It's not just the developer's job to do the task, but to find the most efficient way to do it. But if you think about what that means, something else may occur to you, something that every developer knows, even if they don't admit it to themselves. If you don't know how someone does something, how can you know where the limits of their capabilities end? Developers are often given tasks that have nothing to do with software development. In the example above, I could have simply spent 5 hours creating the folders by hand. It's not really software development, but the manager didn't know what is and what isn't included in that list. A knowledge worker's job is to get it done. Programming is a side-note to developers today. Our job is just "whatever it takes".
I talked about this at length in my previous post on Managing Developers. The truth is that your programmers took the job because they love it. But motivation is a genuine problem with all employees. The answer to this is (surprisingly) found in the daily scrum. I don't advise that all of Agile is needed for every org. But the morning meeting where developers talk to other developers about what they're doing is really everything you need to provide them with motivation. They will see when they're slow, and have help from others in moving quicker.
But as managers know, every person is unique. Many blogs suggest varying degrees of balance between pay and making the work interesting. But the truth is, your best developers will be working on code, even if they're not working on your code. Getting them to work on your code is matter of making your code something interesting to do, which a lot of companies get. But there's a second factor there that a lot of people forget as well. We'll get to that in a bit.
Developers make crappy managers. This isn't new information. In fact, in software development, to tell another developer "you would make a good manager" is an insult. It means "get out of my code, you're breaking it". Because developers make crappy managers, they don't often take on the role. More importantly, when they do, they do a bad job of that. Managing people is a complete 180 turn on how they did their job as a knowledge worker. As a knowledge worker, they had to "get it done" regardless. As a manager, their role becomes "what is reasonable to get done" and "what can I be certain of"?
What's worse is that estimating is hard. As I said above, software development is about getting any task done, even if you're not sure how to do it. How do you estimate how long it will take to do a task that you've never done before? You don't--not well at least. At the good software companies, at least they let the developers do the estimating (at the bad ones, their managers try to estimate for them), but that's not really a solution to every task being unique and new.
Unfortunately, while it's hard for developers to estimate, it's even harder for them to estimate their own skill level. I couldn't count the number of developers whose response to every task is "sure, I can do that". Maybe some of you can, but a minor argument could mean the difference between six years and six weeks. This would be a manager's job normally, but those managers were often developers before. So their default response is also "sure, we can do that".
And the hardest part to understand here is that the "sure, I can do that mentality" isn't wrong. As I said above, that's what a knowledge worker's job is. But when you transition into the role of managing people, your job is to make decisions, not to simply follow instructions. What tends to happen is the opposite. Developers either managing themselves or managing other developers just keep saying "yes I can" instead of "do you think that's a good idea?". They are perpetually, and consistently overworked. Actually, that's not true. Some of them are perpetually and consistently overworked. These guys burn out and quit. The others are perpetually and consistently under-performing, often intentionally to avoid ending up like the other group. There is very little middle ground.
That dichotomy has created an interesting stereotype. Developers are considered lazy. Their estimates are considered over-generous. And they're usually given even more work and complained to about how long it's taken. I like to refer to Software Development as magic (which I take directly from SCIP @ MIT). The problem with magic is that it is simultaneously impossible and instantaneous. So developers often see their co-workers simultaneously mesmerized by their work and complaining that it took too long. That's not a reasonable situation in any other profession.
The good managers have learned that managing up is often more important in software development than managing down. As I said, the good developers want to be there. But note that I'm also only talking about the good ones. Because many developers have worked other places and seen other developers burn out, they may already have bad habits and find ways to reduce their workload.
The reality is more akin to the Scotty Principle than you might think, and there's a reason for that. It's not about you. It's not about reducing the work-load. It's not even about keeping your boss in line. It's about your company! The cost of software is astronomical. It's goal is to make your company money (or save your company money, but the result is the same from an accounting perspective). And as we have seen, software estimates are basically bullshit, so if you trust them, you're going to have delays with releasing the software.
And that's the core of it. Unexpected delays cost money--a lot of money. If you release software early, no one gets hurt. If you release it late, often millions of dollars are lost. It is vital that software estimates be inflated, not for the overworked team members, not for the slackers, not even because it makes you look good to release early. It matters because the estimates will be wrong and that costs your company money.
Here's an example:
You tell your company (or customer) that it will take you 6 months to implement something. You deliver it in 3 months. The staff has been retrained in another month, and you have a better company for it. Imagine if you had said 2 months? Staff training taking a month, the company would have started retraining 1 month into the project. Retraining would be complete a full month before the project was finished. The staff training might stick, or it might not. The new machines they brought in to run the project would be sitting gathering dust, and the contract they had cancelled had to be unexpectedly renewed for astronomical costs--and that's just for starters.
Because the project is behind, you're pushed to release it in an incomplete state. Your developers are overworked and the end result is not as good as it would have been. To clean up the code and get it working right with all the original intended functionality is likely to actually end up taking the full 6 months in that situation. It's incredible.
This all sounds like you're going to end up being the manager who gets fired for stuff taking too long. And there will be people who claim they can do it faster, but that's corporate politics and is well outside the scope of this blog post. Here's the reality. Trust is everything in management. You're in charge of people because the company trusts you to have their best interests at heart. If you betray that trust by failing to deliver on time, then you are not strengthening your position.
Trust is even more of a big deal in software development. I often get jokes from charities I help out with IT services about how "I don't mess with you because I like my money in my bank account". And that's a real thing in enterprise development. Not just from the perspective of trusting programmers to correctly handle tons of PII data about you and your employees and customers, but also because the programmers don't have to be malicious to cost you money.
Since the role of managing software development is more trust-inflated than even that of other managers, you need to be that much more reliable. If you make a mistake, the costs can literally be every dollar in the bank. Do not take that responsibility lightly. More importantly, don't shrug it off to get a slightly better estimate. Take your time. Get it right. This is a scientific game, not a productivity one.
This is where things get interesting. We have seen companies (like Valve) where their programmers never complete a project. This is a very real possibility if you only manage up. If you only ever inflate estimates and keep telling the upper management "no". But that's only half of managing programmers. What I've described so far is all about managing their estimates. The second part of this discussion is about managing the work.
Everything I have to say about this can be summarized in one sentence. Don't lose focus. Software Developers (especially the good ones) love to explore every new technology, try every new thing, and learn every new language. At every meeting with them, you can expect them to suggest using this technology or that to make the project better. New things excite them.
Other managers, similarly, love exploring new ideas. New sales ideas, new software to increase productivity. New technology that will automate more of the business. These ideas align perfectly. The result is that the managers and programmers feed off of each other talking about how they can leverage this new technology to provide this new software. It is a wonderful experience being in a meeting of dreamers like that. The problem, of course, is that dreamers aren't always doers.
Dream big. Let your developers dream big. But you set the timeline. You set the agenda. And you make sure they finish a project before moving onto the next. Managers will often want to pull people off of your current project to start on another. Push back! If your company is worth the money they pay you, then it's important work! A manager pulling a programmer off of one project--even one the developer is excited about--is just as dangerous as changing your technology stack halfway through a project. And it happens ALL THE TIME.
Work will progress just fine, as long as you don't let your programmers lose focus, either from their own hubris (I can implement this new thing in no time) or from the company's eagerness to try new things.
Something magical happens when these things align. Your developers find they don't have to pretend not to work hard. Your managers don't have unrealistic expectations. Your company makes money, and progress moves forward--at a reasonable, but not breakneck pace.
Something even more terrifyingly magical happens when they don't. I've seen this, so this is actually happening. There are companies that no longer hire their internal software developers to do things. They hire outside contractors because their internal developers give them timelines that can literally be 10 years for a single page website with no major functionality.
That is not how a manager conflates timelines. That is how a developer does. This is a place where the developers have learned that no amount of time is enough. So they come up with arbitrarily high numbers because they don't want to be wrong anymore.
So understand how important it is for you to get it right. Because if you don't they'll find another way to survive, and it will look like that, or worse...and yes, I've seen worse too.
How are they different?
A lot of companies get this part right. Software developers are different from other employees. The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction worker. But they are employees, which means they must be managed too. Software development is brain work. Everyone says this, but no one acknowledges what it means. Maybe I can get the point across with and example.
I was working my first .NET job years ago, and I was still learning how to code .NET. I was capable of coding other things, but I was still getting a grasp on the complexities of the Visual Studio IDE, something that takes months to years depending on the developer. A random manager (not the development manager) came up to me and asked me to create a bunch of folders on a shared drive. He sent me an excel spreadsheet with over 1k folder names. I pondered how to do it and gave him an estimate of 5 hours as I tried to figure out how to write a program to manage file systems in .NET. I started creating a complex application and learning about how the code could be used to manipulate the folders and how to import the list of folder-names from excel. After an hour, the development manager called me over and showed me how dumb I was being. He showed me a quick Excel trick (that I knew) to add extra columns with other content, (specifically the mkdir command from the windows command line) then copy pasted it into a command prompt and pressed enter. I immediately used his idea for the larger list and had the project completed in 5 minutes.
Developers are tasked with jobs that other people don't know how to do. There are usually 100 ways to do the task. It's not just the developer's job to do the task, but to find the most efficient way to do it. But if you think about what that means, something else may occur to you, something that every developer knows, even if they don't admit it to themselves. If you don't know how someone does something, how can you know where the limits of their capabilities end? Developers are often given tasks that have nothing to do with software development. In the example above, I could have simply spent 5 hours creating the folders by hand. It's not really software development, but the manager didn't know what is and what isn't included in that list. A knowledge worker's job is to get it done. Programming is a side-note to developers today. Our job is just "whatever it takes".
How do you keep them working?
I talked about this at length in my previous post on Managing Developers. The truth is that your programmers took the job because they love it. But motivation is a genuine problem with all employees. The answer to this is (surprisingly) found in the daily scrum. I don't advise that all of Agile is needed for every org. But the morning meeting where developers talk to other developers about what they're doing is really everything you need to provide them with motivation. They will see when they're slow, and have help from others in moving quicker.
But as managers know, every person is unique. Many blogs suggest varying degrees of balance between pay and making the work interesting. But the truth is, your best developers will be working on code, even if they're not working on your code. Getting them to work on your code is matter of making your code something interesting to do, which a lot of companies get. But there's a second factor there that a lot of people forget as well. We'll get to that in a bit.
How they screw themselves
Developers make crappy managers. This isn't new information. In fact, in software development, to tell another developer "you would make a good manager" is an insult. It means "get out of my code, you're breaking it". Because developers make crappy managers, they don't often take on the role. More importantly, when they do, they do a bad job of that. Managing people is a complete 180 turn on how they did their job as a knowledge worker. As a knowledge worker, they had to "get it done" regardless. As a manager, their role becomes "what is reasonable to get done" and "what can I be certain of"?
What's worse is that estimating is hard. As I said above, software development is about getting any task done, even if you're not sure how to do it. How do you estimate how long it will take to do a task that you've never done before? You don't--not well at least. At the good software companies, at least they let the developers do the estimating (at the bad ones, their managers try to estimate for them), but that's not really a solution to every task being unique and new.
Unfortunately, while it's hard for developers to estimate, it's even harder for them to estimate their own skill level. I couldn't count the number of developers whose response to every task is "sure, I can do that". Maybe some of you can, but a minor argument could mean the difference between six years and six weeks. This would be a manager's job normally, but those managers were often developers before. So their default response is also "sure, we can do that".
And the hardest part to understand here is that the "sure, I can do that mentality" isn't wrong. As I said above, that's what a knowledge worker's job is. But when you transition into the role of managing people, your job is to make decisions, not to simply follow instructions. What tends to happen is the opposite. Developers either managing themselves or managing other developers just keep saying "yes I can" instead of "do you think that's a good idea?". They are perpetually, and consistently overworked. Actually, that's not true. Some of them are perpetually and consistently overworked. These guys burn out and quit. The others are perpetually and consistently under-performing, often intentionally to avoid ending up like the other group. There is very little middle ground.
That dichotomy has created an interesting stereotype. Developers are considered lazy. Their estimates are considered over-generous. And they're usually given even more work and complained to about how long it's taken. I like to refer to Software Development as magic (which I take directly from SCIP @ MIT). The problem with magic is that it is simultaneously impossible and instantaneous. So developers often see their co-workers simultaneously mesmerized by their work and complaining that it took too long. That's not a reasonable situation in any other profession.
So how do you manage that?
The good managers have learned that managing up is often more important in software development than managing down. As I said, the good developers want to be there. But note that I'm also only talking about the good ones. Because many developers have worked other places and seen other developers burn out, they may already have bad habits and find ways to reduce their workload.
attribution: Dilbert
The reality is more akin to the Scotty Principle than you might think, and there's a reason for that. It's not about you. It's not about reducing the work-load. It's not even about keeping your boss in line. It's about your company! The cost of software is astronomical. It's goal is to make your company money (or save your company money, but the result is the same from an accounting perspective). And as we have seen, software estimates are basically bullshit, so if you trust them, you're going to have delays with releasing the software.
And that's the core of it. Unexpected delays cost money--a lot of money. If you release software early, no one gets hurt. If you release it late, often millions of dollars are lost. It is vital that software estimates be inflated, not for the overworked team members, not for the slackers, not even because it makes you look good to release early. It matters because the estimates will be wrong and that costs your company money.
Here's an example:
You tell your company (or customer) that it will take you 6 months to implement something. You deliver it in 3 months. The staff has been retrained in another month, and you have a better company for it. Imagine if you had said 2 months? Staff training taking a month, the company would have started retraining 1 month into the project. Retraining would be complete a full month before the project was finished. The staff training might stick, or it might not. The new machines they brought in to run the project would be sitting gathering dust, and the contract they had cancelled had to be unexpectedly renewed for astronomical costs--and that's just for starters.
Because the project is behind, you're pushed to release it in an incomplete state. Your developers are overworked and the end result is not as good as it would have been. To clean up the code and get it working right with all the original intended functionality is likely to actually end up taking the full 6 months in that situation. It's incredible.
Why would you do that?
This all sounds like you're going to end up being the manager who gets fired for stuff taking too long. And there will be people who claim they can do it faster, but that's corporate politics and is well outside the scope of this blog post. Here's the reality. Trust is everything in management. You're in charge of people because the company trusts you to have their best interests at heart. If you betray that trust by failing to deliver on time, then you are not strengthening your position.
Trust is even more of a big deal in software development. I often get jokes from charities I help out with IT services about how "I don't mess with you because I like my money in my bank account". And that's a real thing in enterprise development. Not just from the perspective of trusting programmers to correctly handle tons of PII data about you and your employees and customers, but also because the programmers don't have to be malicious to cost you money.
Since the role of managing software development is more trust-inflated than even that of other managers, you need to be that much more reliable. If you make a mistake, the costs can literally be every dollar in the bank. Do not take that responsibility lightly. More importantly, don't shrug it off to get a slightly better estimate. Take your time. Get it right. This is a scientific game, not a productivity one.
But nothing will get done!
This is where things get interesting. We have seen companies (like Valve) where their programmers never complete a project. This is a very real possibility if you only manage up. If you only ever inflate estimates and keep telling the upper management "no". But that's only half of managing programmers. What I've described so far is all about managing their estimates. The second part of this discussion is about managing the work.
Everything I have to say about this can be summarized in one sentence. Don't lose focus. Software Developers (especially the good ones) love to explore every new technology, try every new thing, and learn every new language. At every meeting with them, you can expect them to suggest using this technology or that to make the project better. New things excite them.
Other managers, similarly, love exploring new ideas. New sales ideas, new software to increase productivity. New technology that will automate more of the business. These ideas align perfectly. The result is that the managers and programmers feed off of each other talking about how they can leverage this new technology to provide this new software. It is a wonderful experience being in a meeting of dreamers like that. The problem, of course, is that dreamers aren't always doers.
Dream big. Let your developers dream big. But you set the timeline. You set the agenda. And you make sure they finish a project before moving onto the next. Managers will often want to pull people off of your current project to start on another. Push back! If your company is worth the money they pay you, then it's important work! A manager pulling a programmer off of one project--even one the developer is excited about--is just as dangerous as changing your technology stack halfway through a project. And it happens ALL THE TIME.
Work will progress just fine, as long as you don't let your programmers lose focus, either from their own hubris (I can implement this new thing in no time) or from the company's eagerness to try new things.
And...Magic!
Something magical happens when these things align. Your developers find they don't have to pretend not to work hard. Your managers don't have unrealistic expectations. Your company makes money, and progress moves forward--at a reasonable, but not breakneck pace.
Something even more terrifyingly magical happens when they don't. I've seen this, so this is actually happening. There are companies that no longer hire their internal software developers to do things. They hire outside contractors because their internal developers give them timelines that can literally be 10 years for a single page website with no major functionality.
That is not how a manager conflates timelines. That is how a developer does. This is a place where the developers have learned that no amount of time is enough. So they come up with arbitrarily high numbers because they don't want to be wrong anymore.
So understand how important it is for you to get it right. Because if you don't they'll find another way to survive, and it will look like that, or worse...and yes, I've seen worse too.
Comments
Post a Comment