But I didn't get a CS degree because I'm great with people. I've had some limited management experience, mostly interviewing applicants and running standups. I'm now responsible for the performance and well-being of a team of junior devs, and I'm definitely out of my comfort zone.
I want these guys to succeed, and I want to succeed in helping them succeed. But I'm mostly flying by the seat of my pants and I'd like to learn from others who have been in my shoes.
What are some good resources I should look at? What are some things I might be neglecting that I need to pay attention to? How can I best be effective in my new role?
Some basic suggestions:
You'll learn from experience while you go, far more than from reading books (although that's still good). The fact that you're asking is a good sign. Find a mentor and meet them regularly, in person. You'll benefit from an external perspective.
Work out how to support your team while keeping everyone's expectations realistic. It's easy to burn yourself out by taking on too many responsibilities. In cynical workplaces, this can lead to you being hung out to dry and alienated, which is thankfully rare in my experience.
Short (5 minute) meetings at the beginning or end of the day are better than hours of chat. Usually.
Your job includes removing your team's barriers and problems. Ask them what they are.
Figure out what motivates individuals and empower/enable them to get it.
Praise in public, criticise (constructively!!) in private.
Constructive criticism: extremely hard to get right. Sensitivity is critical. Ask for training. Objectives need to be S.M.A.R.T. Don't dwell on the negatives. Find ways to reach the positive. You will never perfect this.
Protect your team. Do it without pissing off your colleagues and superiors. This is not easy :)
The best managers I've known have qualities that I know when I see, but would struggle to define. Breezy, friendly but professional, reliable, genuine, clear understanding of both big and small picture... difficult to cultivate all this but not impossible.
Get up from your desk. Meet people in person. Meet your mentor in person. Walk and talk instead of email/slack. Skype is not "in person". Your interpersonal skills will improve.
Finally: things will go wrong. This is painful. It happens to everyone, don't beat yourself up. Carry the good things with you and learn to let go of failure. I'm still working on this one!
Anyway. That's a scattergun offloading of some highlights I've learned. There's no recipe, but there are some basic ingredients. Oh... everyone's different as are their circumstances, and none of the above may apply.
Good luck, you can do it.
I wish I had it 5-6 years back when I stepped up as TL (it wasn't written yet).
Actually you might as well get your team members to read it too. Unlike the title might make you think - book covers both management and tech (individual contributor) paths.
https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...
Two books that really helped me:
- The 21 Irrefutable Laws of Leadership (John Maxwell)
- Leaders Eat Last (Simon Sinek)
Empathy (i.e. the ability to understand what’s going on in someone’s head) is a key leadership trait in my opinion. The good news is that you can develop this skill.
First and foremost, listen. Use 1:1 meetings to talk about how the person is doing, not what they’re doing. Ask open-ended questions. One of the most underused and most powerful questions in the workplace: “how does that make you feel?”
Pay attention to weak signals, like someone changing their daily routine, being snappier than usual in team meetings, etc. Learn how the people in your team usually behave, what they like and don’t like.
Then, put yourself in their shoes. This is easier than you think: if you’re used to writing code, chances are you can emulate pretty complex systems in your head (like the behavior of the piece of code you’re working on). A normal human being is a complex system that you can learn to emulate, by which I mean that once you know how someone usually behaves, what motivates them and so forth, and you know their current situation (see step 1: “listen”), then you can take a pretty good guess at their internal state.
Once you know how your team works, both as individuals and as a team, your job is simply to keep them in a state of maximal happiness. And they will move mountains.
As soon as we realize that we're not alone and there is a wealth of information to learn from, we are taking a proactive step in becoming better leads.
I would also suggest; - Host regular (perhaps every two weeks) meetings to discuss how the team are feeling. Gather their feedback and make changes based on it.
- Do some light reading in your downtime on the topic.
- Try to think in their shoes. Imagine what it would feel like working for you if you were one the dev team. That will allow you to appreciate where they are coming from.
All in all, be positive!
Ensure every complaint is met with a positive response. Make everyone feel valued. Always listen to their opinions.
Have fun!
Also, join Rand's manager slack. http://randsinrepose.com/welcome-to-rands-leadership-slack/
Even if you only have time to lurk on that slack, the discussions have been incredibly illuminating for me!
---
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!
Shots fired
