
Ask HN: Learning tech leadership vs. growing as a developer? - dark_lands
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&#x27;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.<p>This is the only workplace I&#x27;ve worked at yet. And I&#x27;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?<p>Is this also even advisable to learn project leadership of this sort?
======
kasey_junk
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.

~~~
wisebit
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.

~~~
kasey_junk
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.

------
jfarmer
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...](https://www.amazon.com/Project-Management-Unofficial-Manager-
FranklinCovey/dp/194163110X)

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.

------
build_products
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.

~~~
AnimalMuppet
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.

------
rufugee
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

------
matty_makes
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.

------
PopeDotNinja
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.

------
brianmcc
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.

------
QualityReboot
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.

------
ibash
+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.

------
sirrele
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!

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

