4 ms·

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not. I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.

zorpner 5y ago
> I earn the respect every day I come in How much of each dollar you make for the company with your hard work do you take home?
- bosie 5y ago
  Any advice on how to calculate the first?
  - pjmlp 5y ago
    For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something outside the planned roadmap, their monthly salary divided by the amount of hours they are supposed to be working per month, correlated with the time spent on said activity. Actually I have been in a couple of projects, where instead of sprint points or hours, we actually had euros as ticket efforts.
    - bosie 5y ago
      > For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours. With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)
      - pjmlp 5y ago
        Value/work is driven by market. Too many Java devs to chose from? Salaries going down. Can't get hold of them? Salaries going up. Whatever engineer wants is driven by market prices in land, and offshoring prices as well. And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.
        bosie 5y ago
        > Value/work is driven by market. i might be missing something but you are still equating value of work with salaries for some reason. this is the context we are discussing, the original quote: "How much of each dollar you make for the company with your hard work do you take home?" i was asking how you calculate how much you make for the company. you specifically. not 'revenue/hours' or whatever. you and you only. salaries do not factor into this. how could they? > And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement. that isn't true though. this might be the case in some countries (please provide a reference) but in europe with strong unions and collective agreements, it is wrong. it sets the minimum standard and companies pay over that agreement all the time.
  - Aeolun 5y ago
    A very simple one is to improve the performance of your app by some degree and see if you get the savings on AWS cost on your bank account.
ipaddr 5y ago
That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.
- emptysongglass 5y ago
  My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM. You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.
  - ipaddr 5y ago
    I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product. That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.
    - pritambaral 5y ago
      > ... your team with a strong lead or more senior developers could work with a regular pm and get the job done. Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done. Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that technical people in those teams who did do the management work did it without the title? IME, far more often, it's the latter.
      - temac 5y ago
        If work activities is about titles, I hope yours is multiple lines long. We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised. So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.

zorpner 5y ago

> I earn the respect every day I come in How much of each dollar you make for the company with your hard work do you take home?

bosie 5y ago
Any advice on how to calculate the first?
- pjmlp 5y ago
  For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something outside the planned roadmap, their monthly salary divided by the amount of hours they are supposed to be working per month, correlated with the time spent on said activity. Actually I have been in a couple of projects, where instead of sprint points or hours, we actually had euros as ticket efforts.
  - bosie 5y ago
    > For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours. With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)
    - pjmlp 5y ago
      Value/work is driven by market. Too many Java devs to chose from? Salaries going down. Can't get hold of them? Salaries going up. Whatever engineer wants is driven by market prices in land, and offshoring prices as well. And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.
      - bosie 5y ago
        > Value/work is driven by market. i might be missing something but you are still equating value of work with salaries for some reason. this is the context we are discussing, the original quote: "How much of each dollar you make for the company with your hard work do you take home?" i was asking how you calculate how much you make for the company. you specifically. not 'revenue/hours' or whatever. you and you only. salaries do not factor into this. how could they? > And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement. that isn't true though. this might be the case in some countries (please provide a reference) but in europe with strong unions and collective agreements, it is wrong. it sets the minimum standard and companies pay over that agreement all the time.
- Aeolun 5y ago
  A very simple one is to improve the performance of your app by some degree and see if you get the savings on AWS cost on your bank account.

ipaddr 5y ago

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

emptysongglass 5y ago
My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM. You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.
- ipaddr 5y ago
  I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product. That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.
  - pritambaral 5y ago
    > ... your team with a strong lead or more senior developers could work with a regular pm and get the job done. Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done. Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that technical people in those teams who did do the management work did it without the title? IME, far more often, it's the latter.
    - temac 5y ago
      If work activities is about titles, I hope yours is multiple lines long. We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised. So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.