IT team dynamics
Discussion
There is an interesting difference in views between 2 members (call them A and B) of a small IT team in my office.
For example:
Given a tested and working program to run as a one off data setup. A wanted it modified in the hope of making it more efficient, B argues that since it is going to run through in a few seconds at a time nothing else is running on the system spending time modifying and retesting would not be a good use of resources.
A suggested adding additional functions to a new application on the basis that even though not requested they might come in handy and this is a good way to 'over deliver'. B pointed out that the whole point of this application is to reduce the number of key presses and screens the user has to go through to get through her work, so adding complication would be under delivering not over delivering.
Typical dispute between a techie and a manager, except in this case B is the techie and A is the manager.
Is my experience unusual, or are these disputes usually the other way round?
For example:
Given a tested and working program to run as a one off data setup. A wanted it modified in the hope of making it more efficient, B argues that since it is going to run through in a few seconds at a time nothing else is running on the system spending time modifying and retesting would not be a good use of resources.
A suggested adding additional functions to a new application on the basis that even though not requested they might come in handy and this is a good way to 'over deliver'. B pointed out that the whole point of this application is to reduce the number of key presses and screens the user has to go through to get through her work, so adding complication would be under delivering not over delivering.
Typical dispute between a techie and a manager, except in this case B is the techie and A is the manager.
Is my experience unusual, or are these disputes usually the other way round?
B sounds like he is speaking from experience - as the i devices have demonstrated, users want clean, simple to use apps with no additional frippery that other people think they might need
From a support perspective, more complex is more expensive, so in the long run your over delivery costs you
From a support perspective, more complex is more expensive, so in the long run your over delivery costs you
Dr Jekyll said:
Typical dispute between a techie and a manager, except in this case B is the techie and A is the manager.
Is my experience unusual, or are these disputes usually the other way round?
I thought it was unusual at first, and then realised that earlier on in my career I was said techie and often got 'managed' in just that way!...Is my experience unusual, or are these disputes usually the other way round?
It can be common for such managers to think it's all about 'encouraging' the techie to create a 'better gadget' rather than a usable, reliable package, and thus lose sight of the ultimate goal, especially when they don't really understand the down-sides to 'playing' in such a way.
My advice to A) would be to understand the bigger picture (and/ or get a proper education in how to manage & deliver IT projects) and to B)to either put up with it or focus on stating his case more (no matter how good he already is at that, there's always more skills to be had in terms of influencing such people!
Based on the information given I completely agree with B here and it's not as uncommon as you think for the developer to push back.
B is trying to avoid two well known anti-patterns::
B is trying to avoid two well known anti-patterns::
- Premature Optimisation : Yes you could make the task faster, but you probably don't need to. http://c2.com/cgi/wiki?PrematureOptimization
- Feature Creep : Build what the users have asked for, not what you think they want as you will normally be wrong http://en.wikipedia.org/wiki/Feature_creep
If the techie did their job efficiently in say 10% of the time, would the consequences be the manager's team would shrink and their status in the organisation be diminished?
If this is the case, the fault is with senior management and how they set the goals for the manager and reward them.
If this is the case, the fault is with senior management and how they set the goals for the manager and reward them.
cornet said:
Based on the information given I completely agree with B here and it's not as uncommon as you think for the developer to push back.
B is trying to avoid two well known anti-patterns::
I couldn't have put it better myself. Regarding the implementation of un-requested features - these may never be used but have an ongoing cost, both in terms of added code complexity for the programmer(s) to understand, and future maintenance.B is trying to avoid two well known anti-patterns::
- Premature Optimisation : Yes you could make the task faster, but you probably don't need to. http://c2.com/cgi/wiki?PrematureOptimization
- Feature Creep : Build what the users have asked for, not what you think they want as you will normally be wrong http://en.wikipedia.org/wiki/Feature_creep
(A) sounds clueless from the OP's brief description.
Dr Jekyll said:
I agree that B is right, what's interesting is that it's the manager who is complicating the technicalities unnecessarily and the techie who sees the big picture.
Happens all the time. Normally when the manager either lacks understanding/experience or is receiving lots of pressure from people further up the ranks.Dr Jekyll said:
There is an interesting difference in views between 2 members (call them A and B) of a small IT team in my office.
For example:
Given a tested and working program to run as a one off data setup. A wanted it modified in the hope of making it more efficient, B argues that since it is going to run through in a few seconds at a time nothing else is running on the system spending time modifying and retesting would not be a good use of resources.
A suggested adding additional functions to a new application on the basis that even though not requested they might come in handy and this is a good way to 'over deliver'. B pointed out that the whole point of this application is to reduce the number of key presses and screens the user has to go through to get through her work, so adding complication would be under delivering not over delivering.
Typical dispute between a techie and a manager, except in this case B is the techie and A is the manager.
Is my experience unusual, or are these disputes usually the other way round?
Imo - I don't think its that unusual a situation - and in fact its far from been an issue with IT only.For example:
Given a tested and working program to run as a one off data setup. A wanted it modified in the hope of making it more efficient, B argues that since it is going to run through in a few seconds at a time nothing else is running on the system spending time modifying and retesting would not be a good use of resources.
A suggested adding additional functions to a new application on the basis that even though not requested they might come in handy and this is a good way to 'over deliver'. B pointed out that the whole point of this application is to reduce the number of key presses and screens the user has to go through to get through her work, so adding complication would be under delivering not over delivering.
Typical dispute between a techie and a manager, except in this case B is the techie and A is the manager.
Is my experience unusual, or are these disputes usually the other way round?
Seen it myself a fair few times and I have myself found myself arguing the toss with a manager or 3 - as I tried to get the job done right.
Have to admit I have not always been right - but always tried to do the right thing - and was genuinely trying to move things in the right direction in terms of what I and the manager were looking to achieve.
My personal fave is when a manager says - right Sir Fergie - you decide how to do it - a judgement call is made - and manager disagrees with the decision made even thought there wasn't much wrong with the decision made under the circumstances - the manager just has to be the big man about it and remind Sir Fergie whose boss.
Like id forget who my manager was
.Sir Fergie
Here's a special little conversation I had this morning
a : 'we are moving the database from server x to server y to improve performance'
b : 'did server x catch fire or something? these problems have only existed a few days'
a : 'server y is new and faster. but no, we dont know why the database is slow. server x should be fine with it'
b : 'so, a bit of a gamble on whether it will fix it?'
a : 'no, I dont think so, youre going from a clapped out escort to a ferrari'
b : 'a clapped out escort with bad fuel in it to a ferrari with bad fuel in it?'
It all went a bit quiet at that point.... now I have the dead guys hologram from I Robot playing 'You must ask the right questions' in my head.
a : 'we are moving the database from server x to server y to improve performance'
b : 'did server x catch fire or something? these problems have only existed a few days'
a : 'server y is new and faster. but no, we dont know why the database is slow. server x should be fine with it'
b : 'so, a bit of a gamble on whether it will fix it?'
a : 'no, I dont think so, youre going from a clapped out escort to a ferrari'
b : 'a clapped out escort with bad fuel in it to a ferrari with bad fuel in it?'
It all went a bit quiet at that point.... now I have the dead guys hologram from I Robot playing 'You must ask the right questions' in my head.
Keep it simple. Don't introduce unnecessary features or functions that are not required. Don't close the door to those options in the future either though.
It sounds like A is trying to second guess the users without understanding either the requirements or the solution.
This is very common, management always try to over complicate matters. Technical staff prefer to keep it simple.
It sounds like A is trying to second guess the users without understanding either the requirements or the solution.
This is very common, management always try to over complicate matters. Technical staff prefer to keep it simple.
shouldbworking said:
Here's a special little conversation I had this morning
a : 'we are moving the database from server x to server y to improve performance'
b : 'did server x catch fire or something? these problems have only existed a few days'
a : 'server y is new and faster. but no, we dont know why the database is slow. server x should be fine with it'
b : 'so, a bit of a gamble on whether it will fix it?'
a : 'no, I dont think so, youre going from a clapped out escort to a ferrari'
b : 'a clapped out escort with bad fuel in it to a ferrari with bad fuel in it?'
It all went a bit quiet at that point.... now I have the dead guys hologram from I Robot playing 'You must ask the right questions' in my head.
First rule of IT is always don't fix it if it ain't broken. Moving a database onto a new server might also bring complications as you are moving onto a new environment.a : 'we are moving the database from server x to server y to improve performance'
b : 'did server x catch fire or something? these problems have only existed a few days'
a : 'server y is new and faster. but no, we dont know why the database is slow. server x should be fine with it'
b : 'so, a bit of a gamble on whether it will fix it?'
a : 'no, I dont think so, youre going from a clapped out escort to a ferrari'
b : 'a clapped out escort with bad fuel in it to a ferrari with bad fuel in it?'
It all went a bit quiet at that point.... now I have the dead guys hologram from I Robot playing 'You must ask the right questions' in my head.
If it's SQL I'd first look at the database itself.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff