4 ms·

Ask HN: How do I work with a frustrated boss?

Hi folks, I'm a junior level programmer at my company. I was hired in less than a year ago. Lately the company has been adding in more process in our work. Instead of spending 75% of my time coding, I'm now cutting to 30-50% due to the amount of documenting and overhead that is now required for each production change. This adds up over time and the team is growing increasingly displeased with it. I had a bi-weekly meeting with my boss today, and he just came from a meeting with HIS boss. He was quite frustrated and mentioned process issues that the team was not following. He also mentioned in our conversation (very briefly) that he was "this close to snapping". There wasn't anything I did here... he has said several times he was very pleased with my work. The source of his frustration was completely out of my control. That's not to say he's a bad boss! He's normally a great guy. In fact, prior to management, he was a senior programmer for ~10 years. His style isn't "What do we need done" but rather "What obstacles can I remove for you?". So my question to you folks: how do I deal with a frustrated boss (or coworker)? And how do I make the most of this situation?

calcsam 12y ago
The issue isn't that your boss is frustrated per se, it's that he seems to have little to no leverage with his boss -- to the point that he vents to you. Power is an inherited property, so if your boss has little leverage, then you have very little power or reason to hope that things will change. Take from that what you will.
anigbrowl 12y ago
It's an implicit invitation for you to take over the job of process compliance and get into management instead of coding. Presumably someone else (with, as another commenter points out, more power) actually needs that stuff - and let's face it, lots of programmers are really crap at documentation. Make your manager's problem evaporate and you'll be his golden boy or girl. Downside: you won't get around to writing any code if you devote yourself to this. Upside: if you go into management you get to have ideas and leave the implementation to your staffers while you deal with people problems. Also, you'll make more money.
Monkeyget 12y ago
Sounds like a textbook case of a capability trap and a failure to recognize that an improvement programs may actually result in a reduction of productivity in the short term. From 'Nobody Ever Gets Credit for Fixing Problems That Never Happened'[0] that was discussed a few days ago [1] : In one firm we studied, the general manager laid out his goals for improving the product development process [...]. At the same time, they launched many new development projects in anticipation of the expected productivity gains. Viewed through the lens of management’s mental model these decisions were entirely rational. However, that mental model [...] led them to the erroneous belief that the delay between improvement effort and results was short and that their engineers were under-utilized, undisciplined, unmotivated, and unwilling to adhere to the specified process. The company spent millions and invested countless person-hours to create a new product development process. The new process [...] also increased monitoring, including a structured stage-gate review process and mandated use of project management software. While there were some pockets of success, in most cases the effort had little impact. The leaders of the change effort often attributed its failure to the engineers’ lack of discipline: “A lot of the engineers felt that [the new process] was no value-add and that they should have spent all their time doing engineering and not filling out project worksheets. It’s brushed off as bureaucratic.”—Manager A Yet, when we asked engineers why the effort failed, we got a different story: “People had to do their normal work as well as [use the new project management system]. There just weren’t enough hours in the day, and the work wasn’t going to wait.”—Engineer B “The new process is a good one. Someday I’d like to work on a project that actually uses it.”—Engineer E While managers felt the engineers had little interest in following the process, engineers became increasingly frustrated with leaders they felt had no understanding of what was really required to develop new products. Faced with the double bind of hitting aggressive performance targets and equally aggressive improvement targets, they were forced to cut corners while still appearing to follow the process. As one engineer remarked, As management discovers the engineers’ shortcuts and workarounds, their view that the engineers can’t be trusted is confirmed, and they are forced to step up their monitoring. [0] http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.p... [1] https://news.ycombinator.com/item?id=8940820 https://news.ycombinator.com/item?id=8940820
cauterized 12y ago
It wasn't appropriate for your boss to vent to you, but it sounds like that was what he was doing. Continue to do your work well, and cooperate with the extra process for now. Give him a week or so to cool off. If you're feeling brave, ask him if there's anything you can do to help him support the team. Documenting how the new process affects your productivity? Taking the process to new heights of absurdity? The answer may be to just follow the damn process and let him deal with the politics. Process isn't always a bad thing - it can help make sure that your coding time is spent on the right things and it can help stem a lot of value loss and productivity obstacles related to siloed information. Work that feels like a big time sink up front can pay big dividends in the long run (the process equivalent of building a test suite for an existing code base). And if it's really that bad, touch up your resume!

