--- title: "The Right People For The Right Job" url: "https://osherove.com/blog/2003/5/23/the-right-people-for-the-right-job.md" canonical: "https://osherove.com/blog/2003/5/23/the-right-people-for-the-right-job.html" published: "2003-05-23T12:27:00" updated: "2003-05-23T12:27:00" tags: ["Off Topic"] author: "Roy Osherove" description: "I recently met with a friend of mine, also a programmer. After sharing the usual “war stories” he mentioned some things about his project manager/Team Leader that made us both go into a long conversation about IT roles…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Right People For The Right Job By Roy Osherove May 23, 2003 In [Off Topic](https://osherove.com/blog/category/off-topic) **Historical article** · Originally published May 23, 2003; technical details may be outdated. I recently met with a friend of mine, also a programmer.  After sharing the usual “war stories” he mentioned some things about his project manager/Team Leader that made us both go into a long conversation about IT roles and the right people for the job. He kept ranting about his PM not being as qualified as he would have liked. This person was usually out of the office, unreachable. When he was in the office, he would give bad advice, or change his mind frequently. The outcome of this PM’s behaviour was that his team did not perform very well. It turns out that my friend was the “unproclaimed” leader of his team, filling in for the roles of the missing PM. **He** would be asked all the questions, **he** was the one everyone turned to when they needed anything. It occurred to me that the problem here was much deeper then just a lousy PM. The real problem here is that companies don’t (usually) put a person for a particular job because of his/her abilities (or lack there of) but because that person was just there at the right place at the right time. This is much more apparent at small companies or start-ups, in which several roles must be performed by one person. In a company I know, for example, the same people who program also do the QA’s job, since they have no QA department. This of course, sucks. No one can objectively test their own output. But they have to, so they do it. The problem gets worse when you assign a person to a role which is very far from their particular field. Putting a programmer as a marketing guy can have some horrendous results to a company, yet that same company does exactly that. That PM which my friend mentioned, seems to be the result of exactly this deadly cocktail of company needs and unprofessional task assignment. I don’t know just how prevalent this is abroad, but in Israel it seems to be a pretty common practice.  Of course, you could argue that giving a person a task with significant responsibility can motivate that person and push his/her abilities forward. Rubbish. There’s a difference between trying to push your workers towards excelling in multiple areas and between using your resources unprofessionally and hiding behind a warn-out excuse. If that worker takes that role and makes something out of it – it’s pure luck. Management had nothing to do with it. It could just as easily have gone the other way around, at which part that same worker would be accused of doing their job unprofessionally. I see companies doing this all the time. It makes me feel queasy.    ## More in Off Topic [All posts in Off Topic](https://osherove.com/blog/category/off-topic) - May 25, 2003 ### [Work, work, work....](https://osherove.com/blog/2003/5/25/work-work-work.html) - May 24, 2003 ### [Random Thought](https://osherove.com/blog/2003/5/24/random-thought.html) - May 21, 2003 ### [Assorted News](https://osherove.com/blog/2003/5/21/assorted-news.html) - May 20, 2003 ### [I'm In!](https://osherove.com/blog/2003/5/20/im-in.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/