Hey I this is legit the same thing that I said to someone else that had a similar question here and I think it addresses your questions..
---
I am not sure what role you are actually in with this start up but at the end of the day its really going to be more about what you enjoy more... HOWEVER, here are my two sense from my experience of the years. I am going to assume that this "tech lead" has the potential of growing into a CTO role or some exec/admin role within the organization structure. Regardless everyone in this situation will reach a bridge where they are going to have to pick management or a "hacker" that is always going to stay in the code regardless of the transitions. I personally have chosen the technical route in the situations. Here are some bigger points just to outline..
1. Set the team culture.. it speaks volumes having the highest role also on the ground with everyone else (as much as they can)
2. Choosing to not be part of code will create risk for yourself and for the company, especially if you were a vital part of the scaling
3. No one needs to be a delegator full time.. or better yet, just don't be.
4. A PM role is a FULL-TIME role.. can it be done part time? Of course.. but its going to be half ass and that person will not have a full picture of the current state of the software, the team pulse, the product pipeline, and ect.
5. Do what you have to do to make things work but have a clear path insight collectively. Your role may be a hard to define role overtime, especially as a CTO but there are many members of a software dev life cycle for a reason. There is risk of things becoming detrimental if clear processes aren't the goal.
6. Be protective over your time. Allocate at least 4 hours of your day to code even if you wont be able to get all that time in. At least you are communicating the need and importances of your contribution.
7. GET A MENTOR! Get someone that knows what they are talking about and don't just take anyone.. Thing through what you need in a mentor and ask for one. You need a sounding board, but just be careful of conflicts of interest.
8. Focus on knowledge transfer and team processes so the team and software can scale. This is one of the harder parts and should be leaning on whoever is leading the operations to collaborate with.
9. Use agile + JIRA and if you have the company funds add Confluence.. and get your team on the same page.. YES there are other options. I am really not debating that but these are solid solutions that are going to assist the PM and the entire team as you all develop procedures..
10. It doesn't exist unless its a ticket.. I would be sensitive and put thoughtful effort when introducing non-technical people to the software dev life cycle. However, user contracts/requirements, tasks, bugs, QA, design, etc are all HUGE influences of how well your team will do over time. Build a culture around that.
Thats enough even though I have a bit more too say.. at the end of the day you will figure it out. I think the better leadership choice is to keep as much of your time in code as you can as well as the bigger picture while at the same time, develop the processes to allow for scaling in all areas..
---
I am not sure what role you are actually in with this start up but at the end of the day its really going to be more about what you enjoy more... HOWEVER, here are my two sense from my experience of the years. I am going to assume that this "tech lead" has the potential of growing into a CTO role or some exec/admin role within the organization structure. Regardless everyone in this situation will reach a bridge where they are going to have to pick management or a "hacker" that is always going to stay in the code regardless of the transitions. I personally have chosen the technical route in the situations. Here are some bigger points just to outline..
1. Set the team culture.. it speaks volumes having the highest role also on the ground with everyone else (as much as they can) 2. Choosing to not be part of code will create risk for yourself and for the company, especially if you were a vital part of the scaling 3. No one needs to be a delegator full time.. or better yet, just don't be. 4. A PM role is a FULL-TIME role.. can it be done part time? Of course.. but its going to be half ass and that person will not have a full picture of the current state of the software, the team pulse, the product pipeline, and ect. 5. Do what you have to do to make things work but have a clear path insight collectively. Your role may be a hard to define role overtime, especially as a CTO but there are many members of a software dev life cycle for a reason. There is risk of things becoming detrimental if clear processes aren't the goal. 6. Be protective over your time. Allocate at least 4 hours of your day to code even if you wont be able to get all that time in. At least you are communicating the need and importances of your contribution. 7. GET A MENTOR! Get someone that knows what they are talking about and don't just take anyone.. Thing through what you need in a mentor and ask for one. You need a sounding board, but just be careful of conflicts of interest. 8. Focus on knowledge transfer and team processes so the team and software can scale. This is one of the harder parts and should be leaning on whoever is leading the operations to collaborate with. 9. Use agile + JIRA and if you have the company funds add Confluence.. and get your team on the same page.. YES there are other options. I am really not debating that but these are solid solutions that are going to assist the PM and the entire team as you all develop procedures.. 10. It doesn't exist unless its a ticket.. I would be sensitive and put thoughtful effort when introducing non-technical people to the software dev life cycle. However, user contracts/requirements, tasks, bugs, QA, design, etc are all HUGE influences of how well your team will do over time. Build a culture around that.
Thats enough even though I have a bit more too say.. at the end of the day you will figure it out. I think the better leadership choice is to keep as much of your time in code as you can as well as the bigger picture while at the same time, develop the processes to allow for scaling in all areas..
Hope that helped!