Comment by Aperocky
2 years ago
Smells fishy.
Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing".
I've seen rare examples who don't "pair" but just deliver by themselves.
I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.
I agree that it seems like a weird distribution of time for someone senior. It's fine and good to mentor juniors or pair some of the time but I think that in general pairing is net less effective than two people working individually. Seniors certainly and usually team leads are expected to deliver some individual work product. You can definitely help make teammates more effective without spending all of your time on their shoulder.
Also: the business established a metric it wanted ICs to meet, the guy in the story refused to participate in it at all. At the very least, he's demonstrating resistance to following the expectations of leadership. He might be a good team player at the smallest scope, but great engineers can do that and simultaneously play along with management/biz interests.
(I'll also agree with the article that measuring "story points" or whatever is probably a bad metric, like most measures of software productivity.)
Hi. I barely deliver anything of value from my perspective.
I asked to swap teams. Two levels up both said "no way you can't be replaced. "
I have a reputation and didn't know.
You do realize that pairing is also delivering in everything you mentioned? Just because you hadn't the luck to experience this in your career so far doesn't invalidate this
More cynically, perhaps they have experienced this but labelled the person as a non-performer.
Oh I had plenty of luck in my career, there are people who the entire team goes to when new/unknown/specific problems show up, and I happen to be one of them.
But I don't sit over someone's shoulder at all times. I only try to help when I'm needed, otherwise I'm knee deep in my own deliverables.
In orthodox agile environment planning, design and architecture might not result in any "story points".
Also these activities might not always result in a lot or any artifacts. E.g. being in a meeting, making sense of messy stream of requirements and using institutional knowledge to help set the right priorities on a project or prevent team from spending months on a dead end idea might not leave any paper trail at all.
Seniors are usually expected to do these things and also produce tangible artifacts. At the principle / architect level maybe you aren't producing code artifacts but you should easily be demonstrating 7+ figure impacts to the business from your efforts.
It's a great deal for Tim. He never has to work overtime to deliver something, and never has to fix bugs on stuff he built.
That said I believe the author that Tim was a huge net positive.
Too lazy to track down the exact company, but the author does link to Tim's LinkedIn. He has many titles as "Agile coach" and his lede is
>Enabling technology teams to operate at their full potential
Sounds like he is a very particular type of developer focused precisely on enabling teams in this manner.
-----
also, I can just post the obvious here but: he may be doing work but not tracking it. I've never been perfect at creating stories for every task I get, especially retroactive ones that pop up in the middle of the week.
This^^ The article depicts it like it's an either-or when in real world capable engineers can consistently do both
The team being described here was one where all work was done paired. Senior engineers were never delivering by themselves. It sounds like you have experience of teams which are not like that, which makes comparisons ineffective.
The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.