Mistakes I've Made as an Engineering Manager
css-tricks.com
css-tricks.com
I joined a company once where a particularly skilled engineer had become a manager. She was very good at her job and I'm fairly certain had something like 'perfect recollection'.
We were in a meeting and she went on about how she was upset people were doing a troubleshooting process wrong despite having sent out a detailed email.
Not wanting to do that thing wrong I searched my email, but couldn't find it. I asked about it and she told me "Oh it was before you joined us.".
I had been with that team for two years...
People tend to remember important things like it was yesterday, but don't always realize that other people can only absorb so many important things / don't always know how important it is... and email is kinda a terrible way to communicate it too. Let alone 2+ years earlier ;)
I recently joined a great team that has lots of different services that do things.
Some people explain to you how things using names of things you don't know about, they don't realize that telling me and then we get "info from dragon" means nothing to me.
Email isn’t your knowledge base. Slack isn’t your knowledge base (unless you’re using a tool like Guru).
Use Notion, use Roam, shit even organized GDocs can work. There’s no excuse to not have things written down, maintained, and constantly shared.
I think it's better to just continually verbalize any "core values" with your team as you go day-to-day. Thinking that you've written it down inside of an organized GDocs is not much different than having sent it via email (the location to retrieve it just changes).
For example, I maintain a document that helps me keep track of bioinformatics files and some of their quirks (which files have two-line headers, etc). I do it for myself, but this information is also referred to by dozens of people in our group.
Setting up MediaWiki and throwing it up on a Linode server costs 20 bucks a month and can be deployed from a Docker image in roughly 15-20 minutes. It can referenced by everyone, anyone can contribute to it with a full audit of changes, and it's easily searchable.
I use it to document technical and non-technical things like company policies, work flow processes, security practices, coding style, pretty much anything. New employees have a standardized on-boarding process that is clearly documented step by step for them to get setup with everything they need to start being productive by their second day of working here.
It's actually fairly low effort to do this and is a lot easier than having a bunch of people have to remember God knows what and when, or forgetting and then having to ask someone else who may have a vague recollection of it.
An authoritative source of knowledge that everyone has access to and anyone can contribute to is worth setting up.
Easily searchable on my machine with grep or ack or whatever you use. Many tools (such as github, many IDEs etc.) open it up with when you open up the project, including formatting it. If you really want, you can serve it up somewhere via HTTP. When something changes I can commit it right with the changes I'm making.
Our code style is also committed. As spotless configuration files, eslint configuration files etc. You can run these locally if you want to. Our CI/CD definitely runs them and fails the build if it doesn't pass. No exceptions.
The README.md I am speaking of is actually more than one README.md. We have more generalized ones dealing with "This is how to set up your dev env, so you can actually develop stuff", to more module specific ones like "this module is special from everything else in X, Y and Z".
That is absolutely not what we're talking about here though. If a project manager really wants to set up a local dev env for whatever reason, they can be my guest but don't expect me to tailor our whole everything around them and not my developers.
But then I remembered nothing takes 20 minutes. I'll bet it takes 20 minutes to set up the wikimedia server and then 4 days of Googling to get our single sign-on to work. We'll have to figure out what to do with backups. Plus we'll need to document the documentation process itself and do the painful change management with the organization. Finally, we don't use Linux, so it would probably take more than 20 minutes to figure this stuff out.
It's a great idea, but it's a non-trivial amount of work. Not that I disagree with your approach, but I'm saddened when I think about how to get there.
* What’s being written down isn’t valuable, so people don’t trust the wiki to have valuable information and therefore ignore it.
* What’s being written down is valuable, but people have been trained to get information elsewhere and therefore don’t bother going to the wiki
I don’t really know how to address the former (“write better!” isn’t very actionable advice), but in my work I see the latter a lot, and the only way you can fix it is socially—if someone asks you a question that’s answered in the wiki, you have to tell them “read the wiki” instead of giving them the answer yourself.
People are lazy, and it’s almost always easier in the short term to just ask someone for the answer instead of looking it up yourself.
Having the information written down is important if nothing else than a source of reasoning going forward (people tend to remember do X but rarely why in my experience). However saying that asking a coworker is a bad thing is giving way too much credit to the documentation.
Additionally if you are talking about anything but the most basic associations talking with people is a good thing anyway as you can discuss your idea and see if there are problems the documentation couldn't tell you about because said problem would be listed in a different place.
- What permissions do I need to contribute code to this repo
- Where are the telemetry tables for X event
- Who’s the manager for project Y
- When will my commit make it into production
For the whys and hows that often warrant discussion, while I still think you should have basics documented (How do I add a new screen to this app, why do we call into this proxy service, etc) so that folks have a starting place, and then pursue actual discussion.
Even if the wikis are literally just the most basic associations, I still believe that would clear up a ton of repeated and honestly unproductive discussion time.
Good ops and code are usually to some extent self-documenting. If you had a wiki with 20 steps to perform some task, maybe the answer is that the process needs to be simplified.
This is a choice, not a fundamental law.
It’s very rare you find an employee that’s purposefully malicious, at least in the early stages of a company (< 50 employees). Unless you have terrible character judgement.
If what you are writing down has value, and there’s no other way to obtain that knowledge, then people will use it.
How exactly can you use an email (or email thread) buried somewhere as a part of onboarding process? How exactly can you improve that email when it shows as unclear/lacking info after you somehow managed to use it during onboarding?
1. It is easy to tell which documents are clearly marked as snapshots in time vs. living documents.
2. Most docs are snapshots, so people have enough energy to maintain the living documents.
3. There is a slack channel or team name on the living documents. That way, if you see something out-of-date and want to update it, you know where to ask.
I have never, ever seen a company where those wikis are actually read.
One company I worked with had a very detailed weekly logging of changes, important things etc. The goal was to keep other teams informed of what each team was doing. It took many times many hours a week to keep it up to date. When they looked at the usage log, literally no one logged into to read the stuff except when going into to upload their part.
The problem with documentation is that it is the making of it that creates most of the value. Like so many things the value looks like duplication.
This misses a key point.
When I get a query that's answered by something on the wiki, I reply with a link to the wiki.
If the wiki link isn't fully relevant, if possible I update it before replying.
If I have to write significant new content to respond to the query, I create a wiki page.
Your attitude of "docs are useless" is self-fulfilling.
Docs are only useless in companies that actively want them to be useless. And those companies are, with no exceptions, seriously dysfunctional.
Like most things in life, it takes active effort of ongoing maintenance.
Yes. Of course the docs are horrible, if no one can take time to improve them, because improving them is not "real work". Spending one day fixing the wiki pages to make information easy to find, that's one wasted man-day! On the other hand, the whole team spending a few hours in meetings to clarify misunderstandings that would not happen if there was one clearly written wiki page about the topic... that's okay, because communication is important.
I think another problem is that things work bad by default whenever the "customer" is not in a position to give feedback and require improvement. Suppose the developer needs an information, and the wiki page is hard to understand. The developer is hardly in a position to request a rewrite from the author -- the author has more knowledge (about given topic) and therefore is in a stronger position. Also, the author may choose to explain verbally or in e-mail, and then the wiki remains unfixed.
Still a net time savings as those people won't have to reverse engineer things.
- p2, which is basically a live blog for long-form communication. Each team has one, and important conversations happen there. The informal saying goes, “p2 or it didn’t happen”. Long-form async communication is crucial for distributed work, and slack (or email for that matter) is a very poor tool for the job. (https://wordpress.com/p2/)
- a large wiki built on WordPress (e.g. it’s very easy for anyone to publish changes to it)
Both tools are used extensively at the company because everyone understands that real-time communication doesn’t last. I think the wiki gets a lot of traction because:
- it is integrated into our global search tool.
- People share wiki pages when someone asks a question. (E.g, someone asks me about $topic that I know a lot about, and I share with them the wiki document I already wrote about it.)
- Plus, these are linked to from p2 or slack as needed.
When I start trying to get historical context for something, I’ll use the global search tool and find anything ever written across p2 or the wiki site. That normally gives me a great start for what I’m working on.
I would argue that it is a cultural failing when companies don’t have effective communication and documentation habits. Is it habitual to write that wiki page when finishing your project? Is it habitual to have large, technical conversations in a publicly searchable environment? Is it habitual to summarize important conversations (in slack or from video meetings) on these more accessible tools? Is it normal for everyone to be commenting, editing, and participating? These are all normal for me, and I think a big aspect of that is the existing company culture. (And obviously the tools make it very easy to do.)
It definitely is a cultural thing. For example at my present company no-one reads wikis, or email, or chat logs, or even error messages, because that is perceived as "low status" activity. High-status people give a vague idea of the problem then sit back and watch minions scurry about trying to figure it out. The problem is that this senior-manager example is now being emulated at even the lowest levels, so there's no-one left to actually do it.
The company I work for has at least 5 that are relevant to any single employee... as far I am aware of. That is, I'm not counting different departmental knowledge-based for different departmens or anything like that. I learned about the 5th more than a year after I joined the company, and I haven't changed positions either.
Naturally, when they teach you things as a newbie, half of the information is not on any of the 5; and if you go rummaging through them you'll find a lot of gems - but also a of conflicting, confusing, and/or outdated information (often kept up-to-date in a useless sense and thus dated recently).
Slack is definitely a good enough knowledgebase for problems with your environment setup and other transient things. We have a channel that all the devs are on and if someone has a problem with their setup they usually ask there. Since all of this stuff is sort of changing all the time or new problems come up (say because of OS updates or toolchain updates), writing it all down in a knowledgebase is sort of wasted energy and time if you ask me. Slack search is good enough.
And I don't think that it's about whether its written down either but more about people not remembering stuff and not knowing that search exists... We literally had a case last week, where a guy was reporting an issue on there and I was like "wait, that problem happened like 3 or 4 times in the last couple week", so I searched slack, found it right away and sent him a link to the thread, which had a solution to the problem. Turns out, it was actually _the same guy_ with the same problem!
Please tell me how a "knowledgebase" would've helped him?
(and yes we do have docs for the general "this is how you setup your dev env from 0" right in our source repo.
I don’t disagree that Slack _can_ be a knowledge base, but it’s not by default. For something like you mentioned, and I’m not kidding, I would have immediately written it down in a doc for environment troubleshooting. Something like Guru can actually help you do this automatically in Slack. That way you can add it to your existing knowledge base. This helps employees transition from “hey let me ask Bob” to “hey I’ll just check the wiki”. When the default is to check the docs, instead of asking “Bob” you know you’re on the right track.
For proper persistent documentation we have README.mds in the source code. For transient problems (like the above, it's actually something buggy in our code but nobody has been able to figure it out yet), there's slack and I don't think it warrants spending time to write it down somewhere else. Let's say you are a SaaS company with one product. You use kubernetes. Let's say one day you have a problem with minikube on your dev machine because of an OS upgrade (say MacOS Big Sur effs something up). Does it make sense to document this specifically somewhere (takes time i.e. money) vs. the next time someone upgrades their machine they search slack for the error message that someone posted, figure out all they need to do is upgrade their minikube version. After some time, all your devs have upgraded to Big Sur and upgraded. The information will automatically age out of slack.
I find this is actually pretty neat and the most efficient way of doing it. Especially because 90% if not more of your developers will always "ask Bob" before searching anyway, so putting effort into the wiki (or any other doc) is wasted effort anyhow. That's because sending them a link to an old slack convo vs. the wiki or an SO thread or whatever you use is really not that different.
This is no opinion. It's spot on truth. Human Comms Rule #1 - The clarity of the communication is the responsibility of the sender, not the receiver.
The last company I worked at, had a weekly Friday team meeting where major announcements were most often made. More than once, I took a Fri PTO - often prior to a Monday holiday - and never did anyone say "You missed important X and Y on Friday." Instead it would come up later with an air of being common knowledge. Maybe it was, but not to me.
I got tired of the amateur approach to comms and eventually left.
All in all, I actually agree with you. Knowledge bases are great when done right. But it takes time and a general knack for writing, and that's not something that most devs have from my experience.
The reality is - while learning how to communicate well is hard, actually getting anyone to listen is many times harder.
I used to joke that in any meeting with more than 4 people, at any given time at least 1 person is day dreaming.
And since mobile phones and social media all this has got many times harder; attention spans are shorter and there’s a higher expectation that information should be somehow entertaining.
These days communicating something simple like an important date to 10+ people inside a company requires multi level marketing; email, calendar invite, Slack, face to face time ... use it all and still one of the 10 will somehow miss the message.
[0] http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
Ideally there is a back and forth that checks that important information was correctly passed on. Failing that, some redundancy can make a big difference.
This phrase has a specific meaning I’m quite sure you did not intend: https://en.wikipedia.org/wiki/Multi-level_marketing
Perhaps “requires a multi-pronged approach” captures your meaning clearly?
This was a big problem with me in college. While going through proofs in a lecture, I would frequently have questions in my head and try to pursue them, and in 10 seconds I would have lost the line of reasoning of the proof.
If I get an "all hands" type of group email, I skim it, or maybe just read the subject line, depending on who it's from. Over time I've learned that there's almost never anything directly actionable for me in these messages.
The day is too short and there's too much to do to spend time carefully reading long-winded broadcast messages.
I dunno, I'd maybe weaken that a bit before putting money on it:
> at any given time at least 1 person isn't day dreaming.
This is my experience too. Based on this I concluded that 3 is the optimal number of participants in a meeting. Two would be having an active conversation the third one would be actively absorbing the content of that conversation chiming in once in a while. In fact even in a meeting with 6-8 people I noticed this pattern of 3. Just that members of this 3-clique would slowly change over the course of the meeting.
Edit: wording.
Part of the problem is that people get really upset when you don't assume that.
You don't even have to joke: you can put it in statistical context. If people day dream around 45 % of the time spent in meetings, and assuming that day dreaming time is distributed independently among meeting-goers, there's only a 0.55^5 = 5 % chance of nobody day dreaming at any given moment.
If you're willing to accept a lower p-value and go for an even money bet, people only need to day dream for 14 % of the meeting for you to win money in the long run.
Of course, in practise, day dreaming time is probably not independent: multiple people probably think of the same part of the meeting as dull.
However, management would sometimes feel the need to bring in a developer from neither team who was supposed to facilitate development, I believe to cut down on meetings (because developer meetings that weren't standups, retros, or refinements were bad, apparently). What ended up happening is that this dev would have a meeting with Team A, get the details about the project, then go to Team B and talk about the implementation. Team B would have another idea for how the development should go, so the median dev would agree that the plans would change. That dev would not write down any of the details, let alone communicate back to Team A about Team B's changes. It caused a lot of unnecessary friction and wasted time. Management pretended like this wasn't something that could be avoided.
So long story short (and also to your point): communicating once isn't enough, but not communicating at all is unacceptable
It's fine to use email to announce for example that a new procedure/policy exists, but if it's not posted in some canonical location (where the latest copy will always be found) it might as well not exist. Email is where your keystrokes go to die.
Just the other day I asked about something and was forwarded a document titled ".... FINAL-v2 (July 2017)". I can't tell you how much that enrages me.
Once people have put in that effort they aren’t going to bother redoing the effort for another medium. Meeting notes are the same way.
I’ve found myself repeatedly in a position similar to the one you describe for your former teammate but where I’d been regurgitating the same information for anyone who’d listen for months on end, often multiple times a day. I was on the newer end of the spectrum so I couldn’t imagine it being brand new information to anyone.
But I had to repeat the same details, including how they related to other recurring problems, for months before I could get any kind of shared understanding of the general problem. And even when I achieved that it would flit out of existence at the presence of any new shiny thing, even as I tried to butt in and explain how the problem was known and how I knew it related to the underlying problem.
People just don’t listen. They might want to. They might even embrace it. But unless they’re targeting the problem you’re trying to raise awareness about it’s all too easy to treat something as novel and all too easy to dismiss a repetitive voice.
And when you're troubleshooting all those symptoms rarely just present themselves just like the examples and so forth.
After the fact it is easy to match and say 'this is just like that' but that's miles away from trying to do that every step of the way as something develops.
- not acknowledging obvious elephants in the room
- not building enough trust early on with their reports that when a problem comes up, the information they get is biased as they are seen as part of leadership/management and not the team
- applying pressure in the wrong direction (ie; if the team is moving slow because of stress or fear, making things more stressful will not speed things up)
- trying too hard to be friends with all their reports, rather than figuring out the appropriate boundaries on a person to person basis
- relaying anonymous information around in an effort to "protect people" and thus making themselves the go-between between all members on a team rather than encouraging people to work things out themselves
- for ICs that then became mgrs, staying way too focused on the in the weeds details and not on the bigger picture or people details, up to an including still spending too much time coding or trying to do PR reviews that carry too much weight
--
I would actually go so far as to say that the best "IC turned managers" I've had have been about at par with the most mediocre "good people mgrs that didn't come through coding for that role", and the people in that role that excelled at it (a motley crew of former stage managers, teachers, guidance counselors, project managers, etc)
Could you elaborate on ways to build trust early on? I'm curious and intrigued. Do you have any ideas / systems that you follow to build trust with different kinds of people?
Just to make sure this parsed correctly: non-technical, but good at people, engineering managers >> ICs that became technical engineering managers?
They know how people worked (how to intrinsically motivate them, keep an eye on moral, really good listeners, power of being in the zone) and at the same time understanding how tech works (where will things likely fall apart, an eye for unknown unknowns, value of good tests, power of primitives, focus on minimizing scope and saying no to things).
It comes down to “wow! This person understands how software is built, that it’s expensive and an iterative endeavor. That I am a human being with feelings, ambitions and passions that will make mistakes along the way”
yes in my experience the best IC turned managers are about on par with a mediocre manager that is really good at managing, and didn't come up as a coder, and the best managers I've had have all been from other backgrounds.
No doubt there are great coders-turned-managers out there, but it often seems like the "people skills" are just assumed to be easy to acquire, when actually they take a pretty complicated mix of talent and experience for that sort of thing as well
Its very naive to think, that the manager replacing you will see eye to eye with you. I have seen countless occasions, where the engineer in the team who is ontrack for promotion doesnt get it, because the management above has changed.
While being in IC role, I never relied on the company to promote me. Its better to jump ships than reestablish the relationship with new manager. It takes same amount of work anyway. At least jumping ship will give you much higher compensation.
> For example, I didn’t teach her how to advocate for herself or how to navigate the system.
In fact, it takes less energy to advocate for a promotion with a new manager than to jump ship. Ideally, you have a multi-year track record to lean upon at your current company. You'd have no such track record at a new company.
To the author's point, if you put together a persuasive promotion packet, resting upon your accomplishments and past "exceeding expectation" reviews, and make it a priority to repeat how important this is to your new manager, then often you'll get the promotion.
If after some time, you don't? Jump ship. :)
I’m a staff engineer at my current company. In my whole career I never once got a promotion.
Also, if you come back within a certain timeframe, you don't have to re-interview, but you also don't get a bump in level. That timeframe is usually a year or so. I'm not sure if they would even allow you to re-interview if you come back within a year, but I'm not sure of that part.
I should also say that I see this claim a lot, but I am on a hiring committee and I have never seen this happen. I'm sure there are some people for which this works, but I think it's more rare than people know. I also suspect that the vast majority of people are leaving at L3, and coming back at L4. If you are good at doing a Google interview and have some experience, it's not that hard to interview at L4 and get in.
Now what I have seen is someone leaving for two or three years and coming back in at a higher level. But that seems like it is based on the experience they gained outside of Google, not that they were necessarily passed over for promotion while at Google.
Now the promo process at Google is the absolutely worst process for promotion I have ever had to endure, so I'm positive that good engineers are passed over on a regular basis. But this idea you leave and come back in a year to get your promo is more myth than reality.
One thing I worry about in such situations is the competence of my colleagues - if everyone got a promotion to take this job, is it a good environment to learn and grow in that role I got newly promoted to?
Too many egos; people who think senior means 3 years of experience; and the idea that there is a clear boundary just make the whole thing hard.
Reward people with a salary that reflects their value to the team, give them feedback, encouragement and challenge.
I have made plenty of mistakes over 20+ years, and learned the painful way.
All of your problems are people problems, the tech parts are much easier to manage.
I can stay technical in my role as an individual contributor and be content. IMHO I'd be more valuable to the company in a leadership role...but also at the same time not sure if I want to have to deal with it for a 10% raise.
If it does not suit you in the end, your technical skills will still be there as a fallback option.
Wish you well.
Funny thing is I'd feel less pressure as a senior dev with 9 other college hires, than a new manager w/ 1 senior dev and 9 college hires (even though technically the team would have 2 senior devs including me if the development parts get rough!).
This resonated with me and made me excited to fall back to an IC role for a period: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
What can you, as their manager, do to instead increase their productivity by 10%? Likely many things, and this is a lot more sustainable, because otherwise the team gets neglected from a manager support perspective while you're busy working with them.
Of course, find things to do technically to help the team if you want, that's a great idea. But don't assume that the best thing you can do for them is always to do what they are doing.
This cannot be emphasized enough. I have seen lots of smart engineers attempting to "architect" the engineering manager role, while not being able to handle the people aspect at all.
That's just ... management. Management is mostly about people, it is mostly about the HOW instead of the WHAT. I'd go one step ahead and make a statement that "Management is mostly about dealing with people's observable behaviours".
If you try to "manage" that, they will resent and resist you.
The best you can hope for is that they like and respect you enough to follow your leadership. But that's their choice.
How much time do you spend on helping your team members grow? It takes a long time (years not weeks), but this can be very rewarding!
I share my own (humble) insights right here, its a huge topic but I post regularly, you might find some of those posts helpful: https://techleader.pro/
> it just doesn't feel the same in terms of pride in technical achievement .. i.e. my coding days are over
Same for me, I had to learn to take pride in building successful teams and individuals, and not code anymore.
As an ex-engineer, the key "eureka!" moment I had was when I realized that management != leadership, and leadership > management. After that, I started to study "leadership" as a formal topic, everyone from Marcus Aurelius to Steve Jobs, as if I was learning a new programming language for example.
The combination of technical chops + great people leadership skills is very rare, if you nail that many opportunities will open up for you during your career.
Wish you well on your journey.
You're claiming that is unavoidable? Hmm. I wonder.
I did not "claiming that is unavoidable" on this thread, if you care about being fair.
Some years ago I was in a small company going through a cash flow problem. We had zero revenues for two straight quarters, cut salaries, laid off people, and drove the remaining developers to burn out by treating the situation as BAU instead of the crisis that it was.
I would dread those conversations with the engineers, telling them there's no more work. They were very good people and we're still well connected but it sucks when this happens.
When this happens, morale is at rock bottom and the smart ones start to quit. Been through this too, until the team was just me and 2 more engineers trying to do the work of eight people, until everyone quit for saner roles.
The company is still trying to generate some cash, they're around like a zombie.
If it’s some others fault, you can be sad but shrug it off more easily. Also, the others wont be as mad towards you.
Performance problems can be fixed. Attitude problems are much harder to solve. You will face this situation multiple times in your career as engineering manager.
I'm not very aggressive or confrontational by nature, so having that conversation with the engineer in question is absolutely not something I looked forward to. This obviously led to an unfair amount of work for the others in the team, a feeling of unfair treatment, resentment and a hit to morale and performance.
Two situations were so extreme that we've had to lay off the engineer(s) in question, which is one of the hardest things to do as a manager. I can tell you that in both instances the teams fared much better afterwards.
In one case the developer was hostile to working with anyone else. This was a project that involved close co-operation with teams across three countries, so his attitude was a no-go.
In another case, the engineer was constantly slacking off, dumping his work on the other devs in the team.
In both cases I'd have several 1:1's with the engineers, and first try and understand what was going on.
I usually trust people, and when something like this turns up, there are often other serious problems, for example at home with family or with the developer's health. We settle these issues quickly through flexi-time, reduced workloads, sabbaticals, coaching, changing their scope of work, etc, and things turn around very nicely. However the engineers I wrote about above didn't fall into this category.
In both cases I had extensive 1:1's with them, to help both of us understand what was going on. In this process I'd get insights into the nature of each person, and that helped define the right approach to resolve the problems. I then set clear expectations that we would review each week. We unfortunately got no progress for both the devs after 4 weeks, and at this point I had to involve HR and turn this into a probation. Both flunked and were asked to leave the companies.
There's no set formula here. If faced with this situation today, I'd handle it slightly differently and more quickly.
“Try to think through what skills someone needs to succeed without you. Teach those things incrementally.”
I quickly saw my team wasn’t performing at my level (duh otherwise they would be at my level), and have had a hard time trusting them. I have slowly gave them more responsibilities but I like how this makes it very explicit / planned out.
1. I need to have team members I can trust to take things off my plate when things get busy.
2. I want to help my team members grow their technical skills and they can only do that when given difficult tasks that push them outside their comfort zone.
I keep reminding myself that if I took a specific task, I may be able to get it done faster, but when I add up all the tasks that I delegated, there's no way I could get that all done faster than spreading it out.
I find my role is mostly about keeping team members unblocked and productive.
At first I thought the same. But I then came to realise that people work differently, are motivated by different factors, are blocked by something not visible to me, etc.
And once all those factors where accounted for, I saw that the delegated tasks were done better than could have hoped to do. Sometimes absolutely so, sometimes given time constraints.
Incredibly rewarding.
Yes, deciding how to deliver feedback could be a nuanced, delicate challenge.
But a non-obvious related problem I've found is whether to deliver it at all. The mistake there being that people want or can benefit from the feedback you think you would've wanted, were you in their position.
This is definitely a problem when you are peers, but as an engineering manager one of the things you are often responsible for is making sure that individuals development is both progressing and tracking well to group/company needs. So a certain amount of feedback is often unavoidable.
Too often, I see feedback being used for individual convenience. Typically, feedback should be linked to team/organisational goals. If you can not frame the feedback towards team/organisational objectives, it might be the case that feedback is not necessary at all. In the end, HOW you deliver feedback matters. Personally, I have three important characteristics for a feedback.
Point 1 : "Be Specific". I can not stress this enough. Please point out specific observable behaviour.
Point 2 : Frame feedback in terms of team/organisational goals. Every team has a purpose within the organisation. It's a team game and every team member should know the feedback in context of the team game. Individual feedback, team context.
Point 3 : Cite the past but look for future changes in behaviour. You can not change the past but you can influence the future.
For example, "Hey John! When you do X, it helps the team achieve Y. Please continue doing so!" or "Hey John! When you do Z, it impacts the team to achieve its objective. What can you do differently?".
I don't know if anyone has alternative tips. I know people who do all their hands-on stuff as managers on the weekends with private projects so they can learn new tech (like k8s).
In the end your senior developers will end up better developers and better in technical stuff than you. And that is fine.
The feeling of urgency of those things, connected to a reputation for being on top of things, makes it extremely hard to book a 4 hour uninterrupted window to work on something.
... and has the power to pick and choose what they work on. My present manager does this and only does the fun/interesting stuff leaving the grunt work to the team. Sometimes he does half a ticket, gets bored, and “delegates” the rest.
A manager who picks clean interesting stuff and leaves the rest would be an absolute nightmare to work for. He shouldn't be in the business of managing people, since his self-interest now interferes with the interests of the team and the company.
So it seems like a really strange assumption on your part that the new manager or the person "on track to be a senior dev" would behave in the way you expected. What exactly should a manager do different in that scenario? Close their "poop umbrella" and potentially let the person you're mentoring fail?
Furthermore, is shielding an employee with a "poop umbrella" tantamount to "doing everything" for them? I feel like putting your employees on track to a promotion and shielding them from organizational concerns that might distract them is a fundamental aspect of being a manager, if the next manager comes in and doesn't do that, then that's on them...
edit: fixed typo
It's a good time to have everyone's voice heard. We write it all down in succinct phrases and compare to previous sprint review.
But I have her beat. I made a lot more mistakes; some, quite embarrassing. Nevertheless, people seemed to like having me as a manager, so I guess I got a few things right.
Here's a quick short list. These are mistakes I made only once, or eventually stopped making. Some are mistakes that came about as overcompensation for previous mistakes:
1) Believing HR's lies.
2) Transmitting HR's lies to my employees, unfiltered.
3) Getting HR involved in stuff that they only make worse (a function of #1).
4) Not believing anything HR says at all.
5) Not transmitting HR's policies and/or requests to my employees.
6) Not getting HR involved, when they should have been involved.
7) Making off-color jokes. OK when a grunt; NOT OK when a manager.
8) Getting too nosy about employees' personal lives.
9) Not getting nosy enough about employees personal lives.
10) Projecting my personal values and motivations onto employees.
11) Projecting my personal values and motivations onto other managers, or my managers.
12) Trusting too much.
13) Not trusting enough.
14) Refusing to delegate.
15) Overdelegating. Putting too much responsibility on the shoulders of people that shouldn't have to deal with it.
16) Putting the burden of progress reporting into basic team policy. It needed to be my job to know progress; not my team's to tell me. This is what scanning commit comments and build results is good for.
17) Not respecting different cultures within the team. I did fine with cultures outside the team, but each of my team members had their own personal culture, and I needed to get familiar with (and respectful of) each team members' personal culture.
18) Putting my team's needs before corporate needs. The #1 job of a manager is to make sure the corporation's needs are met; regardless of whatever else is going on.
19) Putting my needs ahead of my team's needs. I learned that I needed to make sure the team, and its costituents, were healthy, and had its needs met, BEFORE my own.
20) Being afraid to say no.
21) Being afraid to say yes.
22) Avoiding taking personal responsibility for the team's performance.
23) Throwing my employees under the bus, in order to save my own butt.
24) Letting employees get away with crap, until it became an emergency.
25) Thinking that my job was all technical. In reality, the tech was only a tiny part of it.
As you can see, "hard and fast rules" are not particularly helpful. It really is a human exercise.
I think it is pretty normal even if a bit off the mark at times.
it happened to me recently. working for a manager that literally took all the credit for all of my visible work, taking 0 responsibility when the team was failing on projects while he is the one who assigned juniors on complex projects without any oversight. He obviously blamed his own team members to upper management rather than taking responsibility too.
He recently got promoted while I am being asked to attend trainings to get better at my job in order to be promoted (While at the same time being qualified as a top achiever in my yearly review...)
Don't forget that no one will ever be on your side in a company. You don't meet leadership. Your line manager does. HR is not on your side never.
So yes. The only way out is to kneel down and accept it. be nice to the guy who takes credit and if you do it well enough you might be the next he will promote. except if he brought his friend to the company and this friend is competing with you....
Problems I struggle with sometimes:
- Finding time for product management (including research) (PO is my actual job title).
- Difficult personalities (relatively I think I'm very good at handling these, but trying to change someone instead of just mitigating harm is hard).
- Keeping non-full-stack devs busy. E.g.: The most urgent topic is some DB migration and I need back-end people for it. I could have front-end work on the next user facing feature in the meantime, but they are blocked by back-end delivering the data. (well front-end can mock the back-end in my example, but you get the idea).
- Balancing how well prepared or defined tasks have to be. There are so many factors: Getting a good outcome / staying agile / having the devs think along (no micro-management) / not overburdening the dev / and maybe most importantly: not knowing who will take the task because devs are on such different levels.
* How do you create a reality distortion field inside outside the team. Bad managers just list accomplishments, great managers tell a story.
* How do you manage/remove toxic people, personalities and influences and create a solid team culture
* How do you translate the relatively rigid corporate structure and objectives into flexibility and room to move for your team. Until you're VP level, you actually don't have much freedom in direction and a great manager will understand how to interpret and reinterpret this for the reports.
* How do you balance the relationship between business, engineering and product. Can you walk the line between tech debt, code quality and delivering? Can you have those conversations business is never willing to have to convince them to allow eng to pay down tech debt?
* How do you unblock and accelerate your team without being a micromanager. Do you regularly take a strategic view on pain points and blockers for your team?
Seems like I’m the go to guy to always fix things and I seem to be stuck as a tech lead (I spend most of my time reviewing code and doing architecture design and then code when I absolutely have to)
I was made one because my director said during a team meeting that we needed more senior staff to get work moving forward and I disagreed, saying if we made our processes better we could deliver faster.
I had a conversation with him after saying if he gave me a team I would get him what we needed, and that's how I started.
An anon survey with a sample population of one? I don't get this...
The anonymous aspect probably makes more sense when you have more reports, but there's probably an aspect of "i can basically guess who this is, but i'm going to try to take this at face value as generic feedback to improve, instead of trying to contextualize and maybe explain it away using someone's current situation".
I feel better reading this as I am known to repeat myself!
It communicates what matters, separate from the reminder aspect of the act.
I recently joined a US company and it was a shock to me to hear how often my colleagues will drag in irrelevant social issues into the discussion of day to day business. These colleagues appear to be so in their own bubble that they just assume everyone is on the same page as them.