Although IANAL, I can tell you that UK law is strongly protective of the employee in such cases. As a principle of anti-slavery you cannot force someone to do anything. In particular, you cannot effectively force them to work for you by blocking them from other companies in their skill area (and so leaving your company as the only option).
To get round this you can draw up contract, agreed/signed by mutual consent, but the principle of a contract involves "consideration". In other words, both parties have to get something out of it. So for example you cannot require someone to avoid competitors unless they get something in return --- e.g. you pay them.
Trade secrets are related. An employee cannot take trade secrets to another employer but they can certainly take any skills they learned. The difference between the two is of course blurred, but the principle is that you cannot be prevented from using skills which are now part of you as distinct from part of the former employer.
When a client buys a product from Company X, they buy more than just the product. They buy into Company X itself. They ask "Can we do business with these folks? Do we like them? Do we trust them? Are they our kind of people?" They go by gut instinct as much as anything else, and so you must learn this lesson in business: People buy people.
I understand your frustration that you see things going badly and want to do a better job, but knowing the details of developers' work is not the answer.
The best project manager I ever worked with knew nothing about the details. It was in the early days of the Web, building a very complex Web site for a client, and he barely knew how to write HTML. But here's why he was a great PM: He trusted his team, including the technical lead, he understood the people and knew how to get them to work well together, and he knew the importance of high level issues like testing, clear specifications and change control. He was a good *manager*.
And here's another key to success: strong sales people. Good sales people will get the right cost estimates from the developers/consultants, and then won't buckle under pressure when they present those to the client. Then you actually have time to do the testing which was factored into the proposal.
I was a very technical project manager, not quite a developer, but I like to think I understood the tech details very well and got on well with my various teams. But I would regularly get bogged down in the details simply because I enjoyed them, and as a result would spend less time on the strategic issues like persuading the client that they should reconsider their latest idea. I think I did well, but I know I could have done better.
My advice to you is this: talk to your project managers and sales people, and get them to understand the importance of the various stages of work. Show them that a slip early on can lead to more costly slips later. Advise them, and get them to trust you, so that when you say "We need to spend two weeks testing" they make sure you get that two weeks and don't think "Oh, but I'm sure we can get away with a couple of days".
As for progress in your career, project management is a lot about people and little about knowing obscure technical details. If it's people you want to focus on, then great. Otherwise perhaps you should aim for being a senior architect. And then your company can charge more for your time, and they'll have even more budget to spend on testing!
...there is no hope for children. Their "PDA" will become a veritable Game Boy in a short amount of time.
Too right! Kids shouldn't be playing games,
they should be creating balance sheets for their
pocket money and word processing their weekly
"What I did at the weekend" memos. I gave a PowerPoint presentation on this issue when I was four.
Slashdot Mirror
Although IANAL, I can tell you that UK law is strongly protective of the employee in such cases. As a principle of anti-slavery you cannot force someone to do anything. In particular, you cannot effectively force them to work for you by blocking them from other companies in their skill area (and so leaving your company as the only option).
To get round this you can draw up contract, agreed/signed by mutual consent, but the principle of a contract involves "consideration". In other words, both parties have to get something out of it. So for example you cannot require someone to avoid competitors unless they get something in return --- e.g. you pay them.
Trade secrets are related. An employee cannot take trade secrets to another employer but they can certainly take any skills they learned. The difference between the two is of course blurred, but the principle is that you cannot be prevented from using skills which are now part of you as distinct from part of the former employer.
When a client buys a product from Company X, they buy more than just the product. They buy into Company X itself. They ask "Can we do business with these folks? Do we like them? Do we trust them? Are they our kind of people?" They go by gut instinct as much as anything else, and so you must learn this lesson in business: People buy people.
I understand your frustration that you see things going badly and want to do a better job, but knowing the details of developers' work is not the answer.
The best project manager I ever worked with knew nothing about the details. It was in the early days of the Web, building a very complex Web site for a client, and he barely knew how to write HTML. But here's why he was a great PM: He trusted his team, including the technical lead, he understood the people and knew how to get them to work well together, and he knew the importance of high level issues like testing, clear specifications and change control. He was a good *manager*.
And here's another key to success: strong sales people. Good sales people will get the right cost estimates from the developers/consultants, and then won't buckle under pressure when they present those to the client. Then you actually have time to do the testing which was factored into the proposal.
I was a very technical project manager, not quite a developer, but I like to think I understood the tech details very well and got on well with my various teams. But I would regularly get bogged down in the details simply because I enjoyed them, and as a result would spend less time on the strategic issues like persuading the client that they should reconsider their latest idea. I think I did well, but I know I could have done better.
My advice to you is this: talk to your project managers and sales people, and get them to understand the importance of the various stages of work. Show them that a slip early on can lead to more costly slips later. Advise them, and get them to trust you, so that when you say "We need to spend two weeks testing" they make sure you get that two weeks and don't think "Oh, but I'm sure we can get away with a couple of days".
As for progress in your career, project management is a lot about people and little about knowing obscure technical details. If it's people you want to focus on, then great. Otherwise perhaps you should aim for being a senior architect. And then your company can charge more for your time, and they'll have even more budget to spend on testing!
Too right! Kids shouldn't be playing games, they should be creating balance sheets for their pocket money and word processing their weekly "What I did at the weekend" memos. I gave a PowerPoint presentation on this issue when I was four.