The Executive Singularity Project Management Methodology

Posted April 24, 2014 by developnorth
Categories: Morale, Project Management

Previously, I postulated that my employer had created a new project methodology called the Reality Free Project Management Methodology.  I think I’ve discovered the real project management methodology in use in my company: The Executive Singularity Project Management Methodology (ESPMM).

What is ESPMM and how does it work?

The Executive Singularity Project Management Methodology, at its core, is modeled on the gravitational singularity, or simple terms, the center of a black hole.  Armed with a semester of Quantum Physics (yes, I took quantum physics in college, but only because it was required) and a hastily read article on Wikipedia, I’ll explain how this works…

A Digression

A black hole is caused when a really massive star collapses on itself at the end of its life.  The gravitational force of this mass continues to pull in more mass, increasing the gravitational force.  At some point, the mass reaches a point where a gravitational singularity is formed.  The gravitational singularity is a point that has no volume, but contains the mass of the black hole, thereby having an infinite density.  Black holes also have an event horizon which is the last point before an object is pulled into the black hole.  Eventually, the gravitational pull is so strong that anything that passes the event horizon, even light, cannot escape.  As you approach the event horizon, time seems to slow down for anyone looking at you from quite a distance away, but to you, time continues as normal.  It has been theorized that it might be possible to exit a black hole into a different space-time.

What Does This Have to Do With Project Management?

Management kicks off a project.  They start to apply more and more pressure to the project.  As they do so, more and more requirements are added to the project, resulting in increased pressure.

Looking at the black hole model, one could say that the project requirements might represent the mass of the project, the resources allocated to the project would be the volume of the project, and executive pressure would represent the gravitational forces.

At some point, the executive pressure and the ever increasing number of requirements create what I term an executive singularity.  The executive singularity is a project that has no resources, but all of the requirements, thus achieving an infinite density.  The executive singularity would also have an event horizon which would be the point before something is pulled into the project and can never leave.

Practical Benefits of the Executive Singularity Methodology

From a management point of view, the Executive Singularity Methodology allows an ever increasing amount of requirements to be added to a project.  Once the singularity is created, management could only see anything up to the Event Horizon.  As a result, time would seem to slow down from anyone approaching the singularity which means that they should have plenty of time to deliver all of the requirements.  In fact, to management, far away from the executive singularity, time might appear to stop altogether for anyone trapped in the singularity, thus assuring 100% percent delivery of all requirements.

The Drawbacks to the Executive Singularity Methodology

The drawbacks to this methodology are only apparent to those who have been drawn past the event horizon and cannot escape.  For these unfortunates, time continues to function normally so there really is only twenty four hours in a day and seven days a week.  As a result, they realize that it’s impossible to meet the requirements of the project, but since they’ve passed the event horizon, there’s no way to communicate this to management.  In addition, the executive forces begin to twist and distort the participants.  It is theorized that it may be possible to pass through an executive singularity and come out in a different assignment, but to date, no proof has been found that this is in fact possible.  empirical evidence tends to show anyone trapped in an executive singularity is crushed by the weight of the requirements.   While this is certainly detrimental to the person crushed within the singularity, this is another benefit to management because it means less employees to pay.

Conclusion

I think I may have something with this theory and may look to publish a paper on it; perhaps it might win a No-Bull prize!  I’ll continue to collect empirical data and perhaps I might be able to pass through the singularity relatively unscathed.

I believe this accounts for the real reason why all of our projects at work really suck and no one else can see why.

A New Project Methodology!

Posted August 9, 2013 by developnorth
Categories: Uncategorized

I’m no Project Management Professional (PMP), but I have learned a fair amount about project management in my career.  I’ve actually had a few training classes in general project management as well as a specific project methodology.  I’ve also learned the differences between waterfall, lean, and agile.  But in my new job, I believed that I have discovered a brand new project methodology at my place of employment and I can’t wait to share it with everyone.

