[tgittos]

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.

[stuntkite]

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

[thisoneworks]

This 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]

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

[zrobotics]

RE the architect handwriting tutorials: do you have any recommendations? I can barely read my own scribbles, and I've struggled with poor penmanship forever. I'd looked for courses/tutorials, but hadn't found anything that resonated.

[stuntkite]

I have a few friends that are draftsmen. I asked them and they said they just gave them a font and graded them on it with homework blueprints.

What I did was just googled architect fonts and downloaded a bunch of examples then used a field notes pocket dot journal[0] to practice.

I would just try to copy a font exactly, then do drills on problem letters. I probably drilled on four fonts I found that I liked. Focusing on accuracy monospacing and staying in the grid. A big thing I learned was that it was ok to slow down, it gives me more time to think about the thing, the clarity of the lettering seems to reflect the clarity of the idea. I think previous attempts to improve my handwriting had failed because I wanted to write as fast as I type. It's a different thing obviously, but I didn't really realize the benefits the slower pace has for processing things and concept recall.

I also bought some drafting tools. Angle rulers, protractor, etc. I decided to overdo a couple network layout projects and work on it in that context. The end product was so nice that I laminated a bunch and gave them to people and they’ve been a great reference!

Oh, there is also a tool called an architectural lettering guide[1] that can be helpful.

It took about three weeks to really kick in. Now I’ve got my own style and it changes a bit still and I experiment, but the core just adds to the rote process of the daily exercise. I can see by looking through the journal if I'm not fully on my game by how much drift there is.

I would probably drill for 10-20 minutes a day for the first week. After that, it was just here and there if I noticed something just wasn't working. Like when I decided Ps and Ys got flourishes, but only in some context. Also changing anything usually meant other letters would start regressing to my scrawl. It's weird how related the patterns are in your head.

Another thing that helped me was finding a pencil I liked. I ended up with a super fat 5.6mm HB firm lead on a woodworkers pencil[2]. It sharpens to a fine point and holds it forever and never breaks. Always using the same tool is really important to me now. I had to go through a bunch of stuff until I found a pencil I didn’t hate. It might not be the right one for you. I love them though and buy extras and hand them out to anyone that likes to write. My polling seems to agree that they are dope.

Here is a pretty good blog[3].

[0] https://www.amazon.com/Set-Dotted-Notebook-Travel-Journal/dp...

[1] https://www.dickblick.com/products/alvin-ames-lettering-guid...

[1] https://www.woodcraft.com/products/woodcraft-woodworkers-pen...

[2] https://www.google.com/amp/s/artdepartmental.com/2009/10/12/...

[MarvelousWololo]

Even though I was not able to understand 100% of it (non native speaker) it was a fantastic read. Thanks for sharing that!

[fencepost]

As a quick note, if you want the dot grid notebook (vs the smaller 3x5 memo books) from Field Notes, it's the Pitch Black Notebook: https://fieldnotesbrand.com/products/pitch-black-note

[amenod]

Just wanted to say - thank you for sharing this! This sounds like an incredible idea and I can't wait to try it out.

I already seem to work better when I write down whatever development tasks I have on paper, but it has never occured to me that management tasks could be handled in a similar fashion.

[stuntkite]

No problem! It was hard for me moving from dev to management. I think a key difference in the tasks is that the majority of management tasks are personal and cannot be collaborative or even public. They involve peoples feelings and behavior. Sharing them to scrum the problem would shame people for no reason and cause a mutiny. As a manager, my task is to catch chaos and distill it to comforting direction. You can’t write good software if you are aware of the terror of the day to day. Daily terror should be invisible to my team so when real emergencies happen, it’s not stacked on a constant pressure of minor annoyance. Predictability in the day is so critical for engineers to produce amazing shit. Predictability allows for room to experiment.

I think that is why journaling is so effective. If you rely on dev tools and tracking for management tasks without journaling you have no outlet for the real work of the job, sifting human conflict and ambition into a rewarding work environment. Through that, building a cohesive historical narrative that can act in defense of my teammates when shifting goals make engineering look like it failed and giving a concrete foundation for process improvement.

[tra3]

That was so great. I've been journaling for a while now but can't seem to leverage it as much as you have.

I'm especially curious about how it helps you anticipate risks. If you have a way to illustrate this I'd most appreciate it.

[eeeeeeeeeeeee]

I wish I had done something like this. Some of the insane days where you are being pulled in every direction can feel so scattered that they become impossible to recall even a week later.

[ChuckMcM]

Hopefully 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]

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

Be 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]

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

[DanielBMarkham]

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

[yuchi]

I keep returning to dev projects exactly for this.

To the OP, do not underestimate this.

[eeeeeeeeeeeee]

Yep, 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.

[alexbanks]

I 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]

You 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]

No, I work at a product company in the video games space.

[lordnacho]

One 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]

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