6 ms·

Let me give two stories. I am in full agreement with your statement, however want to give supporting evidence as part of a "I'm not sure how to push back well

Let me give two stories. I am in full agreement with your statement, however want to give supporting evidence as part of a "I'm not sure how to push back well even after all these years without compromising a lot of political capital". 1. Just this week, I watched a manager wait until after I was on vacation, and then publicly chew out my employee for slipping a deadline. I would agree he should have pushed harder, BUT he slipped it due to our peers being very rigorous on his CR (he is a new employee) to bring him up to standards. (I would add we would have had even MORE buffer had the person in question not continued to change the spec 2 months into a 3 month project, which can happen, but should be acknowledged as a cost) . The manager in question found this (the deadline slipping) regardless unacceptable and gave him grief in front of the whole team about it, and this is the second time I've watched the manager place these meetings when I'm going to be gone because otherwise I come down like a bag of bricks on someone going after my employees. But to why I mention that last sentence regarding my nature, NO AMOUNT of this seems to motivate positive change in the long run, _especially_ since I'm "managing up" and having to do this as an engineer myself, any big "push" I make costs a lot of effort and karma, and doesn't seem to stick long term despite my best efforts. 2. More specifically, I had a conversation you summarized above (taking TIME to dev well) just a few weeks ago with my manager. Over the last few years we've repeated a pattern, I take longer than he'd like, he gives me shit for it, I tell him it'll pay dividends long term, he grumbles, but then it does. (bug rates, iteration speed under frameworks I write, reuse due to good modularity/code cleanliness, these are all benefits you see rendered on a very short time scale, even just keeping with the most broad basics.) Now, I will give him credit for saying "you have a point and I'll leave it to your judgement" but that took me _two years_ of very incendiary 1:1's of my trying to put my money where my mouth is against someone who has been at this a lot longer than me and with some very strong opinions about that. I frankly don't see a "shortcut" after that experience, although the conclusion was more positive. So let me tie up this ramble with addressing your conclusion: I'd LOVE to take control of my working conditions back. But when the same people (PMs) who lead to my just throwing my hands up at even TRYING to get work done at work due to constant context switching/interruptions _SCHEDULE MEETINGS_ asking us why we're so slow (and then spend the whole meeting complaining about how WE pull them into meetings they don't need), it seems like there are just massive gaps of understanding or lack of shared incentive between the various powers that be. I don't know how to take control of my working condition back, but I've damn well been trying, and would be curious to hear any anecdotal suggestions from you in working this through more "political" environments.

ebiester 10y ago
I personally don't tolerate abuse and would GTFO, but I understand that's not always an option. :(
wpietri 10y ago
Hopefully others will jump in with answers more relevant to your situation. I work mainly in a startup and small-company context because the customer and business realities are more prominent than the political situation. In my mind's eye, I see companies as opaque spheres of different sizes. The bigger they get, the farther the average person is from the external reality, and so the less that reality matters. I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways. So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win. But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment." If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work. Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative. And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination. Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years. Does that help? If not, feel free to reply here or email me. Glad to help as I can. [1] For example, the dumbfounding mess in Mississippi, which we know about because of one stubbornly honest engineer: http://www.nytimes.com/2016/07/05/science/kemper-coal-mississippi.html?_r=0 http://www.nytimes.com/2016/07/05/science/kemper-coal-missis... [2] A good book is Larsen and Derby's Agile Retrospectives: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 https://www.amazon.com/Agile-Retrospectives-Making-Teams-Gre... [3] Also handy is the Retromat: http://plans-for-retrospectives.com/ http://plans-for-retrospectives.com/

ebiester 10y ago

I personally don't tolerate abuse and would GTFO, but I understand that's not always an option. :(

wpietri 10y ago

Hopefully others will jump in with answers more relevant to your situation. I work mainly in a startup and small-company context because the customer and business realities are more prominent than the political situation. In my mind's eye, I see companies as opaque spheres of different sizes. The bigger they get, the farther the average person is from the external reality, and so the less that reality matters. I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways. So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win. But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment." If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work. Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative. And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination. Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years. Does that help? If not, feel free to reply here or email me. Glad to help as I can. [1] For example, the dumbfounding mess in Mississippi, which we know about because of one stubbornly honest engineer: http://www.nytimes.com/2016/07/05/science/kemper-coal-mississippi.html?_r=0 http://www.nytimes.com/2016/07/05/science/kemper-coal-missis... [2] A good book is Larsen and Derby's Agile Retrospectives: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 https://www.amazon.com/Agile-Retrospectives-Making-Teams-Gre... [3] Also handy is the Retromat: http://plans-for-retrospectives.com/ http://plans-for-retrospectives.com/