The Peter Principle comes home to roost

[BrokenPaw]

>sigh<  Sorry, just need to vent a little.

I'm a C++ Software Engineer by profession.  13 years of experience in software development, doing C and C++ (and, under duress, FORTRAN, Java, and C#) development, primarily on Unix/Linux platforms. 

I'm a darn good software engineer, too.

As recognition of the fact that I'm the person in my group that has the most comprehensive grip on how our system works, from the viewpoint of interfaces, data flows, and requirements, I have been made the System Engineer/Architect.  Which is to say, I've been removed from the role of software engineer, and placed into a role that could be better described as "people engineer".  I'm now the one who tracks interfaces, and makes sure that if components A and B need to change how they talk, that component C won't be adversely affected.  I'm now the one who tracks features and writes release notes.

I've been removed from my development task (which involved the design and implementation of a part of the system that was absolutely critical for its success).  They've given my piece to a junior guy who is very good in an academic sense, but who has no real-world grip on how our system works (and has to work) in the field.  He's going to make implementation decisions based on perfect-world theory, not on real-world practicality. 

I'm out of my depth.  I'm a software engineer, not a wetware engineer.  I don't want to chase engineers around all day asking them to "pretty please keep your ICDs up to date". 

I was a good software engineer.  I'm going to be bad at this.  I'm already bad at this, and I have no desire to become good at it; it's not where my interest lies.

Why are people who are good at what they do taken out of what they do well, and put into positions where they have no idea what they're doing?  Where is the sense in that?

-BP

[The Rabbi]

Isn't there a Dilbert cartoon just like this?
Have you gotten the hang of that management-wear called necktie yet?

[mtnbkr]

Your hair points are over that way ----->

Chris

[BrokenPaw]

Eh, if I were a manager, at least I'd have something resembling authority to go along with the new shackles.  This is empty busywork responsibility with no attendant power.

And the day they expect me to put on a necktie for anything other than meeting with a customer is the day they learn the depths to which my scorn can delve.

-BP

[Lee]

It's because corporate leaders really are like the boss in Dilbert.  It's the same way where I work....they always take the most competent chemists, IS, or R&D geeks, but who have no people skills, and make them managers.  My life becomes more Dilbertized every day. Perhaps the strategy is, that you will find all of your reports unfit for raises and promotions.  And if they can't do the work...you will work overtime on your grand salary to get the job done.  Sad but true.

[Matthew Carberry]

Also, and I think this was covered in another thread.  Being a "manager" is considered higher status than being "just a technician".  Many management types who define their self-worth by how many people they manage can't see just having pride in one's abilities.

Also, in many companies I assume they actually restrict tech pay so the guy who does the work can't be considered more valuable than the guy in the suit who watches him.

[Bogie]

Oh yeah...
 
I'm a VERY good scientific communications/graphics person. Highly technical, or layperson, no big deal.
 
Then there was a merger, and they didn't really know where to put the function, so they moved it to "procurement and purchasing" where they put all the other stuff they didn't know what to do with. So they put me into a slot where I was supposed to count copiers, irritate people who made copies, and listen to hour after hour of meetings about optimally counting copies. Oh, and while I was at it, keep doing my original job. Needless to say, I sucked overall.
 
Then they replaced me with a guy who does meetings, and two contract people who do "design," and at last look didn't dig science. Didn't WANT to dig the science.
 
My advice: Start looking, and don't let 'em burn you out.
 

[BozemanMT]

Push back
Look, i'm a darn good software manager and a terrible technical person
two totally seperate types fo people
I thrive on doing 5 minutes here and 5 minutes there, it drives most technical people crazy, they need 2 hours of uninterrupted work (which drives me nuts)
go to your boss and tell them, Look, i'm very happy and very good at what i"m doing, i want to go back.

I think you'll be pleasantly surprised.
I know most managers don't care, but I ask everyone on my team, what they want to do, where they want to go and many of them say "i'm happy where i"m at"

ok, done, I can give more challenging things to do within those confines for growth, but I won't push someone to be a lead/manager when they don't want to.

[Standing Wolf]

I'm out of my depth.  I'm a software engineer, not a wetware engineer.

The user interface is always at least 85% of any application, which is why software engineers shouldn't be allowed anywhere near them.

[Tallpine]

BrokenPaw - you don't happen to need a c++ s/w engineer who can work offsite, do you ....?

[Bogie]

IMHO, you write the manual first, working with the customers to design the interface along with the manual. Then you make the program do what the manual says.
 
But what do I know...
 

[BrokenPaw]

go to your boss and tell them, Look, i'm very happy and very good at what i"m doing, i want to go back.

Unfortunately, I already tried that.  The response was, in its entirety:  "I expect you to make it work."

This particular guy redefines the word "capricious".

Standing Wolf, you're absolutely correct that software engineers should not, by and large, be allowed to do user interface work.  Unfortunately, if you don't allow software engineers to do it, it generally ends up being done by managers.  In VB.  Badly.

