3 ms·
> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.) My eyes rolled back so hard I'm not s
by rfrey 3y ago
> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.)
My eyes rolled back so hard I'm not sure they'll ever face forward again.
Lotta good stuff in this essay, but that one missed the mark a bit.
- icedchai 3y agoYep. In my experience, the only people who like sprint planning and retros are the PMs.
- dclowd9901 3y agoIf we have to have a manager, I like retros as they’re a way to give feedback to our manager on things we don’t like about our operational process.
- AtlasBarfed 3y agoSeriously, the retro each week should be two questions: 1) Is this process working to the satisfaction of the team? 2) Anyone have anything else to discuss about it? And it should be perfectly fine for it to be less than one minute most weeks.
- benjiweber 3y agoIf the team habits you have aren't joyful or even useful, why don't you change them?
- icedchai 3y agoI mention it, and I get “[other person] wants to do it this way.” The other person is a product manager, not an engineer. You can only complain so much.
- neilv 3y agoThere absolutely are engineering teams that like the routine and rituals of sprints, their version of "Agile", etc. And thrive, in a sense. (But I've not heard of anyone liking anything about on-call, except for extra pay.) I'm normally concerned when that seems to be going on, especially in a startup... For example, in a big company, the problems and coordination and politics are usually hard... so you might "thrive" if all you need to do is sprint tasks, you feel individually unblocked and productive, your individual metrics/reviews look good, and maybe your team looks good as far as anyone can tell. I'd be careful with that in an early startup, which usually (unless it's more a "growth" scheme) needs to be more effective, efficient, and creative than a large, entrenched company. (You can have some people be doing such brilliant holistic coordination in a startup, so that others can just go through routines and rituals, with their ducks lined up to plink, and get the right great startup execution out the other end... But I don't know how often or how well that actually happens.)
- marcinzm 3y agoA lot of the essay is along the same lines to me. Top down product strategy that teams then simply execute on versus being co-creators of. In that environment you want rituals/routine since it avoids the team thinking about things that are seen as the purvey of others.
- AtlasBarfed 3y agoI skimmed this article, and it is basically IMO garden variety IT management perspective that could be dropped into an org from the 70s/80s/90s/00s/etc, aside from the agile namedropping. Which leads me to: great, you are a "VP of Engineering" but there is little to justify why I should believe you are an exemplar of that title/position. The LinkedIn isn't a fraud, but it isn't full of any formal management degrees, IT coursework, IT Management coursework. I don't see companies whose products are on the front lines of foundational technology, scale, or quality. Frankly, the resume is full of 1 year hopscotches. That... doesn't really tell me they are battletested. I get IT is an industry with zero respect for the neckbeard, and yeah they went to Yale, so they are of a minimum floor of hard work and intellect. There are people out there with 40 years of experience in IT, and probably 30 years of management, with stories of massive failures, grace under fire, and the usual stories Machiavellian fake smiles to navigate. And plugging a "Organizational Health" book is hilarious when you are a startup. Yeah, there are lots of unhealthy startups, but the really hard organizational health problems are long standing companies with the "dead pool" effect that chased away the best people, long standing feuds/grudges, sociopathic/paranoid wars over diminishing resource pools and budgets, and deep problems with legacy systems that need to be updated. A startup? That's peanuts in comparison.
- codampa01314 3y agoI've had the opposite experience. Several dev teams I've been on want retrospectives to help review and make things better. But those places are where devs have a lot of autonomy and ability to change how things operate in the team. I've seen and been on teams that align more with your reaction but those are at jobs where where the dev teams have very little say in how they do things. Well that or it's filled with a lot of cynical people that don't actually care about what they are doing and don't have much desire for things to improve (they actively fight to keep the status quo).
- switch007 3y agoSkirting close to a veiled “all engineers are on the spectrum” remark
- mock-possum 3y agoYeah I don’t thrive on that stuff, I barely tolerate it because I am being paid to do so I don’t just sit around thinking “god I had a schedule I was stressed about keeping. You know what I need right now? A two hour meeting with eight people including my boss and my boss’s boss where I have nothing to say and nothing to hear. If I could pick one thing to change in my life, it would be that I have to go to bed early every single fucking day because I’m worried if I don’t I won’t get enough sleep and it’ll be a struggle to wake up and do work early tomorrow morning.” Fuck your routine. I thrive on control. Let me have control.
- spicyusername 3y agoWhat's wrong with those things? In my experience, places that lack things like them are either small, and don't need them, or large, and in constant chaos.