Mistakes I've Made as an Engineering Manager(css-tricks.com)
css-tricks.com
Mistakes I've Made as an Engineering Manager
https://css-tricks.com/mistakes-ive-made-as-an-engineering-manager/
194 comments
There’s some cognitive bias in which we assume that when we regard some information as important, that anyone exposed to that information will fully absorb it.
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.
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.
> multi level marketing
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 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?
Ah yeah - NOT a pyramid scheme - multi pronged is what I meant
You can't tell people anything. [0]
[0] http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
[0] http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
Interesting essay. Reminds me of some of the issues that come up in teaching. Even when you think you have explained something at the simplest possible level you are often missing background assumptions that seem to obvious to you that you can't even conceive of not knowing them
I’ve read that essay before and I re-read it just now and I still don’t understand what is meant by “avatars walking around on top of our company home page”. So I guess the essay proved its point.
> I used to joke that in any meeting with more than 4 people, at any given time at least 1 person is day dreaming.
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.
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.
For me, writing notes work to overcome that. If I write notes, I can keep focus longer. Plus, I would scribble all those questions on side and come to them later if they were not answered by something in lecture after.
Funny, I've always viewed that behavior as more conducive to learning than trying to follow a proof or lecture exactly.
It's alright if there the proof is sketched down somewhere, but I had a couple advanced courses where there were important concepts that weren't already written down anywhere.
> I used to joke that in any meeting with more than 4 people, at any given time at least 1 person is 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.
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.
Just because 3 means that theoretically everyone is paying attention the entire time (certainly not the case) doesn't mean it's the optimal number.
There's also the problem (for me, and I have observed for others) that emails sent to lists or large numbers of recipients/CCs automatically get less attention and priority than emails sent to me individually.
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.
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.
If you miss a word in a conversation, you automatically fill it in. This is usually pretty reliable even with unfamiliar material, since if you follow standard grammar rules there's a decent amount of redundancy. Sometimes, though, this doesn't work. You think you were paying attention, but you missed parts and filled them in with what you wanted to hear.
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.
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.
> I used to joke that in any meeting with more than 4 people, at any given time at least 1 person is day dreaming.
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.
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.
> There’s some cognitive bias in which we assume that when we regard some information as important, that anyone exposed to that information will fully absorb it.
Part of the problem is that people get really upset when you don't assume that.
Part of the problem is that people get really upset when you don't assume that.
> at any given time at least 1 person is day dreaming
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.
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.
I’m always blown away when companies don’t have a knowledge base. Imo, if it’s not written down, shared with me, and told how important it is, then it’s your fault.
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.
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 respectfully disagree to an extent. I think most/all documentation ends up rotting and being ignored. If you take the time to write it down, it doesn't mean that others will take the time to read it or refer to it.
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).
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).
There are two ways that I interpret this
* 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.
* 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.
If we get better search systems I would be totally on board. But most knowledge base systems have a hard time finding similes for words let alone sorting articles containing multiple keywords in a useful order.
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.
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.
Sure, I should make clear: documentation/wikis are best for who/what/when/where of things like
- 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.
- 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.
I've had a funny observation over the years. The more refined the wiki, the worse the code/ops are.
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.
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.
I've noticed it a lot of times in legacy systems. There's often a page with 20 different idiosyncrasies that you have to deal with, and the code is too critical to update even with comments
This might be fine at a smaller company, but as you grow, having people verbalize these things results in slight variations that over time grow into very big inconsistencies.
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.
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.
I got really excited about the Linode/mediawiki solution. We're looking at Jira/Confluence right now, and it seems pretty heavyweight.
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.
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.
I do the same, even just for my own notes. That way it's all there, accessible, searchable, in the same place. Far better than everyone squirreling their own critical data away in a different tree-trunk.
Why would I want something like that on an external resource like a wiki? What's wrong with having it right there in the source in a README.md?
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.
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.
This works for developers but excludes large swathes of other stakeholders, some with huge amounts of business/process knowledge. MediaWiki supports WYSIWYG via VisualEditor, which increases usage from others (and has the benefit of making tables much more pleasant to work with).
I completely agree with you for documentation that is not developer centric. A wiki and a WYSIWYG editor is the way to go there. Though it is funny to see PMs and other people fight with say the Confluence editor (that's what I'm stuck with at the moment @work and they've recently effed up the Jira editors as well in favour of non-developers). It's abysmal and since they changed it to remove proper wiki syntax editing I can't even really fix things for them easily and have to use workarounds myself instead of teaching them a little bit of wiki markup syntax from time to time or using it myself to fix things. It's like MS Word and everyone learning all the workarounds of how to undo weird formatting or fix documents. What was wrong with LaTeX? :)
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.
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.
I assume you're referring specifically to the coding style document rather than the host of things that a company should document. The advantage of having the coding style documented in a format that supports some kind of markup over a plain text file is to support syntax highlighting, searching/indexing, cross referencing other documents, including diagrams and a host of other features that plain text files lack support for.
You should not assume and I should have specified more clearly.
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".
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".
Documentation that ends up rotting and being ignored is usually a consequence of a poor organization/processes. Such places are usually not a very happy place to work at.
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?
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?
Documentation rotting is fine so long as:
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.
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.
from years of doing wiki documentation, document rot is fine, if it rots, so be it. Most of the time I write the docs for me but with a "getting started" frame of mind. On our wiki there are a whole bunch of actively maintained pages now that were initially seeded by myself or other devs, and there's a bunch of dead pages which are occasionally very useful , some of it is horribly dead. But the active pages are great, they save everyone time. Main thing is to not invest vast amounts of time to the docs, don't spend time drawing diagrams unless its a photo of a quick hand drawing, and just put in more effort as things prove useful
I think this is all cultural. Smart employees want to do good work. If you aren’t providing them with the context and knowledge to do that work, then you’re failing. If your documentation isn’t useful, that’s your fault. If no one cares about the roadmap and couldn’t even tell you what’s on it, that’s your fault.
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.
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.
> I think most/all documentation ends up rotting and being ignored.
This is a choice, not a fundamental law.
This is a choice, not a fundamental law.
Not really a general counterpoint, but I do think that if documentation is concise and useful enough so that stakeholders keep it up to date, it can work.
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.
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.
I agree with Tafster. I've been a consultant for 6 years and so I've seen dozens of knowledge bases and wikis. Some companies even have great processes to fill them in.
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.
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.
> I have never, ever seen a company where those wikis are actually read.
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.
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.
> Docs are only useless in companies that actively want them to be useless.
Like most things in life, it takes active effort of ongoing maintenance.
https://www.edge.org/response-detail/27023
Like most things in life, it takes active effort of ongoing maintenance.
https://www.edge.org/response-detail/27023
> Your attitude of "docs are useless" is self-fulfilling.
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.
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.
Isn't a low read count fine in most cases? I wrote up some documents on setting up some apps in AWS. I expected those to be read maybe 2-4 times over their lifetime (and maybe some random browsing). There just aren't many people that should have to go through the steps.
Still a net time savings as those people won't have to reverse engineer things.
Still a net time savings as those people won't have to reverse engineer things.
> I have never, ever seen a company where those wikis are actually read.
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.
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.
I totally agree with you, and disagree with the other two commenters here. I think this is a culture and communication difference in companies. I work for a distributed company, Automattic, and we use two tools for information which needs to remembered:
- 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.)
- 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.)
I totally agree with you, and disagree with the other two commenters here. I think this is a culture and communication difference in companies.
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.
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.
I've seem some larger projects at bigger organizations where extensive wikis were available. I'm pretty sure updating docs/wikis was part of the "definition of done" on a task. Problem was, most of the devs were terrible, terrible writers. There was little to no consideration made for "explain this as if I don't already understand it" on these pages. They were dry, full of useless generated ERDs and other generated filler, and generally I'd end up reading the source code or reading the integration tests to get a better sense of what was going on.
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.
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.
We ought to work harder at teaching writing. I think there's a definite group of people that really _love_ writing, have a general knack for it and work hard to turn that knack into a talent. But, those folks aside, I've found there's simple tweaks that can be made to most technical writing that greatly improve it. For example, in code documentation explain "why" and not "how". Later source readers will probably be able to understand your code unless it's especially complicated but they will not, from the code, be able to figure out why it exists. Lots of folks write the "how" down though, in part because the external context is taken as a given in the moment -- they're very familiar with it right then and there -- but also because the "how" is probably more interesting than the "why". Empathy for the ignorant is something you see in excellent technical writing, less so in the middling stuff.
Do you have more on how to get better at writing?
> Imo, if it’s not written down, shared with me, and told how important it is, then it’s your fault.
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.
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.
> I’m always blown away when companies don’t have a knowledge base.
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).
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).
Well yes but no if you ask me.
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.
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.
> wait, that problem happened like 3 or 4 times in the last couple week
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.
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.
Funny you mention that. We do have Stackoverflow (check it out if you like this sort of thing. You can have your own private section basically) but I personally don't find it useful. We basically only use it like a troubleshooting section to document longer lasting information.
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.
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.
The cost of documentation is far larger than its creation though. I agree stuff needs to be captured, but it also needs to be maintained and promoted, otherwise call it by what it really is, sharepoint.
[deleted]
Not to be contrarian, because you’re not wrong, but to provide a little additional flavor... I don’t have anything close to perfect recollection but I do have good attention to detail and how problems intersect, and a career-long recognition for it.
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.
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.
People can only listen so much too. Like if you go over 6 critical issues at a meeting once or more times a week.... how many issues can you really 'know' / remember.
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.
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.
Well in the case I was describing it was just the same symptoms recurring. The reason they recurred so long is that the people who weren’t listening were focused on the symptoms and ignoring the root cause.
I wish everyone would treat email as the temporal medium it is.
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.
[1] https://jamesclear.com/keystrokes
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.
[1] https://jamesclear.com/keystrokes
The problem with email is that it ported letter writing culture to the internet. A big internal announcement at my company can take days to write and undergoes multiple rounds of review.
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.
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.
This reminds me of my last job. There were some instances where two teams would work on the same feature. The team leads and devs would regularly get together to make sure that we were on the same page in terms of who was developing what and what the specifics of the design were. It worked well.
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
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
100% agree. The problem of knowing too much.
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.
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.
Mistakes I've seen eng mgrs make:
- 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)
- 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)
> 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
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?
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?
> 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)
Just to make sure this parsed correctly: non-technical, but good at people, engineering managers >> ICs that became technical engineering managers?
Just to make sure this parsed correctly: non-technical, but good at people, engineering managers >> ICs that became technical engineering managers?
I’m 50/50 on this assessment. Best managers I have worked with are IC turned managers that have real good empathy for their team members.
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”
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”
Yeah, I'm also having trouble parsing the parent on this one...
sorry, sometimes my fingers and my brain aren't in sync.
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
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
Very informative 10 lines post. The original article is slightly uninteresting and the "mistakes" not clearly acknowledged and rather obscure.
> She was on a steady track to land a senior role. Even after I decided to leave the company, I let the next manager know this person is track for a senior position in the next few months.
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.
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.
One of the most important lessons I've learned as an engineering manager is to mostly stay away from job titles for developers. There are not many things that sow discord than calling someone Senior when someone else considers themselves better (unless you have a very objective way of defining it).
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.
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.
You and the article author are both right! From the author:
> 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. :)
> 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 disagree. When you jump ship you don’t need to build track record to get a promotion but instead join at a higher level right away.
I’m a staff engineer at my current company. In my whole career I never once got a promotion.
I’m a staff engineer at my current company. In my whole career I never once got a promotion.
Same thing here. It's much easier to demonstrate competence for an afternoon of interviews than for a few years of real life projects.
It really depends on the company. Companies like Google and Facebook are very unlikely to hire people at a higher level than their previous level (though certainly it happens). That's easier at smaller companies.
I saw someone leave then come back a year later as L+1 at google all the time
People say this, but I think they mean that you can go from L3 to L4, or L4 to L5. It is very difficult to come in at L6, and it's even relatively hard to come in at L5, where L3 is new college grad.
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.
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.
So I’ve def seen someone come back from uber L5->L6 but it’s probably rare (but then L6 itself is relatively rare) and under a year. And I’ve been told by VP that it does happen (I was doubtful too) but needs director? approval. Heard of may cases below L6 though
Congratulations, that's great! There are certainly different paths towards achieving the same goal. I'm sorry you weren't able to get any promotions to work out.
Congrats!
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?
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?
Wow that's a pretty easy going list. Just wait until you have to fire a bad hire that you made, have an entire team quit after a bad crunch, or have to lay off an entire team due to that exciting startup just you joined going bust.
This is hard, specially when you have very little control over the root cause of the problem.
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.
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.
One note: For me it is much harder if I had control of the root cause because then it is my fault and I am crushing myself about how I was wrong etc.
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.
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.
Have you had that happen?
Yes and I could go on! Engineering management is brilliant and rewarding, but also very demanding.
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 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'm a senior technical IC (have a phd in tech along with many years of exp) who moved to management about 2 years back. I am having very mixed feelings on being on the other side. Being a manager is a lot harder than I expected. It feels like wading in slush all day long and I don't really get a sense of accomplishment (as an IC, I could take credit for what I did; as a mgr, I definitely add value and am a force multiplier to the team .. be it in setting direction, utilizing learnings from all my old experiences .. it just doesn't feel the same in terms of pride in technical achievement .. i.e. my coding days are over). I am also completely clueless how to switch jobs as a manager. Any insights would be greatly appreciated.
Is there a network of managers in your company you could sync with? If you consider switching companies or even career paths you might be at a point where learning might be more important than keeping (secret sauce type) leverage or saving face.
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!
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 am also completely clueless how to switch jobs as a manager. Any insights would be greatly appreciated.
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.
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.
> All of your problems are people problems, the tech parts are much easier to manage.
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.
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.
I have an opportunity to apply (and be very competitive) for manager positions that just opened up and this is the part that scares me the most. I could (and likely will) be managing a team of 9 college hires with 1 senior dev. Not a great ratio but that's about what it is from the new teams that were created.
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.
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.
I'd always recommend you try it! The really brilliant part about engineering leadership is mentoring, there is nothing more rewarding than seeing one of your teams succeed, or growing your own leaders and watching them thrive autonomously.
If it does not suit you in the end, your technical skills will still be there as a fallback option.
Wish you well.
If it does not suit you in the end, your technical skills will still be there as a fallback option.
Wish you well.
A part of my does want to try it because rarely does my company opening up so many managerial spots (we are in a growth phase). I wonder if anyone has "falling back"? And how that experience was. Is there a stigma? I assume there was a paycut?
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!).
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!).
Be careful about diving in and doing too much work yourself as a developer. If you do, sure, your team now has 11 engineers instead of 10. 10% bump!
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.
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.
Re: going from management back to IC, yes I’ve done it, not within the same company though. It was a good experience for me. Later, I swung back to management.
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...
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...
> All of your problems are people problems, the tech parts are much easier to manage.
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".
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".
You can't "manage observable people behaviours", they are complex human beings with unique emotions and motivations, each one behaves differently.
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.
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.
> have an entire team quit after a bad crunch
You're claiming that is unavoidable? Hmm. I wonder.
You're claiming that is unavoidable? Hmm. I wonder.
Did I?
Well, to be fair, the article is about "Mistakes I've made", not "Hard things I've had to do".
My mistakes contributed to those hard things.
I did not "claiming that is unavoidable" on this thread, if you care about being fair.
I did not "claiming that is unavoidable" on this thread, if you care about being fair.
One of the most difficult things I had to learn to do as an engineering manager was to be able to confront attitude problems and take action as quickly as possible.
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.
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.
Can you please elaborate on the attitude issue and how you handled it?
Two instances, in two different companies that I can share.
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.
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.
I’m a relatively new manager and this really stuck out for me
“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.
“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.
> I quickly saw my team wasn’t performing at my level
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.
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.
Delegation is extremely important for multiple reasons.
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.
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.
> Mistake 1: Thinking people give feedback the way they want to receive it
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.
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.
> 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.
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?".
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?".
> related problem I've found is whether to deliver it at all.
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.
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.
Me: trying to stay hands-on and technical on all topics, which first of all was impossible, and second which distracted me away from the key managerial duties of keeping communication channels flowing, projects on track, people unblocked, strategy devised, and so forth.
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).
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).
I believe you cannot stay hands on and technical on _everything_. You might have some specialties you are good at from before becoming a manager, and have constructive input there. The rest, you delegate to other, usually senior members of the team. They will be better suited to do architectural decisions and code reviews than you.
In the end your senior developers will end up better developers and better in technical stuff than you. And that is fine.
In the end your senior developers will end up better developers and better in technical stuff than you. And that is fine.
IMO this is part of your job, and not something to be done on weekends. I had a manager that would set time aside on Friday afternoons to write some code or play with new tech, worked well for him.
It's incredibly hard to find time where a) you're not in meetings and b) you're not interrupted or needing to reply to communication through email or Slack.
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.
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.
Take (Jira) tickets and do them just as any other direct report. That's what I do.
Personally, I'll never stay at a company where my manager does this. The manager almost never has time to do these things properly.
The manager almost never has time to do these things properly.
... 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.
... 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.
I often do mediocre / small / shit tickets, it's definitely true that my staff have way more interesting tasks than I ever do.
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.
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.
The part about "doing everything" for someone hit home at first, but it took a turn when you mentioned leaving that position. Sometimes I've had managers come in and just take over a project because a client/investor wanted it yesterday, which I think is a bad approach. Sometimes it's necessary, but it should be mitigated by proper project management practices.
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
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
I really think we can all learn a ton by sharing our mistakes. I wanted to implement this in the office but nobody would share. I have no problem sharing now I've messed up but I'm also weird in a lot of social respects.
If you do sprints, schedule a 15 minutes meeting at the end of the sprint called Sprint Review. That's when everyone is able to say what went good and what went bad.
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.
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.
This is such a great article, and I'm glad Sarah wrote it. Any organization would be lucky to have her as an engineering leader.
The biggest mistake I made when I became a manager was thinking it was easy. It’s like being a therapist with a deadline on wellness and productivity.
That's a great read! She was spot on, as far as I'm concerned.
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.
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.
Would you like to share some?
I would love to. You may need to wait a bit, though. I am up to my ass in alligators, right now...
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.
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.
Wow, thanks. That's a lot to think about.
These are not the toughest problems. Here's a tough one: managers that compete with their employees for credit and rewards. Does the company reward managers based on the total output of the team they manage, or do they reward managers on their contribution to the success? If the former, managers will try to hire the best, and help their employees do the best work. If the latter managers will not necessarily try to hire or retain the best, since they are competing for rewards.
That may be an additional interesting problem, but why shoot down the OP? I think the things it goes over are entirely legitimate and important lessons-learned.
This is hackernews. Instead of thoughtful comments on the article, people prefer to make up an argument and then bitch about that so they feel smart.
I think it is more people hear a topic that is wide ranging and sort of riff off of it and discuss related and not so related things.
I think it is pretty normal even if a bit off the mark at times.
I think it is pretty normal even if a bit off the mark at times.
Or you have good high-ups that are just glad if you do a good job and they don't have to intervene.
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.
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.
That's not a hard problem, that's an easy problem for leadership to solve (you explained the solution in half a sentence), or an impossible problem for a line manager to solve.
Who do you think leadership listens to? the employees they never talk to or the line managers they have weekly discussions with?
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....
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....
What you are describing is an organization problem, and typically above the pay grade of an engg manager. So interesting, yes, but a different category.
This is pretty solid advice, but very much basic EM feedback. The really hard stuff are ideas such as...
* 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?
* 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?
Great points! Not sure why you were down voted
How do I even become an engineering manager? I’ve been coding for > 10 years...
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)
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)
Have you applied? I, just last week, moved from a dev role to a manager role. I had previously talked with my manager at our one on ones about being interested in this path. They pointed out some new positions being hired and so I applied.
>How do I even become an engineering manager?
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.
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.
>> Asking folks directly in a one-on-one meeting if they have feedback for me as a manager, and following up with an anonymous survey
An anon survey with a sample population of one? I don't get this...
An anon survey with a sample population of one? I don't get this...
Probably more of the value is just in letting someone formulate their thoughts and write something up, instead of iterating live in conversation. Most probably need both avenues of communication available.
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".
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 think they probably mean that they get feedback from each person, then formulate an anonymous survey that goes out to the group.
>Mistake 3: Communicating something one time is enough
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 feel better reading this as I am known to repeat myself!
It communicates what matters, separate from the reminder aspect of the act.
When explaining something technical I do it twice but from different angles. Then i like to have the listener explain it to someone else on the call (I work remote). The surest way to make sure someone understands what you’re trying to communicate is to ask them to communicate it to someone else.
Not on the same call that you explained it to the first person, I imagine?
Even in the same call. You’d be surprised how often people say “I got it” and then stumble when you ask them to explain what they just “got”.
Tell us about a time when you made a decision that led to costly consequences and if you could go back and change approaches, you would.
Most management mistakes are made through bad, or improper, or ineffective communication.
ubersync(4)
Not sure why it required the strong caveat of "I’m white and a woman in tech"
Indeed. Apparently these things are important to state upfront yet leaves out what country she operates in and which industry. It was enough for me to stop reading.
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.
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.
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 ;)