5 ms·

Developer interactions with management suffer from huge information imbalances, and a lack of trust. For example, I'm working on a project now to update a code

Developer interactions with management suffer from huge information imbalances, and a lack of trust. For example, I'm working on a project now to update a code base running on a (very) old compiler. We've been working for a year, and large chunks of the system are done. One (fairly major) part is yet to be completed. Management doesn't understand the process, or have confidence that the project will ultimately be successful. I don't blame them for being skittish, software projects (especially conversions) have a long history of failure. We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) Mostly they don't attend directly, a middle manager acts as a go-between. The developer view is that of course this will work (personally I've never been in doubt on that front) but the time-scale is uncertain because the system is large and old. But we're talking months left, not years. Yes, I'm aware of the 80/20 principle, but we're well into the 20% already. Of course to management it's a binary state, done or not-done. It's hard for them to guage progress. There's no "trust" in what we say. Which makes sense to me. We might have done 0 work for a year. If all we did was the meetings -they wouldn't know-. (Its a fixed price job, so it doesn't make sense for us to drag it out.) Of course the risk is all on them. They've spent a bunch of money and are nervous. They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. Ultimately if the project fails they'll take a hit (not so much us.) There's no easy fix here - you can't just argue that managers should be technical (the tech is not their core business), and more "consultants" won't make them feel warm and fuzzy. The best we can do is push through and deliver.

trueismywork 2y ago
> They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. If they took advice of internal people and then made the same internal people work on it, this trust issue might get solved. Ultimately by showing lack of trust in their developers, they are showing lack of trust in their management skills for having selected the correct developers. They are doing one core part of their job very badly.
- ikiris 2y ago
  They probably didn't pick devs that they trusted, they picked the ones they thought were the cheapest.
  - trueismywork 2y ago
    And so again failed at their jobs.
  - bruce511 2y ago
    I think very few execs care about the cost of individuals. Firstly it's not their money, secondly they're not rewarded for "hiring cheap" but they are penalized for their failure to perform. Throw in that hiring in general is hard, and that hiring technical people when you are non-technical is even harder, and it's hard to have lots of confidence right out the gate.
    - skydhash 2y ago
      > I think very few execs care about the cost of individuals. From what I've seen, it's always about cost. They would post salary ranges if that weren't the case. > hiring technical people when you are non-technical Non-technical people are always hiring technical people. How do houses get built? Who hire lawyers?... It's either references or researching the person's professional experience. And yes, people can lie. But that happens everywhere not just in tech.
- ethbr1 2y ago
  The problem with hiring good developers is that you need good developers and a solid corporate tech culture to hire them. If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers? And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones. It's very hard for non-tech companies to hire and retain quality talent.
  - skydhash 2y ago
morgante 2y ago
If management has no visibility into the project progress, that seems like a pretty major problem. It absolutely shouldn't be "binary." Any year-long project should have tractable progress metrics. Upper management doesn't need to be technical, but someone in the chain absolutely should be capable of translating progress into a digestible format.
- roenxi 2y ago
  It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. Under normal conditions the metrics you are talking to boil down to "the dev says we're making progress". The level of formality with which they say that changes, but not the underlying process of how the metric is generated. The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.
  - morgante 2y ago
    > It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. That seems like a cop out. Knowing precisely how long a project will take is famously hard, but knowing the rough progress being made towards milestones is absolutely solvable. Git is the best place to look, but you don't need that level of detail to see new things being shipped. Everywhere I've worked (from small startups up to Google) it is absolutely the norm to have clear milestones to work towards on at least a quarterly basis.
    - roenxi 2y ago
      > knowing the rough progress being made towards milestones is absolutely solvable Yeah, but the process for knowing that is ask the dev and they will tell you. Or ask the PM who will ask the dev. Or ask a tech lead who will ask the relevant dev. Or read the spreadsheet entry that the dev updated. All roads lead through conversation with the dev working on a feature. There are occasional exceptions, but they are rare. If the dev is willing to lie, or honestly mistaken, or just too inexperienced to estimate how they are doing then it is close to impossible to gauge progress. > That seems like a cop out You would probably believe the number of people who say that.
