>Mistake 3: Communicating something one time is enough
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 ;)
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.
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.
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.
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.
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 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.
> 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.
> 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.
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.
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).
* 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.
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.
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.
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.
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.
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.
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.
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".
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?
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.
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.
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.
> 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.
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.
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.)
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.
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.
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.
> 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.
> 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).
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.
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.
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.
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.
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.
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.
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.
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
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.
- 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?
> 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?
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”
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
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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!
> 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.
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'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.
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!).
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.
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.
> 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".
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.
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.
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.
> 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.
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.
> 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.
> 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?".
> 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.
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 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.
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 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.
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.
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...
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.
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.
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.
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.
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.
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....
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 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)
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.
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.
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".
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.
If... your argument is that it's easier to be a woman in tech than a man in tech... (rubs eyes) that most men in tech are "protecting" the women in this industry... I... don't even know where to start, except, er, a huge freakin mountain of data points to the contrary.
> What’s clear is that there’s a vicious circle of perception and reality in terms of gender imbalance. And that schools, universities and industry are failing to show young people – and especially girls – the realities of technology jobs and careers in today’s world.
> Despite such exciting opportunities, girls aren’t considering technology as a career – partly because nobody is putting it forward as a possible option. While 33% of male respondents say they’ve had a career in technology suggested to them, the figure for females is only 16% – a glaring lack of advice that’s helping to reinforce the stereotype of a male dominated industry.
> Our research shows that their main reasons for not choosing to study STEM topics include: being better or gaining better grades in humanities or other
essay based subjects; not finding STEM subjects as interesting; STEM subjects not being relevant to the career they plan to choose; teachers not making STEM subjects appealing; and the need to get the highest possible grade, as this influences both university entrance and future career options.
So even this slide deck points to a difference in interests and aptitudes as a key driving factor in women focusing less on STEM careers.
> In term of the latter, women are more involved with healthcare than men – accounting for 77% of NHS employees8 – and, according to research from the US9 females make 80% of buying decisions about healthcare products and services.
Why are the authors of these slides not equally concerned with the under representation of men in health care?
When we talk about sexism in the workplace people will often say "it's a pipeline problem" -- we don't see women leaders because there aren't enough women juniors to apply for those positions.
> women are more involved with healthcare than men – accounting for 77% of NHS employees
Why are women under-represented in senior leadership positions in the NHS?
I don't know, but the original topic was whether women are actively discouraged from studying technology and pushed towards other fields by high school educators. There seems to be some evidence girls and women are picking other fields over technology due to their personal interests and talents.
The question of men disproportionately filling higher level roles within organizations is a separate question, and seems to affect other industries in addition to technology.
> 31% of males have learned about technology from their own research, against only 12% of females.
So a lot of male interest in technology is self driven.
This is a slide deck trying to show women are being unfairly denied a technology career, but then goes on to give a lot of evidence most of the discrepancy is due to self selection.
"The present study makes several important contributions to the literature. First, it is the first comprehensive meta-analysis on sex differences in vocational interests. We synthesized evidence from interest inventories over four decades and found large sex differences in vocational interests, with men preferring working with things and women preferring working with people. These sex differences are remarkably consistent across age and over time, providing an exception to the generalization that only small sex differences exist. Second, this study provides a systematic review of the sex differences in the STEM interests that has not previously appeared in the literature. The pattern of sex differences in theSTEM interests revealed by the present study closely resembles the composition of men and women in corresponding occupations and contributes to the understanding of the gender disparity in theSTEM fields. The results suggest that the relatively low numbers of women in some fields of science and engineering may result from women’s preference for people-oriented careers over things-oriented careers"
Because men and women aren't as equal as everyone likes to think. And here's the best part: that's OK! It's OK to admit that men are better at some things than women, and vice versa. There's a reason why the men went out on the hunting trips and the women stayed back at the village to take care of the village children: it kept everyone alive.
I contend that there may still be some forces in some industries that try to subvert efforts at more women in them, but those are few and far between. With the gender earnings gap already proven to be bullshit (and if anything, in tech, women are getting paid more simply because companies want to fill diversity quotas), we need to stop wasting time fighting amongst ourselves and focusing effort on real, actual problems. Workers divided over petty shit like this is what the rich and powerful want.
There's a simpler explanation. Stem is all about persistent laser focused attention on specific measurable things, and females are less inclined to like this activity.
Actually it's not a myth. Look up bureau of labor statistics. Women clearly make less than men. I feel something must be done to resolve compensation when controlling for skills, experience, etc, gender alone shouldn't result in lower pay.
Again, there is no difference in average hourly rate of wage. Men make more money than women because men (on average) work more hours a week as compared to women. Also men take fewer days off (on average). Thats the reason behind the mythical "wage gap". So, the correct term for it is "earnings gap".
There have been a bunch of studies of this, and the conclusions are pretty consistent: women aren't paid less for doing equal work, they're paid less because they end up doing less or lower-paid work once they have children, because they do a disproportionate share of the childcare.
This should still be fixed, but it means the fix is mostly about what happens at home, not what happens at work, which is much more difficult.
> no one is forcing women out of the tech industry
Nobody said that. They never end up in the tech industry to begin with, because they're either dissuaded in high school, or they start and then leave because it's such a male-dominated environment
"A meta-analysis by Flore and Wicherts (2015) concluded that the average reported effect of stereotype threat is small, but also that the field may be inflated by publication bias. They argued that, correcting for this, the most likely true effect size is near zero.[19]"
The third reference wasn't available, so can't comment.
These types of "studies" tend to suffer from causal inversion, i.e. "wet roads cause rain", in arguing that the perception of these fields as male-dominated causes women to not enter them.
The simpler and more plausible explanation is stereotyp accuracy: people correctly perceive these fields as male-dominated because women tend to not enter them. That such a perception is an effective deterrent seems implausible given the many other fields that used to be completely male-dominated and are now female-dominated (for example veterinary medicine).
As a feminist, I also can't get on-board with a view of women as such delicate fragile flowers that such perceptions would prevent them from doing something they like, and it doesn't match the women in my life...but maybe I have been blessed with unusually non-delicate women, who knows?
Finally, who says it is female underrepresentation? Maybe it is male overrepresentation? And in fact, there is strong evidence that this is the case. Both men and women who score well in both verbal and math SATs tend to go into non-STEM fields. People who only do well in math tend to go into STEM fields, partly because they don't have a choice. And that group is largely male.
Yes, there is debate about these things, as there often is in the social sciences. This is from the same criticism section on wikipedia:
"In a 2009 meta-analysis, Gregory M. Walton and Steven J. Spencer argued that studies of stereotype threat may in fact systematically under-represent its effects, since such studies measure "only that portion of psychological threat that research has identified and remedied. To the extent that unidentified or unremedied psychological threats further undermine performance, the results underestimate the bias."[23] Despite these limitations, they found that efforts to mitigate stereotype threat significantly reduced group differences on high-stakes tests.[23]"
Please also note that nobody is claiming that stereotype threat is the only factor in STEM performance.
I'm no expert in the field either, and I welcome discussion. But I would prefer a better faith argument than copying the most "gotcha" paragraph from the criticism section of wikipedia.
If you could verbalize your skepticism more clearly I think this discussion would be more fruitful.
EDIT: I see you have edited your comment and added a lot. The above was my response to your first draft.
>As a feminist, I also can't get on-board with a view of women as such delicate fragile flowers that such perceptions would prevent them from doing something they like, and it doesn't match the women in my life...but maybe I have been blessed with unusually non-delicate women, who knows?
This feels especially in bad-faith. These are statistical effects, at society scale. Considering how clear the effectiveness of repeated messages is at a social level (e.g. marketing, religion, fake news, ideology), it should not surprise you that ideas of stereotypes influence people's behaviour. Humans fall for marketing as a society, are we all "delicate fragile flowers"?
I have many times, yep! My male reports have had huge promotions and raises under me as well. Very strange that people think because she was a woman it must be favoritism.
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 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 ;)