How to Try Out Management

I get why they do this - I think in a lot of companies, a first-line tech manager usually does some IC tasks mixed in with managing tasks.

Having been in a similar role, I've found that the reality isn't that there are just dials you can tweak as the author says, but that time management is much more like what's described in http://www.paulgraham.com/makersschedule.html ... Once you take on direct reports, your day just gets interrupted more, and when it's interrupted more it's hard to do the same kind of deep thinking through problems. If you are new to managing, chances are you'll be managing people earlier in their careers as well. Since those new in their career need more guidance, you'll be interrupted a lot.

You can, of course, create blocks of time on your calendar. But as a manager, things come up: if someone on your team resigns or is having a performance issue you need to deal with, you can't just leave that for the next day.

My first manager was an ex coder who I remember for two things. One of them was that he would constantly lament giving up development for management. That has been hanging around me like a spectre ever since.

I know a few things. I know that some aspects of our development strategy are not under my control, and there's little I can do besides beg and cajole. I know that line managers don't have much more control over that process, and that if you get any higher in the org then you won't even see code let alone touch it.

I also know, through my career and volunteer work, that I can manage about 6 people sustainably. And that pigeonholes me into line manager where I get none of the things I want.

And because of that, I've barely gazed at the grass on that side of that fence, let alone yearned for it. I'll continue to do tech lead and mentoring work and the major changes from here on out will be the kind and reach of the projects I associate with, not my status within those projects.

> Why not call them a Junior/Associate Engineering Manager?

How about "because putting Junior or Associate in someone's title diminishes their importance to the project and these people are some of our most senior technical people. Making a joke out of them will encourage them to go work for someone else"?

I've always struggled a bit with the use of tech lead type approaches. I know it can work, but there are some real pitfalls and more effort needed than is often expected.

For people to succeed in it they need to understand that the skill development will require hard work and focus, and they will probably not ever be as effective in either role as they would doing only one. The organization side needs to understand the latter point too, but also that without real mentoring and support this will likely fail. Even worse if the failure is then blamed on the insufficiently supported new manager.

NB: I'm not suggesting this is an issue in OPs case, just that it's a common pattern I've seen in different organizations.

Something to keep in mind is that this is an example a difficult type of hybrid job, one where the roles themselves are basically orthogonal in the sense that doing well at one can limit your effectiveness at parts of the other. Such jobs are inherently unstable and without additional effort will tend to fall apart. Compare this to hybrid roles that reinforce each other (e.g. editor/writer, some design/implementation roles, etc.).

Some of the specific advice in this guide is great, but I really think all the advice about managing people is about competencies and strategies that a good engineer should also be developing. People get caught out because for an engineer the role often doesn't involve explicit one to ones or anything with other team members, but the best way to have an influence beyond your own skills is through your ability to influence other people.

The only other thing I think is missing in this article (and fair enough, it's long, and you can't cover everything) - is about the expectations. One of the most difficult parts of making your way into the glorious role of Lower management is that you're generally in a new role, and so it's up to you, your subordinates, and your boss to define what is your role. Very often your boss was doing your role (as part of their larger role) previously and it'll be a transition to get them to a place where they're coming to you instead of directly to your team, and it's clear when people should be coming to you.

>Add on another 8 weeks (16 in total) before introducing constructive feedback so they are used to your communication style.

There are lots of good tidbits in there, but I can't agree with waiting 4 months to offer constructive feedback. Failing to provide constructive feedback is one of the biggest mistakes new managers make.

This is just my own personal opinion based on what i've seen but, some people should be managers, they enjoy it, they're great at it, it's their career path. Some people shouldn't be managers, no matter how good they are at something, it bores them, they don't like directing and organizing people, they like working on direct specific problems, they are actually really good at whatever skill it is they're being considered as manager for.

Some anectdota, a friend of mine, was really good.at.their job, they'd worked hard for the better part of a decade, trained some good people and grew the company, took a role as manager while his trainees took on his old duties. His job became pretty easy, his employees were good and didn't need much management, the rest of what he needed to do was pretty simple by comparison, his job came with a pay rise, but, he became fucking miserable.

He didn't get to work on the day to day things any more, when problem did occur, he couldn't really get his hands dirty, he'd delegate and the problem would get solved. Though, when something did actually go wrong, he was responsible, when there were complaints by employees, disputes and other things, he ended up dealing with them and he hated it.

