Hacker News Reader

Comment by thanatropism | Hacker News Reader

> . Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc.

Most of these look like MBA problems.

That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wider shallower knowledge base etc) so the dynamics of tech debt are clear to people who are in charge of making debt decisions.

View on HN

As someone who has spent time as a project and product manager, I will say a lot of it comes down to a point of view that 'tech will make it happen'.

Many times I've seen long time estimates for something, because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature.

The problem is that most managers are looking to suck up to C level guys and 'deliver'. And many C level guys won't stand the insubordination of someone telling them 'maybe that thing you guys thought of isn't the best way to achieve what you want', no matter how much you work on the techniques from How to Win friends and influence people. Some guys are just dictators, and some are suck ups, and when the two meet, as they often do, it means tech will work 10x what is needed to get where the company needs to be, because the focus will be on what someone requested, not what we are looking to get at.

Also, many developers get stuck in the mindset of places like that, where they assume they have no voice and everything they say will be used against them. So you ask them as a manager how they would achieve X and they just say "tell me what you want in the spec sheet"... people get weirdly conditioned when in negative re-enforcement environments.

> because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature.

In the best functioning development organizations I have experienced or seen, nobody should be asking for "X feature", they should be explaining what their actual needs are, what they need to get out of the software and why. And how important it is to them, or even what their "budget" for it is.

And a technical designer (who could be a developer who has some design skills perhaps by experience, or a designer who understands the tech) _designs a solution_.

This requires someone(s) on the "development" side who can do needs/requirements analysis leading design (ie, "UX"). And it requires the stakeholders to trust that the capacity is there, and that it will turn all right if they don't try to micromanage the feature -- not just "all right", it'll be SO MUCH BETTER.

This works so well when the organization staffs itself to make it possible and the people in charge allow it to happen, that it seems kind of insane that so few organizations do so.

You just described product managers.

They solicit needs from customers, support conversations, etc. and translate those into future development. They combine those needs into major product directions and balance them with an internal compass for where the companyw wants the product to be (i.e., what jobs they want to solve for which users.)

They are technical people with an eye for how something should be built, working closely with designers (visual, UX, etc.)

Excellent companies figure out how to deploy these types of thinkers -- with appropriate mandate -- throughout the organization.

I am pretty sure that my Product Manager has no technical experience at all. And I assume that it's not mandatory for them.

If they are supposed to be technical, then we hired wrongly.

Technical enough to understand, but probably not technical enough to build (but maybe was at some point). That's where they need to live. Their job is to align the devs and the roadmap with the business needs, prioritize what bugs to fix, and decide which enhancements are worthwhile. They also need to know when the team is bullshitting them and when a tech design is too complex or simple.

I can imagine a non-technical person could end up in this role and succeed, but someone with a technical background and some business acumen will have a much higher probability of success.

Though you know, sometimes organizations fall into this issue in other areas.

I once worked with a company that had that attitude toward accounting/compliance - so much more work and all because the primary holders were not in agreement, so they kicked the corporate structure can down the road.

Same goes for CS, etc.

I guess the only solution is a holistic approach, but even then sometimes someone will have to bear the brunt of being the area where people will 'will handle it', at some point a CEO will decide that is what is needed and it will be needed, even in a perfect organization.

Well, because stating needs and not implementations disempowers managers and means they're left with no feeling of grip. It makes it hard to imagine what you'll actually get and whether it'll be useful, which is scary. Plus, what people need is often so vague that literally anyone could have come up with it and it's embarrassingly obvious. If a manager goes to his tech team and says, "I need to make our business more efficient. Think of something!" then this may be the best way to get results because often the programmers understand the business as well as or better than the managers and they understand the codebase, but who would respect a manager who said that? It'd be Dilbert cartoons all over.

This is one reason why tech firms win. Their senior management are made of [former] engineers who are much more aligned with the workers around what implementations make sense.

That's why it's an actual skill to translate needs to implementation. It's not one most managers have either, is why when the managers just give you implementation it does not work.

The skill includes working with the stakeholders to develop actionable needs (not just "make our business more efficient"; the obvious place to go from there is, okay, what do we know about where the greatest bottlenecks/inefficiencies are now, if we don't know enough what can we do to learn?).

Also you don't just take needs and come back with a finished feature, you iterate with feedback from the stakeholders. The first iteration might just be a textual description of the feature, to make sure it makes sense to the manager/stakeholder.

It's a skill, and it involves building trust.

But translating needs to features that will succesfully meet those needs is not a skill most managers/stakeholders have either, is exactly why it doesn't work to just get detailed micro-managed implementation directions from managers/stakeholders. (Or customers!).

My boss/friend just sat (passed) his PMP [0] exam and was talking to me about it as he learned. The main thing that I learned is that the amount of time they say you need to spend planning a thing is waaaaaaaaay longer than we’ve ever spent planning a thing. Orders of magnitude longer. And you plan it multiple times over, with rounds of stakeholder engagement, rounds of risk analysis, rounds of breaking it down and analysing each component and figuring out what it is and how long it will take and what can go wrong and the dependencies and so on and so forth ... and then going back and doing it again until you’re sure it’s correct.

Why do we, as an industry, expect to be able to run a project to schedule when we often give it the most cursory of glances in the planning stage? I work for a very large integrator and we don’t plan at all. We jump in and start while we’re ‘planning’. It’s absurd.

He and I have long said that if the people who built [hospitals|bridges|aeroplanes] behaved the way we did, the world would look very different [1]. Now, thanks to my recent PMP-by-proxy, I’m starting to understand.

[0]: Project Management Professional. One of the main accreditations for project managers, I think PRINCE2 is the other one.

[1]: I’ve seen the project schedule for a railway line extension. “You really plan a concrete truck coming three weeks from now down to the half-hour?”, I asked my friend. She does.

> you need to spend planning a thing is waaaaaaaaay longer than we’ve ever spent planning a thing. Orders of magnitude longer. And you plan it multiple times over, with rounds of stakeholder engagement, rounds of risk analysis, rounds of breaking it down and analysing each component and figuring out what it is and how long it will take and what can go wrong and the dependencies and so on and so forth ... and then going back and doing it again until you’re sure it’s correct.

Yuck. I think the agile approach might be better here. It's better to expose your plan to reality ASAP and adapt along the way.

Except, that's not how agile really works. How agile works is "bosses" have an hour planning meeting, and then act as though they have a veeeeery robust plan (like you talk about) and get upset if things do go according to their quick one-hour plan. So much for adapting along the way.

So I just said that in order to get a project planned properly you need to spend way more time planning it, and you literally said "yuck", let's use agile instead. Which is ... not planning it properly.

And anyone wonders why we're in this situation? We dug this hole, kids. (And to be clear, I'm guilty. I'm not trying to be better than anyone. I am not! I'm just attempting to explain it.)