Tallpine, unfortunately, no; more or less all of what we do involves air-gapped networks and rooms that one can't get into remotely.   

Bogie,  writing the manual first works only when the customer knows exactly how the software will be used when it's done.  That's a great method for things like word processors and stuff like that.  Unfortunately, it doesn't work so well when the application itself is creating the niche in which it lives, because it's never been done before.  When that's the case, it's not always possible to see in advance how the end users will need things to be, because the environment isn't fully understood until after the first revision of the thing is in the field, producing results.

I've pushed back in my own way; yesterday's pronouncement by fiat (the thing that finally drove me to vent here) was that the PHB-in-question mandated that the portion of the project that I have had technical responsibility for (which was coded on Linux, for Linux, using linux dev tools, and which used a source-code repository called subVersion, running on linux, integrated into the dev tools) should store all of its source code in Visual Sourcesafe, like the Windows app front-end, despite the fact that the subVersion repository has never caused a single issue, and we have SourceSafe problems all the time.  And despite the fact that none of my dev tools work with SourceSafe.

His plan was that today, whether I liked it or not, the subVersion server was going to be slagged and repurposed.  But I have the root password.  And now I have the entire subVersion repository hosted elsewhere.  So when he goes ahead and slags the old machine, he can feel all clever and impressed with how well-endowed he is, and I can get on with my job.

Because I know for a 100% iron-clad fact that if I hadn't done this, six weeks down the road he'd have come back and wanted to know why I couldn't fetch a particular prior version of my software out of the new repository[0] in order to debug a previous revision in the field.  And when I told him why, he'd have made it my fault.  Because he's that kind of guy.

-BP

• Why?  Because you imported all of the current branch into SourceSafe, that's why; you lost all of the history when you did that.  Duh.

[Vodka7]

Well, the one plus is you know your team has a manager who actually understands the way things need and ought to be done, which is a relative rarity.

[BrokenPaw]

Well, the one plus is you know your team has a manager who actually understands the way things need and ought to be done

Not sure I follow.

[Vodka7]

Well, the one plus is you know your team has a manager who actually understands the way things need and ought to be done

Not sure I follow.

Maybe I misunderstood--when I first read your post I thought you were being put in more of a managerial position.  If there's a manager above you who's making the decisions (i.e. the do it because I said so stuff), then no one benefits.

[BrokenPaw]

Oh, I see.

Yeah, I was put into a position that ultimately has no authority, so nothing I say actually carries water.  That's what's so frustrating about it; why put me in a position that makes it seem as if I have a say in stuff and then override, second-guess, or flat-out ignore every suggestion I make?

-BP

