Ask HN: Learning tech leadership vs. growing as a developer?
I work in a startup which is growing at a steady pace. We are competing with some of the other companies in the market with similar revenue.
Started working here right after college and
was learning a lot of things on my way. I have worked on some challenging problems which make me learning and advance as a developer.
In the past 4-6 months though, the shift has all moved to not just delivering release but to manage them end-to-end. We don't have any tech leads in the company and this is an expectation from individual developers like me, about 1 to 4 years into the industry to run the project, not just develop them which includes talking to customers, defining a plan, and executing it while also developing it usually in team of size not bigger than two.
This is the only workplace I've worked at yet. And I'm confused if whether to grow as a tech lead yet when I still want to learn to better and bigger software with good architectures and good code quality. Should I take a detour and focus on learning project management?
Is this also even advisable to learn project leadership of this sort?
14 comments
[ 3.2 ms ] story [ 46.9 ms ] threadUnfortunately, that's going to mean some late nights for you. To stay sharp while "managing", I'd also take on software development projects by night and weekends from other companies to keep my skills honed. In our field, you constantly have to be learning anyway, so doing similar things will really help.
Have my development skills suffered from not being a full-time developer? Probably...but not that much. I can still write code which would likely equal most of the developers that work for me. That said, I'd love, at times, to have mentors from who to learn better ways. The web is my mentor for now.
I will say that staying sharp on the development side has really made me a more effective CIO. I can call bs on our vendors when a less technical CIO would've bought into their sales pitch. I can keep my employees honest and can see paths to solving issues that other CIOs might not.
So...consider both. FWIW
If you're trying to pick a career path, you need to ask yourself why you work at all. Are you trying to be someone well known? Is it all about the money? Do you crave organizational power?
Figure out what you enjoy about work, and you might get a better idea about where to go next.
If you really want to hone your craft as a dev, you need a mentor. Spending more time as a dev without one is going to be a very inefficient path forward.
Also, don’t freak out too much about it. Careers are long. Especially at the beginning of them it is easy to lose sight of that.
But basically everything we've found in rigorous study suggests that to master something you need a mentor/coach. It's not that you can't' figure the stuff out on your own. It's that you will save tremendous amounts of time by not doing so.
So one of the big weaknesses of going to work for as startup, especially as a newish dev, is that the mentorship opportunities are frequently lacking (startups have a hard time paying what mentors are worth). But this just means that you have to account for that in other ways:
- make sure your next job is geared around the mentorship opportunities
- go out of your way to develop mentorship relationships outside of work.
There are lots of very good benefits to working at startups. Just be aware of the trade off and make sure you are accounting for it in your career plan. Careers are long, no reason you have to optimize for each thing at each job.
A tech lead is a different role than a PM. Tech leads should be mentoring junior devs, guiding overall solution and working with a PM from a technical perspective like being a sounding board for crazy customer ideas.
Your company is small enough to keep dabbling in the project mgmt while coding. You don't need to make any decisions, just see where it goes. You may want to suggest to management that if there are enough devs doing PM tasks spread across X projects, at some point it might help to get a PM to do the PM stuff, then devs can focus more on development.
Having done the PM role, SW Mgr role, and lead engineer role, I found the PM role the most tedious/repetitive and missed coding. The problems being solved by a PM weren't technical and that is what I missed.
It ultimately comes down to what interests you more.
Not saying finding such a person is easy btw, but could be worth considering?
~40 years of "total career", approximately speaking, and usual caveats re YMMV, is a long time. 3 years coding then 37 years managing/leading isn't necessarily the best balance. That is another factor to consider. Drifting from hands on tech this early could cause you problems relatively soon into your own career.
Honestly, it's up to you. There is no "right" answer here, although there might be a "right" answer for the company (i.e., they need you to step into a leadership position or else they need to find someone to be your new lead).
It seems like you're confusing "tech lead" with "engineering manager," because most tech leads spend a significant amount of time coding. The tech lead on a project is the person who shapes the technical direction of the project, knows all the ins and outs, and helps other people on their team from a technical perspective.
At many companies they might have 1-2 reports, often junior people who need active mentorship, but most of their time is spent on technical + project management work.
I recommend the book _Project Management for the Unofficial Project Manager_: https://www.amazon.com/Project-Management-Unofficial-Manager...
A very coarse generalization is that tech leads own the "how", engineering managers own the "who", product managers own the "what", and project managers own the "when".
At smaller companies these responsibilities naturally blur together. It also depends on the nature of the business. If the company has a big client services component with lots of custom integrations, then project management will almost certainly be its own dedicated function.
Give it a shot and see how you like it! Speak with your boss and say you're unsure of whether this is for you, but you'll give it a college try. The worst that happens is you learn you don't enjoy that type of work.
1. Define what you want the end of your career to look like.
2. Next think about where you want to be in 1 year, 2 years and 5 years.
3. Identify skills which you can learn to help you achieve your goals for each time horizon.
4. Identify opportunities to develop those skills.
It's important to remember that your career and desire shift and that is OK. You should embrace that change.
At the end of the day, what we shoot for in our careers is rarely what we end up getting. Just do your best to figure out what you want, evaluate your options, pick a path, and commit to that path 100% for as long as you care to. We're all making things up as we go. As we gain more experience, we just get a more evolved sense on what is likely to be a good fit. You'll always be in the position of not knowing which path to choose. You get better at accepting that & having the confidence to make wild ass guesses.
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!