Hiring the wrong people
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
ed welch wrote:
Supposing you want to put together a small development team, who would you hire?
Lots of sales and marketing people. And managers. ;)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
I used to work for a company where I was the project manager for our internal projects. We had a DB team, a data layer tem and a graphics team. Since my background is computer science, I could meet with the 'clients' and have a better idea of what we could/could not do. I called it being bilingual. I could talk the business talk but communicate it in 'geek speak' through documentation. The only problem I ever really had was this one inexperienced programmer who just said, 'it can't be done' to everything. When I asked why he wouldn't explain. He just didn't want to bother to learn which I thought was odd since he was new (you think he would want to learn). Each group had their own leader who also represented the group in team meetings. My last job was awful. Basically one guy who taught himself (no problem with that) but built bad code ontop of bad code. It was impossible to develop the project further.
__________________ Bob is my homeboy.
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
ed welch wrote:
The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything.
speaking of myths.... :) this is one of my nightmares. Even in a 2 year development project (let alone that I am now going on 13 years for this one project), the idea that you can always predict everything in design and then the programmers can just be grunts following orders without any ability to think for themselves.... you don't have to sign on to an agile concept to realize that even the best design will change during the process of actually writing the code. And forseeing the future is a very difficult job. Of course, if the manager and designer can successfully and accurately predict the future as well as design to it, sure they deserves a bigger check.... but otherwise, get some really good developers that can recognize and adapt to changing needs, its better in the long run. Just my 2 cents for what they are worth.... actually, what you later described is nearly our company. Though senior and junior developers will do design, I asked for and was granted the request that designs must be paired. Even if the two junior developers do a design, that means they agree on process, and with peer-design-review the senior developers get a word in (or often more, not that I am wordy, I just always say more than is needed... ;) ). :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
ed welch wrote:
Supposing you want to put together a small development team, who would you hire?
Lots of sales and marketing people. And managers. ;)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
and some PR and HR!
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
-
and some PR and HR!
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
How foolish of me. I also forgot the really pretty receptionist.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
How foolish of me. I also forgot the really pretty receptionist.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
someone to file all the TPS reports
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
Well, I once worked on a team that had more business analysts then developers. They spent their time meeting with people making up projects to justify their existence even though they had no chance of getting built.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
I used to work for a company where I was the project manager for our internal projects. We had a DB team, a data layer tem and a graphics team. Since my background is computer science, I could meet with the 'clients' and have a better idea of what we could/could not do. I called it being bilingual. I could talk the business talk but communicate it in 'geek speak' through documentation. The only problem I ever really had was this one inexperienced programmer who just said, 'it can't be done' to everything. When I asked why he wouldn't explain. He just didn't want to bother to learn which I thought was odd since he was new (you think he would want to learn). Each group had their own leader who also represented the group in team meetings. My last job was awful. Basically one guy who taught himself (no problem with that) but built bad code ontop of bad code. It was impossible to develop the project further.
__________________ Bob is my homeboy.
Seems like old love story! :rolleyes: :rolleyes: :rolleyes: :rolleyes:
--------------------------- Life is a game... with limited life line and unlimited power! http://www.idlsol.com
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
Just follow the 7 steps of software development. 1. Analyze (What it is that you're gonna make. All aspects of it + Near future features). 2. Design (How things should be done to ensure speed / reliability & security). 3. Setup (Workflow control / Crisis handling / Communication channels / Hierarchy). 4. Equip (Buy the tools / Build the required testing structure / setup the entire dev proccess). 5. Develop (Build the damn thing). 6. Test (In house testing, Limited public beta testing, bug fixes, ... etc) 7. Release (Marketting, release, website, ... etc) ----------- ANALYZE This is done by the Marketting people, Sales reps. The Lead programmer (tech superv) only speaks to set the limits on features just so the non-ITs don't go asking for Star-Trek things like teleportation and such ... DESIGN Lead technical manager + All development staff (the heads anyway). This includes Network / Internet / Hardware / Databases / Programming ... etc. SETUP !!!! Lead technical manager + Project manager + Department heads (if any). Make sure you define the Who/What/How/When variables. What must be done during development, by Whom, How and When. It's also very crucial to have a procedure to handle crisis such as errors, failures, data loss, member resignations, ... etc. If a company already exists and works, this scheme is more or less defined already. However, it never hurts to refine things once and a while. EQUIP Lead technical manager + All development staff. Define the best technologies suitable in oder to LIMIT THE TIME !!!! Buy or build the infrastracture to test / data entry / deploy the application during development. This is MOST IMPORTANT as it's a major time eater. DEVELOP If design / setup / equip stages are all cleared up, this proccess is fairly straight forward. TEST & RELEASE Sorry, this is not my field. I'm only an IT person .... :) ---------------------- Bottom line is that you get the required people of the required skills, to cover all those stages. Some companies prefer to hire just before each phase but regardless, you'll most certainly need the guy that has the original ide/concept, a skilled Technical manager and of course the project manager (who ONLY OBSERVES & SUGGESTS by the way) to draw the limits on what & how it can be done !!!
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
I'd still want a non-techy paper-wrangler for all the crap that gets thrown around that developers are crap at handling. Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food. You need people to keep the coffee machine stocked. They do their job, you do your job. (I have long disliked the disrespect developers give everyone else in a company. They think they are the only people who matter when really they are part of the chain of business. Managers need to let developers do what they do best but developers need to leave managers to do what they do best.)
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
Well, I once worked on a team that had more business analysts then developers. They spent their time meeting with people making up projects to justify their existence even though they had no chance of getting built.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
ed welch wrote:
The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything.
speaking of myths.... :) this is one of my nightmares. Even in a 2 year development project (let alone that I am now going on 13 years for this one project), the idea that you can always predict everything in design and then the programmers can just be grunts following orders without any ability to think for themselves.... you don't have to sign on to an agile concept to realize that even the best design will change during the process of actually writing the code. And forseeing the future is a very difficult job. Of course, if the manager and designer can successfully and accurately predict the future as well as design to it, sure they deserves a bigger check.... but otherwise, get some really good developers that can recognize and adapt to changing needs, its better in the long run. Just my 2 cents for what they are worth.... actually, what you later described is nearly our company. Though senior and junior developers will do design, I asked for and was granted the request that designs must be paired. Even if the two junior developers do a design, that means they agree on process, and with peer-design-review the senior developers get a word in (or often more, not that I am wordy, I just always say more than is needed... ;) ). :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
That's a common misconception of the word 'Design'. It's not like every bit of information is written down on paper. Design refers to the way all parts of the application will interact with each other so when 2 pieces of code written from 2 different people come together, they work (with minimum adjustment if needed). If 'Design' covers GUI, Database, Network communication, Graphics, Data entry, Validation, Security, .... then the only thing programmers (Grunts) have to look out for is NOT to violate those rules, leaving them of plenty of freedom to write code / implement things the way they want.
-
someone to file all the TPS reports
-
I'd still want a non-techy paper-wrangler for all the crap that gets thrown around that developers are crap at handling. Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food. You need people to keep the coffee machine stocked. They do their job, you do your job. (I have long disliked the disrespect developers give everyone else in a company. They think they are the only people who matter when really they are part of the chain of business. Managers need to let developers do what they do best but developers need to leave managers to do what they do best.)
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
Paul Watson wrote:
Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food.
I disagree. These are things that require no specialist skill and anyone in the team can do them - remember this is a small project we're talking about. If there is enough of this type of work to keep one person busy 100% of the time, then that position is justified. But, why can't a developer buy a chair, that's just ridiculous?
-
Paul Watson wrote:
Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food.
I disagree. These are things that require no specialist skill and anyone in the team can do them - remember this is a small project we're talking about. If there is enough of this type of work to keep one person busy 100% of the time, then that position is justified. But, why can't a developer buy a chair, that's just ridiculous?
OK. A team of five developers in an office situation: - 5 desks - 5 sets of drawers - 5 chairs - Adequate space for 5 people - 5 computers - 5 network points - 5 monthly salaries - Office insurance for 5 people - 5 power points with plug boards - Water supply - Coffee supply - 5 contracts with yearly reviews - 2-4 waste bins - Waste collection service - Adequate electricity - Heating in winter, cooling in summer - Security for the office with 24/7 access - 5 income tax forms - Many, many more business tax forms - Adequate servers with offsite backup - Internet access - Cleaner service (carpets, chairs, desks, windows etc.) - Legal resource for disputes - Stationery supply - Domain setup and renewal - Business funds account with auditing - Bathroom facilities - Someone as the fire warden - Annual office safety and access checks - Someone to answer the phone - Someone to accept deliveries - Someone to send deliveries - Replacement contracts for equipment so that e.g. a failed screen doesn't delay work - Someone to make travel arrangements (flights, hotels, visas, rent a car etc.) You can "just buy a chair" but when it breaks and you have to sit on a cardboard box for three days because you don't want to use your own money to buy a new chair and you have no business process... well, its not just a chair. There is a reason good technology companies have a wall of non-techy people. They are there to deal with all the bits of life that we techies would rather not be bothered with. Some of it we could possibly do ourselves but to supply a team of even just 5 people on even a small project takes an efficient and knowledgeable administrator. I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday. The HR girl sitting a floor above me keeps so much crap away from me it is unbelievable. She lets me get on with my job. Without her I'd be spending half of everyday dealing with admin instead of coding.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
OK. A team of five developers in an office situation: - 5 desks - 5 sets of drawers - 5 chairs - Adequate space for 5 people - 5 computers - 5 network points - 5 monthly salaries - Office insurance for 5 people - 5 power points with plug boards - Water supply - Coffee supply - 5 contracts with yearly reviews - 2-4 waste bins - Waste collection service - Adequate electricity - Heating in winter, cooling in summer - Security for the office with 24/7 access - 5 income tax forms - Many, many more business tax forms - Adequate servers with offsite backup - Internet access - Cleaner service (carpets, chairs, desks, windows etc.) - Legal resource for disputes - Stationery supply - Domain setup and renewal - Business funds account with auditing - Bathroom facilities - Someone as the fire warden - Annual office safety and access checks - Someone to answer the phone - Someone to accept deliveries - Someone to send deliveries - Replacement contracts for equipment so that e.g. a failed screen doesn't delay work - Someone to make travel arrangements (flights, hotels, visas, rent a car etc.) You can "just buy a chair" but when it breaks and you have to sit on a cardboard box for three days because you don't want to use your own money to buy a new chair and you have no business process... well, its not just a chair. There is a reason good technology companies have a wall of non-techy people. They are there to deal with all the bits of life that we techies would rather not be bothered with. Some of it we could possibly do ourselves but to supply a team of even just 5 people on even a small project takes an efficient and knowledgeable administrator. I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday. The HR girl sitting a floor above me keeps so much crap away from me it is unbelievable. She lets me get on with my job. Without her I'd be spending half of everyday dealing with admin instead of coding.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
"I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday." No, they're not. All I said was that they are general skills that anyone can do. and, I did say if there is enough of this type of work to keep one person busy 100% of the time, then that position is justified.
-
"I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday." No, they're not. All I said was that they are general skills that anyone can do. and, I did say if there is enough of this type of work to keep one person busy 100% of the time, then that position is justified.
ed welch wrote:
No, they're not. All I said was that they are general skills that anyone can do.
Sure, with training and education and experience. Much like most of programming.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
ed welch wrote:
No, they're not. All I said was that they are general skills that anyone can do.
Sure, with training and education and experience. Much like most of programming.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
You don't need one to programme.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...