For my non-technical friends, project management is taking a large task (like developing a new system, or it could be building a house), breaking it into the stages, breaking the stages into tasks, figuring out the resources that are available, figuring how long it takes each resource to complete  a specific task, and putting that all together to tell you how long it will take to do the big task.  You have three variables that you can use to change the project: Quality (this would be a combination of the quality of work to be done and even the scope of the work), Resources (people and money), or Time.  A common adage in project management is that for any given project, you can only favorable control two of the variables at once.  For instance, if you want something done well in a very short time frame, you have to throw lots of resources at it (people and/or money).  If you want it cheap, but good quality, it will take a long time.  

But I’m proud to say that my place of employment (that shall remain nameless) has a groundbreaking approach to this dilemma.  Allow me to present the Reality Free Project Management Methodology (RFPMM). Let me explain how this works:

1) Take a major task that would be considered a project

2) Pick a manager who will manage the project

3) The manager picks the completion date

4) The manager assign resources – as a rule, no more than two people should work on this, even though others might be available.

5) Expect it to be done by target date.

The advantages to this are many – you don’t have to worry about pesky things like figuring out what tasks make up this project, how long it takes to do the task, whether you have enough resources, communicating plans and task schedules to the people doing the work  You just pick the date you want it done and the resources have to get it done by that time.

In all seriousness, this is how major (and even not quite so major) tasks are planned at my company.  Yesterday, my supervisor asked me to come up with a plan to convert a system built in one language to another…in two months.  By myself.  And probably while I also have to contribute to another important (but not as big task) as well as two major projects. On a monthly basis, tasks are assigned to developers for the fixed date release and there better have been an apocalypse to excuse not having your tasks completed for the release (even if assigned to you two days before release day).  

But there’s the beauty of RFPMM – it doesn’t matter.  You have a task and a due date. You can control all three project management variables because…reality doesn’t apply.

Hmmm…I wonder if I could patent this and then charge my company for violating my business process patent….

Say What You Mean, Damn It!

Posted September 15, 2011 by developnorth
Categories: Uncategorized

“You keep saying that word. I do not think it means what you think it means.” – Inigo Montoya, The Princess Bride

I guess I’m slowly becoming a grumpy old man, but one thing that really bothers me is when words are used to denote a meaning that really doesn’t mean what the person has intends it to mean.

Case in point:  The other day, I got a message about a list of web classes  at my day job.  One of them caught my eye: “The Attitude of Servitude”.  Huh?  Did they really mean that?  Are they really trying to get us to think like indentured servants?  Thinking that maybe my grasp of English vocabulary wasn’t what it used to be, I looked up servitude:
  • a condition in which one lacks liberty especially to determine one’s course of action or way of life
  • a right by which something (as a piece of land) owned by one person is subject to a specified use or enjoyment by another
Merriam Webster Online Dictionary

Who’s ready to sign up for this class?  Sorry, not me!

Suspecting that this wasn’t really what they wanted to teach, I did a Google search and I think I found the course description:

“… provides insights into building customer relationships through service. Customer service insights include: Seeking personal excellence; Intense customer focus; and Win-win spirit. This course will help you differentiate your organization from your competitors by following the outlined concepts.”

I suspect that the person who created this course was trying to be clever. Change the word service to rhyme with attitude and it sounds great… The Attitude of Servitude…except for people with  a vocabulary.  I’m sorry, I really don’t want to have the attitude that I have no liberty to determine my own course in life.  What’s the follow-on class…Smile and Be Servile?

In the corporate world, it happens constantly.  It makes me just grit my teeth and mutter under my breath. People constantly make up words out of existing words to try to make themselves sound smarter.  It’s like in high school when you have to write a 500 word essay and you made up variations of the same sentence so you could make the word quota.

But if I hear any sentences like “We need to incentivize people to be proactive in synergizing their learnings to create a new paradigm”, I think I might scream. How about just saying “We need to find a way to get people to come up with new ideas”?

The point of language is to convey thoughts and ideas to another person.  You know, communicate! When people start trying to make their language sound more intelligent by making up words or torturing existing meanings, they are not acting intelligently. They are not communicating; they are just attempting to show off.  I suppose nothing can be done about this because corporate speak and its ilk will be there so that someone can spend five minutes talking and not really communicate anything.  It’s a good PR strategy – talk for a while without really saying anything definite.

But my mission and my new mantra is “Keeping Things Simple”.  That doesn’t mean using simple words all of the time.  There something to be said about using one bigger word in the place of numerous smaller words.  But the point of communication needs to be about conveying the idea, not seeing how many words you can use.  We’re not in high school anymore – we aren’t graded on word count! (although at this point I’m at roughly 590.)

Michael’s Laws of Software Development

Posted February 11, 2011 by developnorth
Categories: Miscellaneous, Software Development

In the course of my career, I’ve come up with a few rules/laws that I’ve found to be true time and time again. Sadly, these laws are based on actual experience. So I thought I’d share them with the Software Development community (or the five people who read this blog):

I. Michael’s Immutable Law of Software Requirements

Users always perform the same process to the same data every time…except when they don’t.

II. Michael’s Law of Vocabulary Variance

Words like “required” seem to have a different meaning to a developer (“always must exist”) than to a user (“it must exist, unless I don’t feel like it”). Also “optional” also seems to mean “required”; unless, of course, if it doesn’t.

III. Michael’s Law of Feature Longevity

The feature that is a “must have” and is the hardest to code will be the feature that will be reversed in six months. See Laws I and II.

IV. Michael’s Law of Prioritization

Every feature or request is absolutely the highest priority, even if the requests are from the same person and there’s only one programmer to implement them.  When pressed to prioritize which features/requests should be addressed first, the answer is “all of them”.   Apparently, having dual core processors on computers now means that a programmer can program multiple features simultaneously.

V. Michael’s Law of Project Accountability

The lateness in delivery of code for testing is directly proportional to the perceived failure of the project.  However, the length of time it languishes waiting for testing and signoff, even if greater than the lateness of code delivery, has no effect on the perceived failure of the project. In a word, it’s always the developer’s fault.

VI. Michael’s Law of Diminishing Returns

When joining a successful company or new group within a company, that company or group will immediately lose resources (budget, personnel, etc.) approximately one year after you join it.  And it only gets better from there!

I’ll continue to update these as I uncover more laws of software development.  This blog would not be possible without the pioneering work of Mr. Murphy and all who came after him.

In Praise of Maintenance Programmers…

Posted July 2, 2010 by developnorth
Categories: Career, Software Development

I know this is supposed to be a blog about development, but I want to spend a few moments in praise of a group of technologists often overlooked in the discussions of software development: maintenance programmers.  There has been much discussion about “rock star” developers, particularly from Joel Spolsky at Joel on Software.  And that’s great.  Any discussion that raises the social standing of programmers is a good thing!  But I want to talk about the unsung heroes of software development and IT – the maintenance programmers.

First, a confession.  This topic is slightly self serving, in that in my new day job, I am now a programmer in the maintenance group.  In fact, my recent trials and tribulations at work made me really appreciate how hard maintenance programming really is and how the skills essential to maintenance programmers are a little different than a developer.

The Obligatory Star Trek Reference

Using Star Trek as an example, I see developers as the Starfleet Engineers who build the starship and the maintenance programmers as the Scotty’s of the world.  Think about it – Scotty is always enlisted to perform miracles to make the ship work because Kirk (the user) wants it to do something it was never designed to do or has messed it up so badly that it needs heavy duty maintenance.  And Scotty usually has to perform these feats of miraculous engineering under extreme time constraints or without key personnel or resources.  Sounds like the kind of day I had every day for the last week and a half!

Obviously, Star Trek is fictional because Scotty always gets the accolades and praise…when was the last time maintenance programmers got praised for working diligently to fix a problem?  Usually it’s, “That’s nice, now here is my list of another 20 things for you to fix…”

