The user is always right
November 23, 2011 12:53 PM Subscribe
I get really frustrated with the process at my workplace, particularly meetings. After many details, I have a couple of questions about work (specifically software development and project management decisions) and how to deal with meeting-related frustration.
I work for a small research department of a larger business. Myself and a second person were hired to create a software application to assist in the research this department does. Neither of us has had a software development position before. We are under the guidance of a Project Manager (PM) who has worked in marketing and is knowledgeable in this specific realm of research but not in software. There are a few other "advisory" team members: A couple of researchers familiar with the research process, a programmer 'consultant', and the lead researcher, the visionary behind this software application.
The second programmer and my roles are pretty much the same - we both work on all aspects of the project. We started with nothing except a vague goal that has changed tremendously over time. When we started, I decided on the programming language to use (this fact is important and overwhelming and embarrassing to me, because it makes me feel like a) I should be an expert in all things related to the language [I'm not], and b) that any limitations of the application are my fault because I picked the language). At this point we have more or less finished the basic application and we have a well established "to-do" list of features. In addition to creating this application, we are occasionally given writing tasks to do, mock-ups to make, presentations to make for researchers to show elsewhere, and documentation tasks. Part of our role has also been to help design this application, which I've found to be difficult given the complexity of this research and my lack of depth of knowledge in it.
However, I'm having a problem with the processes here. I cannot tell if these are personal issues that I have and need to get over (such as being a control freak, or not understanding how "work" works), or if these are issues anyone would have in this situation. This is my first job after college and I really do not know what is "normal."
Many times during the week we have meetings that are just the three of us - two programmers and PM. When PM is around these meetings can happen one to three times a day. Full project-team meetings happen weekly. Lately I am finding that I have to suppress a huge amount of annoyance and frustration before and during these meetings, particularly the PM-only ones. To hide it, I try not to volunteer input, and I say as little as possible to get the meeting over with. Other tactics (providing and defending my opinion, suggesting an idea) have proven unsuccessful. A PM meeting is usually something like the following:
- "Can you come into my office and look at something? Look at [X feature on some commercial program]. Can we do something like that for [Y feature on our program]? Is it hard to do?"
- "Let's go through this list of comments from users. User A thinks the label on this button should be different, let's change that. User B thinks [Z feature on our application] should be more like [Q feature on commercial application]. [Head researcher] would like that. How long would it take to do that?"
- "Let's look at your mockups for the next to-do feature. Can we make it look more like [existing application] I showed you? What if a user wants to [do more complex thing we didn't discuss before]?"
In our last full team meeting, PM had my co-programmer demo the progress of a feature. The resulting team conversation was about rearranging stuff on screen, and eventually went backwards to discussing changing an existing feature. (Co-Programmer and I do not have the authority to say "No, we aren't going to change that.") After this I presented some mock-ups PM asked me to do. I only got to slide 3 of 20. The team discussion was about user privileges (something that has been discussed greatly but not decided on), and the conclusion from Head Researcher was "let's come up with more general concepts for the feature." Another point of frustration for me was that it had previously been agreed that my mock-ups would apply to a clearly defined scope of the project, but much team discussion was about having the feature in a larger scope that would be more complex (and confusing to users) and take more time to create. I will probably end up having to implement both.
Re-reading these things, they do not seem that bad and I should be able to suck it up and deal with it. However, for some reason I have become conditioned to feel overwhelmingly ANNOYED by meetings. I dread them. I am starting to dread hearing PM's voice. I am struggling to articulate why I feel this way. I think it is because nothing is ever decided. We never get a chance to perfect and fix problems in what we have because we are always adding new bells and whistles and changing things to make the team happy. If I volunteer what I think is valid input, it's not used or it's modified until it's complicated. I feel kind of bad for the users of this application and I don't have much pride in the result - but I am not a researcher/user so maybe it is completely fine!
Another short story: When Head Researcher thought we might want to get input from a user interface consultant, I quickly jumped on it and found one. I was hoping that some things might get finalized faster if we had an authority on software design and development giving us advice. Nobody really knew 'how to use' the UI consultant. We do not get input from them any more because "the research process is too complex" and they can't help us with designing features without us taking lots of time to teach them about the process.
Yesterday when talking to PM, they said "No, you really seem more angry when things don't go your way" and I internally said oh no everyone here thinks I'm selfish and bitchy and angry all the time, better apply for jobs on the other side of the country so I can never see any of them again. I wasn't able to express that I'm trying really hard not to be a jerk, it's not because things don't go my way, I really don't care if someone likes my input or not, it is this inexplicable frustration I feel at the process of things here. PM's comment to me from yesterday and my internal reaction to it are leading me to seek advice here.
What I need help on is:
- Are these normal processes for software development? Are these meeting situations par for the course, or is it just my particular workplace? Do I just not understand something here?
- Is my inner meeting rage completely unjustified? Do I have anger problems?
- How can I get rid of my meeting frustration and just be a normal worker who works? If I can't get rid of it, how can I better hide it?
- Does this mean I will be frustrated as a software developer anywhere?
Thanks for taking the time to read this mess. I can attempt to clarify anything as needed. But feel free to tear me apart. I think I need it.
I work for a small research department of a larger business. Myself and a second person were hired to create a software application to assist in the research this department does. Neither of us has had a software development position before. We are under the guidance of a Project Manager (PM) who has worked in marketing and is knowledgeable in this specific realm of research but not in software. There are a few other "advisory" team members: A couple of researchers familiar with the research process, a programmer 'consultant', and the lead researcher, the visionary behind this software application.
The second programmer and my roles are pretty much the same - we both work on all aspects of the project. We started with nothing except a vague goal that has changed tremendously over time. When we started, I decided on the programming language to use (this fact is important and overwhelming and embarrassing to me, because it makes me feel like a) I should be an expert in all things related to the language [I'm not], and b) that any limitations of the application are my fault because I picked the language). At this point we have more or less finished the basic application and we have a well established "to-do" list of features. In addition to creating this application, we are occasionally given writing tasks to do, mock-ups to make, presentations to make for researchers to show elsewhere, and documentation tasks. Part of our role has also been to help design this application, which I've found to be difficult given the complexity of this research and my lack of depth of knowledge in it.
However, I'm having a problem with the processes here. I cannot tell if these are personal issues that I have and need to get over (such as being a control freak, or not understanding how "work" works), or if these are issues anyone would have in this situation. This is my first job after college and I really do not know what is "normal."
Many times during the week we have meetings that are just the three of us - two programmers and PM. When PM is around these meetings can happen one to three times a day. Full project-team meetings happen weekly. Lately I am finding that I have to suppress a huge amount of annoyance and frustration before and during these meetings, particularly the PM-only ones. To hide it, I try not to volunteer input, and I say as little as possible to get the meeting over with. Other tactics (providing and defending my opinion, suggesting an idea) have proven unsuccessful. A PM meeting is usually something like the following:
- "Can you come into my office and look at something? Look at [X feature on some commercial program]. Can we do something like that for [Y feature on our program]? Is it hard to do?"
- "Let's go through this list of comments from users. User A thinks the label on this button should be different, let's change that. User B thinks [Z feature on our application] should be more like [Q feature on commercial application]. [Head researcher] would like that. How long would it take to do that?"
- "Let's look at your mockups for the next to-do feature. Can we make it look more like [existing application] I showed you? What if a user wants to [do more complex thing we didn't discuss before]?"
In our last full team meeting, PM had my co-programmer demo the progress of a feature. The resulting team conversation was about rearranging stuff on screen, and eventually went backwards to discussing changing an existing feature. (Co-Programmer and I do not have the authority to say "No, we aren't going to change that.") After this I presented some mock-ups PM asked me to do. I only got to slide 3 of 20. The team discussion was about user privileges (something that has been discussed greatly but not decided on), and the conclusion from Head Researcher was "let's come up with more general concepts for the feature." Another point of frustration for me was that it had previously been agreed that my mock-ups would apply to a clearly defined scope of the project, but much team discussion was about having the feature in a larger scope that would be more complex (and confusing to users) and take more time to create. I will probably end up having to implement both.
Re-reading these things, they do not seem that bad and I should be able to suck it up and deal with it. However, for some reason I have become conditioned to feel overwhelmingly ANNOYED by meetings. I dread them. I am starting to dread hearing PM's voice. I am struggling to articulate why I feel this way. I think it is because nothing is ever decided. We never get a chance to perfect and fix problems in what we have because we are always adding new bells and whistles and changing things to make the team happy. If I volunteer what I think is valid input, it's not used or it's modified until it's complicated. I feel kind of bad for the users of this application and I don't have much pride in the result - but I am not a researcher/user so maybe it is completely fine!
Another short story: When Head Researcher thought we might want to get input from a user interface consultant, I quickly jumped on it and found one. I was hoping that some things might get finalized faster if we had an authority on software design and development giving us advice. Nobody really knew 'how to use' the UI consultant. We do not get input from them any more because "the research process is too complex" and they can't help us with designing features without us taking lots of time to teach them about the process.
Yesterday when talking to PM, they said "No, you really seem more angry when things don't go your way" and I internally said oh no everyone here thinks I'm selfish and bitchy and angry all the time, better apply for jobs on the other side of the country so I can never see any of them again. I wasn't able to express that I'm trying really hard not to be a jerk, it's not because things don't go my way, I really don't care if someone likes my input or not, it is this inexplicable frustration I feel at the process of things here. PM's comment to me from yesterday and my internal reaction to it are leading me to seek advice here.
What I need help on is:
- Are these normal processes for software development? Are these meeting situations par for the course, or is it just my particular workplace? Do I just not understand something here?
- Is my inner meeting rage completely unjustified? Do I have anger problems?
- How can I get rid of my meeting frustration and just be a normal worker who works? If I can't get rid of it, how can I better hide it?
- Does this mean I will be frustrated as a software developer anywhere?
Thanks for taking the time to read this mess. I can attempt to clarify anything as needed. But feel free to tear me apart. I think I need it.
Best answer: It sounds to me like your anger is because you feel responsible for delivering good software, but powerless to actually do what you think is right because of direction from your customer (the PM). That's a pretty common source of frustration in software development.
In your situation I would just try to let go of that sense of responsibility: you are the programmer and your job is to implement what the PM wants. Do that well, and you have discharged your job responsibilities.
To actually improve the situation for yourself, you can try a couple of things - one may be to just treat it as a learning exercise in software development. How are your language skills for instance - if you're going to use that language in the future maybe try to use the job to extend them. Or look at the process more broadly - how do you build and deploy the software - is that automated? Do you have automated tests? Source control? How do you know when you broke something? There's sure to be something you could learn and develop from on the technical side.
If you want to push back a bit more, maybe consider learning about Scrum or a similar process, and then trying to persuade the PM that you will be more effective if you go through the cycles of planning features, implementing those features without interruption or change for a set time, and then demoing and re-planning. To me the small team and desire for quick changes would suggest this is a good project for that kind of agile methodology.
posted by crocomancer at 1:29 PM on November 23, 2011 [5 favorites]
In your situation I would just try to let go of that sense of responsibility: you are the programmer and your job is to implement what the PM wants. Do that well, and you have discharged your job responsibilities.
To actually improve the situation for yourself, you can try a couple of things - one may be to just treat it as a learning exercise in software development. How are your language skills for instance - if you're going to use that language in the future maybe try to use the job to extend them. Or look at the process more broadly - how do you build and deploy the software - is that automated? Do you have automated tests? Source control? How do you know when you broke something? There's sure to be something you could learn and develop from on the technical side.
If you want to push back a bit more, maybe consider learning about Scrum or a similar process, and then trying to persuade the PM that you will be more effective if you go through the cycles of planning features, implementing those features without interruption or change for a set time, and then demoing and re-planning. To me the small team and desire for quick changes would suggest this is a good project for that kind of agile methodology.
posted by crocomancer at 1:29 PM on November 23, 2011 [5 favorites]
Best answer: I feel your pain. I was you 15 years ago (business analyst, not programmer, but techie).
- these types of frustrations are pretty much par for the course. I've worked in 3 different companies in the BA capacity, and all were very different in their processes, but the similarities are: Users don't understand the SD process (even the simplistic waterfall method) and it results in scope creep to the nth degree. Is your company using a requirements document? Where are the ideas, expectations, etc., being documented? It can be helpful to have two main "buckets" for all the features and/or bug fixes needed.... 1 is a master list of everything that occurs to anyone with an idea; 2 is copying items from the master list to an actual requirements document when a project scope is defined.
- your inner rage is not COMPLETELY unjustified, but you have to learn to let this shit go or you will drive yourself crazy, and won't be happy in any job since it happens everywhere. Your ambition will also be stifled because your higher ups will see the bad attitude and be more reluctant to promote you.
- seriously consider getting an SSRI anti depressant. I have found that my brain chemistry doesn't ALLOW me to let things go without the meds I'm on. Whatever you do, you have to learn to LET THIS SHIT GO. I'm repeating myself on purpose here!
There are a lot of strategies for trying to cope with this. One is the meds, obviously. You can try re-framing how you look at things... in academia we are all taught the SD process and how things "should" work. Instead of putting that frame on things, why not think of every change they want to make as job security for you? Software is NEVER really done, especially when it's an internal application that users can tweak practically on demand. So basically, strategy #2 is doing what you can to adjust your attitude, and do it for YOURSELF. A third strategy would be to try to formalize the SD process a little more at your company. Sounds like your PM is not trained in software dev practices. Coming from marketing, brainstorming and coming up with cool ideas is a really good thing. They don't see it as annoying scope creep. Can you approach your PM with some documentation about a process you'd like to use? If you can frame it as something that will benefit EVERYONE, not just you, you may get a lot farther in your argument.
Feel free to memail me if you want. You do not have anger problems, per se, but for your own sanity you need to reframe this. Best of luck!
posted by wwartorff at 1:33 PM on November 23, 2011 [2 favorites]
- these types of frustrations are pretty much par for the course. I've worked in 3 different companies in the BA capacity, and all were very different in their processes, but the similarities are: Users don't understand the SD process (even the simplistic waterfall method) and it results in scope creep to the nth degree. Is your company using a requirements document? Where are the ideas, expectations, etc., being documented? It can be helpful to have two main "buckets" for all the features and/or bug fixes needed.... 1 is a master list of everything that occurs to anyone with an idea; 2 is copying items from the master list to an actual requirements document when a project scope is defined.
- your inner rage is not COMPLETELY unjustified, but you have to learn to let this shit go or you will drive yourself crazy, and won't be happy in any job since it happens everywhere. Your ambition will also be stifled because your higher ups will see the bad attitude and be more reluctant to promote you.
- seriously consider getting an SSRI anti depressant. I have found that my brain chemistry doesn't ALLOW me to let things go without the meds I'm on. Whatever you do, you have to learn to LET THIS SHIT GO. I'm repeating myself on purpose here!
There are a lot of strategies for trying to cope with this. One is the meds, obviously. You can try re-framing how you look at things... in academia we are all taught the SD process and how things "should" work. Instead of putting that frame on things, why not think of every change they want to make as job security for you? Software is NEVER really done, especially when it's an internal application that users can tweak practically on demand. So basically, strategy #2 is doing what you can to adjust your attitude, and do it for YOURSELF. A third strategy would be to try to formalize the SD process a little more at your company. Sounds like your PM is not trained in software dev practices. Coming from marketing, brainstorming and coming up with cool ideas is a really good thing. They don't see it as annoying scope creep. Can you approach your PM with some documentation about a process you'd like to use? If you can frame it as something that will benefit EVERYONE, not just you, you may get a lot farther in your argument.
Feel free to memail me if you want. You do not have anger problems, per se, but for your own sanity you need to reframe this. Best of luck!
posted by wwartorff at 1:33 PM on November 23, 2011 [2 favorites]
Best answer: You might want to pick up a reference on software engineering management -- how things are "supposed to" work -- and use it as a reference for "how it's working today" in your workplace. Your PM sounds a little (ok, maybe a lot) clueless to me.
The reframing ideas and all that are great, but you probably also want to have a productive workplace and what you guys are doing doesn't sound all that productive.
A short, but good reference, is The Software Project Survival Guide which is a "what to do" book. If you want more depth than that, I suggest Rapid Development by the same author which goes into all the different options for getting software done and the rationale behind each approach.
Inefficient, time wasting processes drive me nuts which is why I became a software project manager early in my career. The trick is to channel that frustration into figuring out how to effectively change the system from within -- which isn't easy. But, it can be quite rewarding.
One last book you may want to check out is Influence without Authority -- until you become the PM, you'll need to convince the PM to adopt the ideas you get from learning how software engineering management is supposed to be done, and this book might help with that. Learning these skills when you don't have the authority is useful because if/when you become a manager yourself, you will know how to influence people without resorting to ordering them around :).
posted by elmay at 2:23 PM on November 23, 2011 [3 favorites]
The reframing ideas and all that are great, but you probably also want to have a productive workplace and what you guys are doing doesn't sound all that productive.
A short, but good reference, is The Software Project Survival Guide which is a "what to do" book. If you want more depth than that, I suggest Rapid Development by the same author which goes into all the different options for getting software done and the rationale behind each approach.
Inefficient, time wasting processes drive me nuts which is why I became a software project manager early in my career. The trick is to channel that frustration into figuring out how to effectively change the system from within -- which isn't easy. But, it can be quite rewarding.
One last book you may want to check out is Influence without Authority -- until you become the PM, you'll need to convince the PM to adopt the ideas you get from learning how software engineering management is supposed to be done, and this book might help with that. Learning these skills when you don't have the authority is useful because if/when you become a manager yourself, you will know how to influence people without resorting to ordering them around :).
posted by elmay at 2:23 PM on November 23, 2011 [3 favorites]
Best answer: Watch this little presentation by Seth Godin and see if it helps you any: http://vimeo.com/5895898
Seth does mention a software development book by Steve McConnell and method which goes along with his view. Here is a book list by Steve McConnell: http://www.amazon.com/Steve-McConnell/e/B000APETRK/ref=sr_ntt_srch_lnk_1?qid=1322088033&sr=8-1-spell
posted by gearspring at 2:44 PM on November 23, 2011 [1 favorite]
Seth does mention a software development book by Steve McConnell and method which goes along with his view. Here is a book list by Steve McConnell: http://www.amazon.com/Steve-McConnell/e/B000APETRK/ref=sr_ntt_srch_lnk_1?qid=1322088033&sr=8-1-spell
posted by gearspring at 2:44 PM on November 23, 2011 [1 favorite]
I see @elmay has the same books in mind. Cool.
posted by gearspring at 2:46 PM on November 23, 2011
posted by gearspring at 2:46 PM on November 23, 2011
Best answer: Hi,
I've been a software developer for about 15 years now in four very different industries so I have some experience.
Are these normal processes for software development? Are these meeting situations par for the course, or is it just my particular workplace? Do I just not understand something here?
The thing you have to remember about software development is that no one knows how to do it properly. It's been 35 years since Fred Brooks wrote The Mythical Man Month and we're still making the same mistakes (or sometimes new and innovative mistakes). So no, your development processes aren't normal but only because every programming group in every industry seems to have its own view on how to do things.
Your meetings seem to be on the bad side of usual. There are too many of them and, worse still, they are too unfocused.
chickenmagazine gives some good advice about meetings and wwartorff makes some excellent points about software development processes.
One other technique you could use is to take your to-do list of features and put them in order of priority (decided by you or your users). Then take this list into every meeting and if a new feature is requested (or an old one modified) ask where on the priority list it should go. I've found this an excellent technique for getting the users (and some less than able managers) to focus on what they really want. Even if they don't understand the software development process everyone can grasp the fact that things at the top of the list get done first.
How can I get rid of my meeting frustration and just be a normal worker who works? If I can't get rid of it, how can I better hide it?
Every software developer I know despises useless meetings because it gets in the way of real work. For some people though meeting are how they do work, so if you can reconcile yourself to the fact that other people need meetings it might make them less frustrating.
Does this mean I will be frustrated as a software developer anywhere?
No, as I wrote above everywhere is different. The main problem with your situation is that you don't have anyone senior enough on the software development side to say no to things. That won't always be the case.
posted by antiwiggle at 3:27 PM on November 23, 2011 [1 favorite]
I've been a software developer for about 15 years now in four very different industries so I have some experience.
Are these normal processes for software development? Are these meeting situations par for the course, or is it just my particular workplace? Do I just not understand something here?
The thing you have to remember about software development is that no one knows how to do it properly. It's been 35 years since Fred Brooks wrote The Mythical Man Month and we're still making the same mistakes (or sometimes new and innovative mistakes). So no, your development processes aren't normal but only because every programming group in every industry seems to have its own view on how to do things.
Your meetings seem to be on the bad side of usual. There are too many of them and, worse still, they are too unfocused.
chickenmagazine gives some good advice about meetings and wwartorff makes some excellent points about software development processes.
One other technique you could use is to take your to-do list of features and put them in order of priority (decided by you or your users). Then take this list into every meeting and if a new feature is requested (or an old one modified) ask where on the priority list it should go. I've found this an excellent technique for getting the users (and some less than able managers) to focus on what they really want. Even if they don't understand the software development process everyone can grasp the fact that things at the top of the list get done first.
How can I get rid of my meeting frustration and just be a normal worker who works? If I can't get rid of it, how can I better hide it?
Every software developer I know despises useless meetings because it gets in the way of real work. For some people though meeting are how they do work, so if you can reconcile yourself to the fact that other people need meetings it might make them less frustrating.
Does this mean I will be frustrated as a software developer anywhere?
No, as I wrote above everywhere is different. The main problem with your situation is that you don't have anyone senior enough on the software development side to say no to things. That won't always be the case.
posted by antiwiggle at 3:27 PM on November 23, 2011 [1 favorite]
I think your frustrations are coming because what you describe sounds to me like a terrible environment, one that is unlikely to produce a good product. Some elements of basic project management sound like they're missing here, such as identifying stakeholders (who has a stake in the outcome of the project, and are they accountable for providing input and living with their decisions), getting those stakeholders to agree on the desired project outcomes (what will success for the project look like, including time spent on it, budget, etc.), and defining clear requirements (functional--what does the software need to do; technical--specifically how it should do it).
It sounds like you're constantly trying to hit a moving target (changing requirements), with different people being able to suggest "it would be nice to have" (but are these folks real stakeholders, who are accountable for the outcome?), etc. That's enough to drive anyone crazy.
That said, it isn't great to be a walking ball of frustration around the office, because people will put that on you, and not the sucky environment you're in.
So, what can you do about it? Well, the resources elmay and gearspring suggest are good ones, to give you an idea of what a better environment would look like. I'd think the biggest thing you want to do is try to get your PM to understand the value of identifying the real stakeholders, and getting those stakeholders to agree on a current set of requirements (what the software needs to do) for the initial release. Then stick to those requirements, get a finished product out, and contemplate upgrades/a second release later.
I completely get how this is making you nuts--you want to do a good job, and no matter what you do (select what you think is the right language, call in a UI expert, etc.) nothing helps. While I think it will help to learn about good software devel practices (as above), I think it will also help if you try to care less, in a way. Yes, the environment stinks, and there are things you can try, but in the end there's only so much you can do. Don't make yourself insane over this, and if it doesn't get any better/ you don't think the PM will ever change, consider looking for something else down the line...
posted by msbubbaclees at 3:35 PM on November 23, 2011 [1 favorite]
It sounds like you're constantly trying to hit a moving target (changing requirements), with different people being able to suggest "it would be nice to have" (but are these folks real stakeholders, who are accountable for the outcome?), etc. That's enough to drive anyone crazy.
That said, it isn't great to be a walking ball of frustration around the office, because people will put that on you, and not the sucky environment you're in.
So, what can you do about it? Well, the resources elmay and gearspring suggest are good ones, to give you an idea of what a better environment would look like. I'd think the biggest thing you want to do is try to get your PM to understand the value of identifying the real stakeholders, and getting those stakeholders to agree on a current set of requirements (what the software needs to do) for the initial release. Then stick to those requirements, get a finished product out, and contemplate upgrades/a second release later.
I completely get how this is making you nuts--you want to do a good job, and no matter what you do (select what you think is the right language, call in a UI expert, etc.) nothing helps. While I think it will help to learn about good software devel practices (as above), I think it will also help if you try to care less, in a way. Yes, the environment stinks, and there are things you can try, but in the end there's only so much you can do. Don't make yourself insane over this, and if it doesn't get any better/ you don't think the PM will ever change, consider looking for something else down the line...
posted by msbubbaclees at 3:35 PM on November 23, 2011 [1 favorite]
You have a worse than average project manager who, rather than protecting his/her project team from scope creep imposed by the client/business, is creating it himself. You can't turn a mediocre project manager into a good one. You can only treat this as a learning experience (use the great book and resource suggestions above to bone up on software development and project management in general) and chalk this up to the culture at your particular workplace.
It's not like this everywhere. Some project team cultures are much better. Unfortunately some are much worse. It's something to keep in mind when you interview for future jobs: probe about expectations of the project team, how to deal with change requests and scope creep, etc.
posted by ImproviseOrDie at 3:36 PM on November 23, 2011 [1 favorite]
It's not like this everywhere. Some project team cultures are much better. Unfortunately some are much worse. It's something to keep in mind when you interview for future jobs: probe about expectations of the project team, how to deal with change requests and scope creep, etc.
posted by ImproviseOrDie at 3:36 PM on November 23, 2011 [1 favorite]
You work at a "larger business". You hate meetings. You think your PM is a dolt.
You have a problem.
You might want to look elsewhere. Boring, mind-numbing meetings with clueless PM's kind of come with the territory you're currently occupying. This is more the norm than the exception within large organizations.
As for the "rage" you feel about it, that's not normal. Normal is you bitch about the meetings and the PM to your trusted co-workers for a little bit, and then go about your day.
posted by Ike_Arumba at 4:02 PM on November 23, 2011 [1 favorite]
You have a problem.
You might want to look elsewhere. Boring, mind-numbing meetings with clueless PM's kind of come with the territory you're currently occupying. This is more the norm than the exception within large organizations.
As for the "rage" you feel about it, that's not normal. Normal is you bitch about the meetings and the PM to your trusted co-workers for a little bit, and then go about your day.
posted by Ike_Arumba at 4:02 PM on November 23, 2011 [1 favorite]
Frequent change is normal in software, and yes, if you're going to work as a developer, you need to learn to roll with it. A basic strategy for dealing with change is the "dev estimates, PM prioritizes" cycle. PM comes to you with new request. You say, "That'll take two weeks, what's the priority? I can cut feature A, or we can push the release out two weeks." The PM can either take responsibility for the delay or remove some other work from your plate.
If you believe a request is unreasonable, emphasize how long it'll take and/or how risky a change it is (and all change gets riskier as a release progresses). Suggest putting it in the next version, or get someone with more authority to smack it down. This doesn't need to be personal.
A note on estimates: It takes time to learn to do dev estimates accurately, especially when you're new to the language. It's perfectly reasonable to make the PM wait a day for you to do some research and make an estimate. When in doubt, make your best guess and double it.
posted by orangejenny at 4:08 PM on November 23, 2011
If you believe a request is unreasonable, emphasize how long it'll take and/or how risky a change it is (and all change gets riskier as a release progresses). Suggest putting it in the next version, or get someone with more authority to smack it down. This doesn't need to be personal.
A note on estimates: It takes time to learn to do dev estimates accurately, especially when you're new to the language. It's perfectly reasonable to make the PM wait a day for you to do some research and make an estimate. When in doubt, make your best guess and double it.
posted by orangejenny at 4:08 PM on November 23, 2011
Two things:
1- Lighten up. Best advice my boss ever gave me when I was having a "why does everyone besides me suck" moment. You can't run at 100% all the time. Dealing constructively with annoyance is a job skill like any other.
2- Try to manage the manager a little bit. During a moment of calm, mention that you find the frequency of meetings distracting to getting the work done, and could we come up with a better solution? Maybe a beginning of the day and a midday update meeting? Ask the PM to try to note the "what if" moments he has and bring them up at the meeting.
Finally, are you sure it is the meeting that you don't like, or what happens at a meeting?
posted by gjc at 5:10 PM on November 23, 2011
1- Lighten up. Best advice my boss ever gave me when I was having a "why does everyone besides me suck" moment. You can't run at 100% all the time. Dealing constructively with annoyance is a job skill like any other.
2- Try to manage the manager a little bit. During a moment of calm, mention that you find the frequency of meetings distracting to getting the work done, and could we come up with a better solution? Maybe a beginning of the day and a midday update meeting? Ask the PM to try to note the "what if" moments he has and bring them up at the meeting.
Finally, are you sure it is the meeting that you don't like, or what happens at a meeting?
posted by gjc at 5:10 PM on November 23, 2011
I worked in the construction trades for years, trashed my back, became a computer programmer, then into some lead and then mgt positions. Each step up from programmer involved less and less actual work, more and more bullshit, to the point where everybody just talked to everyone about everything and nothing got done.
To this day I'm amazed that anything ever gets done in large organizations.
Dave Barry wrote that organizations have meetings because they cannot physically masturbate.
The further I got from the actual work being done, the more childish the people acted. It came to where it was helpful to me to look around those tables and see those people as first-graders, solemn little boys wearing plaid ties, their hair neatly combed but sticking up some here and there, wearing little brown shoes, the little girls in pigtails or hair braided maybe, bright flushed cheeks, little white socks turned down, flowered blouses that buttoned up the back. Seeing those people in that way—which really is how it was—reduced the stress; they were acting exactly as they were supposed to.
That PM of yours is an incompetent, of course. I worked with a guy once who called ALL THE DAMN TIME about the least significant things, he was the absolute embodiment of that Dave Barry quote, jerking off all the day long, he couldn't quit fantasizing about his project. I wish him ill.
Good luck.
posted by dancestoblue at 5:27 PM on November 23, 2011 [4 favorites]
To this day I'm amazed that anything ever gets done in large organizations.
Dave Barry wrote that organizations have meetings because they cannot physically masturbate.
The further I got from the actual work being done, the more childish the people acted. It came to where it was helpful to me to look around those tables and see those people as first-graders, solemn little boys wearing plaid ties, their hair neatly combed but sticking up some here and there, wearing little brown shoes, the little girls in pigtails or hair braided maybe, bright flushed cheeks, little white socks turned down, flowered blouses that buttoned up the back. Seeing those people in that way—which really is how it was—reduced the stress; they were acting exactly as they were supposed to.
That PM of yours is an incompetent, of course. I worked with a guy once who called ALL THE DAMN TIME about the least significant things, he was the absolute embodiment of that Dave Barry quote, jerking off all the day long, he couldn't quit fantasizing about his project. I wish him ill.
Good luck.
posted by dancestoblue at 5:27 PM on November 23, 2011 [4 favorites]
These sorts of requests are not at all unusual. The requirements list for software projects is often in flux and you will have to get used to this. However, a thing that you can do is train your PM that every request to you of this nature entails a cost:
PM: "Can you come into my office and look at something? Look at [X feature on some commercial program]. Can we do something like that for [Y feature on our program]? Is it hard to do?"
You: I'm not sure. I can take Z hours to look at the feature and make an estimate.
PM: "Let's go through this list of comments from users. User A thinks the label on this button should be different, let's change that. User B thinks [Z feature on our application] should be more like [Q feature on commercial application]. [Head researcher] would like that. How long would it take to do that?"
You: Ok, it will take ten minutes to change the button, I can do that right away. For the other thing, I would need to think about what needs to change in our code to make Z more like Q. I can take a few hours to look hard at the feature and make an estimate.
PM: "Let's look at your mockups for the next to-do feature. Can we make it look more like [existing application] I showed you? What if a user wants to [do more complex thing we didn't discuss before]?"
You: Well, that wasn't part of the previous requirements, so I'm not sure how easy that will be. Let me take an hour to investigate, and I can get back to you.
The issue is that your PM thinks that the cost in terms of your time for a requirements change starts after the decision has been made to implement the change. They are wrong-there is a cost in your time involved in considering the decision.
If you start making it clear that this is the case, your PM will think, sitting in their office, "Man I just had another great idea but if I bounce it off of sarahj, it's going to take a couple of hours AND keep her from getting the other feature done today. And then the great feature I thought of yesterday won't get going until next week! I'd better check in with the head researcher again and make sure that we really need this"
And this will eliminate many of the unnecessary requests without you having to lift a finger.
posted by Kwine at 6:20 PM on November 23, 2011 [2 favorites]
PM: "Can you come into my office and look at something? Look at [X feature on some commercial program]. Can we do something like that for [Y feature on our program]? Is it hard to do?"
You: I'm not sure. I can take Z hours to look at the feature and make an estimate.
PM: "Let's go through this list of comments from users. User A thinks the label on this button should be different, let's change that. User B thinks [Z feature on our application] should be more like [Q feature on commercial application]. [Head researcher] would like that. How long would it take to do that?"
You: Ok, it will take ten minutes to change the button, I can do that right away. For the other thing, I would need to think about what needs to change in our code to make Z more like Q. I can take a few hours to look hard at the feature and make an estimate.
PM: "Let's look at your mockups for the next to-do feature. Can we make it look more like [existing application] I showed you? What if a user wants to [do more complex thing we didn't discuss before]?"
You: Well, that wasn't part of the previous requirements, so I'm not sure how easy that will be. Let me take an hour to investigate, and I can get back to you.
The issue is that your PM thinks that the cost in terms of your time for a requirements change starts after the decision has been made to implement the change. They are wrong-there is a cost in your time involved in considering the decision.
If you start making it clear that this is the case, your PM will think, sitting in their office, "Man I just had another great idea but if I bounce it off of sarahj, it's going to take a couple of hours AND keep her from getting the other feature done today. And then the great feature I thought of yesterday won't get going until next week! I'd better check in with the head researcher again and make sure that we really need this"
And this will eliminate many of the unnecessary requests without you having to lift a finger.
posted by Kwine at 6:20 PM on November 23, 2011 [2 favorites]
Response by poster: Oh my goodness, I was not expecting such constructive comments from this. Thank you so much for the wonderful info and advice, everyone. I've definitely got some good reading ahead of me.
For the record, I really don't think my PM is as horrible as it came off in the question. I guess I thought I wouldn't be consulted every time there is an idea and that the requirements-deciding and the dev process would be more... concrete.
And I think 'rage' was the wrong word choice regarding my feelings towards these meetings. "annoyed" is probably more accurate. I've realized that I fully enjoy everything about my job except this Process and I was expecting that being a software developer would involve more Creating and Doing and less Process. It doesn't ruin my life, but The Process is what makes me groan about going to work because I know a significant fraction of my day will be Process. I'm glad to know now that this is pretty standard so I can get my butt on an alternative career path ASAP.
I probably won't be speaking up again or asking anything about changing the process any time soon. I just sound angry and annoyed when I do so, I guess. Last time I tried to do that I asked PM to send me requests in emails so i could prioritize things that way, and then just ONE time I forget to open my Outlook... sigh. So now, meetings.
and someone mentioned SSRI's which I find funny because I just went off them. they made me give too few fucks and I got nothing done. I will consider reconsidering.
Seriously, thanks a million, everyone. I'm off to get some of those books.
posted by sarahj at 7:44 PM on November 23, 2011
For the record, I really don't think my PM is as horrible as it came off in the question. I guess I thought I wouldn't be consulted every time there is an idea and that the requirements-deciding and the dev process would be more... concrete.
And I think 'rage' was the wrong word choice regarding my feelings towards these meetings. "annoyed" is probably more accurate. I've realized that I fully enjoy everything about my job except this Process and I was expecting that being a software developer would involve more Creating and Doing and less Process. It doesn't ruin my life, but The Process is what makes me groan about going to work because I know a significant fraction of my day will be Process. I'm glad to know now that this is pretty standard so I can get my butt on an alternative career path ASAP.
I probably won't be speaking up again or asking anything about changing the process any time soon. I just sound angry and annoyed when I do so, I guess. Last time I tried to do that I asked PM to send me requests in emails so i could prioritize things that way, and then just ONE time I forget to open my Outlook... sigh. So now, meetings.
and someone mentioned SSRI's which I find funny because I just went off them. they made me give too few fucks and I got nothing done. I will consider reconsidering.
Seriously, thanks a million, everyone. I'm off to get some of those books.
posted by sarahj at 7:44 PM on November 23, 2011
then just ONE time I forget to open my Outlook
Wait, what? Remember, you work at a "larger" organization. Outlook is open at ALL TIMES. Sorry, no exception here.
Glad to see your response. You will get through this.
posted by Ike_Arumba at 8:10 PM on November 23, 2011 [1 favorite]
Wait, what? Remember, you work at a "larger" organization. Outlook is open at ALL TIMES. Sorry, no exception here.
Glad to see your response. You will get through this.
posted by Ike_Arumba at 8:10 PM on November 23, 2011 [1 favorite]
I've worked in software for several years and I've honestly come to the conclusion that it is exactly as stupid to ask somebody how long it would take them to do a software anything, and then accept that estimate without argument, as it is to ask somebody how much they would like to be paid this month, and accept that without argument.
See if you can get them to hire a statistician to attempt the crystal ball aspects of the job. I've never heard of somebody actually hiring a statistician, but I think it would be a good idea. The hi-larious thing is that even people with software development backgrounds haven't ever been trained to predict the future. Every single person I work with approaches the problem with virtually no intellectual rigor at all. It is like a trivia night question:
"How long will that take?" "Uhhh, a month!"
And people are still somehow unhappy when these predictions are wrong!
So yeah, I don't know what to tell you. My plan is to go back to grad school and figure out some way to work for myself.
posted by SomeOneElse at 8:26 PM on November 23, 2011
See if you can get them to hire a statistician to attempt the crystal ball aspects of the job. I've never heard of somebody actually hiring a statistician, but I think it would be a good idea. The hi-larious thing is that even people with software development backgrounds haven't ever been trained to predict the future. Every single person I work with approaches the problem with virtually no intellectual rigor at all. It is like a trivia night question:
"How long will that take?" "Uhhh, a month!"
And people are still somehow unhappy when these predictions are wrong!
So yeah, I don't know what to tell you. My plan is to go back to grad school and figure out some way to work for myself.
posted by SomeOneElse at 8:26 PM on November 23, 2011
Response by poster: Also if anyone has any suggestions as to how to salvage my probably-i-fucked-it-up-beyond-repair-already relationship with my PM and coworkers and their opinion of me... yeah. much appreciated.
ugh
posted by sarahj at 10:06 PM on November 23, 2011
ugh
posted by sarahj at 10:06 PM on November 23, 2011
I am not sure why you are doing the mockups and the PM is not. The PM should be doing mock ups. Also I am not sure why the PM is not driving the schedule. The PM should not be wandering in and randomizing you at every single possible opportunity. I say this as a PM. You need to make the PM act like a PM, and stop acting like a child.
You can salvage this. The way to do it is to push back. Have a meta conversation in private about how you have conversations with your PM. Tell your PM that you just want to do your shit in a timely manner, and not be randomized with requests out of the blue all of the time. You understand that PM wants to make the product better, however this PM's requests are simply annoying you and distracting you from getting important work done. Ask for PM's input on how you can communicate better to solve this problem. Brainstorm for a while. Set some boundaries - perhaps sandbox the feature creep discussions to once a week, not once a day. Enforce the boundaries.
Good luck, it is hard to get dumb PM's to smarten up. I feel for you.
posted by crazycanuck at 10:38 PM on November 23, 2011 [1 favorite]
You can salvage this. The way to do it is to push back. Have a meta conversation in private about how you have conversations with your PM. Tell your PM that you just want to do your shit in a timely manner, and not be randomized with requests out of the blue all of the time. You understand that PM wants to make the product better, however this PM's requests are simply annoying you and distracting you from getting important work done. Ask for PM's input on how you can communicate better to solve this problem. Brainstorm for a while. Set some boundaries - perhaps sandbox the feature creep discussions to once a week, not once a day. Enforce the boundaries.
Good luck, it is hard to get dumb PM's to smarten up. I feel for you.
posted by crazycanuck at 10:38 PM on November 23, 2011 [1 favorite]
Remember, you work at a "larger" organization. Outlook is open at ALL TIMES. Sorry, no exception here.
Not sure I agree here. Outlook is remarkably resource intensive, and if you have, say, a laptop hobbled by middling RAM and disk encryption it's not unheard of to close it for a while. Particularly if you can also be reached, say, by IM, cell phone, office phone, and in person.
It really depends on the particular group, though. There are certainly people out there who can't fathom letting an email go unanswered for a while.
posted by RikiTikiTavi at 10:56 PM on November 23, 2011
Not sure I agree here. Outlook is remarkably resource intensive, and if you have, say, a laptop hobbled by middling RAM and disk encryption it's not unheard of to close it for a while. Particularly if you can also be reached, say, by IM, cell phone, office phone, and in person.
It really depends on the particular group, though. There are certainly people out there who can't fathom letting an email go unanswered for a while.
posted by RikiTikiTavi at 10:56 PM on November 23, 2011
"Are these normal processes for software development?"
Yes, fairly normal. Crazy, disfunctional, a primary reason software's is often late, over-budget, and buggy, but fairly normal.
crocomancer mentions "agile", use this to reign in your PM. "Scrum" is an agile framework, probably the most popular one currently. With Scrum, whenever the PM or anyone starts with the whipsawing and feature creeping, you can say "add that suggestion to the backlog, and we can prioritize it next month. With Scrum, you decide on a set of features and work on that for 4 weeks, then re-calibrate, pick the next set of features, and go for another 4 weeks. It's your only way out to stop the insanity.
You can still meet with the PM whenever he desires, but he must expect that you won't act on anything that comes out of these meetings 'til the next sprint. And the demos will happen and the end of each sprint, and, sure people can jump in and derail you, but you won't start new features until they let you get thru your demo and sign off on it.
If you need authority, hire an Agile consultant and point to their authority when the insanity starts again. That consultant should also be able to help you use the UI consultant to get some "user stories" that map to features.
There're a ton of intros to Agile and Scrum on youtube.
posted by at at 1:04 AM on November 24, 2011
Yes, fairly normal. Crazy, disfunctional, a primary reason software's is often late, over-budget, and buggy, but fairly normal.
crocomancer mentions "agile", use this to reign in your PM. "Scrum" is an agile framework, probably the most popular one currently. With Scrum, whenever the PM or anyone starts with the whipsawing and feature creeping, you can say "add that suggestion to the backlog, and we can prioritize it next month. With Scrum, you decide on a set of features and work on that for 4 weeks, then re-calibrate, pick the next set of features, and go for another 4 weeks. It's your only way out to stop the insanity.
You can still meet with the PM whenever he desires, but he must expect that you won't act on anything that comes out of these meetings 'til the next sprint. And the demos will happen and the end of each sprint, and, sure people can jump in and derail you, but you won't start new features until they let you get thru your demo and sign off on it.
If you need authority, hire an Agile consultant and point to their authority when the insanity starts again. That consultant should also be able to help you use the UI consultant to get some "user stories" that map to features.
There're a ton of intros to Agile and Scrum on youtube.
posted by at at 1:04 AM on November 24, 2011
I struggled with the same feelings in my first post-college job, and I also had a manager call me on it, even though I thought I was hiding it. It was super embarassing, but it actually forced me to deal with my feelings, which helped.
During meetings, I would focus on keeping my voice even and a little bit softer than normal. That gave me something besides my emotions to focus on and prevented me from talking through clenched teeth.
Also, if I was the one currently presenting, I made myself be assertive about controlling the discussion. The phrase "let's take this offline" is your friend (delivered with a polite smile, of course).
I left that job six months later for unrelated reasons, but in that time I didn't receive any more criticism for being angry. And somehow I found that at my second job, those feelings were just gone, even though the workplace was even more disorganized and frustrating. I think it can be a trial-by-fire thing for new grads.
posted by neushoorn at 1:26 AM on November 24, 2011
During meetings, I would focus on keeping my voice even and a little bit softer than normal. That gave me something besides my emotions to focus on and prevented me from talking through clenched teeth.
Also, if I was the one currently presenting, I made myself be assertive about controlling the discussion. The phrase "let's take this offline" is your friend (delivered with a polite smile, of course).
I left that job six months later for unrelated reasons, but in that time I didn't receive any more criticism for being angry. And somehow I found that at my second job, those feelings were just gone, even though the workplace was even more disorganized and frustrating. I think it can be a trial-by-fire thing for new grads.
posted by neushoorn at 1:26 AM on November 24, 2011
We are under the guidance of a Project Manager (PM) who has worked in marketing
I stopped there.
RUN AWAY
posted by flabdablet at 1:59 AM on November 24, 2011 [2 favorites]
I stopped there.
RUN AWAY
posted by flabdablet at 1:59 AM on November 24, 2011 [2 favorites]
I work in a very different sector and am relieved to see this isn't unique to us. I started out four years ago very angry and loathing meetings. In some ways I hate how I've become so resigned and passive in just letting it wash over me now. But in other ways I realise that being less angry is part of growing up and working in a team. It made me angry that I'm right and they can't see how wrong they are but then I realise
(1) I may not know everything (that came as a shock)
(2) maybe they know something or they're bringing something to the table that balances my outlook
(3) it's a human process and these are opportunities to study people. As far as I can see, being able to deal with people will do more for career prospects than technical knowledge. Can you treat this job as an opportunity to hone your people skills/study peopledynamics/acquire a toolkit for conflict disposal (frame it how you like)?
Sorry to ramble, but to offer inexpert advice (after Dale Carnegie) on you question of how to how to repair office relations, I think the first principle of peopledynamics is seeing the issue from the other's point of view reduces friction. If you can work out what kind of personality your PM has, what pressures he's under and what his brief is, you'll find it much easier to be nice to him, and you'll get along better.
posted by Gomoryhu at 7:08 AM on November 24, 2011
(1) I may not know everything (that came as a shock)
(2) maybe they know something or they're bringing something to the table that balances my outlook
(3) it's a human process and these are opportunities to study people. As far as I can see, being able to deal with people will do more for career prospects than technical knowledge. Can you treat this job as an opportunity to hone your people skills/study peopledynamics/acquire a toolkit for conflict disposal (frame it how you like)?
Sorry to ramble, but to offer inexpert advice (after Dale Carnegie) on you question of how to how to repair office relations, I think the first principle of peopledynamics is seeing the issue from the other's point of view reduces friction. If you can work out what kind of personality your PM has, what pressures he's under and what his brief is, you'll find it much easier to be nice to him, and you'll get along better.
posted by Gomoryhu at 7:08 AM on November 24, 2011
To directly address the issue of being interrupted multiple times per day - ask the PM to gather those items onto an "issue log" and have regularly scheduled meetings to go over the items and make decisions on them all at one time. Try to get them to be weekly meetings, but be prepared to meet somewhere in the middle between 3 times a day and weekly.
posted by CathyG at 1:04 PM on November 24, 2011
posted by CathyG at 1:04 PM on November 24, 2011
Response by poster: Sigh, a late follow up, for my own sanity...
I had another sort of falling out with my PM today, as in we were previously back on at least somewhat-good terms and now it has become very clear that I'm the child with the bad attitude who needs correction.
She emailed me to talk about something unrelated to my current project, I replied asking if we could discuss it tomorrow so I wouldn't get off track, she insisted, I went over and then she asked me to close her office door and gave me a talking-to. In the previous month I had started doing a lot of asking about "where will this fit into the schedule" and "is this priority?" whenever a new Random Thing 2.0 popped into conversation and she called me out on my "stress" about the schedule, mainly, although I can tell it was also against my (poorly hidden) resentment/bad attitude towards her constant distractions. (I know. I suck at this sort of social graces thing, I guess.)
The funny thing is, rereading this response from crazycanuck:
After today I think I've pretty much sufficiently trashed whatever positive reference I thought I might get out of this job so I'm looking for other positions, although I'm pretty disenchanted with software/web development if this is what it's going to be like generally. So it goes.
posted by sarahj at 10:11 PM on January 3, 2012
I had another sort of falling out with my PM today, as in we were previously back on at least somewhat-good terms and now it has become very clear that I'm the child with the bad attitude who needs correction.
She emailed me to talk about something unrelated to my current project, I replied asking if we could discuss it tomorrow so I wouldn't get off track, she insisted, I went over and then she asked me to close her office door and gave me a talking-to. In the previous month I had started doing a lot of asking about "where will this fit into the schedule" and "is this priority?" whenever a new Random Thing 2.0 popped into conversation and she called me out on my "stress" about the schedule, mainly, although I can tell it was also against my (poorly hidden) resentment/bad attitude towards her constant distractions. (I know. I suck at this sort of social graces thing, I guess.)
The funny thing is, rereading this response from crazycanuck:
Have a meta conversation in private about how you have conversations with your PM. Tell your PM that you just want to do your shit in a timely manner, and not be randomized with requests out of the blue all of the time. You understand that PM wants to make the product better, however this PM's requests are simply annoying you and distracting you from getting important work done. Ask for PM's input on how you can communicate better to solve this problem. Brainstorm for a while. Set some boundaries - perhaps sandbox the feature creep discussions to once a week, not once a day. Enforce the boundaries.I said all of these things and was overruled because I'm not PM. I tried to describe that my work style is to take things one step at a time and asked if we could implement scrum-style daily morning meetings and have those be the ONLY daily pm-programmer meetings, and she said "that's not going to happen." She also brought up the fact that I come in at 9:30 instead of 9 and work through lunch to make up for it and have weekly doctor's appointments, so shouldn't you stay late today to make up for it? so it also turned out to be mostly that I'm not following office protocol (and not being there when she needs me for whatever) although I'm still getting the important things done when they need to be done. I'm a pretty terrible employee to begin with I guess, so I really have no business pushing my own desires in this place.
After today I think I've pretty much sufficiently trashed whatever positive reference I thought I might get out of this job so I'm looking for other positions, although I'm pretty disenchanted with software/web development if this is what it's going to be like generally. So it goes.
posted by sarahj at 10:11 PM on January 3, 2012
I'm a pretty terrible employee to begin with I guess, so I really have no business pushing my own desires in this place.
That doesn't follow. If you're incompetent, you won't keep a job whether or not you push your own desires (unless, obviously, you're at least in middle management; incompetence is apparently no barrier to career advancement in a management role). If you're competent and you know it, negotiating whatever working arrangement suit you best is perfectly appropriate.
Software project managers without software development experience are usually not the least bit good at managing software development teams. They tend to prefer managing the kind of useless drone who just puts their head down and shuts up and pretends to do what they're told, and they're almost always totally insensitive to whether or not the people they're managing can actually write code. This makes them insanely frustrating for any competent developer to work with; hence my original advice.
posted by flabdablet at 1:50 AM on January 4, 2012 [1 favorite]
That doesn't follow. If you're incompetent, you won't keep a job whether or not you push your own desires (unless, obviously, you're at least in middle management; incompetence is apparently no barrier to career advancement in a management role). If you're competent and you know it, negotiating whatever working arrangement suit you best is perfectly appropriate.
Software project managers without software development experience are usually not the least bit good at managing software development teams. They tend to prefer managing the kind of useless drone who just puts their head down and shuts up and pretends to do what they're told, and they're almost always totally insensitive to whether or not the people they're managing can actually write code. This makes them insanely frustrating for any competent developer to work with; hence my original advice.
posted by flabdablet at 1:50 AM on January 4, 2012 [1 favorite]
On the flip side, working alongside competent colleagues on a project with a competent PM can be extremely enjoyable. Don't write off professional software development just because your present boss is pointy-haired.
In general, you're more likely to find competent teams working for smaller businesses. Or perhaps you could try to land a job as the sole developer in a really small business whose proprietor you have reason to respect - there's a lot of fun and freedom there as well.
posted by flabdablet at 1:54 AM on January 4, 2012
In general, you're more likely to find competent teams working for smaller businesses. Or perhaps you could try to land a job as the sole developer in a really small business whose proprietor you have reason to respect - there's a lot of fun and freedom there as well.
posted by flabdablet at 1:54 AM on January 4, 2012
If you have a sympathetic manager (that is not the PM), I would talk to him/her about it. You tried to work it out with the PM, the PM is not working with you, and now you need to do something else about the obstructive PM. Time to get somebody else to have a talk with her.
posted by crazycanuck at 8:29 AM on January 4, 2012
posted by crazycanuck at 8:29 AM on January 4, 2012
This thread is closed to new comments.
Workplace culture can be hard to change, and it sounds like you have one where there are lots of meetings that don't accomplish much. As a result, it sounds like you feel you're banging your head against a wall. A few things here: First, others probably feel this way too. Maybe you can informally talk to others and enlist them in making meetings more productive. Second, read up on ways to make meetings more productive (entire books have been written on this subject -- here's one of many articles, you will find more with some quick Googling) and think about what you can implement in your workplace. Third, talk to the PM and try to explain that you're not concerned about things not going your way, it's that [you would like more input] [you would like to spend less time in meetings] [you would like meetings to be more focused] [or whatever -- it's not clear from your post].
One easy tip about meetings -- start with an agenda and end with a list of action items. You don't need to be in charge of the meeting for this. At the beginning, you can speak up and say, "I think we're here to accomplish X and Y, is that right?" and at the end you can say, "Okay, so I will do ___, Second Programmer will do ___, and PM will look into issue ___ and we'll meet about this again next week to discuss that issue." This prevents meeting sprawl and makes sure you're focused on actually getting something done.
You may want to check about a book about negotiation -- Getting to Yes and Crucial Conversations are good ones. They will help you communicate clearly and effectively about what you want. These books, or generally learning about negotiation and workplace communication, will also help you talk to PM about some of your frustrations without sounding angry or defensive.
posted by chickenmagazine at 1:24 PM on November 23, 2011 [2 favorites]