The Mindful Manager

I’ve been on both sides. I’ve gone from being a first-line manager, then back to a developer. Then a director, then back to a developer. Then a VP, and yes, then back to a developer – which is what I am now, a developer.

One of my observations of the differences between developers and managers is how each views software schedules. Managers want schedules. They want them to show progress on the software. Sometimes their compensation is tied to major milestones in the schedule. Sometimes they want to show their boss/manager how good they are at managing by driving their teams to finish the software as quickly as possible. I get the pressure of showing progress. As a manager, if I didn’t show progress via a schedule with major milestones, I would definitely receive a poor performance rating.

On the developer side, schedules are arbitrary especially if it is an entirely new product. How can I know when it will be done if I don’t know everything required to create this new product?

Take, for example, the application I am working on now. It’s totally new. There is no code base I can leverage to get things up and running quickly. For new features that require API’s that I haven’t used before, I have to read up and understand how to use them in the new product’s code base. Then I have to consider the design and design patterns to use so that I don’t write spaghetti code. Well, I could write spaghetti code but I will only suffer when I need to add a new feature or I find I need to provide an API between subsystems. I try to set milestones but I sometimes miss them because of unfamiliarity with an API or a needed design feature.

However, I also find that if I don’t have milestones defined, I procrastinate. Maybe I should watch one or two more WWDC videos on whatever topic so I really understand how something works. Or, I don’t remember a particular algorithm that might be more efficient. Better read up on it! I find in the absence of a schedule, I wander a bit from the work. I could argue learning is always beneficial, but I find I can really take it to an extreme.

So are schedules good or bad? I’m neutral on it. As a developer, I think schedules can help me stay focused. But the schedule often doesn’t include time for things that are unexpected, particularly if it is a totally new piece of software. As a manager, I want to know the team is making progress on the software. A schedule helps me to see that progress.

Is there a way to balance these two views? I think there is. Both the developer and manager must consider the other’s needs. The developer requires time baked into the schedule to learn and to write good software. The manager supports this by creating milestones allowing for learning and for the unexpected. The manager does not go crazy if milestones aren’t obtained, however, the developer clearly communicates why milestones might be missed – and does so as soon as possible before the milestone arrives. Missing a milestone should be for good reasons. For me, I need the focus milestones provide. None of this is perfect. But developing software isn’t a perfect process with a checklist. Yes, as a manager I’ve had those checklists, but it didn’t help complete the software any faster.

Give and take is needed on both sides when creating a schedule. Both sides have to sign up for constant communication on the progress of developing the software and any unexpected issues that arise.

Give and take + frequent communication = creating software schedules that work.