It's many years since I read this but I seem to remember the original impetus for agile was an internal software development team having a mix of longer term goals, and then lots of reactive work/support. Possibly the latter making up the majority.

It was a way to bring some sense of order to what was chaos: new requests coming in all the time, work being dropped partway through to deal with the new requests, little progress on any front.

I think agile works really well in this kind of context by bringing in a sense of discipline and keeping new work at bay until the beginning of the next cycle[1]. It can also help to keep teams delivery focussed in other contexts but, key point, does not obviate the need for additional planning outside the sprint/iteration framework.

The problem really occurs when people treat agile as sufficient on its own, or as the one project management tool to rule them all. Total nightmare, especially with multiple teams involved.

[1] How workable this is in practice is open to question: I can tell you it's not always a great approach in an environment where client projects typically last a few days and on time delivery has been known to depend on a critical bug fix for a legacy codebase. Especially problematic when requests come in either during the launch phase, because there's usually a fairly hard window, or during the reporting phase, because there's a delivery deadline looming.

Agile works well for redecorating a house (“let’s paint the walls first, and worry about the couch later”), less so for building one. That requires more foresight, larger-scale planning, and writing things down.

With agile, building houses still somewhat works because people will do that planning in their heads. So, knowledge will end up _only_ in people’s heads, not even in everyone’s heads, and will deteriorate there, even if those people do not leave the project.

So, by the time it’s time to do a large-scale update to the house (add a room, update ventilation to modern standards), nobody knows where the ventilation ducts run, why one of them is so much larger, that there’s asbestos in the ceiling, etc.

And of course, some people try to use agile not for building houses, but for building apartment blocks.

Agile doesn’t excuse you from having to do the work of resourcing, budgeting, business alignment, goal setting, sprint planning, acquisition, and so on. For bite-sized projects with just a few developers, it’s less of an issue, but for a project covering PMO, design, QA, change management, and multiple technical workstreams you have to have — and need to communicate to the business — at least a reasonable idea of what you’re getting into.

You ain’t wrong about how most businesses implement “agile,” though. :)

Not that it's the best or only methodology to project planning in a given scenario, company, or industry, but I do think there's significant value in PMP training. I completed the PMP exam in 2012 after being encouraged by a coworker, and I see it as both useful and cheap enough to suggest it to most software/hardware developers.

Learning and applying "how to plan a project" has pretty universal career relevance. I suggest 30-40 hours of study time, and it's around ~$600 to buy the book, take the exam, etc.

Many times, they are indeed MBA problems. VPs micromanaging instead of delegating, not investing enough money into hiring, retaining and developing their talent, etc.

Other times, it is a problem with the existing developers. Choosing not to learn/follow industry best practices. Creating an over-engineered solution instead of a simple one. Skimping on automated testing and spending more time on manual testing instead. Making their colleagues wait an inordinate amount of time for a simple question, code-review or approval. There are many things developers can do that would slow down their team's productivity.

I don't think tribal finger-pointing is very productive. It really does vary case-by-case.

Ugh. MBAs? No thanks. Usually it's interactions with MBA-holding folks that gives me heartburn. They try to mechanize everything. I agree that an MBA education is probably fairly useful for developers, as long as you can retain your perspective and balance the two worlds--they are very different after all. I'm _very_ business-minded (though I don't have an MBA) and I still run into extensive frustration when I get these kind of queries from the business: why is this taking so long? As this article laid out well, the change or new feature is often conceptually simple but there can be _so_ much required to make conceptually simple things actually happen. Unless you have real development experience before becoming "management", I doubt it's possible for a developer to truly convey that complexity to you. Ultimately it ends up becoming a matter of trust, and frequently competent managers realize over time something along the lines of "well, if every developer I've ever had has taken a long time to deliver conceptually simple things then perhaps that means there's a lot to do to deliver things I think are simple." Sadly, there remain some managers who remain convinced, in the face of all evidence to the contary, that all developers are lazy, slow, and just need to be whipped more and harder.

Reply on news.ycombinator.com