12
votes
New to Leading a Team of Software Developers
Hey Tildes, I got a job directly supervising a small team of 4 software developers. I'm very excited at the prospect and would like to put my best foot forward. To that end, I would like to have a discussion around a few topics. Feel free to expand the scope if you believe the conversation would be beneficial. I'm sure I won't be the last person to be in this position. I've done research, read, and watched videos regarding several of these questions; however, since Tilde prioritizes high-quality discussion, I thought it would be a fun opportunity to chat with others about these topics.
- As a member of a software development team, what are things that your supervisor has done that has had the greatest (a) positive and (b) negative impact?
- Supervisors, when you joined your new team, what was your methodology for reviewing the team, projects, and processes? What was the scenarios behind your review and the outcome? What would you do differently?
Some random points:
Yeah. The human side is so often neglected. The thing that I see many managers fail so hard on is what I see as the true test of management/leadership: a willingness to have uncomfortable conversations about the human aspect. Is someone being unreasonable? So many managers will tell the reasonable party to let it slide because it's easier to ask of someone reasonable than someone unreasonable. You let this shit slide for a year and watch a team fall into complete dysfunction. Nothing else will matter if you can't get this right.
Random other thoughts:
Trust but verify, or don't micromanage. If you ask someone to do something and they aren't junior just leave them be. A few days or whatever. Set the expectation that they should come to you with actionable information and feedback because push is better than pull.
Don't give people tools for reporting feedback and then make them use some other channel to make it easier for you to do reporting.You laugh but the number of idiot managers that have both insisted on jira and then wanted people to track time / tasks in some janky-ass spreadsheet. It's embarrassing. One of my fav managers was a JQL god and just made jira his toy and it did all the heavy lifting. No one needed to remember the process because the process was enforced in the ticket workflow. Nice.
Don't be afraid to change course or admit a mistake. It's something I can't stand in coworkers and it's something I absolutely do not tolerate at all in managers. You shouldn't be punished by your team for making mistakes, and you shouldn't punish them by failing to ack them and move on.
Lastly: the best managers clear the way for their staff, the worst seem to think they are some reporting layer dying to be automated away.
Good luck!
As a team member: my boss was more knowledgeable about the library we were using than any of us, and encouraged us to ask him for help if the what we needed wasn't easy to find in the docs.
The greatest negative was with another boss who let a certain team member take his pick out of everyone else's assigned tasks because he was "more productive". The guy worked unpaid overtime, so his daily output was really fast. The quality of his code was shit, though (maybe because he was exhausted all the time) and it bit the project in the ass. It also resulted in waste work, because he would often deliver his version of a task someone had already started working on.
Unfortunately a lot of people in management don't quite grasp the concept of "technical debt". It doesn't matter how many tickets someone can blow through if the entire team's throughput ends up grinding to a halt because they have to fix the bullshit that the other person hacked together in the first place.
Do it right or do it twice, as the saying goes.
I’m also partial to 'slow is fast and fast is slow'.
Ha! I like that one :)
Additionally, "don't stick to a mistake just because you've spent a lot of time making it". I've scrapped days of worked just because the solution I had was obviously terrible and there clearly had to be a better way to do things. It's been worth it every single time.
SO. I am not a professional developer. I have never been a professional developer. But I did work in a tech startup once with a five person Android app team, and a three person iOS app team. I was in charge of maintaining the Git repositories (in the days before Github), the application's custom network protocol (both clients and server), and the actual server infrastructure.
If I could give you ONE piece of advice, it is this. Never be afraid to just stop everything and talk with your team. Or at least encourage your team to spend some time away from the keyboard talking to each other. Our entire team essentially worked under the implicit assumption that if we were not writing code, we were not being productive. That every minute the project wasn't done was a minute closer to the lights being shut off.
Nobody even told us this, it just kind of became our culture. We'd show up every day, write code, go home. There'd be at least one fire to put out every day, and each component of our project accumulated many code smells from the "just add code to it" nature of our development. We'd hold occasional meetings, but there was no regularity or process to them.
Now, there are dozens of different software development methodologies out there. I'm not here to tell you which one is the best - but you should have one, and practice it semi-religiously. There is a lot more to software development than writing code. If there is no process or order in your development practices, there will be no process or order in your code.
You will probably be inheriting a more organized team than the one I worked with, but if you feel like chaos is ruling the day, don't be afraid to pump the breaks and work with your team to come up with a more orderly process. It can save everyone a lot of stress and improve the quality of your product. On the other hand, if its not broke, don't make change for the sake of change.
Again, I am no professional, but I feel like it is worth sharing my experience anyway.
Obviously all (commercial) software teams exist to serve some business, and so business timeframes, cashflow etc are all important. One thing that I have seen massively stifle progress is intransigence when it comes to unblocking progress through dealing with serious, chronic technical debt. By this I don't mean acquiescing to every refactoring wet dream that crosses the mind of your senior engineers. I mean things like builds that people are scared to touch. Anything that is blocking the feedback loop is a silent but massive tax. I have met so many managers unwilling to give a month to solve this because there is always something more important and have through their dull lack of vision setback projects by years. Tooling / Builds / Observability are key differentiators that make average teams look like 10x god-tier devs because they aren't fumbling blindly when it comes to figuring out where the gap between their expectations and reality lies.
Do not let next month become a tyrant that dominates next year in perpetuity. It's bad for the business, it's bad for morale.
It's been years since I was a developer, but here are a few things that still stick in my mind.
I've worked for managers who just bowed down to whatever the voices on high said and never pushed back. This resulted in crazy hours trying to meet unrealistic deadlines. Push back on these as much as possible.
This is important because there will be a day when you can't protect them. When that comes you don't need the team to react as if you should have done more. You want to have that relationship with them so that they know you've already done all you could and now it's time for them to step up, not start bickering and arguing.
Manager and former team leader here... You're already to a good start by giving a damn.
A few suggestions.
First. Try to setup weekly or semi-weekly "one-on-one" meetings with your team members. Just a half hour will do. Some teams love this, others hate it. The goal of those meetings is almost 100% to make sure they have everything they need, and that you understand what's going on with their job/career. I had a boss that asked 3 questions, and then opened up to chat. I love them. His 3 questions:
99% of the time, the answer is always "yes, yes, nothing" even if it's not 100% true... but if you keep asking it and meaning it, you start to hear "yeah you know this damn service is making me lose sleep and I don't have the time to go fix it" or "I feel like every project is just writing data models, just because I've done a lot of that", etc... Suddenly you know something that improves the company and helps you make the team member happier.
Second, while you want some percent of hands'-on time, you really have to understand that every hour you spend helping your team out pays back 4-5 hours of your dev time or more. You'll have weak team members, you'll have overconfident team members. Your job is to help everyone be (and stay) better than you are at coding your project.
Finally: Process is king. It should be simple, but there should be process for almost everything. When something goes wrong, you blame the process or yourself for failing to maintain the process. It's not necessarily that a good process is really that good, but a good process helps you insulate your team members from mistakes. Everyone makes them, and at even the best company, someone is going to want to crucify a really good coder because he let a minor bug through and it cost $50k or more. At the end of the day, a programmer afraid of rebuke is not going to code well.
Also, everything @webgambit said. He's spot on, so not worth repeating.
As for your direct questions:
Honestly, a good team peer-reviews anyway. Get Code Review going. If they don't yet, start with PRs for features, or voluntary review. PRs are a poor-man's code review. Almost all git apps support em. For projects/processes, look for documentation and consistency. And more importantly, does it work?
I'd stick it out a month before you start suggesting changes. Try to get plurality buy-in from the team, but realize you might not always get that. When you don't, make any run a trial run. If something is unpopular and can't demonstrably improve things, drop it.
Not quite sure how you're asking here. Examples of what goes right/wrong?
Not sure. I'm still learning my "democracy/mandate" balance, but am sure it differs team to team. Communication is always king, and the rest of your job is more about keeping the team from getting blocked or becoming slowed than anything else.