Skills Essential for a Maintenance Programmer

  • Ability to Read and Decipher Someone Else’s Code – It goes without saying, that most of the time, maintenance programmers don’t actually write the code they have to support.  Nothing says you’re going to have a day of fun like digging into a steaming pile of…code.
  • Ability to Be a Forensic Scientist – Not only do you have to be able to read the code, you have to figure out how it actually works in the REAL WORLD.  Developers rarely see their code live in the world and don’t have to worry about pesky details like when the database table is locked because one process is doing something while another is trying to update the same table.  You have to make friends with every kind of debugger/trace tool that you can lay your hands on so that you can do a little CSI work on the culprit (the problem).
  • Ability to be Sherlock Holmes –  Hand in hand with the CSI work, you need to be able to logically deduce what is happening from the (hopefully) piles of evidence you have discovered.  Remembering that when you you have eliminated the impossible, whatever remains, however improbable, must be the solution,  goes a long way in maintenance programming.
  • Dogged Persistence – You have to keep beating your head against the problem until either you win or the problem miraculously disappears.  This is where the rubber meets the road…you’re the one who has to get it working for the users.
  • Being a Jack of All Trades -While it’s great to be an expert in a development language, once that code hits the real world, it is likely interacting with any number of other things out of your control (like it might have been in development) – like web services, networks, databases…you name it.  Knowing at least something about all of the elements of helps give you an appreciation for all of the possible areas to explore.
  • Intuition – Sometimes intuition is the best tool for trying to figure out what is happening.  This is sort of an addendum to the previous skill.  When you’re grounded in a varied background, you begin to make connections and improve your  intuitive skills.
  • Patience – You really need to have the patience of a saint to keep from going crazy.  Each roadblock that’s thrown up by the code or the production environment has to be either worked around or driven over.

The Stigma of Maintenance Programming

But let’s face it, maintenance programmers don’t get treated the same as developers.  Why?

  • They are not perceived as being able to grasp new technology – Maintenance programmers may seem like they don’t “get” new technology, but I don’t think that’s universally the case.  In my limited stint as a maintenance programmer, I have to understand a wide variety of things – XML, web services, C#, Java, JavaScript, SQL Server, and mainframe JCL to support the applications.  Sure there’s old technology, but there’s a good chunk of new technology that I have to learn quickly.  And usually without the training that the developers got so they could figure out how to develop the system.
  • Keeping things going is not as glamorous as building new stuff – This is universal it seems.  This happened at a previous employer. I’ve had co-workers and friends that never seemed to do well and weren’t looked on favorably by management because they went about the job of keeping things going silently and efficiently.  I know that some of peoples were on the list of people to be downsized because they weren’t producing new exciting work.  But they kept the business going.  If it were my business, I would have hired them without reservation because they were model workers.  Yet somehow, the idea of doing what’s needed to keep the business going is not as important as producing new things.  I don’t care how many new systems/products you develop, if you can’t execute on a day to day basis, it just doesn’t matter.
  • They are not “real” programmers because they don’t create anything – That’s simply hogwash.  Maintenance programmers are usually the ones who have to extend/recreate/totally rewrite the original application when the business needs (or the user’s minds) change.  They are the ones usually stuck with refactoring – now that’s a REAL programming task.

What Can Be Done to Fix the Maintenance Programmer’s Lot?

In reality, probably nothing.  As a business culture, we only seem to care about the next new thing.  I realize that business can’t just stay focused on doing the same thing all the time, but if you don’t have stable, dependable systems, all the new development work in the world is not going to keep the business going.  So, here’s my wish list for what could be done to help maintenance programmers:

  • Recognition for the important work that’s done – Sure, there might be some sort of celebration for a new project that was completed, but how about some sort of recognition for someone who finally fixed a long standing problem?  Came in in the middle of the night to get the jobs running?  Yes, I know it’s part of the job, but you know what?  So is delivering a project if you’re on the development team.  A little recognition would could go a long way.  It doesn’t have to be an elaborate thing: an email to the group praising someone’s efforts or a mention at a staff meeting. Although food is always good!
  • Rotate developers and maintenance programmers through projects – I think it would be great if one maintenance programmer could join a specific development project, while one development programmer took a tour of duty as a maintenance programmer.  I think it would have very many positives – maintenance folk get in on the ground floor and get to build something , they get to see the struggles that developers have in trying to create something from nothing, and they may get a chance to pick up a new technology.  Developers get to see what it’s like to have to support code over the long haul and deal with the inevitable changes that occur as the software is let out in the wild.  This may help inform their development choices later…especially if they know they may have to support it at some time.
  • Make sure that maintenance folk get the same training opportunities as developers – How many times have you seen this?  A new technology comes in and the people who are going to implement it get training.  Down the road, they move on or the system moves to the maintenance group…who now have to figure out how to support or even change this thing.  But there’s no training for the maintenance group because the company has already spent enough money training people…who are now completely consumed doing something else and have no time to help.  If it’s important in enough to train people to develop with a technology, it’s just as important to train the maintenance people!

