Episode 388: Money not compliments and principal engineer coding guidelines

In this episode, Dave and Jamison answer these questions:

1. Hey guys, love the show. Not sure if its really a question or more of a confession. I’m an individual contributor at a software company with a few thousand employees. A lot of professional books/training courses I encountered over the years talk about the importance of positively acknowledging your employees/reports/team members when they do a good job. Most of them say that this sort of praise and other immaterial motivation is more important than material motivation (bonuses/raises). More and more, my higher ups had started trying to motivate us with public “pats on the back” for individuals and teams. They were never generous with the material motivation to begin with. Honestly, i find these pats on the back grating. I don’t need to be told “good job kiddo” to actually work hard. To be blunt, i want a raise and/or bonuses, not empty words. But material recognition is all red tape and budget constraints these days, so I dont actually expect much. The issue is that the immaterial motivation just reminds me of what is just out of reach, and thus just demotivates me. Is there any good way to express these frustrations to my manager without sounding like a materialistic greedy bastard? Which I suppose I am, but I’m tired of feeling like one.

2. I’m a principal engineer working with two teams of developers who own a product domain that is being rewritten on an aggressive schedule. We’ve increased headcount over the past year but we’ve started having friction with some of the new hires. Its clear that they want more input into the patterns and coding styles used by the teams that were established prior to them joining. Unfortunately, this seems to come up in PRs rather than discussions and leads to push back from me and the tech leads on the teams. This has lead to our engineering manager commenting that they’re getting complaints about us being too restrictive and developer happiness being impacted. While I don’t want any of the developers to be unhappy, I worry that the EM is risking hurting the team as a whole by focusing on the happiness of one or two new hires. The Tech Leads are also starting to worry about what they are allowed to comment on in PRs. Help! How do I keep the devs from feeling underappreciated, the tech leads feeling empowered to lead, and ensure that the codebase stays consistent between repositories so all developers can move between services without feeling lost?

Episode source