I just switched jobs to tech lead with a small team of about 6 other developer. This is my first tech lead job. What do I need to know? At first I won’t have people responsibilities (thus no 1-on-1s or career development for my peers), but only tech. Later those responsibilities will be added.
I found this to be a good read.
Any blog posts or even book recommendations? 
I think the book “Herding Cats: A Primer for Programmers Who Lead Programmers” is one of the first that you need to read and repeatedly refer to in your daily work.
Book ideas will help you set up your work and organize your workflow.
Congratulations on the new position!
The answer(s) to that question depends a bit on what kind of tech lead role you will have. In my experience the term “tech lead” isn’t as universally defined as many other roles and I have seen very different roles all have the name tech lead.
In most places I have experience with, a tech lead role is not a management position, rather that is a separate tech/engineering manager role but it sounds like it’s included in your role description (at least in the future).
Which other responsibilities are included that you know of?
Thanks Hallski.
Yeah, I gathered that tech lead doesn’t always mean the same for each company. Here it’s going to be a technical responsibility only at first and then gradually slide into being team lead as well, combining those two roles and responsibilities.
Mentoring the current developers. Helping guide the product roadmap. Define the technical roadmap. Have fun. 
Ooo congrats @ohm! What kind of projects will you be working on?
I’m not sure if it’s what you’re looking for, but @jrothman has written some books that you might find interesting:
The latter two are not specific to programming/tech leads but might be worth a look all the same 
I clicked through and thought oh great it’s got 4 stars… then scrolled down to the first review 
I was going to say that I agree with @Hallski too, so thanks for clarifying! It looks like you’ll be overseeing the tech side of things then, such as deciding what languages, frameworks, methodologies to use etc? In which case you probably have most of this covered anyway (due to your experience and interest in the field) but an area where you might need to brush up on is planning and communicating, perhaps specifically outlining things for the benefit of others (such as the roadmaps you mentioned). Again I’m not sure whether they’re the perfect fit, but a couple of other books from Johanna might be worth a look!
The funny thing is when I saw your thread and that you were looking for books on the topic I wondered whether there would be many to choose from - seems like there’s a lot! If you read any please let us know how you get on! :+
Wow, lovely coincidence. I went over to the bookshelf earlier and collected Behind Closed Doors by @jrothman and Esther Derby to suggest it (there are several books in the PragProg management section that I found useful when getting into a management role but I especially liked that one).
That sounds similar to my current role and to me it’s mainly an extension of a senior developer role with more focus on communication and less on coding so I agree with @AstonJ, you likely have that part figured out already.
Three aspects that come to mind from my own experience that may or may not be as obvious:
Make sure you are solving the right problem. Many teams have a tendency to jump straight into solution space before having a well defined (and the correct) problem. As the old quote “A problem well-stated is a problem half-solved.”.
Support your product manager/owner and make sure to make yourself available early in product discussions. Not only will your PM/PO love having someone around that understands the technical aspects, it will also allow you to help guide product decisions towards more technically feasible solutions.
Document decisions. Both for the team to later go back and understand why a decision was taken but it is also a great resource when onboarding new people.
Thank you!
Wow @AstonJ. That’s a lot of books recommendations. @jrothman if you could only choose one, which one would you pick? 
I agree. In the beginning it will just be an extension of the Senior Software Developer role. I would say communication would be more important than management in the beginning as well.
What? So no “Move fast and break things” 
(I’m just kidding, of course) From previously in my career I have a healthy relationship with so-called “Project Briefs” where we described everything we were going to investigate/build in detail, who the stakeholders were and who was responsible for what.
I got the recommendation from a friend to “overshare and over-communicate in the beginning” as well as “answer every email, text, tweet, slack message, etc immediately”
In software development we always joke that there are two hard problems: Cache invalidation, naming things and off-by-one errors. I would say that the hardest of them all must be writing good documentation. Any tips on a framework for doing this right the first time?
Yeah, identifying those are great for building understanding of what the problem actually is. Using this simple question and ask it with different emphasis is a great way of uncovering a lot of open questions:
https://twitter.com/jfairbairn/status/1379579191151063041
I agree with the first part of that recommendation, just need to be mindful of sharing in a way that doesn’t trigger different discussions leaving you in a whisper game synchronisation role 
About the second part I’m a bit more wary as it can lead to building a culture where people expect instant replies to everything. I’m a strong proponent of asynchronous work flows where people have more control over their own time and when to deal with requests rather than being interrupted throughout the day.
In my experience, the key is to make it lightweight enough for people to not feel it’s a burden.
There are a number of different similar “frameworks”, like Architectural Decision Records that you can look at for inspiration. Just keep in mind that if it adds too much friction to the discussion, it’s likely not going to be used as much.
I’ve been using a low friction “RFC-like” work flow in several teams and it’s been working pretty well (with some reminders now and then to move a discussion from Slack or Teams to capture the discussion as well as the decisions). If your code is in Github (or similar), using Github issues with a special label works great for this. It goes something like this:
The format for the post can be more or less strict but I’ve found it’s better to have an underdeveloped post than to not have it at all. It’s a flexible starting point and then you can add as much structure you need within the team on top of it.
And of course, the first post would be a suggestion to adapt the process, describe it and serve as a blueprint for how to use it.
I love it! 
Although, maybe the order should be:
Oh, for sure. “Immediately” in the sense that you shouldn’t postpone an answer after you’ve read the question. If you take the time to read an email, text, slack whatever, you should also reply. It’s good dating advice as well Never leave somebody on read.
The “RFC-like” format sounds nice. How do you know when the discussion is over? Are they timeboxed in some way?
Start with Practical Ways to Manage Yourself. That’s the book that helps you decide which actions to take yourself, which to do with the team, and when to let the team do it themselves.
I find this “technical lead” role quite challenging. If you’re a senior member of the team, your job has to be to support the learning of the rest of the team. If you’re a technical-lead-on-the-way-to-manager, you focus even more on supporting the team’s learning and each individual’s learning.
I have the technical lead/management continuum in Practical Ways to Lead and Serve Others.
I would ask who are we building this for? What benefits will they get? Those questions help define the overarching goal for the work. (My $.02)
I’ve found that within a team it is usually quite easy to sync on when something is considered explored but when working cross-team setting a date for when a decision will be taken can help everyone involved to know when they need to comment in order to participate in the discussion.
Congrats! The Mythical Man-Month: Essays on Software Engineering should be a good book to read. 
I’d like to add this to the list:
I attended a two-day workshop with the writer, Patrick Kua, who offered some great insights. Have a look at his site, it has some interesting resources:
I got thrown right into the mix.
The old “tech lead” is still around (they’re partner in the company), so it’s a great opportunity to ask questions about the current state of the application.
Everybody agrees that a bunch of bad decisions have been made regarding coding practices and choices tech-wise.
I have a whooping seven developers(!) to lead. 3 juniors, a mid-level and three outsourced. For now it works fine. I have had one-to-one with each of them and plan to make it a monthly thing.
I have started cleaning up in a lot of processes regarding the tech stack, for example how to deploy, CI, and more. The backlog is large, but we have two large current projects, and I won’t fiddle too much with the project process before they are done.
All in all I think it’s going great. 
Sounds good and great that you got the support from the previous tech lead as well. 
I hope your new responsibilities are going well! I have heard good things about “Peopleware: Productive Projects and Teams” (it’s on my list of books to read). It is more about the product management side but as a tech lead you might benefit from that perspective.