So to all my fellow maintenance programmers out there:  keep the faith and keep doing what you’re doing to keep things running!

I Once Was Lost, But Now I’m Found…

Posted April 17, 2010 by developnorth
Categories: Uncategorized

After a long silence, I’m back…in more ways than one.  I’m happy to report I’ve been gainfully employed for almost three  months now.  And I’m back to programming on my own project…and writing a blog.

Why the silence?  You would think that while I was unemployed, I’d have a lot of time to write.  And that’s true.  But as the title of this blog implies, I was lost.  I couldn’t focus on anything.

Anatomy of My Unemployment

After the initial depression and rage of being involuntarily separated, I settled into a somewhat productive rhythm where I looked for jobs, did some programming on my project, and took care of my son over the summer and doing a lot of cooking.  And all was well…OK, all was at least not totally sucky.

Soon the summer faded into autumn and I still was no closer to employment than I was the day I was let go.   By September I had only had one interview.  But not many rejections…because a rejection letter would imply that you would actually receive a response.  And a job that I had previously applied for re-opened at a local company and I re-applied.

And…nothing.  I did get a second interview and was promised a response within a week….And nothing….three weeks of calls and email to company netted….an email that they wouldn’t be extending an offer.  I had other interviews and never heard another word from all but one of the companies. 

Autumn became winter and again, I had no more prospects than on the day I was escorted out.  And the winter weather drove me inside and one of my only outlets, running, was shut off.  And more emails and calls…and no response. 

And Then a Ray of Hope

Then an interview….and then a programming assessment test (that told me I wasn’t a great programmer), then a second interview and almost 7 months from the day I was involuntarily separated, I started a new job.

The Emotional Toll of Unemployment on My Psyche

Months of being ignored made me feel more and more worthless.  Each unreturned call or email was another chip out of  my confidence.   I could make no plans and had no plans.  I had no schedule other than getting my son up for school and being here when he finished.

And as a result, I couldn’t focus.  I’d sit in front of the computer to program or write…and…nothing.  I’d mess around on Facebook or play games or go play on the Wii.

 What I Learned from This Ordeal

  • I (apparently) am a more structured person than I thought I was  – I’ve always thought I was more of a random person, but apparently I need structure.  I had no schedule or anything to frame my day. And I got nothing done.  Since returning to the nicely structured world of 9:00 – 5:00, I am able to get more accomplished in less time because I think I know I only have x minutes to do something, so I focus and do it.
  • “I’m good enough, smart enough, and doggone it, people like me” – I guess I needed Stuart Smalley with me during the dark days of my unemployment.  In my new job, I’ve been able to jump in and be really useful – in fact, coming up with a solution for a problem that the vendor hadn’t figured out yet. Self confidence certainly takes a beating when you’re unemployed and it’s hard to remember that you are as good as you think you are.  See this excellent article by Pamela Slim.
  • Working as part of a team sure beats the lone wolf approach – In my new position, I’m part of a group supporting a couple of systems and we are part of a bigger team supporting a whole line of systems.  And I like it!  Although we’re dealing with the challenge of coordinating changes and activities, it’s a refreshing change from having to do everything yourself!  For most of my career, I’ve been the only person working on a project or, in the case of my previous employer, the only IT person responsible for all of the systems.  Having a much smaller, focused scope of work is…refreshing.

Mike Has Found His Groove

