240 karma · joined December 26, 2017
One of the fundamental duties of a middle manager is to worry about group dynamics, team effectiveness, group communication, etc.
If the engineers are now doing all of that as well, what's middle management doing?
("Nothing, same as always" is of course the snarky answer)
Again, I'm really not trying to put the author down here - but "leverage" is a term that can very easily and often is used in a mindless and vague way. Not always, of course, in the same way that "synergy" can absolutely be used properly.
Still, it would be extremely easy for me to mindlessly posit whatever I want as "high impact", or at the very least "minimal time investment". "Minimal" and "high impact" are inherently subjective phrases (minimal compared to what? high compared to what?) and without a baseline are effectively useless.
So, I guess I still don't see a huge difference between "synergy" and "leverage" in terms of vagueness. And if vagueness exists, mindless usage is pretty soon to follow.
Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?
> This is... unambiguous,
:)
Er, not really. From the article:
> Leverage = Impact Produced / Time Invested
"Impact Produced" has a precise, concrete meaning?
I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.
I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.
See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.
I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science.
Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful.
These are really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.
> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.
You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).
Maybe not, I'll admit I could easily be wrong on that.
Yeah, and I realize it's a spectrum and not a binary thing. My point was more:
If we use the simplistic, trendy definition of introversion/extroversion as "do you gain energy having conversations or does it require energy?" and then say that regular conversations are an extremely important part of doing modern development work, I think it's fair to say that you're implicitly selecting for extroverts.
And again, I don't really put a judgement on that. I think it's fair to say "regular conversations are required to be successful as a software developer." I'm just noting the shift (as you've also done!).
To be fair, though, I don't think having that team-first mentality (where you're focused on improving the team's productivity as opposed to your own) necessarily implies pervasive "management thinking" (for lack of a better phrase) or even soft skills. I imagine we can all think of teams where that isn't the case.
It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated.
We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own <x>" or "growth mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".
Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.
I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.
It's worth noting the social desirability bias here. It's likely the problem is actually much worse than the study indicates.
Could be. Much like communism, it's something that seems to work remarkably well for small groups of people but seems to have problems with large, entrenched groups.
There are enough agile success stories though that I don't think the ideology is completely silly.
> I think my current place is on their, what, 8th "reset" now? Where they try to correct their process because it's "not working."
It's highly unlikely that any methodology would have any effect on your current place, regardless of how brilliant or revolutionary it is.
I think it's tempting to dismiss Agile as stupid or unworkable because it's failed to produce any results at organizations like this (and often just made things worse).
The truth is really that your organization is highly dysfunctional and the problem is management. There's no development methodology that will fix that, and indeed it won't get better until those people see the light of day (unlikely) or leave/are replaced.
For more functional organizations, or even organizations where management is willing to admit they might be wrong, Agile can be a nice set of guiding principles for development work that makes life easier.
Well, it's more than that though - otherwise you'd just assign each developer 80 "points" worth of work for each two-week sprint.
> If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)
Adding stories to an iteration in progress is also (I'm pretty certain) explicitly discouraged.
If your manager is doing that, you've already kinda lost the Agile battle.
I think that's sorta what people mean when they say people are doing Agile wrong - they do these things that are explicitly discouraged.
Whether there's any way to reconcile that, I can't say.
To be fair, this is true a lot. Agile has quickly become "whatever you were doing before Agile but now with stand-ups and kanban boards."
The real problem with Agile is that it's kinda stupid to assume that companies will radically change their development process and that they won't just do "whatever we were doing before but with a couple bits and pieces from this other thing."
It's way easier to keep doing whatever you were doing before and just say that it's "Agile." See, for example, the number of teams that have long-winded standups even though that's pretty explicitly discouraged.
> What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments.
Totally my take on the whole point system, but:
They're definitely related (hours and points), but basically the whole idea is vagueness. Figuring out if something will take 3 hours or 5 hours is kinda meaningless, because you really have no idea until you get into it. Saying it's worth "5 story points" might suffice as a rough representation of that 3-7 hour chunk.
If it ends up taking 20 hours, oh well - good to know for next time!
The idea is not to bicker over whether something will take 3 hours or 5 hours or 7 hours, but to just slap a vague label on it as "low-to-moderate difficulty." It's supposed to save time in that regard.
> Basically, I prefer a more focused and leaner version of the approaches.
I think any reasonable Agile advocate would tell you to discover what's working for your team and what isn't, and to adjust accordingly.
The point is mostly to move away from that extremely long-winded waterfall process and move towards rapid iteration. Story points and stand-ups are just tools for accomplishing that (by estimating velocity and having regular check-ins).
Really?
https://en.wikipedia.org/wiki/Dan_Rather#Killian_documents
https://en.wikipedia.org/wiki/Brian_Williams#Iraq_War_helico...
https://en.wikipedia.org/wiki/Juan_M._Thompson#Reporting_sca...
https://en.wikipedia.org/wiki/Jayson_Blair#Plagiarism_and_fa...
https://en.wikipedia.org/wiki/Lara_Logan#Benghazi_report_apo...
https://www.timeout.com/chicago/tv/how-a-horrible-decision-c...
https://en.wikipedia.org/wiki/Michael_Finkel
https://en.wikipedia.org/wiki/Stephen_Glass#The_New_Republic
Was the problem remote jobs? No, probably not. The problem was complacency: Complacent employees who didn't want to work and used remote jobs as an excuse not to do anything. Complacent managers who didn't know how to manage remote employees and didn't want to learn.
Did we have remote employees who were amazing? Hell yeah. Did lazy employees overwhelmingly choose to become remote because it was the easiest way not to do any work? Hell yeah. There were more than a few stories (not from management, even) about employees who hadn't even logged in in a couple months. It was beyond the typical "bad employee gets no work done," it was just "bad employee doesn't work one iota."
My takeaway was that managing remote employees is a skill that many managers don't possess, and bad employees knew that and capitalized on it very effectively.
So you're correct that it was a move to facilitate a rapid mass layoff, but the part that's unsaid there is that the people being laid off were overwhelmingly the worst employees anyway. Their managers should've been given the boot as well.