Contrast that with another friend, he was good at his job, but didn't really care that much about specifics, tended to already be the kind of person who would delegate or organize, always the party host or the event organizer kind of person, also got promoted to a management position and couldn't be happier. He's the kind of person who'd always talk about the results of things, would brag about group achievements like personal achievements, and generally always cared more about end results than processes and from what I know, is a pretty damn good manager and is happy with their career path.

My first friend though recently had the opportunity to go back to a more technical role and has been a fair bit happier since.

Just some of my observations anyway.

This is excellent. Honestly, even experienced managers would do well to read it. Actually, ICs should read it as well, so you have better context for your manager’s priorities.

Regarding feedback: "Please be on time" is not a very valuable encouragement. It's obvious. Of course one should be on time.

The next sentence should have been, "What is preventing you from being on time?" Or something like it.

I like that - author is clearly clued up

I find it quite fascinating how this concept of moving into management is different from finance. There is still a lot of emphasis on actual doing here. Which makes sense in the "technical lead" sense of the title

e.g. It would never have occurred to me to include pair programming as part of management

Article also seems to imply a fairly flat organization. i.e. managing very few people / grades. By the time our guys get designated manager they've got 20 people reporting to them & have realistically been "managing" for years already.

At work, my manager's profile image on slack is mapped to ":chartsandgraphs:" mainly because it seems like he only deals with charts and graphs :P

All the points made in the blog post is valid but people should take note that their experience may differ wildly depending on the team you are managing and the goals of that team.

While most of the article is good (not that my opinion as a developer without a keen interest in management matters that much), there's a particular sentence I can't agree with:

> Fortunately for you, coding is no longer your highest value skill.

No, coding is the most valuable skill; without the code, there's no product. Maybe I'm biased, but I just can't agree with the implication that what creates the product is not the most important part of, well, the company selling that product.

It's why, if I ever manage to start a company, the developers in it would always have the highest salaries possible (within the company at least).

Nice summary of what makes a tech lead manager. I could have said it in similar words. I was managing teams of up to 8 people this way. Sometimes more, sometimes less, but I basically always managed teams. Until I hit a roadblock.

It was a time when I was working with very little coaching from above. I thought I was doing well, I had great loyalty in the team, and I thought that I would soon advance to being an “ordinary” manager. Change of director, and much more involvement of the new person in what I was doing day to day, and soon I got very clear signals that I would not be manager material. That was it. Soon, the world was turned upside down, and a very different set of people came into lead positions, while others left. Apparently, a different culture had set in.

What I had to learn over time -

- managing up and managing across is at least as important as managing down. You can be the greatest coach to your team members, but if your prime internal partner isn’t talking favorably of you you’re not in a great position. I had only a few presentations to do for upper management, but those did not go well - partly because of content, but also partly because at the time I didn’t come across as confident. I wasn’t able to sell what we were doing, and that didn’t land well.

- the management that surrounded me liked the “sensing” type, in Myers-Briggs nomenclature, wheras I’m deeply rooted “intuitive”. What does this mean? Sensing types perceive the world as it is, through their senses. They value concrete actions and tend to favor short-term thinking. They get unconfortable when things are too abstract. Intuitive types create the world in their heads, and then bend the real world to become close to their imagination. You should know the culture you are surrounded by and how you fit in. Chances are that as a manager you are better of being a “sensing” type. As a leader, though, being a visionary might be just fine. These are needed, too, but they probably have not advanced through a management ladder.

- if your talent is in being a tech leader, this talent might become a liability if you’re leading teams. In fact you might have to deal with a team that has quite average technical talent compared to you, and you still need to let them go in order to maximize the team’s potential. Otherwise, chances are that they continue to look up to you to give them the technical direction, and that is neither a great way to boost their careers, nor a good way to remove yourselves as the bottleneck.

- There is an initial impulse to try showing what a great manager you are by asking for a large team. The opposite is true. Large teams are a liability, and require you to deliver large impact. It is better to be impact driven from the start, then the team size will follow suit. There might also be cases where you should ask for your team to shrink.

- The manager is also responsible for setting the tone, the culture of the team. This should be aligned with the business, not with the team itself. Typical example is when there are competing teams with overlapping responsibilities. A bad manager might just become competitive and play zero-sum games. If you’re doing it right, though, you become more of a diplomat, and reach a agreements that put both teams and the business in a position with less frictions. This might in fact be your only job for a long time, and so you better have a team that can work independently on the technical aspects.

Long story short, management is a profession that is very different from a development role and a TLM role. Being good at one is not a good predictor if the other, and in fact I would say they are slightly negatively correlated.

this is a great summary.