How to deal with co-workers who say that I don't trust them?

Question

So we're working on a work process automation project. Basically our company is going to procure a machine and substitute the current manual process to be automatic. Obviously, this project has a success criteria in which the automated system should generate savings to the company. Long story short, that savings could only be generated if the speed of the machine reaches certain number.

I've been thinking what should we track on the performance related variables, and I propose all those in the team meeting.

During the meeting, one member said this to me:

"Why does it have to be this detailed? We have this proven in other sites already. By doing this it seems like you have no trust on us"

They said its too detailed because I set success criteria for each feature of this machine, not only the overall speed of it. To me, it seems like they think I'm being too controlling, while I'm not because all this is actually needed and crucial data to determine which process is too slow and should be improved. I'm not exactly being strict on the target for each feature, but I'm pointing out that it should be at least tracked.

That "other sites" is sites which is not owned by our company. This team consisted of a multi-company worker, simply put, I'm working with a selected vendor/provider company to do a project in my company, and we discuss together what is the success criteria. So this machine is already being operated, they have historical data of its operation, but it is not tested on our site. It is necessary to have that as a primary data, meaning it is tested here, not outside.

That step to determine the success criteria is a company rule, so we need to get agreement on that from both sides.

Did I do something wrong? I've tried saying that this is company rule, but he keeps repeating the same argument that it is already being implemented in other place and it works.

My question is now more about the approach of responding to their claim of me not trusting them enough so that our team work can still run smoothly without any clash like this between team members

NOTE:

The performance number here is an application related performance, not meeting milestone deadlines etc.

Machine here is a production line machine.

Answer 1

OP had made significant edits to the question, so this answer may no longer apply.

Obviously, this project has a success criteria. I've been thinking what should we track on the performance related variables, and I propose all those in the team meeting.

If you have success criteria (which were presumably defined by the end customer/consumer, rather than yourself) which include performance metrics, then all you really need to say is "one of the acceptance criteria for this project is that it meets $FOO performance metric, so we need to start measuring that to make sure it does".

If you don't have any defined metrics, then how are you deciding which things to track? Benchmarking applications in a meaningful way is difficult, and if you just make up some arbitrary metrics (such as X transactions per second, or that a operation must take no more than X seconds) then they're probably going to be completely inappropriate.

Benchmarks on a development environment (which usually has less hardware/resources, and may have features like more verbose logging enabled) are usually not representative of the production deployment, so you need to think about how to deal with that.

You also can't just ask a question like "How many transactions per second can your application handle?", because the answer from any half-competent developer will always be "it depends", especially if they've not even finished developing the application yet.

You also need to consider that it's very easy to cheat on artificial metrics and benchmarks - companies like Nvidia and Intel have a history of doing this. It can also encourage bad practices from your developers (such as not performing proper data checks and validation to speed things up), which is the last thing that you want.

Ultimately, you need to be able to explain properly to them exactly what it is that you're wanting to measure, and why you think it's worth measuring. And then bear in mind that if these metrics actually matter (such as being linked to their pay, or the acceptance of the project), then they will be able to find ways to cheat them.

Answer 2

I think you need to take a step back, and approach the conversation as a collaboration.

They said its too detailed because I set success criteria for each feature of this machine, not only the overall speed of it.

From this sentence, it sounds to me like the metric that actually matters is the 'overall speed'. It also sounds like you don't think they have a problem with tracking that metric. That feels like a sensible starting point where everyone agrees, and from where you can work on adding more detail, if it's required.

My guess is that - to the team member(s) - it feels like you've started from there, and with an assumption that you won't meet that criteria, you've gone away and come up with a whole solution about how to deal with the fact that you haven't hit that criteria, before you've even started. If that's correct, it's hardly surprising that they don't feel trusted.

Additionally, and assuming that you're either non-technical or at least not as clued-up on the details of the device as the rest of the team, it's very likely that you've inadvertently asked for some metrics that are either difficult to gather, or will give confusing results that don't actually achieve the goal you have in mind. That will feel to the team like they've got to put in a whole load of work that either won't be necessary, won't achieve what you hope for and/or will actually harm the efforts to get the performance to where it needs to be. Possibly they also worry that once they've collected these numbers, there will then be an even greater effort involved in explaining to you and/or other management-types what the numbers actually mean. Any of that could explain their references to the metrics being too detailed.