I feel like I’m finally getting back in the groove.  I realized that despite being ignored, rejected, and told that I’m not a good programmer, I AM a decent programmer.  Maybe I’ll never build truly amazing, transformational software, but I’m a decent developer.  I have the desire and stubbornness to not give up on problems.  I may be a bit of a jack of all trades, but it continues to serve me well. 

So, I’m back and I’m getting back to development and blogging. 

I am geek, hear me roar!!!

Running…and Software Development

Posted August 17, 2009 by developnorth
Categories: Miscellaneous, Software Development

This spring, I took up running.  To anyone who knows me, this comes as a huge surprise.   Up to this point in my life, I have always hated running.  I decided I wanted to get healthier and start losing weight, so I started using the Wii Fit we got at Christmas. I gradually worked my way up to being brave enough to do the running in place exercise.  And I sort of didn’t hate it.  I actually got good at it and was soon running a couple of virtual miles a day.

I thought, “Hey, I can start running outside”.  So I laced up the sneakers and ran to the end of my street ( about 0.6 miles)… and felt like I was going to die.  For the next three days, I felt like my thighs were going to explode everytime I moved.

A couple of weeks later, I tried again.  This time, I got a real running plan and followed it.  It started slowly with more walking than running.  Each week, and later each run, increased the amount of running and decreased the amount of walking.  After eight weeks, there I was running for 30 minutes straight for the first time in my life.

So What Does This Have to Do With Software Development?
I’m in the middle of rewriting an application and trying to upgrade my skills all at the same time.  And my result to date has been much like my first attempt at running.  I think I can do it because I’ve done it before and I start hammering away…and then it doesn’t work and my head starts hurting from not seeing what I should be doing.  I’m trying to run before I’ve built up the mental muscles that support the understanding that I need to move forward.   What I need to do is to start walking and adding my running minutes gradually. 

Who Cares?  Why Is This Important?
I think one of the weaknesses of technical people (myself included) is that we don’t like to admit we don’t know something.  We’re often thrown into circumstances where we have to do something we’ve never done before.  And so we boldy go where we’ve never gone before….and get frustrated.  We may reach  the solution, but we feel like there has got to be a better way.   Sometimes we get lucky in the Google roulette and find a code snippet that will do most of what we need without ever having to think about it.  Sometimes, this is a good thing – especially if it’s for one esoteric feature that a user ABSOLUTELY has to have, but it’s not  part of the core of the application (like say, a routine for changing the colors of the graph reports).  But it’s very easy (and tempting for the sake of expediency) to throw together a whole application of disparate snips of code…and that is a recipe for disaster.

What we should be encouraged to do at our places of work or even on our own, is to embrace the beginner’s mind.  By beginner’s mind, I mean that stage where you go through the basic exercises and start to make the connections that enable you to figure out how to more and bigger things.  In beginner’s mind, you don’t necessary even know what you don’t know.  But you start slow and build the intellectual muscles that you need to start.  And you continue to build those muscles so that you can do more.

How Do You Begin the Journey of a Thousand Miles?
 With a single step, Grasshopper.  By that I mean start at the very beginning.  For me, I’m going back to the .Net books that I have that patiently walk you through the steps to building a .Net application.  No more skimming to find the section that I think will do what I need to do. I also will look at Microsoft’s tutorials online and also squeeze in some online training.  As I learn, I will start to apply each piece to my application, re-enforcing my learning.  To speed up, I have to slow down; move carefully through the preliminaries until I have mastered them.

Because running is just like software development – just because you have been doing for a while, it’s still never really easy – it just gets less painful.

My Ideal Job

Posted August 7, 2009 by developnorth
Categories: Career, Software Development

This started out as a completely different post – one about spending the last month (plus) in Unemployment Nation, but it occurred to me that I should be focused on what I want to do.  I decided that I’ve done enough wasting enough mental energy on my previous job and the way I was discarded…I mean let go. 

Since I’m now looking, I’ve been think about my ideal job.  I’m imaging a place called Utopia Software Company.  Here are some of the elements of Utopia Software Company:

