4 ms·

My rules: 1. Keep nonsense away from your developers. They don’t need to be in meetings. If they do, they’ll ask for it. 2. Have coding standards. What is you

My rules: 1. Keep nonsense away from your developers. They don’t need to be in meetings. If they do, they’ll ask for it. 2. Have coding standards. What is your definition of done? How far do we go with clean code? Hacky solutions are tech debt and will come back to bite you. Standardisation is much more important than the actual rule. 3. Have retrospectives. Why did something not work out as you think it would? What needs to change? 4. Plan tech debt cleanup sprints, or incorporate some stories in every sprint. Tech debt immediately leads to slow down, and very quickly to stagnation. 5. Encourage training and knowledge sharing. Code reviews are a good place to start. 6. Write good tests. This alone will show you if your structure and code practices makes sense. 7. Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well.

randerson 2y ago
In my experience, trying to shield developers from customer/business/product decisions will doom the business to broken telephone syndrome. Developers are also generally more motivated when they feel some connection to the business.
- chasd00 2y ago
  yeah i've always felt it was a good idea for new software devs out of college to spend a few years at a small eat-what-you-kill consultancy. You really get a sense of where you're paycheck comes from and why it exists. Going straight to a giant corporation distorts your view because no matter how detached and abstract you become the direct deposit still shows up. You lose all connection to why you're paid.
- moi2388 2y ago
  Did you read the first or third sentence in point 1?
andruby 2y ago
> Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well. Oh my. I much more prefer it when team are cross-functional, when the Product Manager, Product Designer and Engineers form a team. Those are the people they interact with the most (not the PMs or PDs from other teams). Marty Cagan has a couple of great books on that kind of development, and I much prefer it over teams where engineers are further away from the product people. I've been an engineering IC and in engineering and product leadership roles. Integrating the Why (Vision/Strategy) is more tricky, but we want to do it much more openly then is traditionally done.
- moi2388 2y ago
  I agree. Product owners should be part of the team. The separation is because I often saw Product owners saying “how” something should be made in the stories. Or invite all the developers to meetings. If your developers need a meeting for more details, they’ll ask for it. And let them decide how to make something; as a PO your job is to keep a lot of nonsense away from your team and talk about “what” to make with the client. Perhaps the tech lead joins some of these conversations, especially in the beginning.

randerson 2y ago

In my experience, trying to shield developers from customer/business/product decisions will doom the business to broken telephone syndrome. Developers are also generally more motivated when they feel some connection to the business.

chasd00 2y ago
yeah i've always felt it was a good idea for new software devs out of college to spend a few years at a small eat-what-you-kill consultancy. You really get a sense of where you're paycheck comes from and why it exists. Going straight to a giant corporation distorts your view because no matter how detached and abstract you become the direct deposit still shows up. You lose all connection to why you're paid.
moi2388 2y ago
Did you read the first or third sentence in point 1?

andruby 2y ago

> Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well. Oh my. I much more prefer it when team are cross-functional, when the Product Manager, Product Designer and Engineers form a team. Those are the people they interact with the most (not the PMs or PDs from other teams). Marty Cagan has a couple of great books on that kind of development, and I much prefer it over teams where engineers are further away from the product people. I've been an engineering IC and in engineering and product leadership roles. Integrating the Why (Vision/Strategy) is more tricky, but we want to do it much more openly then is traditionally done.

moi2388 2y ago
I agree. Product owners should be part of the team. The separation is because I often saw Product owners saying “how” something should be made in the stories. Or invite all the developers to meetings. If your developers need a meeting for more details, they’ll ask for it. And let them decide how to make something; as a PO your job is to keep a lot of nonsense away from your team and talk about “what” to make with the client. Perhaps the tech lead joins some of these conversations, especially in the beginning.