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 299: Neophyte estimates and forced framework
In this episode, Dave and Jamison answer these questions:
-
I’m a new team leader running a new project and when asked for a delivery date I gave my best guess (noob!). That date is at hand, our project is not. I gave a new delivery date and you guessed it, it’s later than the date I said way back when.
I presented this new date to my boss, but he wants us to deploy what we have now… even though if we deployed what we have now the business’s cash flow would ignite tearing our collective hopes and dreams asunder. I told him this, in those words, and he said (with a knowing look) “ahhh, you’ve got to play the game, you have a reputation to protect”. I said I’d prefer a reputation of honesty, accuracy and improvement. He said he was talking about his reputation. His other teams consistently miss delivery dates, so I’d guess he has a reputation of missing delivery dates.
I’d love to share my more accurate date, but that now feels like going behind his back, but if I don’t go behind his back - I’m going to get stabbed in my front. For now I’ve settled on putting my new date in confluence so I can use it as a shield when the inquisition comes. Dave, Jamison, what would you do and why?
-
A parallel team has sold our VP on their internal framework, and has the VP convinced all other groups in his org should become dependent on it as a multi-app, multi-platform solution.
Their framework is very buggy and they are very slow to acknowledge and fix bugs. They claim that due to the overwhelming amount of users/adopters of their framework, they can’t look at bugs, or that other projects take priority. This blocks our development. No one except them wanted to use their product, and somehow they used forced widespread adoption to avoid responsibility for missing their deadlines. This group has magnificent soft skills that have allowed them to evade being accountable for their issues.
This team is a darling to the VP, so they are immune to accepting our feedback for the points I listed in the above question.
How can we, who are multiple levels removed from this VP, improve our situation? Our group enjoys working together and on our product, so we don’t want to leave. We just want to find a way to become more tolerant of this other underperforming team.
Show Notes
- https://www.hillelwayne.com/post/we-are-not-special/