[ftlio]

What works: A lead who plans out the project and works with engineers or engineering teams with different specialties to scope out the required components. Lead puts together a plan that is path dependence aware, engineers / teams work iteratively and communicate status.

Leads often don’t know how to lead, scrum hides this.

Management is supposed to be understanding the organizational needs of completing such projects i.e. making sure the right personnel are on the team, on the right teams, that the right teams exist, and that individuals are capable (technically, as a matter of attitude, incentives, conflicts of interest).

Management often doesn’t know how to manage and scrum hides this.

Product is supposed to be coming up with the projects. It gets more complicated as there are “technical” products where the PMs are maybe the leads of Engineering teams, and other ones, but overall, someone is supposed to be responsible for defining what to do next as a discrete goal.

Product often doesn’t know how to do this and scrum hides this.

The thing everyone gets wrong with agile / scrum is that you just keep hacking away until “something” gets done. Without getting into how “agile isn’t scrum” and really just meaning “the death march of ill-specification and low accountability that often gets described as scrum or agile”, you’re supposed to actually start and stop stuff. You can start, fail, and restart. But you need to complete stuff, then look at what was planned versus what was delivered. You need to make specific people responsible for specific things getting done. If people can’t handle their assignments, they need to be given different assignments or removed.

This all sounds really simple, but at dysfunctional orgs, it gets way off track. Being somewhere where nobody is responsible for anything is practically a right of passage in this industry.

[d_sem]

You perspective is interesting. Do you have an opinion about to help management know how to manage? I'm personally in a constant struggle to improve my management skills but struggle to weed through the sudo-science of management training resources.

[rewgs]

Hot take: “management skills” are bullshit. A good manager is empathetic, logical, and organized. Easier said than done of course but that is the only “signal” required — the rest is just noise.

[fatnoah]

I've been managing for a long time, and where I always seem to land are to ask stakeholders and the engineering team what a successful engineering org looks like to them, and I start from there. The almost universal answer from stakeholders is consistency and some measure of predictability. For Engineers, it's usually consistency and feeling like their making valuable contributions and shipping products.

People tend to gravitate towards Scrum because they know it, but it's usually implemented because a process is deemed to be required, not that specific goals are trying to be met. By starting with the goals, I can at least start from a position of agreement, and develop a Scrum or other process that can provide some measure of success for stakeholders while meeting the needs of the engineers. It's also a forcing function for me to say that if you want X from the Engineering team, we need Y from you.

I'm also very upfront that a hill I'll die on is that velocities and story points are great planning tools and signals around process health, but they're never goals nor are they tools for judgement and reviews.

[ftlio]

I think clarity on what “level of leadership” (link, Netflix presentation) is expected is a good thing and also helps people understand that such a hierarchy exists. It gets people thinking about just handling things for you.

Otherwise, I dunno, my best managers had their own way of waxing philosophical about leadership and my role, the product, company, etc to make me more autonomous.

https://www.infoq.com/presentations/netflix-five-level-owner...