71–80 of 385 posts
It’s so difficult to quantify the value of “support” but they’re indispensable. I have yet to really find a sensible way to quantify it. It’s ultimately just something that you need to trust leaders to get right.
So the real metric is the manager who knows their team and what each member brings in.
Earlier quoted context omitted.
> You sound like a manager. Yeah, I think that's a good read. Give management credit for being smart. They mostly do manage only to promote the most egregiously avid Taylorites from among us.
Is a Taylorite a known expression or are you riffing off the idea of a Taylor series? Haha.
Earlier quoted context omitted.
Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. That's not a management activity - that's the kind of coaching you would expect from a senior IC ("Individual Contributor" - I still hate that term.) Generally I would expect a "manager" to have authority over other people in the company: run perfo…
I can't quite tell what the manager in this story should have been doing though. Where is their value add? If its just MBA fluff playing psycho games with metrics then I'd argue they can get fucked.
Earlier quoted context omitted.
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…
I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do? I have a person who I…
So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.
On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.
> "Many cultures don’t allow for someone to say bad things about their coworker"
Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.
> "If you have better metrics or management skills than what everyone in the world has figured out"
This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.
Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.
Earlier quoted context omitted.
> Was Tim hired as a teacher or trainer? Do you think that's any relevant? Software development engineers in general are hired to work on projects as part of small teams, and their goal is to deliver projects. It's not story points, it's not burn down charts, it's not PRs, it's not LoCs touched. It's how many projects are delivered, and keep everything and everyone problem free. This means that if you are struggling,…
> If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team. I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.
I don't think your opinion is educated, or based on any experience working on a functioning team, let alone a high-functioning one. Any team working on non-trivial projects does stumble upon critical bugs that are hard to catch or features that are faster to roll out if a subject matter expert sits down with someone to show them the ropes. If you care about performance and time to market, this is your baseline already. You are not better off with a dozen cowboy developers who wouldn't even piss on a team member if they were on fire.
Earlier quoted context omitted.
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…
I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do? I have a person who I…
Earlier quoted context omitted.
yeah, what the company should have done, is only hire experts! Hiring new grads is definitely a mistake they're making! ...except then I never would have been willing to work there. I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people. One that doesn't treat life as a zero sum game, where someone else has to lose so the company can make money. I get it; for most people…
> yeah, what the company should have done, is only hire experts! I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)". > I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people. Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in peop…
Nah, this was a pet project of my skip level, and I joined after he asked my boss for solutions to the delay. The manager who owned the project had all of his experienced eng working on direct contracts.
This company had a lot of contracts in where the number of engineering hours allocated are specified. This was an internal project, without a hard cap on number of hours, and they were assigned because it would have been malpractice otherwise. This was very much a team built out of the resources available, rather than intentionally selecting only new grads.
I couldn't be replaced because it being an internal project, it would have been killed once it had no active development. And I suspect internal politics would have prevented it getting restarted after the first delay/failure. Turns out stuff is way more complicated than the easy assumptions people like to make.
> sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
It's easier to predict failure than success. That's that same zero or negative sum game though. Usually a cheap way to feel superior instead of doing the harder things. My previous edit already addresses that though. Failure wasn't actually a given like you want to predict.
edit:
> I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".
Right, of course I know you didn't say that, nor do I think you'd actually advocate for it. But taking something to the extreme to see where it fails is a useful rhetorical tool. The point being, that only hiring experts is obviously bad, for the same reason that only hiring new grads is bad.
I think we agree that there is a balance to be struck?
I think 5 noobs to 1 expert is fine, just like 5 to zero is bad, just like 1 to 1 is bad. The point being, there's no magic line where one is right, the other wrong. This team had no problem once the missing puzzle piece was added. And it was able to be successful in ways that 1 and 1 wouldn't have been. There is no reasonable way to say "what you should have done" when describing a puzzle where you can't see most of the pieces.
These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community. We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints. We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer eff…
> Meanwhile in the real world, hordes of awful engineers deliver no story points
Do you think the point here is that not delivering on one specific metric is a good thing, or that not delivering one specific metric can't be assumed to be the whole picture?
Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…
I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.
Pointedly not playing the game when you have the political power to do so is often the most effective way to point out issues in the system that folks are being evaluated under. It can be a very wise move in some cases, as well.