
How to Try Out Management - acconrad
https://adamconrad.dev/blog/technical-lead-management/
======
jkingsbery
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](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.

~~~
acconrad
> If you are new to managing, chances are you'll be managing people earlier in
> their careers as well.

I agree with many parts of your comment but I think this comment warrants some
caution.

In many cases, adding in a layer of new leadership is to help spread the EM
demands across all ICs, not just those new to their careers. I have TLMs who
manage senior and principal engineers.

My job, as director, is to guide those TLMs into understanding the exact needs
of those direct reports, regardless of the ICs rank or role. Everyone is
unique in their needs - not only in their role but as people.

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

~~~
jtreminio
> who I remember for two things

I'll bite, what's the second thing?

~~~
hinkley
Oh, I introduced him to “kakipea” (kaki no tane with peanuts) , a Japanese
snack food. He alternated between shoving money into my hand when we went to
the Asian market for lunch and then cursing me around a mouthful of them the
next several days and calling me his dealer.

------
hinkley
> 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"?

------
ska
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.).

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

~~~
hinkley
When TWD was still new on TV and everyone loved to chat about their end-of-
the-world survival strategies I would joke that in the Apocalypse I'd be a
tinker and head of HR.

Both of these sound like menial jobs in the 1st world but if you can repair
broken shit _OR_ you can decide who has useful skills (and ultimately, who
stays or goes), you are one of the five most important people in the group
(and I could be two of them). They'd look at me funny and go back to talking
about what machete or door design was best.

Being able to find things that people can excel at (or at the very least meet
expectations) comes in pretty handy at work. You have the people you have,
what's the best outcome you can get out of them? Not a conversation everyone
wants to have, but pretty damned useful when it does happen.

~~~
hinkley
> head of HR. [...] menial job

I'm sorry, that came out judgy. If you're Head of HR for a 300+ person company
that's a lot of work, a lot of responsibilities and a ton of coordination.

If you're 'Head of HR' for a ragtag group of 20 people that's a title without
much gravitas. A head with no tail is just a node.

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

~~~
acconrad
Thanks for the feedback. This was based on the guidance I received from "The
Effective Manager." The idea being that brand new managers need enough reps in
conducting one-on-ones before they start introducing new concepts. So...

1\. 8 weeks practicing 1-1s

2\. 8 weeks practicing positive feedback

3\. Introduce constructive feedback

Obviously YMMV so if you build rapport quicker you should totally incorporate
things more quickly

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

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

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

~~~
lojack
The feedback was more than just "Please be on time". It was proceeded by
multiple statements on the impact of being late. The fact that you should be
on time is obvious, but the impact of not being on time isn't always obvious.

Everyone responds to feedback differently. I'm personally a very direct
person, and asking whats preventing me from being on time is just going to
make me feel like you're talking down to me. Understanding why it's important
is enough, let me be a big boy and figure out my own time management. Others
hate being told what to do, and would prefer to work through a solution
collaboratively.

~~~
kqr
Right, but if you find it obvious that one should be on time, yet you aren't,
there are two possible explanations:

\- You are trying to be on time and failing, in which case telling you to try
harder is unlikely to help. There is an underlying cause for your involuntary
tardiness that must be addressed; or

\- You are intentionally disregarding being on time, because something has
made you think that is acceptable. There is an underlying cause to your
_voluntary_ tardiness that must be addressed.

Either way, people generally have a reason for doing things the way they do
them, and willingly ignoring this reason is generally ineffective at provoking
change.

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

~~~
acconrad
> _By the time our guys get designated manager they 've got 20 people
> reporting to them_

Oof, I hope not directly. Based on this evidence (also in _An Elegant Puzzle_
) you wouldn't want more than 8-10 direct reports:

[https://lethain.com/sizing-engineering-teams/](https://lethain.com/sizing-
engineering-teams/)

~~~
ska
Poster didn't specify if it was direct reports or span of 20.

That said, if you are correct and it's direct reports - agree that's bad sign.

~~~
hinkley
If it's indirect reports, that means there's an org tree 'beneath' you... How
are you not _already_ a manager in that case?

~~~
ska
Right, that's what "span" means.

It would be a big step for a first management role, but not insane. The first
time I did it got up to about that number in less than 3 months, so not day 1
but not far off it. This happened by having a regular sized (i.e half dozen)
team first, and hiring another dozen person team soon after where it made
sense to put them under my group.

The only reason we tried that is that a) things were going well and b) I had
good mentorship in the role with the commitment of real help (i.e. _time_ )
from them if things started to get shaky.

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

------
luord
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).

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

------
thatiscool
this is a great summary.

