3 ms·

I worked with this guy for quite a while who I used to supervise as a developer, being a bit tired of his incompetence but seeing that he still had an interest

I worked with this guy for quite a while who I used to supervise as a developer, being a bit tired of his incompetence but seeing that he still had an interest in helping out, he and I suggested to my bosses that he be reassigned to a position that might fit his profile a bit better. Shortly after, the guy was made systems architect, without my prior knowledge (I was still in charge of devs). I pointed out that while a less hands-on position might be better suited, what he was doing clearly had nothing to do with being a systems architect (in no small part because I was the one taking care of that, if given the time). My bosses and said guy agreed and decided to make him a "business systems analyst". As of today I'm still not completely sure what that position entails. The basic idea, I was told, was that he would discuss and gather requirements from clients, then turn them into a useful set of documents and clear explanations. And this is where this article particularly hit the nail. Not once did this "business systems analyst" produce a valuable document. While he was attending meeting after meeting, going to conferences around the globe to supposedly learn about products he had literally no technical knowledge of, I wondered more and more what his value to the company might have been. He essentially created, with my bosses' blessing and encouragement, a whole confusing layer in the development process. He made a lot of noise, produced extremely confusing (and poorly written) documents turning basic client requirements into any developer's worst nightmare, readily passing the blame around without ever putting his position in the balance. Missed deadlines would be the PM's fault, an incorrect feature would be a developer's mistake, a misunderstood requirement would be the client's fault, and the list goes on. Each and every single project he touches simply becomes an absolute bane, but the amount of fuss generated through useless emails, delayed replies and inconsequential yet time-consuming nitpicking, has my bosses falling head over heels for him. Long story short, four valuable people (including myself) have left the company, and the guy is now "business systems director" (I did not make this up) and is on the board. This is both a sad and terrifying state of affairs...

frozenport 13y ago
I frequently hear this and have experienced it myself. The immediate solution is that this guy should have been sent to the sales department instead of given authority.
sanderjd 13y ago
Counterpoint: we had a whole team of people seeming to fit your description, and I thought they were one of the most useful parts of our process. They mostly did sales support and product management, while also supporting and working closely with project managers. I suspect a lot of developers thought they were useless and over-promoted, but they weren't, their value was just not obvious to the developers. Now, you seem like you were in a good position to judge whether or not the guy you're talking about was actually useful, so it's likely that I just worked with a team that was good at this job, and you worked with one that wasn't, but (IMO) technical people are often too quick to judge the non- and only-partially- technical roles in the organization as being less useful than they really are. Oh, also, if anybody's job is "produce documents", rather than "gain knowledge that can be communicated synchronously through conversation or asynchronously through text" then that's probably a smell. All those meetings after meetings are about the information, not the documentation.
- marktangotango 13y ago
  My current boss fits this mold, he has a development background, and I don't know if he can code or not, but when it comes to technical and/or architectural concerns, he 'gets' it, and he's a presenting, selling, webinar fiend. He frequently impresses the hell out of me by simplifying complex requirements down to the basics and saying 'if you guys can get me this subset, that will satisfy most of the costomers/prospects' or 'all I need is this simple subset for most of the reporting requirements'. This dude is Gold.
  - mark_integerdsv 13y ago
    Thanks so much for posting this. I am similar to the guy you describe. Background in development but been in analysis for a while now... I kept seeing myself in the descriptions of cretins in this thread while looking for a post like yours. It's not just about functions and classes. A lot of what happens around actual code is also very important. Specifically where it reduces the amount of code that needs to be written which directly impacts quality.

frozenport 13y ago

I frequently hear this and have experienced it myself. The immediate solution is that this guy should have been sent to the sales department instead of given authority.

sanderjd 13y ago

Counterpoint: we had a whole team of people seeming to fit your description, and I thought they were one of the most useful parts of our process. They mostly did sales support and product management, while also supporting and working closely with project managers. I suspect a lot of developers thought they were useless and over-promoted, but they weren't, their value was just not obvious to the developers. Now, you seem like you were in a good position to judge whether or not the guy you're talking about was actually useful, so it's likely that I just worked with a team that was good at this job, and you worked with one that wasn't, but (IMO) technical people are often too quick to judge the non- and only-partially- technical roles in the organization as being less useful than they really are. Oh, also, if anybody's job is "produce documents", rather than "gain knowledge that can be communicated synchronously through conversation or asynchronously through text" then that's probably a smell. All those meetings after meetings are about the information, not the documentation.

marktangotango 13y ago
My current boss fits this mold, he has a development background, and I don't know if he can code or not, but when it comes to technical and/or architectural concerns, he 'gets' it, and he's a presenting, selling, webinar fiend. He frequently impresses the hell out of me by simplifying complex requirements down to the basics and saying 'if you guys can get me this subset, that will satisfy most of the costomers/prospects' or 'all I need is this simple subset for most of the reporting requirements'. This dude is Gold.
- mark_integerdsv 13y ago
  Thanks so much for posting this. I am similar to the guy you describe. Background in development but been in analysis for a while now... I kept seeing myself in the descriptions of cretins in this thread while looking for a post like yours. It's not just about functions and classes. A lot of what happens around actual code is also very important. Specifically where it reduces the amount of code that needs to be written which directly impacts quality.