

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

Hi folks,<p>I&#x27;m a junior level programmer at my company. I was hired in less than a year ago.<p>Lately the company has been adding in more process in our work. Instead of spending 75% of my time coding, I&#x27;m now cutting to 30-50% due to the amount of documenting and overhead that is now required for each production change.<p>This adds up over time and the team is growing increasingly displeased with it.<p>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 &quot;this close to snapping&quot;. There wasn&#x27;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.<p>That&#x27;s not to say he&#x27;s a bad boss! He&#x27;s normally a great guy. In fact, prior to management, he was a senior programmer for ~10 years. His style isn&#x27;t &quot;What do we need done&quot; but rather &quot;What obstacles can I remove for you?&quot;.<p>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?
======
cauterized
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!

------
anigbrowl
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.

------
calcsam
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.

------
Monkeyget
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_.p...](http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf)

[1]
[https://news.ycombinator.com/item?id=8940820](https://news.ycombinator.com/item?id=8940820)