calcsam 12y ago

The issue isn't that your boss is frustrated per se, it's that he seems to have little to no leverage with his boss -- to the point that he vents to you. Power is an inherited property, so if your boss has little leverage, then you have very little power or reason to hope that things will change. Take from that what you will.

anigbrowl 12y ago

It's an implicit invitation for you to take over the job of process compliance and get into management instead of coding. Presumably someone else (with, as another commenter points out, more power) actually needs that stuff - and let's face it, lots of programmers are really crap at documentation. Make your manager's problem evaporate and you'll be his golden boy or girl. Downside: you won't get around to writing any code if you devote yourself to this. Upside: if you go into management you get to have ideas and leave the implementation to your staffers while you deal with people problems. Also, you'll make more money.

Monkeyget 12y ago

Sounds like a textbook case of a capability trap and a failure to recognize that an improvement programs may actually result in a reduction of productivity in the short term. From 'Nobody Ever Gets Credit for Fixing Problems That Never Happened'[0] that was discussed a few days ago [1] : In one firm we studied, the general manager laid out his goals for improving the product development process [...]. At the same time, they launched many new development projects in anticipation of the expected productivity gains. Viewed through the lens of management’s mental model these decisions were entirely rational. However, that mental model [...] led them to the erroneous belief that the delay between improvement effort and results was short and that their engineers were under-utilized, undisciplined, unmotivated, and unwilling to adhere to the specified process. The company spent millions and invested countless person-hours to create a new product development process. The new process [...] also increased monitoring, including a structured stage-gate review process and mandated use of project management software. While there were some pockets of success, in most cases the effort had little impact. The leaders of the change effort often attributed its failure to the engineers’ lack of discipline: “A lot of the engineers felt that [the new process] was no value-add and that they should have spent all their time doing engineering and not filling out project worksheets. It’s brushed off as bureaucratic.”—Manager A Yet, when we asked engineers why the effort failed, we got a different story: “People had to do their normal work as well as [use the new project management system]. There just weren’t enough hours in the day, and the work wasn’t going to wait.”—Engineer B “The new process is a good one. Someday I’d like to work on a project that actually uses it.”—Engineer E While managers felt the engineers had little interest in following the process, engineers became increasingly frustrated with leaders they felt had no understanding of what was really required to develop new products. Faced with the double bind of hitting aggressive performance targets and equally aggressive improvement targets, they were forced to cut corners while still appearing to follow the process. As one engineer remarked, As management discovers the engineers’ shortcuts and workarounds, their view that the engineers can’t be trusted is confirmed, and they are forced to step up their monitoring. [0] http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.p... [1] https://news.ycombinator.com/item?id=8940820 https://news.ycombinator.com/item?id=8940820

cauterized 12y ago

It wasn't appropriate for your boss to vent to you, but it sounds like that was what he was doing. Continue to do your work well, and cooperate with the extra process for now. Give him a week or so to cool off. If you're feeling brave, ask him if there's anything you can do to help him support the team. Documenting how the new process affects your productivity? Taking the process to new heights of absurdity? The answer may be to just follow the damn process and let him deal with the politics. Process isn't always a bad thing - it can help make sure that your coding time is spent on the right things and it can help stem a lot of value loss and productivity obstacles related to siloed information. Work that feels like a big time sink up front can pay big dividends in the long run (the process equivalent of building a test suite for an existing code base). And if it's really that bad, touch up your resume!