IT/Development  Work is Either THE Product of the Company or an Integral Part of the Company’s Products – In my previous IT jobs, IT was always viewed as, either a necessary evil or a black hole where money was poured with nothing coming out.  When the inevitable tough times would come, IT would be the first on the block.  In my first job, I watched IT get chopped in third. Recently, my IT department of three employees was reduced to one contractor.  The companies I worked for had lots of intelligent people working for them.  Companies where technology (not necessary computer/electronic) are key. You would think that if they could give IT at least some of the resources it needed that there would be a big return for the business.  But what IT got was usually the shaft.

Also, IT had little or no clout within the organization.  Trying to get things done that were needed for the IT organization to work better was damn near impossible.  No one wants to hear that we need a new air conditioning unit for the computer/server room or that we need this or that tool to do our job more efficiently.  And when trying to get the attention of management, if it had to do with IT, forget about it.  As friend of mine said, “You can’t spell shIT without IT!”.

That’s why I want to be part of an organization that either makes software or view software development and the systems as a key part of their business.  IT would not be considered a second rate department, but critical to the success of the company.  I would like to feel valued and supported.

An organization that ACTIVELY supports learning – One of my biggest frustrations with my corporate IT career has been the lack of opportunity for learning, particularly for classes.  I’ve been part of two corporations who SAY they value learning, but I have not seen it pan out.  I have rarely been able to take training I need just to be able to do my job, let alone learn any new skills.  It’s a good thing I can pick things up quickly, because that has been the way I’ve had to learn almost everything.  I did have one good manager who really let me take a number of courses to improve my skills – that was nearly 13 years ago.  I’ve had almost zip since. 

I want to be part of an organization that really encourages learning and gives people the time and resources needed to learn and continue to learn.  Allowing people to take web classes while trying to continue to do support work doesn’t cut it.  If I’m supposed to be learning something, I want to be learning it and concentrating on that. Not trying to learn a new database technology while supporting applications, correcting data entry errors, and fixing printers.

Pay and Compensation

I’ve worked for two companies whose view of pay and compensation couldn’t have been more different.  One paid people in proportion to their performance – the percentage of your raise was clearly tied to your performance that year.  The other company SAID they believed in performance based compensation. But if you worked your ass off or just did what was needed, you might get the same 3.5 %.  The one company expected alot out of you, but actually gave you something back.  Most managers at that company would give you time off if you had to do night or weekend support.  The other company wanted you to work even more than the former, but you were lucky to receive a pittance of an increase and no time off if you had to give up nights, weekends, or even holidays for support.

I want to work for a company that rewards their employees for a job well done with meaningful increases.  If the company expects a great deal of their employees, the employees should expect a great deal in return.  And night, weekend, and holiday support work should be compensated by either time or money. 

Room to Grow

In both my corporate jobs, there really was no place else for me to go.  In my first job, the only way up was into management and at the time, I wasn’t willing to make the sacrifices (move away from my family) to make that happen…I’m still not ready to make that sacrifice.  In my last job, there was, at least on paper, more technical levels for me to pursue, but I knew that no one would want to have someone of that level working in the plant…apparently they didn’t even want to have someone of my level working at the plant…but I digress…

I want a job where there is a technical and management ladder.  I was a pseudo manager for a while (all of the responsibility, none of the power), and I’m not sure I was real great at it then.  I’ve learned a lot since then (particularly what NOT to do) and think I have a better mindset for being a manager, but I still like technical things.  I’m not sure I’m ready to go into management, so I’d like a position where I could advance either technically or managerially.

In Search of Utopia Software Company…

Am I asking too much?  Does this company even exist?  In Central New York (state)?  That’s the kind of company that I would like to build some day, but for now, I’d like to just see on functioning in the wild.  My horror stories of Corporate IT are mild compared to many I have heard with psychotic management and cutthroat politics – I’ve been spared that.  But wouldn’t it be nice to work for Utopia Software Company or at least in the IT department for Utopia where dreams can come true?

And Now, A Rant…

Posted June 30, 2009 by developnorth
Categories: Miscellaneous, Rant

