Tech's guidelines for SE.
We are allowed to make mistakes, because you have to make mistakes to learn new things. The safer team members feel with one another, the more likely they are to admit mistakes, to partner, and to take on new roles. And it affects pretty much every important dimension we look at for employees.
The team decides how things are built and by who! If you feel like you’re being micromanaged, push back. We don’t allow micromanagement here. It’s fine to ask for detailed support. When you ask for it, it’s not micromanagement.
Estimates are inaccurate by definition. Hence you should not aim for certain date. Software development is complex sport and all the things are impossible to see in advance. We work hard to release as fast as possible, when the solution is good enough. Deadlines are no help with this. Of course we understand that some features have a deadline, but it should be clearly communicated why the deadline is important and what can be dropped from the scope, if needed.
Features, bugs and chores is put to queue. This is where management can choose features over another and do prioritization. We work with only one large issue at a time. Part of the team that is not working with the large issue works with smaller chores, bugs and features.
It's better to release often and small to get feedback as soon as possible, so we can fail fast, if needed. Nobody likes big risky integrations. User stories and designs should be done with this concept in mind.
I do quality work and I want to share my work with my collagues. Peer-reviews are done in good spirit, everyone is doing their best. Large issues need separate design that is done with all stakeholders (qa, dev, po). Design needs to be peer-reviewed. When the solution is done, we'll peer-review the results.