Ask HN: Learning tech leadership vs. growing as a developer?

The entire pitch of working for a startup staffed mostly by less experienced people is being able to transition around the wide variety of jobs easily. Getting that breadth of experience is where those situations stand out.

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.

Probably offtopic, but would you mind expanding a bit on the mentor requirement a bit? Being in a similar position, I'm a little embarrassed that's not something I've considered so far and that made me a little bit anxious.

Sorry I didn't mean to create anxiousness. Don't freak out.

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.

Hey hey! I run workshops for engineers who want to develop leadership skills. Shoot me an email at jesse@20bits.com if you want to chat.

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.

I would say it entirely depends on what you want to do. Project manager, people manager, technical lead, and individual contributor are all separate career paths -- but they can intertwine if you want them to. When I work with people on my team I take this approach:

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.

Problem is, dark_lands doesn't have any basis for knowing what he/she wants to do. How do you know if you want to be a project manager, if you've not only never done project management, you've never even really seen project management? How, when you're just a few years out of school, do you know what you want the end of your career to look like? You don't have any basis for knowing that.

Both? I'm a CIO, but was first a developer. I transitioned into management from developer to a director of software development in 2003. If you're in a company like mine (and it sounds like you are) where you have to wear many hats, it'll serve you well to stay sharp on the development side while learning more and more about management.

Unfortunately, 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

Project leadership at a small company/startup is going to be much different than at a larger company and vastly different than at a Fortune 500. The path of a PM is typically to progressively manage more complex and larger projects whether in scope or budget.

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.

One thing to understand is the customers buy what they want. In this case the company company is your customer. Do they want to have an architect on staff? Do they know what an architect does? If they had an amazing architect, would they even be able to tell? Get answers to those kinds of questions & you'll start to understand if the company as exists is an a place where you can grow your career in the direction you'd like to grow.

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.

Have you considered hiring in someone with relevant experience? They could both help you out and provide a good mentoring/learning aspect. If you don't know 100% what good leadership looks like, it's hard to make that journey on your own.

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.

I think code should be treated as a craft. If you enjoy it, you'll do it anyway, even if you stop doing it for a job.

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.

+1 to figuring out what you want to do and then doing that. I was in your position a few years ago and what helped me was talking to more experienced folks 1 on 1. Reach out if you’d like to chat.

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!

apologize for my typos.. I am just about to fall asleep but thought I could support a bit!