zer00eyz 2y ago
>> One (fairly major) part is yet to be completed. Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges. Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz. Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave. Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close.... We both know that going live is gonna be the big hurdle just dont tell them that till your ready.
- bruce511 2y ago
  >> We both know that going live is gonna be the big hurdle just dont tell them that till your ready. Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good. >> Break this down. Break it down into granular chunks even if they are a month long Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation. We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there. Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know. Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.
  - morgante 2y ago
    > We are aware that "it doesn't run". ...what? You have an application that literally doesn't run and you've been working on it for months?
VyseofArcadia 2y ago
> We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) I've been on more than one project with delays. Delays make management nervous. I understand that, but having more meetings about it will never make things go faster. Having a half-hour check-in with the PM every day so that they can "provide me with support and give me what I need to get the project back on track" is not helpful. There is nothing they can give me that I need other than fewer meetings. There are no obstacles but time, and the only reason that is an obstacle is because upper management insisted on an unrealistic timeline to begin with.

trueismywork 2y ago

> They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. If they took advice of internal people and then made the same internal people work on it, this trust issue might get solved. Ultimately by showing lack of trust in their developers, they are showing lack of trust in their management skills for having selected the correct developers. They are doing one core part of their job very badly.

ikiris 2y ago
They probably didn't pick devs that they trusted, they picked the ones they thought were the cheapest.
- trueismywork 2y ago
  And so again failed at their jobs.
- bruce511 2y ago
  I think very few execs care about the cost of individuals. Firstly it's not their money, secondly they're not rewarded for "hiring cheap" but they are penalized for their failure to perform. Throw in that hiring in general is hard, and that hiring technical people when you are non-technical is even harder, and it's hard to have lots of confidence right out the gate.
  - skydhash 2y ago
    > I think very few execs care about the cost of individuals. From what I've seen, it's always about cost. They would post salary ranges if that weren't the case. > hiring technical people when you are non-technical Non-technical people are always hiring technical people. How do houses get built? Who hire lawyers?... It's either references or researching the person's professional experience. And yes, people can lie. But that happens everywhere not just in tech.
ethbr1 2y ago
The problem with hiring good developers is that you need good developers and a solid corporate tech culture to hire them. If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers? And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones. It's very hard for non-tech companies to hire and retain quality talent.
- skydhash 2y ago

morgante 2y ago

If management has no visibility into the project progress, that seems like a pretty major problem. It absolutely shouldn't be "binary." Any year-long project should have tractable progress metrics. Upper management doesn't need to be technical, but someone in the chain absolutely should be capable of translating progress into a digestible format.

roenxi 2y ago
It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. Under normal conditions the metrics you are talking to boil down to "the dev says we're making progress". The level of formality with which they say that changes, but not the underlying process of how the metric is generated. The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.
- morgante 2y ago
  > It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. That seems like a cop out. Knowing precisely how long a project will take is famously hard, but knowing the rough progress being made towards milestones is absolutely solvable. Git is the best place to look, but you don't need that level of detail to see new things being shipped. Everywhere I've worked (from small startups up to Google) it is absolutely the norm to have clear milestones to work towards on at least a quarterly basis.
  - roenxi 2y ago
    > knowing the rough progress being made towards milestones is absolutely solvable Yeah, but the process for knowing that is ask the dev and they will tell you. Or ask the PM who will ask the dev. Or ask a tech lead who will ask the relevant dev. Or read the spreadsheet entry that the dev updated. All roads lead through conversation with the dev working on a feature. There are occasional exceptions, but they are rare. If the dev is willing to lie, or honestly mistaken, or just too inexperienced to estimate how they are doing then it is close to impossible to gauge progress. > That seems like a cop out You would probably believe the number of people who say that.

zer00eyz 2y ago

>> One (fairly major) part is yet to be completed. Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges. Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz. Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave. Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close.... We both know that going live is gonna be the big hurdle just dont tell them that till your ready.

bruce511 2y ago
>> We both know that going live is gonna be the big hurdle just dont tell them that till your ready. Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good. >> Break this down. Break it down into granular chunks even if they are a month long Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation. We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there. Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know. Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.
- morgante 2y ago
  > We are aware that "it doesn't run". ...what? You have an application that literally doesn't run and you've been working on it for months?

VyseofArcadia 2y ago

> We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) I've been on more than one project with delays. Delays make management nervous. I understand that, but having more meetings about it will never make things go faster. Having a half-hour check-in with the PM every day so that they can "provide me with support and give me what I need to get the project back on track" is not helpful. There is nothing they can give me that I need other than fewer meetings. There are no obstacles but time, and the only reason that is an obstacle is because upper management insisted on an unrealistic timeline to begin with.