7 ms·
I made the jump from developer to team lead, and all the advice here is great. One thing that I wasn't prepared for and that I don't see other people mentioning
by tgittos 8y ago
I made the jump from developer to team lead, and all the advice here is great. One thing that I wasn't prepared for and that I don't see other people mentioning (on a cursory glance at the replies) is that your reward function for job satisfaction changes, and the feedback loop length changes.
By that, I mean that for me personally I derived most of my job satisfaction from solving tricky problems, fixing bugs and implementing features. I would get that reward daily, or at least several times a week. When you transition to management, your job satisfaction has to come from watching your team members grow, your project mature as bugs are fixed and releases are made. I would get that reward maybe every month, if not every few months.
I couldn't handle such a long delay in the reward feedback loop - it made me miserable at work - so I transitioned back to development.
Just something to keep in mind as you contemplate the change.
- yuchi 8y agoI keep returning to dev projects exactly for this. To the OP, do not underestimate this.
- DanielBMarkham 8y agoAnd this trend continues. The further you get from development, the vaguer the terms are and the longer and more imprecise the feedback loops. (In fact, I'd argue your job consists of creating useful and lightweight feedback loops) This can be quite frustrating if you're not prepared for it.
- ChuckMcM 8y agoHopefully the parent comment here will stay near the top, it is the key thing to keep in mind, the rewards are different. As a line manager (you manage people doing the work) your #1 goal is to have your team be super good at what they do. That means developing peoples skills in their technical specialty, their ability to understand direction and act on it, their ability to communicate where they are with the rest of the team. You need to learn to recognize when team members are being counter productive (passive aggressive, competing to win), and when they are being under productive (not challenging their own self perceived limitations). You want to average out those behaviors so that your team trusts in the skills of the other members, trust in your willingness and ability to deal with problems, and trust that you will recognize the effort they are putting in to make things work.
- Yhippa 8y ago> and when they are being under productive (not challenging their own self perceived limitations) I'm a fairly new manager and I'm working really hard on how to word something like this to my devs. Do you have any advice for that?
- effhaa 8y agoBe honest with them, and MUCH more important: Be kind, when discussing this. Something along the lines of 'Hey, I realized that something seems to be off since a while, is there anything I can help or change, because I really want you to be happy and productive' works best for me. Pretty much everyone wants to be recognized, happy and productive in their lives, and this usually extends in their jobs, so most likely, that person needs help, to recognize or solve the situation. Sometimes, they just dread for whatever reason the task they have ahead of them, and need someone to talk to. Sometimes it is some time to solve a challenge in their live outside of work - then it might be your job to shield that person to some extent, while also making sure this does not take a toll on your remaining team. Sometimes it is a social problem in your team. Sometimes the assignments for that person dont match what they can and want to do. And of course, sometimes the team, the job, or the company is just no fit, and it is perfectly fine to help there as well. But again, above all: When talking about this, when trying to help, keep in mind that you are the manager, which always implies a power imbalance, no matter what. Such can easily be perceived as a threat instead of help, and if it is perceived like that, you will make the situation just worse. So be kind, listen, try to coach and help, even if your inner self is annoyed with this. It rarely helps to play the testosterone driven top-down approach, unless, of course, you tried the other ways before with no success.
- ChuckMcM 8y agoIt is something you have to develop an intuition for. There are two very different areas that you might find yourself in with performance management, employees that slow down, and ones that never speed up. The first is an employee who was getting lots done and always could be counted on that becomes slower and less reliable. If you have developed trust with your employees then they will be more likely to share with you something going on that has changed or otherwise effected their work effectiveness. I have experienced situations where spouses have become quite ill and needed more attention, and people who have had their teenage kids take a hard turn down an unproductive, if not destructive path. If it is situational then you work with your employee to rebalance their needs, they may need to take some time off to find a new equilibrium or get things into a new normal. Give them the space, and let them find their new groove. If on the other hand it isn't a situational thing, perhaps they just don't like what they are doing any more or, as one of my reports discovered, they like doing something else better (in this case music), the right thing to do is to help them move on to that new activity. That can be really hard if they are hoping the can work part time on a full time salary while pursuing this new passion of theirs, at the end of the day you need people who are as committed to working for you as you are in managing them to be successful in their job. The other situation is someone who is exhibits potential but keeps holding themselves back. Intel used "managing by objectives" and their mantra was if you met all of your objectives you probably had not set a high enough bar. The tool here is to talk with them about what needs to be done and when, push them out of their comfort zone, and then watch closely how that works out. Keep in mind that the goal isn't to get someone to work 60 hrs a week (this will burn them out), the goal is to work with them so that they can make as much of the time at work productive. I really only have seen this reliably in new college graduates. They have study skills but not "design" skills. A session might be like this; Start by giving them a task and a deadline, ask them to identify as many different series of steps (plans) that they think will get them from today to done. Then ask them how they might recognize that a plan isn't working. Once they have that in their head they can go forward on the chosen route, and ideally let you know if they discover it was a dead end. If it was, talk about how it ended up becoming blocked and think about some ways you might test at the beginning if that was going to be the case. All of this hand holding at first is to train someone to think about solving problems where there isn't a "known solution" sitting in some grading manual somewhere. Engineers need to develop an intuition about the "design space" things can be pushed and things that can't, and how those freedoms or constraints are going to make it easier or harder to get done what they need to get done. These are the kinds of things you will end up talking with them about in your 1:1's. Always remember, that because we're talking about people here and not machines, they all respond a bit differently, have different reasons for being there, and different definitions of success or failure. Your job as their manager is to translate things the company needs to get done, into requests that your team can deliver.
- stuntkite 8y agoThe most effective days of management seem to involve so much compromise that everyone is frustrated with me. It’s got not no real hit for solving problems. Also it is all fuzzy and human. A lot of devs that are pure engineers find management maddening. Something that helps me is writing daily. Keeping personal strike lists and logs. This is private and in a journal, NOT jira or whatever. I track my daily emotional state and have a matrix for disappointment, frustration, anger, and stress. 0-4 also noting if its targeted at a specific person. This helps me evaluate why so I can find a positive solution and not be irrationally shitty/counterproductive. I review the last 3 days every morning and go over the previous month on the first. This helps keep me positive and helped me see that when the real work is being done it often feels like failure. My year review of logs was actually full of positive surprises.
- the_greyd 8y agoThis is super interesting. Something I've started doing on a smaller level. I've already made good progress on managing my emotional state (thus productivity) and want to improve the habit. When do you schedule to write or log? Specific times in a day? If you had a template I'd assume it would include mood tracking and todo list, anything else? Thanks for sharing this.
- stuntkite 8y agoI do all the writing first thing when I sit down in the morning. Before I talk to anyone. I use a dot journal, kind of like a graph paper moleskin, but a dot grid. Date the left page and time. Do feelings. I’ll also note the weather, if it’s a special day or holiday and if people are around, who. Then I review the last few pages and I start musing. On the right page I title “<project name> todo:” and start making the list. As I roll over previous day unfinished tasks I x them out on previous day and see if they need to be reworded or broken out. Completed tasks get a check. The body of the left page is free space. Sometimes I’ll write out a conflict I am trying to process. Sometimes just list house chores. Sometimes I draw out process flow or network layouts. I try to empty my head of all the things I’m juggling so that before I say a word at “work” I am a clean slate without too much wonder. I check things off and add new things during the day, but it’s usually not a lot of tasking unless there’s a crisis. A year in, crisis seems to be pretty rare now. No one else I work with does anything similar. It does frequently appear that I am ahead of risk by weeks before other people start clocking it. In the beginning the lists were all catch-up, and now they are sometimes about things coming in the next quarter. I’ve been work journaling for years but I made this effort to formalize and structure at the beginning of the last year when moving into a startup with a lot of internal problems and some huge lifts. Jira was a lie and accountability was missing on all sides. I knew I wouldn’t survive without building my own consensus on truth. I also did tutorials on architect handwriting to improve my clarity. It sounds silly, but my scribbles would vary a lot and now that structure really helps the process. I think it’s had a net positive in all aspects of my life. It’s my favorite part of the day.
- lordnacho 8y agoOne thing you can do that's useful is making sure you can still compile and run the code. The occasional minor off-critical-path edit could also be enough to give you that hit you need as a developer.
- m-i-l 8y agoI used to make a point of submitting a minor contribution to every project's code. I used to (part jokingly) liken it to Alfred Hitchock making a cameo in most of his own films. The stated reason was to make sure I had the dev tools and env set up so if there was ever an emergency I'd be all ready to help out, and the unspoken reason was to help gain the confidence of the team. I think it was a good idea, but unfortunately the approach doesn't scale to work across large numbers of projects.
- alexbanks 8y agoI want to go back. I'm not enjoying the change (or at least my company's implementation of management). It's not even that the feedback loop's length is different, it's just that there isn't any. If my team performs better, the expectations are just upped and we're still "needing improvement". Other managers here have said the same thing. I feel like I am not a leader; I am not positively impacting people's careers or lives. I feel like I'm asking people to update their tickets and telling PMs we "can't just" add something else. I'm not happy, and I'm getting to the point at the job where when I wake up, I linger in bed for a bit, thinking/negotiating on whether I should go in.
- paulgrimes1 8y agoYou don’t happen to work for a digital agency by any chance? I’ve seen multiple agencies botch implementing “management” after growing and needing to shift from a flat structure
- alexbanks 8y agoNo, I work at a product company in the video games space.
- eeeeeeeeeeeee 8y agoYep, I definitely remember this. If you're a developer, the feedback loop is immediate -- you ship a bugfix or new feature and it works or it doesn't. When you're in management, your successes and failures become a bit murkier, or the feedback is heavily delayed. You sort of need to learn to become highly self-critical and introspective about your choices and learn from the moves you make, both good and bad.