Developer Time vs Manager Time

Oct 5, 2020 business management
This post is more than 18 months old. Since technology changes too rapidly, this content may be out of date (but that's not always the case). Please remember to verify any technical or programming information with the current release.

A full calendar, hours on the phone, work into the night and a never-ending deluge of emails: the typical Dev Manager’s life. Time is precious and scarce. It’s also very fluid. You’re jumping from thing to thing; meetings get pushed and calls are rushed. It’s not ideal, but it seems to be the only way you can get to all of the things that need your attention.

You might start to notice that your developers get more and more angry when you have to push a meeting. Or they’re complaining about having too many meetings. Don’t they understand how busy you are? And without meetings, how will you know what’s going on?

There are two types of time: producers and operators. Producer’s time comes in blocks. It takes time to warm up the machine, fit the parts, start the run and mark the job as complete. The operator’s time is one long string. Operators moves through the system assessing, adjusting and measuring. They can move between product lines, control many processes at once, and juggle multiple initiatives. The producer can only focus on their line. Without this focus, much more waste is introduced.

Dev Managers are operators. You move through each team swiftly and fluidly. Your “work” is the information you consume, the adjustments you dictate and delegate, and the processes you assess. Operators can shift easily and quickly because they don’t require massive setup time.

Developers are producers. They need to get their process set up and have some run time to become productive. Opening up their code editor, finding their tasks and tickets, and getting into the creation “headspace” takes time. Once the art of work starts to happen, they need time to really stretch out without being interrupted. Toward the end, they need to mark a completion point, communicate or adjust tickets, and clear their head of all the complexities they were holding during this process. If you’ve ever seen a production line screech to a halt, that’s exactly what happens inside of a programmer’s mind when they are interrupted.

A great Dev Manager understands that there are two types of time. They will respect the process that producers need and try not to interrupt them. Keeping to the communicated timetable really helps — the developer will be ready for you at the required time. If you push this, they’re not going to get any more work done because there isn’t a big enough block. Or, if you cancel it entirely, you’ve wasted a bunch of their time. They had to shut down the line. Now, they have to start it back up again. In a way, it’s self-sabotage for the Dev Manager. The more you force your style of time onto the developers, the less they get done, and the less effective your team is.

The next time you feel like your time is starting to get out of control, don’t panic. The worst thing you can do is blindly push around meetings and impede on your developers. Your time is the most fluid. So, instead, move around your stuff around keep to the time commitments you made with the producers. It’s that easy. You’ll get more productivity and your developers will respect you more.

Go to All Posts