It takes more than great code to be a great engineer. Soft Skills Engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into being a great software developer.

Episode 435: How to make my boss actually do something and kindly shooting down

November 18, 2024 32:40 47.03 MB Downloads: 0

In this episode, Dave and Jamison answer these questions:

  1. First! I recently listened to episode 178 (huge backlog of episodes to work through!) and Dave made the assertion (in 2019!) that 47% of all companies would be remote by 2023: wildly close, what else do you see in the future?

    Second: my work situation continues to confound and external insight would be helpful! My boss and I have a long working history going back to an entirely separate company. I’m a high-ownership/high-drive Principal level IC and feedback has been lackluster. Takeaway from last years performance review would be best summarized as “I agree with your self review. End message.” I’ve been working to “manage up” and mentor (reverse mentor?) him, but he always makes snap decisions and then refuses to reevaluate after presented with more info. Coupled with his myopic view of our team’s scope and general preference for speaking only (not much for action), I’m trying to figure out how to get where I want to be without burning an old and historically very useful bridge! I want to work on big technical problems, instead I’m de facto manager of a team… I managed before and did not enjoy being responsible for people. As a principal I’m responsible for their output somewhat, but if they underperform I work with their manager and them to prioritize, and do up front work to incentivize their investment in what we’re doing… help!

  2. What do I do when my teammate proposes a new architecture or framework in a new project? It might solve some existing problems but has a high chance to create technical debt and make the onboarding harder for new engineers.

    How can I convince them to use the existing solution while still helping them feel comfortable sharing their opinion next time?

    If I follow their suggestion but things don’t go well, how can I convince them to refactor the structure without them feeling like I’m blaming them?