4 ms·

I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not go

by Gratsby 11y ago

I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not good at task management, project management, and certainly not estimation. One of the primary reasons for this is that their plates are always overflowing and they work more efficiently than many people in other professions. They shift priorities on the fly when work in one area cannot be progressed. Development time is social currency. You can make your boss happy by progressing his priority, or you can make someone else happy by progressing their priorities. Not many developers truly answer to a singular master. And few allocate time for learning although we all spend a significant amount of time doing it - how else do we maintain relevant skill sets? Can a developer really estimate a project and tell his manager that 3 weeks in the timeline are for 2 unknown and unforeseen problems that require interaction with vendor support? No, because the manager will fight back and say that those 3 weeks are really just zipping up logs and making three phone calls and "if it takes anything more than that, hand it over to me!" Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. The solution to this problem is simple. Take task management and project estimation out of the hands of developers. It's time for the return of the secretary to the workplace. A single $50-80k administrative assistant could easily support, manage the priorities of, and improve the outward facing communication for five developers. With experience doing so, that admin could provide better time estimates for all of them and would be better at negotiating realistic timelines than any of them individually. People have been coming up with methodologies and software to solve this problem for decades. Developers don't have brains built for project management. Yes, they can do it, but they don't get paid to work in MS Project. They get paid because they know the difference between a bubble sort and a quick sort and when to use either. Conversely, I don't know a soccer mom who doesn't successfully manage a more challenging schedule and competing set of priorities better than every nose-down developer I've ever met. Give appropriate work to appropriate people. Developers have their talents. Scheduling, estimating, and task management are not among them.

orky56 11y ago
Ideally a product manager solves or assists with many of those problems- 1. Reduce the ambiguity of what features to work on and what are the priorities. This involves being the barrier from other manager and team members trying to pull a fast on and changing what should be worked on. 2. Stay on top of what the latest estimates are in an honest and transparent way. Product managers as project managers should be able to translate what a particular developer says into what estimation might be in reality. They can acquire or release resources, or even change scope accordingly or at least make the case. 3. Product managers should provide developers a constant opportunity to break down tasks into components that can be tracked easily in Asana or another task management tool. This takes discipline as a product manager to enforce a system onto developers in ways that make sense. Disclaimer: Product manager here.
- Gratsby 11y ago
  Theoretically yes, and if you're the unicorn, then I'm sure you are very appreciated (and probably under-compensated). Seriously. I'm not mocking you. With a person who's job is to help you and who is not above you on the food chain, you are more likely to have an honest self assessment. Also, with a third party in place, fairness becomes part of the equation. When a developer has to defend his timeline it's personal and can be very stressful. When a third party has to defend the same timeline it's just a matter of business. Conversely, when a third party is in play that is told that a developer needs to produce more, their instinct is to prioritize accordingly rather than simply add more hours to the work day (which is a common instinct among developers).
squeaky-clean 11y ago
Going to join you in this rant if you don't mind. > Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. Ugh! For real! I had this happen to me recently. I have trouble telling people "No", and pushy PMs who also happen to be my friends means that I often bite off more than I can chew, and have to either "be a rockstar" (which you start to realize isn't such a compliment), or deliver late / fail to deliver. So I just started being a dick about it, and it works for me. If I say no too politely, it's really easy to convince me to change to a yes. My turning point was when discussing a project that was much more complex than management assumed it would be (I'm compelled to link the relevant xkcd [0]), and I already felt overwhelmed on my current projects. The discussion was something like "Ok, how about by this date? What about by this date? What if we dropped these features?", I thought for a moment and responded "Ok, look. I can promise you any date you want, and we can shake hands and leave this meeting. But I'm telling you the reality is I can't do it, and it won't be done. If you'd like to take some of my other projects and move them into the will not be done category, we can talk. I'm only saying this because I don't want to agree to a deadline and then be constantly thinking 'Oh well, that's the date I'm getting fired.'" I'm very lucky that everyone here is really nice, and realized how stressed I must have been to react like that. So we've reprioritized some things and are beginning to outsource some of my more menial tasks that took up a lot of time. Didn't really intend for that story to have a point, just venting something my non-dev friends don't relate to. I guess the point could be that the problem isn't just caused by bad managers, or bad dev estimates, or bad process, it's a little bit of everything, and the ratios are different for every company or person. [0] http://xkcd.com/1425/ http://xkcd.com/1425/

by Gratsby 11y ago

orky56 11y ago

Ideally a product manager solves or assists with many of those problems- 1. Reduce the ambiguity of what features to work on and what are the priorities. This involves being the barrier from other manager and team members trying to pull a fast on and changing what should be worked on. 2. Stay on top of what the latest estimates are in an honest and transparent way. Product managers as project managers should be able to translate what a particular developer says into what estimation might be in reality. They can acquire or release resources, or even change scope accordingly or at least make the case. 3. Product managers should provide developers a constant opportunity to break down tasks into components that can be tracked easily in Asana or another task management tool. This takes discipline as a product manager to enforce a system onto developers in ways that make sense. Disclaimer: Product manager here.

Gratsby 11y ago
Theoretically yes, and if you're the unicorn, then I'm sure you are very appreciated (and probably under-compensated). Seriously. I'm not mocking you. With a person who's job is to help you and who is not above you on the food chain, you are more likely to have an honest self assessment. Also, with a third party in place, fairness becomes part of the equation. When a developer has to defend his timeline it's personal and can be very stressful. When a third party has to defend the same timeline it's just a matter of business. Conversely, when a third party is in play that is told that a developer needs to produce more, their instinct is to prioritize accordingly rather than simply add more hours to the work day (which is a common instinct among developers).

squeaky-clean 11y ago

Going to join you in this rant if you don't mind. > Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. Ugh! For real! I had this happen to me recently. I have trouble telling people "No", and pushy PMs who also happen to be my friends means that I often bite off more than I can chew, and have to either "be a rockstar" (which you start to realize isn't such a compliment), or deliver late / fail to deliver. So I just started being a dick about it, and it works for me. If I say no too politely, it's really easy to convince me to change to a yes. My turning point was when discussing a project that was much more complex than management assumed it would be (I'm compelled to link the relevant xkcd [0]), and I already felt overwhelmed on my current projects. The discussion was something like "Ok, how about by this date? What about by this date? What if we dropped these features?", I thought for a moment and responded "Ok, look. I can promise you any date you want, and we can shake hands and leave this meeting. But I'm telling you the reality is I can't do it, and it won't be done. If you'd like to take some of my other projects and move them into the will not be done category, we can talk. I'm only saying this because I don't want to agree to a deadline and then be constantly thinking 'Oh well, that's the date I'm getting fired.'" I'm very lucky that everyone here is really nice, and realized how stressed I must have been to react like that. So we've reprioritized some things and are beginning to outsource some of my more menial tasks that took up a lot of time. Didn't really intend for that story to have a point, just venting something my non-dev friends don't relate to. I guess the point could be that the problem isn't just caused by bad managers, or bad dev estimates, or bad process, it's a little bit of everything, and the ratios are different for every company or person. [0] http://xkcd.com/1425/ http://xkcd.com/1425/