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


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

Machine here is a production line machine.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Sep 28, 2021 at 23:37
  • 2
    Did you ask them back? "can you guarantee that we will not face issues because its followed else where Can you guarantee that there will be no surprises. Is it wrong to be on safe side?"
    – chendu
    Sep 29, 2021 at 5:15

4 Answers 4


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.

  • 10
    This answer his the nail on the head. If you start inventing arbitrary benchmarks for the sake of arbitrary benchmarks, of course people are going to get annoyed, and wonder why you're doing this. Sep 28, 2021 at 11:24
  • 6
    And worse, by optimizing the bogus benchmarks you negatively impact real performance.
    – Jon Custer
    Sep 28, 2021 at 13:32
  • 6
    Have I missed something that states that this "machine" is for programming development? Re-reading the question, it could quite easily be a palletizer on a production line, for example
    – roganjosh
    Sep 28, 2021 at 19:34
  • @JoshPilkington it looks like OP has made a whole stack of edits to the question since this answer was posted.
    – Gh0stFish
    Sep 28, 2021 at 19:53

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.

  • 8
    it's very likely that you've inadvertently asked for some metrics that are either difficult to gather, or will give confusing results -- THIS. Sometimes management don't understand that asking for X is just 2 minutes of work but asking for Y (which superficially looks like X) takes 2 developers 3 weeks to implement.
    – slebetman
    Sep 29, 2021 at 4:30

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.

  • This is the right answer. It is so frustrating when customers are going to prescribe design details because it limits freedom to come up with innovative solution. You tell me the screw has to have a certain diameter? Now I need to have a screw in my design, and I can't apply an innovative alternative that would be cheaper to produce and maintain and consumes less energy whilst achieving the same quality. The customer should be concerned with the requirements on the machine as a black box, not with its inner details.
    – DeltaLima
    Sep 29, 2021 at 8:47
  • @DeltaLima thanks for your comment, I think you get my point completely! Oct 1, 2021 at 4:12

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.

  • 3
    Think about it in finance terms. If I go out and get a $250k loan at 30% APR in 1 week, vs properly shopping for a mortgage, which one is better? It is easy for managers think "fast" is good, but you know that 30% APR will absolutely wreck you down the line, and nobody in their right mind will get that kind of loan, but software companies do this all the time. If your company don't know how to analyze technical debt, you better figure it out before all the good devs leave.
    – Nelson
    Sep 28, 2021 at 8:13
  • 1
    @Nelson that is absolutely true. Used to work for a start-up where creating a website wasnt allowed to take more than a month. As the only developer. Constantly got reminders that I am costing them money and they are losing with every week I dont meet their deadline. While also maintaining all the other websites and working on requests there. I gladly switched to a Job without "customers" and only internal software. Less deadlines, bigger team, less pressure (losing the company money) and a lot more freedom in terms of tech stack. And my work improved so much
    – bibleblade
    Sep 28, 2021 at 8:17
  • 7
    From reading the question, I understood the OP was proposing to measure performance of the product. But from reading your answer, I understand you're responding about a metric to measure the developers' assiduity / performance / etc. Did we understand the question differently?
    – Stef
    Sep 28, 2021 at 16:42
  • 1
    "savings could only be generated if the speed of the MACHINE reaches certain number" - it clearly talks about performance of product. Sep 28, 2021 at 20:36
  • From the OP's question it doesn't seem to be asking about development performance numbers. He's asking about product performance numbers. Like, can your website handle 10000 concurrent connections? Can it handle 20 requests per second? etc.. These have nothing to do with code commits etc. You can just test and/or measure these. I suspect the OP have accidentally asked for a metric that the system is not currently measuring and the developers are annoyed that they'd have to modify the system/code/configuration/installation in non-trivial ways to get them.
    – slebetman
    Sep 29, 2021 at 4:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .