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.
> 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.
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.
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.
> 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.
> I really think all the advice about managing people is about competencies and strategies that a good engineer should also be developing.
I agree with this. At the same time, I think it's important to tease apart skills from rewards. I take all of the skills that are important for managers really seriously and care a lot about them. I work hard on my communication skills, empathy, task and time management, ability to create structure, etc. Those are basically the suite of management skills.
At the same time, I don't get much reward from a management role. When I have been in a lead role, it's been gratifying to see my team do well, but often not as gratifying as the feeling of making a thing myself. I just love building stuff more than I love coaching and creating structure for other people.
So it is important even in an IC role to work on the skills managers also need, but that doesn't necessarily imply that everyone should aim to do management work.
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.
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.
> it's up to you, your subordinates, and your boss to define what is your role
Totally! And this is exactly why we are using this TLM role so you can try before you buy into full management responsibilities.
One of the gravest errors we make in software is assuming that the only way to advance in your career is into management. That said, it's also unfair to assume that great coders will never want to manage. Having a trial role that blends the two responsibilities de-risks the business in new management while allowing developers to see if these new sets of expectations are congruent with how they want to develop their careers.
>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.
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
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.
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.
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.
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.
If you want to go the Joel Spolsky, "managing software teams is psychotherapy" route, then two other questions are
"why do you dread coming to work"
and
"what were you working on that distracted you from the time?"
Being late to (most kinds of) meeting while preventing a production outage, or helping another team, should not just be allowed, it should be respected.
This one I think happens more often than people think. And if you keep sending the message that your meeting is more important than the health of the company, well, eventually you're going to get what you asked for.
It's not at all obvious. People respond to incentives, look at the incentives given by switching them around:
- "When you are on time for meetings, you have to spend more time in the meeting". The attendee likely didn't have any say in the agenda items, and isn't interested in many/all of them. Because the meetings apparently still finish on time (as they have less time for the agenda items), they neither overrun nor get rescheduled, this could be Parkinson's Law of work expands to fit the time available. It's not clear "less time to spend on agenda items" is a problem, it is clear that "less time in meetings" is desirable.
- "When you are on time, the team will trust you to be on time". That isn't any incentive for anything; "the team will expect you to be on time proportionally to how often you are on time" is no statement at all.
- "It inconveniences the team". Allegedly; they all still spend the same amount of time in the meeting either way. The lateness means there is less time for the items, not that the meeting overruns or is rescheduled. Perhaps, scheduling too long for the meeting is inconveniencing the team more, but being late for a meeting which can still do what it planned, is no inconvenience.
- "The team will trust you more". This may incentivize people, but it a) isn't obviously true; the team may respect you more for being busy, or b) wish they could do the same. If it is true, it's not obvious that it's bad - it may be that it means they won't invite you to more meetings (hooray), or they won't dump work on you trusting you to get it done (hooray). It apparently doesn't mean the employee is being fired, which is an odd way to respond to an employee you don't trust.
Paraphrasing a tweet I can't find now from a fictional manager perspective: "It's difficult to find a time for a meeting which suits every attendee. Easier to choose a time myself. Please make every effort to attend". Is the employee late because meetings are scheduled at a particularly bad time for them? It isn't obvious that the meeting is, or should be, the employee's top priority.
"When you are late, nothing happens except you hear an earful of status signalling by people who were on time"; that's not going to change anything, is it?
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.
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.
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.
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.