One thing that’s been bothering me about my downsizing…OK, there’s plenty more than one thing, but this is bothering me right now.  Working in IT, it’s expected that you can be on call ALL THE TIME – evenings, middle of the night, holidays and you have to go in and fix things completely uncompensated in either money or time. 

When I asked my manager about comp time for the time that I drove in on a weekend to bring things up after an extended power outage, I got told “that’s part of being a professional”.  And the day after I stayed almost an hour and a half late to fix a printer that would mess up production, I was chided because on the same day, I arrived 5 minutes late.  The company got 1 hour,  25 minutes extra time from me that day, but the five minutes was a problem.

And what did I get for all of this extra effort?  I was about the first salaried person to be downsized.

Here is my call to arms to my fellow IT workers: 

NO MORE UNCOMPENSATED WORK!

Part of being an IT Professional means making changes when they have the least effect on systems and the users.  This necessitates after hour/weekend work.  I accept and agree.  HOWEVER, that is not card blanche for the company to steal that time for you without compensating you with either money or time.

Professionals – doctors, lawyers, accountants – all charge for their time.  They are compensated when they work.  Why should IT workers be any different?  Employers have successfully used the whole “salary exempt” classification to weasle more work out of workers without compensating them for it.  It’s time for us to just say no to this game.  If we are told we have to do the work on non working hours, we get either time or money in return.  Plain and simple.  And we have to be given the ability to use that time!

I did it out of a misplaced sense of loyalty and professional pride…and it got me an early ticket to the unemployment line.  I’ll never get back the time I didn’t spend with my wife and son when I had to go in on the weekend to restart systems or see my son go to school because I got back home at 4 AM because of a problem and actually wanted a few hours sleep before I returned.

I think every person in IT should adopt the mantra of the movie “Network” :

“We’re mad as hell, and we’re not going to take it anymore!”

And Then There Were None…

Posted June 28, 2009 by developnorth
Categories: Miscellaneous, Morale, Rant

On Wednesday, I got a nasty surprise at my day job.  I went to check my mailbox when my boss asked me if I had a few minutes.  I walk with him to the conference where the HR person is sitting.  I’m thinking we’re talking about training because I had been fighting like gangbusters to get the training I need to do my job.  But that’s not what this talk is about.  I was selected for the Involuntary Separation as part of an ongoing effort of corporate. They politely explained everything to me, led me back to my office where I packed up my stuff and was walked out of the building.  One of my close friends at work had also been the lucky recipient of an Involuntary Separation so we commiserated over coffee.

I have no idea what they were thinking.  There is now no IT at the plant and an ERP and a main system that runs most of production that need support – and no one to support it.  The ERP system was supported locally since Corporate runs SAP and the other system was a Visual Basic system built over 13 years.  And no there’s no one.

I have run the gambit of emotions – anger, shock, depression, relief (today I seem to be centering on depression).  I know that this too shall pass, but it doesn’t make it any easier while I’m going through it.  Mostly, it  makes me feel like wasted four years of my life at a place that obviously didn’t think much of me if they can get rid of IT so cavalierly.  It’s not like my company is losing money – it’s probably a case of not making “enough” money.  Truthfully, I don’t see how they are going to save money and support the business because they’ll have to pay contractors to do it all.

It makes me mad for all of the middle of the night trips I made to get systems up so that production could continue, the working on Christmas holiday so that payroll could get processed and financial closing could complete on time – all obviously meant nothing in the end.  It’s an object lesson to me about trusting any corporation – all they seem to want is to suck out your knowledge and time and when you become inconvenient, you are jettisoned.  And this isn’t a “if we don’t cut people, we declare bankruptcy” kind of decision – this is a “we’re not making enough money” decision.  That I can only hope hurts them in the long run…not that I’m vindictive or anything…

So after having a pity party for myself, I’m redoubling my efforts on my business in hopes of finishing my product this summer and starting the search again.  The last time, it took me over a year before I found this position and the economy was better.  I don’t like my odds this time…

As someone said to me recently, God doesn’t give you anything you can’t handle – sometimes, I wish God didn’t have so much faith in me.