Remix clone Hacker News

>Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before"

I have been working in the industry for more than 25 years and in many very different companies, even different cultures. Yes, that may be my own experience. I have been in continuous exchange with my colleagues in a big network of European CTOs and I validated it enough to say, that it can be considered a best practice. What it makes different from a law of nature is that best practices do not always work in every possible situation, but they are expected to work in similar environments.

>If we put people over processes...

Do not forget the second part of the sentence in my comment. Processes must exist - you cannot eliminate something that serves some real need and expect things to get better. By reducing number of meetings you cannot make management job easier or scale it to a bigger team, on the contrary, you will be doing a shitty job. The sole purpose of a manager is to be an oil in the engine, to facilitate the efficient process, and that includes information exchange and empathetic connections. Not to code, not to move tickets, not to write down the requirements. To talk. If people do not talk, do not engage with each other, you fail at that, because the social fabric of the team will rot. Everyone in the team and in the company has their own agenda and their own goals. If they are not aligned continuously, all sorts of toxic environments may emerge.

>Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option

15 minute meeting cannot kill large parts of the week by the definition of time measurement units. It's 3.5% or less, depending on how long is your working week. If this meeting takes more, the solution is to stick to the time frame, not to cancel.

▲

nuancebydefault 15 hours ago | parent | next [-]

I've been in the software engineering industry for almost 30 years and my take is there are no 'best' practices, only 'fit' practices, as the article articulates so nicely. So many times I've seen processes and organizational structures change, each time imposing it's for the better. It's not converging to something 'better'.

	▲	ivan_gammel 15 hours ago \| parent \| next [-]
		It is a matter of word definitions, really. E.g. a team may call a "best practice" something that they repeatedly mention as "keep doing" on a retrospective and maintain the list of them. It's just what works well and what's reproducible and not something to be canonized in a holy book.
	▲	foobarian 10 hours ago \| parent \| prev [-]
		One may call it a "best practice," another may call it "fit practice," but at the end of the day I have no doubt that were Ivan to step in to lead our org it would change for the better :-). As they say there is no arguing with working code

▲

ownagefool 15 hours ago | parent | prev [-]

> I have been working in the industry for more than 25 years...

I mean sure, but that's not evidence of best practice with any sort of rigor around measurable outcomes.

> Do not forget the second part of the sentence in my comment.

I think the problem we have here is you're acting like my suggestion that there's other successful ways to run a team somehow detracts from your own success. It's worrying that you've jumped to viciously defending your position by suggesting I'm essentially shit before the conversation really started.

Talk about toxic, eh?

Here's another nugget. Learn to deal with dissenting opinions in a more thoughtful and amicable way and perhaps you might not need to spend so much time "aligning" people.

▲

ivan_gammel 15 hours ago | parent [-]

>I mean sure, but that's not evidence of best practice with any sort of rigor around measurable outcomes.

Of course, it is not. I doubt that there exist many management practices that were measurably proven to be effective. It's just an explanation why I perceive those as best practices. They have worked for me and my peers in a reproducible way.

>my suggestion that there's other successful ways to run a team >Learn to deal with dissenting opinion

Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?

	▲	ownagefool 13 hours ago \| parent [-]
		> Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways? Killing shitty meetings, including the standup, was one of those dissenting opinions, obviously. Here's another. PMs, or any other role that abstracts the developers from value, serve to infantilise the developer. Instead of owning the most expedient way service a customer or generate revenue, they're instead owning the minutia of frameworks, architecture, or tooling. Of course, you can still make an argument for the PM via efficiencies and skill specialization, but when you effectively give a non-technical person control of what the team works on, you in many circumstances no longer have a person with a view across both commercial and technical realities. And whilst there are many ways to try and plug this gap, like Engineering Managers or arguments like you're holding it wrong, where exactly are these tech leaders learning those skills when in the vast majority of teams the PM keeps them in the dark? Thus, propagates the cycle where the technical are not commercially mature enough to make business decisions, which necessitates the need for adults in the room. Point being, it's a trade-off and there's circumstances where the trade-off makes sense, and others where it doesn't.