31–40 of 102 posts
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
Earlier quoted context omitted.
Awww. As a product manager who hopes to be serving, encouraging and fostering his team well, this saddens me to read
I read that response in the inverse (that is, hiring product managers is a way to avoid building a toxic software team). Why? Because I'm on a team with no product manager, and we are expected to all service in that role, at least tangentially. Not ideal.
That said, I am actually actively trying to grow my engineers into somewhat of mini product managers themselves.
It’s going quite great so far— the more they get exposed to users and problems, the more they are taking ownership of their work.
I don’t hear things like “the user doesn’t understand” anymore, but rather “I tried to make it clear to anyone who uses it”.
They started coming up with features and changes that were way more brilliant than anything I could come up with. And also interviewing developers (who are also target users for us), performing small tests to validate hypothesis, and so on.
And they also started making little jokes in customer calls to keep users’ mood up! Some users even thanked us for letting them test our early “broken” work-in-progress :D and apologized for not testing well enough. The first time I saw this, it was crazy!
I am so incredibly proud of them!
Earlier quoted context omitted.
I always immediately approve implementation of any good idea regardless of roadmap or resource availability.
Ah, the luxury of no deadlines...
If somebody just improved all future deadlines at the expense of a delay in one, isn't it great? (Yeah, there are a few times when it isn't; but if those are not few enough to be clearly communicated, your management is a bunch of dummies.)
On a positive note, we just had a sprint retrospective today and the entire team gushed with praises for each other and we all agreed that team morale is great, and that we are accomplishing great things despite all the challenges we had been facing recently. I attribute this to a few things I’ve observed. First, we do have some extremely dedicated engineers who lead by example rather than granted authority. This gar…
He was right, his department was great to work in. No recrimination for honest fuck ups (I took down a national banks ATMs for a few hours once).
It was a great place to work and everyone was better / more productive because of it. People were positive, honest, and adults!
Years later we joined a larger company. They acquired another company who had 3x the people doing half the work…. They were all about blame and recrimination. Their productivity was absolutely related to their culture. They were so follow the process / afraid of getting blamed (and people got blamed for no reason) that they were terrible / found the worst ways to work.
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
The non dysfunctional way to deal with this is to allocate between 20% of dev time to process improvements and vote on large scale changes.
Over time, they'll become some of your favorite object lessons about employee engagement!
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well
Tolstoy was right. There are infinitely many ways for a team to be toxic and only one way for them to be happy.
A shared sense of a common goal, knowing how each member uniquely contributes to that goal, and a common respect for the value of those contributions. Deviate from that and you get in trouble.