[Marnoot]

     Before retiring, my dad was an electrical engineer. I never understood growing up why he turned down countless offers for management positions. In my young eyes a management position would have meant more money, and thus more toys, etc. for me and my siblings. We were never poor by any stretch, but we couldn't always afford things we wanted. Now that I've entered the technical workforce myself (C#/VB/Java programmer), I understand his decision. I haven't decided myself what direction I want to take my career, but the path my dad took is one I now consider a very viable option.
     Climbing the corporate ladder brings "success", more money, etc. But it can also bring long hours, time away from family, much more stress, etc. I think most people can naturally find their niche on the ladder, where they have a comfortable-for-them balance of success, money, and responsibility. But from what I've already seen at the workplace, corporate management often forces people out of their niche, usually with negative consequences.

[ONE-SHOT-ONE]

1st thing that comes to mind:
"no good deed goes unpunished" I have lived though this on a lower level (not engineering)
 2nd if going some place else that will let you do what you love, then because you have no real teeth (your words) document every thing. when you ask someone to do something do it in writing and save copies. when the crap starts to fly show your boss how many times you requested the thing to be done. maybe you will get teeth soon after that.

[roo_ster]

go to your boss and tell them, Look, i'm very happy and very good at what i"m doing, i want to go back.

Standing Wolf, you're absolutely correct that software engineers should not, by and large, be allowed to do user interface work.  Unfortunately, if you don't allow software engineers to do it, it generally ends up being done by managers.  In VB.  Badly.

Tallpine, unfortunately, no; more or less all of what we do involves air-gapped networks and rooms that one can't get into remotely.   

Bogie,  writing the manual first works only when the customer knows exactly how the software will be used when it's done.  That's a great method for things like word processors and stuff like that.  Unfortunately, it doesn't work so well when the application itself is creating the niche in which it lives, because it's never been done before.  When that's the case, it's not always possible to see in advance how the end users will need things to be, because the environment isn't fully understood until after the first revision of the thing is in the field, producing results.

I've pushed back in my own way; yesterday's pronouncement by fiat (the thing that finally drove me to vent here) was that the PHB-in-question mandated that the portion of the project that I have had technical responsibility for (which was coded on Linux, for Linux, using linux dev tools, and which used a source-code repository called subVersion, running on linux, integrated into the dev tools) should store all of its source code in Visual Sourcesafe, like the Windows app front-end, despite the fact that the subVersion repository has never caused a single issue, and we have SourceSafe problems all the time.  And despite the fact that none of my dev tools work with SourceSafe.

His plan was that today, whether I liked it or not, the subVersion server was going to be slagged and repurposed.  But I have the root password.  And now I have the entire subVersion repository hosted elsewhere.  So when he goes ahead and slags the old machine, he can feel all clever and impressed with how well-endowed he is, and I can get on with my job.

Because I know for a 100% iron-clad fact that if I hadn't done this, six weeks down the road he'd have come back and wanted to know why I couldn't fetch a particular prior version of my software out of the new repository[0] in order to debug a previous revision in the field.  And when I told him why, he'd have made it my fault.  Because he's that kind of guy.

-BP

• Why?  Because you imported all of the current branch into SourceSafe, that's why; you lost all of the history when you did that.  Duh.
  

I'll never understand why knucklehead policy-makers will insist on using a software config mgt tool with known, serious, problems when another tool does what a config mgt tool ought to without all the drama.  Or...insisting we use the corporate software CM tool for a particular project when we are contractually obligated to deliver the code in another CM tool. 

Oh, VB is a tool of the Devil, second only to VBA used in MS Office apps.

[Brad Johnson]

He's going to make implementation decisions based on perfect-world theory, not on real-world practicality.

[/size]

Present company excepted, this guy sounds like a typical programmer - he lacks the ability to "put himself in someone else's shoes".  In a previous life I reviewed instruction manuals for custom software developers (accounting and database management).  Let's just say that I was not on the programmers' list of favorite people.

Brad

[BozemanMT]

Ok
so you tried the "good boss" method.
The only thing left is to leave.
You're not going to like it, but that's the choice.
He's the boss, he's never going to change, you shoudl move on, life is too short to deal with BS like that.

[peteinct]

BrokenPaw, In this instance your boss sounds like a jerk. But sometimes there is value in working on your weak areas not just relying on your strengths. If you are shooting a gun do you practice strong hand only? I don't know the field but in my chemical plant one of the things we on the operations side have to pound into the engineers is how to lead(not just manage) people to accomplish the job. Some of them never get it. Knowing how to run a job or manage a project may serve you in good stead later on. Also in reality you will never have a boss who doesn't piss in your soup they like the flavor better then.
pete

[Newt]

I had a college class called "Supervisory Management" in which the instructor said one time (and I've never forgotten it):  "Everyone is promoted to his/her level of incompetency."  If you're good at what you do and you get promoted, and you're good at that, and you get promoted, eventually you're going to get to a level beyond what you're good at.  Not to say you're not a good engineer, maybe just out of your area somwhat.  Good Luck!

[BrokenPaw]

so you tried the "good boss" method.
The only thing left is to leave.

Bozeman, that's actually an option that I am already exploring.  With my level of experience in the industry, plus certain extra qualifications I possess, I don't expect I'll have a problem finding something else.  In fact, based upon my solution to their standard candidate puzzle, and my results on a BrainBench exam, there's already a company that would more or less allow me to name my price.

The dithering point comes in when I consider the other aspects of work.  Apart from this aberrant management hiccup, my current company is an astoundingly good place to work.  I've never even heard of a company that does 30 vacation days a year, plus 15% contribution to 401(k), plus annual bonus, plus actual meaningful stock options.  So leaving here is a huge door to close.

Peteinct, you're right that it's good to stretch beyond one's boundaries and expand one's capabilities.  The thing that's bothering me is responsibility without authority (because if I can't enforce my decisions, but I can be held accountable if they fail, I'm in a bad place).  Also, being put into an architect position now, after the system is as old (and therefore inertial) as it is, is not unlike being handed one Captain's Hat (slightly used) with the words "Exxon Valdez" on the brim, about 30 seconds after that ominous crunching sound from the forward hold.

Newt, the idea that everyone rises to the level of his or her own incompetency is what I was referring to in my thread title.

My father was a brave man; when he was a young salesman, he performed so well that he was promoted to manager.  And after giving it a try, he saw that he would never be as good a manager as he could be a salesman, so he demoted himself to salesman again.

-BP

[Tallpine]

Actually, I rather sort of enjoy being a "system architect" - at least when you can start from the foundation up, not when you're adding rooms onto a rambling house that no longer suits the needs and really needs to be torn down and rebuilt from scratch.

SW ... My solution for the "user interface" issue is to design the UI and the actual operating portion of the s/w as two (or more) separate components.  The UI is "dumb" in that it really doesn't know how to do anything but it just displays or accepts input of data that it receives or passes on from/to the working components.  That way if someone wants to change the interface then it is a relatively simple process.  I call it the dashboard and the engine - you don't have to design a new engine just to change the layout of the dashboard.