Hacker News Reader

Comment by teeray | Hacker News Reader

Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically.

However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not.

I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.

View on HN

Simple: it's the job of a good line manager to embed and ingratiate themselves well enough with those doing the engineering work, that at any point they can give a reasonable estimate for how long a certain thing is going to take when asked middle or upper management. That is, WITHOUT adding extra process.

> I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.’

I spend the majority of my career in SCM, not software development. Your comment is absolutely true in my opinion. A good line manager knows what's going on, any KPIs or dashboards just make it easier for a manager to know.

Managers rellying on dashboards and reports only to know whats going on in their teams, have always teams oerforming sub par. And they aren't able to answer upper management questions any better.

This. The people paying for a project want to know how long it will take, how much it will cost, and what the feature set is going to be. This is of course not reliably possible, so we end up with an elaborate back and forth that tries to re-impose waterfall whatever the label on the process is.

Similarly, "Individuals and Interactions over Processes and Tools" is really difficult for an organisation to cope with. Everything else in corporate land is about de-personalising and standardising the actions of workers as much as possible, so that they're interchangeable. See manufacturing lines, fast food production, call centres. "Cattle not pets", but for humans rather than servers. Once you start caring about and adapting the work process to individuals, they're not replaceable.

On the other hand, there's comfort in having a bad process. Because then you don't have to blame and confront individuals as people, just over whether they've followed the process.

I agree with your concern. What’s the alternative? One idea…

> the people paying for a project want to know how long it will take, how much it will cost, and what the feature set is going to be.

Certainly … if they’re “doing it wrong”. :-)

Do VC know any of these things? The agile approach, YC, and the SAFE are predicated on these being unspecifiable to any signficant accuracy.

So a better approach may be to:

1. Change the money process from budgeting to investment.

2. Fund capable teams of dedicated fixed capacity, and you can nail budget to the penny.

3. Then, fund by mix of ROX/ROE/ROI* on prioritization of the backlog, and you’ll get out of the team what you chose to fund as the team capacity.

Done.

* Return on Experience (NPS etc.), Return on Equity, Return on Investment. And consider sharing something like “Implementing Beyond Budgeting” with the money people:

https://smile.amazon.com/Implementing-Beyond-Budgeting-Unloc...

** To maintain trust with the money people, engineering cannot employ unproductive teams. It may be the tradeoff for engineers from a terrible budget driven process is better job security, since their individual performance or abilities to output great features matters less to the corporation than the estimation/budgeting/CYA processes do. In the budgeting world, senior executives get rotated out faster than IT teams.

Yes that's right.

What's missing here is that this doesn't come for free. Requiring to always be able to get information about "what's the progress" without delay means that someone must constantly calculate the current progress. And this is difficult and requires a human that can estimate all the things, including resources (will a dev get sick next week?) and delays from other teams, external blockers and their chance of happening (will the clould environment fail again this week?) and so on.

If this is desired (it may well be) a resource for this has to be planned and implemented _in advance_. That costs a lot of money. And even then, it can just give an estimate in the form of a probablity curve.

If the management has not planned for this, they can either not expect to get status information all the time but have to request it, then wait for it to be calculated and have to accept it will delay the project by the time it takes to calculate it. Or they have to live with an extremely vague and unprecise estimation.

And unfortunately, all methods, be it SCRUM, v-model xt or a randomly assembled method, will not automatically calculate a good estimate. Otherwise no one would complain. :)

The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes.

If they can't understand that stuff they should not be making decisions.

But basically it's a list of stuff done, with proof, and stuff left to do.

Then they can see the progress bar moving and make decisions based on that. To get estimates, ask for explanations of what is involved in the remaining steps. Again, they should have technical competence to get a rough estimate from those reports.

> If they can't understand that stuff they should not be making decisions.

That doesn't seem right. As a developer, if I were the CEO of a company, I would not be able to read progress from the legal team, or finance team, or any other team. What's going on with that lawsuit? No idea. Do I know how long it'll take to wrap that up? Nope. I can't understand any of their jargon. I still gotta make decisions about it.

I don't need legal competence in order to run the company or make decisions about stuff, and I shouldn't need technical competence either.

It's on us, as developers, to communicate clearly and give answers and reasonable estimates, so management can make their plans and adjust priorities if necessary. The process we use to generate those answers (agile, git commits, deployments) is entirely up to us and could not matter less to the business, at the end of the day.

In a sufficiently large organization, managers are hired to have technical (or legal, or financial) knowhow and to use that expertise to provide information to the CEO to not take time from those doing the work. Likewise, those doing the work often aren't even permitted to communicate with the CEO.

In a small organization, the reality is that many hats must be worn. That may mean developers play manager to some degree, but also the CEO must be prepared to step into the trenches.

Yes, it definitely varies by org size. I worked in a medium size org and the “dev manager” could not even look at a git repo. In a years time he was never able to set up his dev environment, despite “wanting to get more into the code.”

Delegation exists as well if a progress bar is too technical.

Why would an executive with access to Git be better at estimating progress than the team doing the work?

Reply on news.ycombinator.com