I'd suggest taking a step back, being a bit humble and apologising for the implication that you don't trust the team (even if you don't think you did imply it, they've taken your words that way). Then ask if you can work together to find the main metric that defines success, but also - if possible - any intermediary numbers that aren't too difficult to gather, and that might be helpful just in case there are any bottlenecks. Be open to the idea that gathering those numbers might be difficult enough that it's not worth expending the effort up-front, at least not until you've discovered that there's a problem.

Answer 3

Not having a software background, I'm going to address this from the "machine" point of view.

I've been thinking what should we track on the performance related variables....

Yes, this is a good idea.

They said its too detailed because I set success criteria for each feature of this machine, not only the overall speed of it.

Yes, your coworkers are correct also. I think their concern was poorly articulated by calling it a lack of trust, but it is true that you need to let your teams each make the call on the various engineering trade-offs in their respective areas.

Why are you trying to get into the middle of the process? Your true performance is only what comes out the end. Getting into the middle of things will not help.

It sounds like you are in a in role where you should be looking at this from the top-level point of view. There are really three things you should be looking at from a systems engineering point of view:

1. Cost
2. Schedule
3. Performance

I'm going to focus on the performance aspect, because that seems to be the topic of the question.

Let's pretend you are buying a sausage making machine, and the team in charge of developing the feed screws is feeling like you micromanage them. Ask yourself: if you are buying a sausage making machine, what do you care about? You do not want to see how the sausage is made. You really only care about the quantity and quality of the sausage, right? Why would you care about the minutiae? You should not.

You should not care about the material of the screws, or the RPM they run at. You should however require that the screw development team produce a certain quantity of ground meat per unit time. If the first design iteration does not perform to spec, leave it to the screw team to figure out the best fix. What's the best fix--more screws? bigger diameter? faster? Leave it to them. Delegate it! You only care about the results.

One scenario where you might be tempted to get into the middle of the process and start micromanaging is the case where you do not have good inspection/metrics/QA/QC/validation/verification. If you have no way to measure the quantity or quality of your sausage, you might be tempted to get into the screw development team's knickers. Don't do that. Instead, fix the root cause instead--buy a scale or a fat-o-meter or flavor-meter (I made those up). Buy whatever inspection equipment is necessary to allow you to take a step back and allow the individual teams to do their thing without micromanagement.

And when you are thinking of performance criteria, don't forget about the boring stuff. How much square footage will the machine require? What kind of power source? How many cubic feet per minute (CFM) of compressed air will this machine suck down? Are you going to have to buy a new $20k air compressor? Is it going to heat up your building so much you need a bigger air conditioner? Are three full-time operators required? Does it need internet access? etc. etc. etc.

Answer 4

Due to edited questions and comments on OPs question this answer does no longer refer to the question!

I still let the answer here for people who might initially think this question is about employee performance numbers.

Many developers like to feel "free" and have some control. And that is what they usually get and are used to.

So if they worked, lets say 5 years, without or with less tracking they might feel personally attacked. Like there is something wrong with their work and now you have to monitor them.

Try to find a middle ground and show the team that you and the PM trust them but that some numbers are required. They wont love it, but you need to clarify that it is not the teams "fault".

On a sidenote:

As a developer myself, I HATE "performance numbers", because development is really hard to put into numbers. There might be days without any code written and it was 10 times more productive than the day before when 1000 lines were written. The only numbers I could think of are deadline dates and how many of those are met or daily tasks and how many of them are met.

Even that is hard to do, sometimes there are some problems no one could've forseen and things get delayed. Requests change, bugs occur, tech evolves, unplanned issues (like not thinking about IE or that 450px phone) and so on. If you then get pressured because you didnt meet some numbers, you get stressed and annoyed and that could lead to sloppy code.

So do you really need those numbers?

In my personal experience meeting more numbers usually means writing worse code ("at least it works"). Depending on project size a deadline is sometimes enough. The best and most maintainable code I have written in my life were on projects with a small team (<=5) and with no deadline at all. I had the time to think about the code, the future and write good documentation.