4 ms·

For a software project, you need 2 main people to run it effectively: - a tech lead who is intimately familiar with the code being written, who keeps the code

by wppick 5y ago

For a software project, you need 2 main people to run it effectively: - a tech lead who is intimately familiar with the code being written, who keeps the code design/architecture on the right path, and oversees all the work being done. This person can make great strategic decisions about how to schedule the work to find opportunities to group common work together, divide the work so that people are not working on top of each other, and make decisions taking in the long term health of the codebase and short term delivery pressures. - a business/product expert. This person prevents the tech lead from being in endless meetings. They sit down and figure out the requirements for the product/project. The clearly communicate these requirements in documents condensing the endless meetings into a coherent clear vision for the product with the long term vision and short term priorities being made clear. The tech lead uses this condensed information to plan the software development. You cannot have one person do both of these things. The tech lead cannot be in endless meetings and keep the needed level of intimacy with the codebase and properly direct the work being done. The business/product expert needs to be an expert communicator, to make that interface between the tech lead and business/product requirements effective. They need to be able to ask the right questions to get the information about what needs to be built, and then clearly paint that vision to the tech lead. The business/product expert does not create tickets of work to be done! They just communicate the vision. The tech lead breaks the work down strategically.

bgroat 5y ago
This is the best case for a CEO/CTO relationship. The CTO shouldn't be writing code, it's too low leverage. But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CEO should be speaking with all of the key stake holders, and then having strategic conversations with the CTO as equals
- aiisjustanif 5y ago
  > But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CTO? The CTO of what type of company? You’re having a laugh if it’s anything other than a startup or medium sized tech company.
  - binarytox1n 5y ago
    I don't know why you're downvoted - it's absolute nonsense to think that your CTO should be 80% your best developer. Your CTO should not be writing code at a company with >100 employees - why would they maintain 80% of the skillset of someone who's entire job is writing code? Is the assertion that what a CTO does is only 20% different than what a software engineer does?
  - kcplate 5y ago
    Yep, I did a spit-take when I read that.
ryandrake 5y ago
> You cannot have one person do both of these things. Isn't that basically what Apple does with their "DRI" concept? One individual directly responsible for the whole project, both for the technical implementation and the product/market fit. This avoids the lengthy back-and-forth negotiation between the tech owner and the product owner about what the user wants vs. what can be done, and also avoids the usual "Wait, I though you were the owner of that?" discussions that we've all seen happen when things get complex and ambiguous. 1: https://mentorphile.com/2019/03/05/fostering-apples-culture-of-accountability-the-dri/ https://mentorphile.com/2019/03/05/fostering-apples-culture-...
- wppick 5y ago
  Not sure about that. I'm not familiar with Apple's DRI concept. But it sounds like there could be a DRI for the tech and a DRI for the business side of things. If not you would probably want the tech role to be the DRI and pull the info from the business/product expert. The alternative would be to have the business/product expert be the DRI and maybe take on a project manager type role. There is also the possibility that someone does do both roles and is super efficient, or just works 100+ hours per week. But in reality my guess is they end up becoming the business/product expert and delegating the tech lead to someone else

by wppick 5y ago

bgroat 5y ago

This is the best case for a CEO/CTO relationship. The CTO shouldn't be writing code, it's too low leverage. But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CEO should be speaking with all of the key stake holders, and then having strategic conversations with the CTO as equals

aiisjustanif 5y ago
> But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CTO? The CTO of what type of company? You’re having a laugh if it’s anything other than a startup or medium sized tech company.
- binarytox1n 5y ago
  I don't know why you're downvoted - it's absolute nonsense to think that your CTO should be 80% your best developer. Your CTO should not be writing code at a company with >100 employees - why would they maintain 80% of the skillset of someone who's entire job is writing code? Is the assertion that what a CTO does is only 20% different than what a software engineer does?
- kcplate 5y ago
  Yep, I did a spit-take when I read that.

ryandrake 5y ago

> You cannot have one person do both of these things. Isn't that basically what Apple does with their "DRI" concept? One individual directly responsible for the whole project, both for the technical implementation and the product/market fit. This avoids the lengthy back-and-forth negotiation between the tech owner and the product owner about what the user wants vs. what can be done, and also avoids the usual "Wait, I though you were the owner of that?" discussions that we've all seen happen when things get complex and ambiguous. 1: https://mentorphile.com/2019/03/05/fostering-apples-culture-of-accountability-the-dri/ https://mentorphile.com/2019/03/05/fostering-apples-culture-...

wppick 5y ago
Not sure about that. I'm not familiar with Apple's DRI concept. But it sounds like there could be a DRI for the tech and a DRI for the business side of things. If not you would probably want the tech role to be the DRI and pull the info from the business/product expert. The alternative would be to have the business/product expert be the DRI and maybe take on a project manager type role. There is also the possibility that someone does do both roles and is super efficient, or just works 100+ hours per week. But in reality my guess is they end up becoming the business/product expert and delegating the tech lead to someone else