Should I stay or should I segfault?
January 18, 2011 7:39 AM Subscribe
Seeking advice on troubles with a project at work. What started out as a great project hasn't gone well of late, and I'm considering leaving. (I think this sounds oddly like a relationship question, and in a way it is. 16-bit snowflake details inside).
I work as a programmer at a large company. About 18 months ago, I started a project with another guy to upgrade a piece of sub-par technology that we have (that is very central to our business). This project was quite ambitious, and something that I'm quite passionate about. The project has gone fairly well technically, in that we produced something that works fairly well, with some rough areas, and shows lots of promise to my mind (I'm obviously biased, but we have some supporters who confirm this point of view). We did this in a reasonable period of time for the project involved.
In terms of adoption however, things haven't gone well. The most obvious customers for our project are not really long-term thinkers (in my opinion, but members will admit this privately). They are a large group, and have reacted in a variety of ways (with some supporters), but the main decision-makers have subtly discouraged adoption within their group. There doesn't seem to be too much debate about whether our project is superior, it's basically coming down to a question of priorities (and by this, I mean that their main motivation seems to be to avoid committing to any extra work, no matter what the future consequences). Naturally enough, we did seek their approval before starting this project, which we got. What we didn't get was actual commitment, which I recognise as a mistake in hindsight. A change in management hasn't helped us here either.
My management is quite supportive of this (the project would be gone now, otherwise), and it would probably be beneficial career-wise for me to continue, regardless of how things turn out. I should add that we now have more people resources than we started with, though the project almost certainly wouldn't survive my leaving it. We've done some soul-searching of late, and some compromises have been made on both sides. However, this essentially means some changes in direction, and longer timelines to deliver (which i would estimate as being over 6 months away). Our customers still haven't fully committed to the project, but have agreed to some measures to make our lives less difficult.
This situation periodically upsets me, and I'm starting to feel somewhat depressed. I have trouble making progress at work when I'm not focussed. I feel like I've done an enormous amount of work, just to have the opportunity to do more work. I'm becoming very uneasy at the idea of another 6 months in project limbo. Though I'm not sure what I would do otherwise, I'm not worried about finding other opportunities. What does the hivemind recommend I do about this?
I work as a programmer at a large company. About 18 months ago, I started a project with another guy to upgrade a piece of sub-par technology that we have (that is very central to our business). This project was quite ambitious, and something that I'm quite passionate about. The project has gone fairly well technically, in that we produced something that works fairly well, with some rough areas, and shows lots of promise to my mind (I'm obviously biased, but we have some supporters who confirm this point of view). We did this in a reasonable period of time for the project involved.
In terms of adoption however, things haven't gone well. The most obvious customers for our project are not really long-term thinkers (in my opinion, but members will admit this privately). They are a large group, and have reacted in a variety of ways (with some supporters), but the main decision-makers have subtly discouraged adoption within their group. There doesn't seem to be too much debate about whether our project is superior, it's basically coming down to a question of priorities (and by this, I mean that their main motivation seems to be to avoid committing to any extra work, no matter what the future consequences). Naturally enough, we did seek their approval before starting this project, which we got. What we didn't get was actual commitment, which I recognise as a mistake in hindsight. A change in management hasn't helped us here either.
My management is quite supportive of this (the project would be gone now, otherwise), and it would probably be beneficial career-wise for me to continue, regardless of how things turn out. I should add that we now have more people resources than we started with, though the project almost certainly wouldn't survive my leaving it. We've done some soul-searching of late, and some compromises have been made on both sides. However, this essentially means some changes in direction, and longer timelines to deliver (which i would estimate as being over 6 months away). Our customers still haven't fully committed to the project, but have agreed to some measures to make our lives less difficult.
This situation periodically upsets me, and I'm starting to feel somewhat depressed. I have trouble making progress at work when I'm not focussed. I feel like I've done an enormous amount of work, just to have the opportunity to do more work. I'm becoming very uneasy at the idea of another 6 months in project limbo. Though I'm not sure what I would do otherwise, I'm not worried about finding other opportunities. What does the hivemind recommend I do about this?
Seconding Doohickie. I've been through this at least four times in the past eight years and I'm glad I kept at it - even though my projects failed a couple of times. If you really care about this project as much as you say you do (a fact of which I have no doubt), then you'll gain valuable insight either way.
As H. Roark said, it is helpful to consider the perspective of the late adopters to understand how you might meet their needs, even if it means taking the project in a slightly different direction.
posted by xax at 8:20 AM on January 18, 2011
As H. Roark said, it is helpful to consider the perspective of the late adopters to understand how you might meet their needs, even if it means taking the project in a slightly different direction.
posted by xax at 8:20 AM on January 18, 2011
As someone who works in a field where my best work often never sees the light of day, I would think about it like this:
Your job is to make the thing. Not to make sure people use it.
Of course, it would be great if people actually did, but that's not in your control. So focus on what is:
If it's something you enjoy doing, then do it because you enjoy doing it. If it's something that shows off your talent at programming, even more reason to see it through.
On your resume, nobody's going to say, "Did anyone at your company actually use this gorgeous system you designed?" Nope. Their evaluation will be based solely on what you did, not what someone else did with it.
So see it through, make it as amazing as you can and when it's done, use your experience and abilities to get an awesome position somewhere else.
posted by missjenny at 8:33 AM on January 18, 2011
Your job is to make the thing. Not to make sure people use it.
Of course, it would be great if people actually did, but that's not in your control. So focus on what is:
If it's something you enjoy doing, then do it because you enjoy doing it. If it's something that shows off your talent at programming, even more reason to see it through.
On your resume, nobody's going to say, "Did anyone at your company actually use this gorgeous system you designed?" Nope. Their evaluation will be based solely on what you did, not what someone else did with it.
So see it through, make it as amazing as you can and when it's done, use your experience and abilities to get an awesome position somewhere else.
posted by missjenny at 8:33 AM on January 18, 2011
These situations are so common that jumping ship doesn't mean you won't run in to the same thing in your next job.
Tech people need to understand that for business people / ordinary users, "upgrading subpar technology" as you put it is not a high priority in itself. What someone needs to do is discover what people's concerns are about adopting this tech, and work out how to make the transition easier, safer, less disruptive, more painless or whatever it is that they need it to be.
Among other things the users could be totally stretched even coping with business-as-usual, never mind having to learn new things, and having to deal with the "rough areas" in your new system.
posted by philipy at 8:55 AM on January 18, 2011 [4 favorites]
Tech people need to understand that for business people / ordinary users, "upgrading subpar technology" as you put it is not a high priority in itself. What someone needs to do is discover what people's concerns are about adopting this tech, and work out how to make the transition easier, safer, less disruptive, more painless or whatever it is that they need it to be.
Among other things the users could be totally stretched even coping with business-as-usual, never mind having to learn new things, and having to deal with the "rough areas" in your new system.
posted by philipy at 8:55 AM on January 18, 2011 [4 favorites]
This isn't your fault, but view from the other side of the dev/business divide: you're passionate and you care about this. If you want to do something positive, consider volunteering to do a couple of sessions with whoever is having to provide rollout/training/support for the product (if that's no-one, then with whomever is the bus sponsor/backer).
posted by unless I'm very much mistaken at 9:36 AM on January 18, 2011
posted by unless I'm very much mistaken at 9:36 AM on January 18, 2011
Next time get more customer buy in before building the system. You know this now, it's a lesson you needed to learn and one of the business lessons you got from the project. Even with buy in system adoption takes longer than you may like (and this is by no means limited to non-technical users, my users are other devs), in the same way that the last bits of any project always feel like they take too long. But seriously, most programing jobs have some element of this, learning how to plan for and manage this situation will make you a more effective engineer because you're right about one thing: building something no one uses is a waste of time.
posted by ch1x0r at 10:01 AM on January 18, 2011
posted by ch1x0r at 10:01 AM on January 18, 2011
There doesn't seem to be too much debate about whether our project is superior, it's basically coming down to a question of priorities (and by this, I mean that their main motivation seems to be to avoid committing to any extra work, no matter what the future consequences).
All good advice above about working on subpar projects, but this passage stuck out at me. Are you saying that your project/replacement requires extra work to use, or that anybody moving from old-and-busted to new-hotness has to be trained? On the face of it I'd recommend reading some Fred Brooks, particularly about the Second System Effect, and see if that might help in the future.
posted by rhizome at 10:09 AM on January 18, 2011
All good advice above about working on subpar projects, but this passage stuck out at me. Are you saying that your project/replacement requires extra work to use, or that anybody moving from old-and-busted to new-hotness has to be trained? On the face of it I'd recommend reading some Fred Brooks, particularly about the Second System Effect, and see if that might help in the future.
posted by rhizome at 10:09 AM on January 18, 2011
I was going to recommend The Politics of Projects by Robert Block, but it is long out of print. While doing a web search for that, I ran across The New Project Management which is on Google Books. I suggest looking at chapter 7, "Acquiring Political Skills and Building Influence" for some ideas why you are having this experience with your users and what you might be able to do about it.
posted by elmay at 10:31 AM on January 18, 2011
posted by elmay at 10:31 AM on January 18, 2011
This thread is closed to new comments.
The bigger picture though, as I see it, is this is a failure of your technology management team. If you are a programmer, even a lead programmer, its not your job to be selling the product. Why is your IT mgmt not pushing this harder? Does he/she want to see your time wasted?
If you agree that the problem here is your IT mgmt, then its time to DTMFA.
As an aside, the last time I was in this situation a couple years back the real motive going on was mgmt was in the process of replacing all software development to a 3rd party consulting firm which happened to be headed by the CEO's brother. It was very frustrating to watch that all unfold, after developing a great product that just had too many managerial headwinds to get become used. never looked back. well actually i did, to gloat about the worthless stock. until they got bought for like 3bajillion dollars. yeah that sucked.
posted by H. Roark at 7:53 AM on January 18, 2011