views:

117

answers:

5

My day-to-day job consists of maintaining large volume websites and this has given me exposure to developing better methods to develop and maintain the code. This has also given me a large body of knowledge in the code base in terms of troubleshooting that is beneficial to the company. I'm also the maintainer of an IDE plug in I created to help navigate and generate code that is used.

Operationally though, my job is to handle any client requests that come in of that are emergencies and make any enhancements and additions to the code base required. This work, along with the daily managing and feeding of the the project managers will take up my entire day.

How does one manage the time between the tactical day job and the strategic initiatives? How does one get and ask for recognition for taking strategic initiatives? Is the 8-9 hour day just not going to cut it? Is there even a job out there for programmers to develop strategic initiatives and solutions for a company?

I want to also point out that this isn't a problem with the company at all. I think this is more of a personal-improvement decision. Nobody will say no to the improvements at all. I believe in making the things happen but I don't think I'm going to get time from the company to do it...

+3  A: 

Present to your management the long term financial benefits of writing better (strategic) code. It's going to be hard to quantify, but being able to say "there's ten weeks of work here that would save us one day of bugfixes every week" is good. Being able to say "and then our clients would be more likely to buy into upsell because they don't have as many bugs", or "we can get more client recommendations if our response time to bugfixes had this improvement" might help

If there's barely enough time to do the tactical bugfixing now, and you expect them to take on new customers in the future, you need to "raise the visibility" of your issues, so they realize Ahead Of Time that they're going to need at least one more developer.

If the workload is becoming too heavy to burden, discuss professionally/politely with management the troubles you see coming down the line. If you don't think they're going to change how they manage it, and there's nothing firmly binding you to that position, quietly start looking for another job on the side, and start thinking of ways to ask - in an interview - "how do you manage your software development processes?".

Good luck!

Dean J
Don't discuss. Put it in writing.
Martin Hohenberg
+4  A: 

This isn't what you want to hear and it isn't advice per se, but my experience has been that the only way strategic work gets done is if I take it upon myself to do that work in whatever gaps in the tactical load I can get. (Hopefully you're good enough to fulfil your tactical duties ahead of schedule to make such gaps for yourself).

Recognition - if it comes - comes after you've done it already and can say "See what I did here? This is awesome and will save/make us money". Obviously my experience is tainted by ineffectual management, and I'm taking a risk that the powers that be won't blindly shout at me for doing this without their approval but it's worked so far. After all, the strategic is for your own benefit as much as theirs.

annakata
Have you written about this anywhere else? :)
Shaun F
Should I? (stupidpaddingstupidpadding)
annakata
you totally should.
Shaun F
A: 

Is there even a job out there for programmers to develop strategic initiatives and solutions for a company?

Yes, we have plenty of them here, but we also have around 100 programmers. These jobs only tend to exist in large programming shops.

Companies make time available for what they perceive to be important, if they won't give you time for strategic initiatves, then they aren't important to the company. If you think they are it is your task to convince management, in management's terms, why it is important and make a suggestions for what you will need to cut back in order to do the initiative.

Pick one initiative you would like to do. Don't start with the largest or most complex one, but one you think you can get done in a couple of weeks if you have a couple of hours of dedicated time every day. Make it something that solves a persistent problem. Write up a decision analysis document showing the benefits and risks and costs of both the current process and the new one. Do a formal LOE if the time it will take to do the initiative and make a suggestion for how the time will be managed (say for instance you will block off two hours a day to work on this and nothing else). Make sure to document the trouble calls that you have gotten that this initiative will permanently solve.

Once you get them in the habit of allowing you a couple of hours a day to do these things and once they have seen the benefits from the first initiative (that's why this one has to be picked very carefully), then it will be easier to move on to more initiatives. Eventually the troubleshooting goes down and then you can dedicate more time per day to them.

HLGEM
A: 

You may want to consider discussing with your manager your issue here. I would suggest having some percentages in mind for how much you'd like to spend on this,e.g. 10-15% for a relatively small amount to allow for experiments, and see if you can get that initial sign off for doing this rather than doing it behind their back and possibly sabotaging yourself. If you don't see how doing the experiments in secret can backfire just think about those times where something doesn't work out and management may think that you've wasted time and money on this.

JB King
A: 

If you don't take it upon yourself, then it looks like no-one else is going to do. I have worked for the same company for the last 11 years, writing bespoke systems for our clients. When I started we did nothing (and I mean NOTHING whatsoever) unless a client paid us for it. I was repeatedly told that '..no client is going to pay us to do this properly..".

Well now I am a team leader and our clients ARE paying us to do it properly as we have explained to them about the costs of doing it badly, and they realise that a neat solution written once is better than a quick, dirty and unsupportable solution written 10 times.

Hope this helps. I think the saying goes "Change your job, or CHANGE YOUR JOB".

Best of luck

Mmarquee