Talk Abstract: 谈话摘要:
Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?
你的职称是“软件工程师”,但你似乎大部分时间都花在会议上。您希望有时间编写代码,但没有其他人来培训初级工程师、更新路线图、与用户交谈、注意遗漏的内容、询问有关设计文档的问题,并确保每个人都大致了解情况相同的方向。如果你停止做这些事情,团队就不会那么成功。但现在有人建议你担任技术含量较低的职位可能会更快乐。如果这描述了你,那么恭喜你:你就是粘合剂。如果不是,您是否想过谁在您的团队中担任这个角色?
Every senior person in an organisation should be aware of the less glamorous - and often less-promotable - work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry.
组织中的每一位高级人员都应该意识到,要使团队取得成功,需要进行一些不那么光鲜亮丽、通常也不太晋升的工作。经过精心管理,胶水工作展示并建立了强大的技术领导能力。如果不自觉地这样做,可能会限制职业生涯。它可以将人们推向技术含量较低的角色,甚至退出该行业。
Let's talk about how to allocate glue work deliberately, frame it usefully and make sure that everyone is choosing a career path they actually want to be on.
让我们谈谈如何有意识地分配粘合工作,有效地构建它,并确保每个人都选择他们真正想要的职业道路。
Slides: 幻灯片:
You know that thing where everyone on a software engineering team turns up and just writes code for eight hours a day and then later the project is successful? No you don't. Projects don’t work like that!
您知道软件工程团队中的每个人都每天只写八小时代码然后项目就成功的事情吗?不,你不知道。项目不是这样运作的!
Of course coding is an important skill in a software engineering team. But there are a ton of other skills that we need to bring to work every day. Skills that can mean the difference between a project that succeeds and one that fails.
当然,编码是软件工程团队的一项重要技能。但我们每天还需要将大量其他技能带到工作中。技能可能决定项目的成功与失败。
Like noticing when other people in the team are blocked and helping them out. Or reviewing design documents and noticing what's being handwaved or what's inconsistent. Or onboarding the new people and making them productive faster. Or improving processes to make customers happy.
就像注意到团队中的其他人何时被阻止并帮助他们一样。或者审查设计文档并注意哪些内容被随意修改或哪些内容不一致。或者让新员工入职并提高他们的工作效率。或者改进流程以使客户满意。
I call all of this glue work.
我把所有这些称为粘合工作。
It's technical leadership, so we do get some signal for it on leadership interviews for senior engineers.
这是技术领导力,所以我们在高级工程师的领导力面试中确实得到了一些信号。
But sometimes a team ends up someone who isn't senior, but who happens to be good at this stuff. Someone who acts senior before they're senior. This kind of work makes the team better -- there's plenty of it to go around. But people aren't always rewarded for doing it.
但有时候,一个团队最终会出现一些不资深的人,但他恰好擅长这件事。一个人在成为高级之前就表现得高级。这种工作可以让团队变得更好——有很多事情可以做。但人们并不总是因为这样做而得到回报。
In fact, doing glue work too early can be career limiting, or even push people out of the industry.
事实上,过早从事胶水工作可能会限制职业生涯,甚至将人们赶出该行业。
It's ironic. We lose good engineers because they happen to also be good at other skills we need.
很讽刺。我们失去了优秀的工程师,因为他们恰好也擅长我们需要的其他技能。
Hello, my name's Tanya and I'm a principal software engineer at Squarespace. I'm whereistanya on twitter and github and I blog here at noidea.dog, which is of course a Squarespace site.
大家好,我叫 Tanya,是 Squarespace 的首席软件工程师。我在 twitter 和 github 上使用 whereistanya,我的博客在 noidea.dog,这当然是 Squarespace 网站。
And today I want to talk about glue.
今天我想谈谈胶水。
Here's our agenda: 这是我们的议程:
1) I'm going to tell a story of someone whose career is hurt by glue work. It's not exactly a true story but it's a lot of true stories combined. I've given this talk a few times now and I've had so many amazing emails from people who’ve told me this was their story too.
1) 我要讲述一个因胶水工作而事业受到损害的人的故事。这不完全是一个真实的故事,但它是很多真实故事的结合。我已经做过几次这样的演讲了,我收到了很多令人惊叹的电子邮件,他们告诉我这也是他们的故事。
2) Then we're going to talk about fairness, both in the outcome of the story and in how work is distributed
2)然后我们将讨论公平性,包括故事结果和工作分配方式
3) Then we're going to talk about whether and when to leave the IC engineer track and become a people manager, product manager, etc. I imagine a lot of people reading this have grappled with this decision at some point. There are a lot of opinions on how to make it and I'll give you one more :-)
3)然后我们将讨论是否以及何时离开 IC 工程师的轨道并成为人员经理、产品经理等。我想很多读到这篇文章的人都曾在某个时候为这个决定而苦苦挣扎。关于如何制作有很多意见,我再给你一个:-)
4) Then how to frame your work if you've been doing a lot of glue, and how to makes your impact visible. Or how to help your coworkers or reports do the same thing.
4)如果你已经做了很多胶水,那么如何构建你的作品,以及如何让你的影响可见。或者如何帮助您的同事或下属做同样的事情。
5) And finally, I want to talk about learning and growing, which is something I don't think our industry talks about enough.
5) 最后,我想谈谈学习和成长,我认为我们的行业对此讨论得还不够。
Ok, story time. Imagine a software engineer....
好啦,故事时间到了。想象一下一个软件工程师......
Here she is, first day in a new team. She's been out of college a few years, had her first couple of tech jobs. She's not wildly confident in her skills, but likes the work.
这是她加入新团队的第一天。她已经大学毕业几年了,开始了她的前几份技术工作。她对自己的技能不太有信心,但喜欢这份工作。
The new codebase is very hairy and her first changes take a long time. This is normal, but everyone's busy with their own stuff and nobody's reassuring her. She feels like she's working too slowly, needing too much help. After a few weeks, she’s afraid they regret hiring her.
新的代码库非常复杂,她的第一次更改需要很长时间。这很正常,但每个人都忙着自己的事情,没有人让她放心。她觉得自己工作得太慢,需要太多帮助。几周后,她担心他们会后悔雇用她。
Then she gets her first win. A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed.
然后她获得了她的第一场胜利。客户提出请求:他们想要 API 真正应该能够提供的数据,但团队尚未优先考虑此功能。我们的朋友花了几天时间手动获取客户所需的数据。顾客欣喜若狂。
She documents how to get that data, and some answers to other questions the team gets asked a lot on slack. The team stops getting so many interruptions. The customers are happy; the other software engineers are happy.
她记录了如何获取这些数据,以及团队在 Slack 上经常被问到的其他问题的一些答案。团队不再受到如此多的干扰。顾客高兴;其他软件工程师都很高兴。
Ok, back to that difficult code.
好吧,回到那个困难的代码。
A while later, she gets talking with people on a nearby team. They seem to have a different idea of what problem they're all solving and they're going in a different direction. She sets up a meeting with System Designer on her team and asks a lot of questions. The thing changes direction. Now they're working together and building something better. She takes notes at the meeting and sends them around to make sure everyone has a shared understanding of what got agreed.
过了一会儿,她开始与附近团队的人交谈。他们似乎对自己要解决的问题有不同的想法,并且正在走向不同的方向。她与团队中的系统设计师召开了一次会议,并提出了很多问题。事情改变方向。现在他们正在共同努力,打造更好的东西。她在会议上做笔记并将其分发出去,以确保每个人都对商定的内容有共同的理解。
New people join the team. She remembers her difficult first few weeks and writes a bunch of onboarding documents. She sets up a mentorship program, so all new people will get a mentor from now on.
新人加入团队。她记得最初几周的困难,并写了一堆入职文件。她设立了一个导师计划,所以从现在开始所有新人都会得到一位导师。
The company keeps having outages, and they’re often attributed to lack of tests in the codebase. She gathers a bunch of senior people and keeps pushing until they agree on coding standards for the whole organisation. All code will be more tested, more readable and more reliable now. There are fewer rollbacks. Code review gets faster because the code's in a consistent style.
该公司不断出现中断,通常归因于代码库中缺乏测试。她聚集了一群资深人士并不断推动,直到他们就整个组织的编码标准达成一致。所有代码现在都将经过更多测试、更具可读性和更可靠。回滚次数较少。代码审查变得更快,因为代码的风格一致。
The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is?
经理有很多团队,并且开始依赖工程师来了解这个团队的情况。嘿,Awesome Coder 似乎被屏蔽了。你知道这笔交易是什么吗?
Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code. Since she now has a lot of state on the project, our Engineer writes his documentation and launch plan. The thing ships on time.
我们的工程师进行了调查,发现 Awesome Coder 需要来自另一个团队的信息,但陷入了长达三周的电子邮件线程中。她与现实生活中的一些人交谈,找出困惑所在,并加以解决。 Awesome Coder 已解锁。他说谢谢,写了数千行代码。由于她现在对该项目有了很多了解,我们的工程师编写了他的文档和启动计划。东西准时发货。
Well done Awesome Coder, says everyone.
大家都说,干得好,Awesome Coder。
Two years pass like this. Engineer keeps vowing that she will write more code soon….
两年就这样过去了。工程师一直发誓她很快就会编写更多代码……
….but every day, something more important comes up. They team has started to treat her as an unofficial lead. She has a broad view of everything that's going on and can spot the negative space between the designs and point out extra things that need to happen. She has 1:1s with everyone. She's mentoring all the new people.
……但是每天都会有更重要的事情出现。他们的团队已经开始将她视为非正式的领导者。她对正在发生的一切有广阔的视野,可以发现设计之间的空白,并指出需要发生的额外事情。她和每个人都是1:1的。她正在指导所有新人。
When she does have free time, it's an hour or two between meetings. The idea of swapping the code into her brain for two hours and then going to a meeting is really painful.
当她有空闲时间时,会议之间会间隔一两个小时。将代码交换到她的大脑中两个小时然后去开会的想法真的很痛苦。
She's not worried though, because everyone tells her how great her work is. She always gets glowing performance reviews. In fact she feels like she's gone up a level.
不过她并不担心,因为每个人都告诉她她的工作有多么出色。她总是得到热烈的绩效评价。事实上,她感觉自己已经上升了一个层次。
Let's see if her company's promotion process agrees. Who should we promote?
看看她公司的晋升流程是否同意。我们应该提拔谁?
Well, obviously the person who wrote all that code! Well done Awesome Coder!
嗯,显然是编写所有代码的人!干得好,很棒的编码器!
And the person who did the design for the thing, and made it integrate so well with the stuff they were building in the other team! Well done, System Designer!
以及为该产品进行设计并使其与他们在其他团队中构建的产品完美集成的人!干得好,系统设计师!
Aaaaaand…. 啊啊啊……
…that’s it. …就是这样。
Wait, what? 等等,什么?
Why not me? 为什么不是我?
Your project isn't finished. You're not producing much code. You didn't have enough impact yet.
你的项目还没有完成。您没有生成太多代码。你还没有产生足够的影响力。
But I decreased onboarding time.
但我减少了入职时间。
I noticed that we were building the wrong thing and made us change course.
我注意到我们正在构建错误的东西并让我们改变方向。
Our customers say I'm the only person who helps them.
我们的客户说我是唯一帮助他们的人。
I introduced coding standards and testing guidelines and now we have faster code reviews and fewer rollbacks.
我介绍了编码标准和测试指南,现在我们有了更快的代码审查和更少的回滚。
I review all of our design documents and the comments I leave and the questions I ask make us build better things.
我会审查我们所有的设计文档以及我留下的评论和我提出的问题,使我们能够构建出更好的东西。
They're like yes, this is good work. But you didn't really have a technical contribution.
他们说是的,这是一份好工作。但你并没有真正做出技术贡献。
“Wasn’t that technical? I mean, it wasn’t code, but not all technical work is code…”
“这不是技术性的吗?我的意思是,这不是代码,但并非所有技术工作都是代码……”
And they say "Look, you're great at communication. Your soft skills are outstanding. We just don't think you're an engineer. Consider becoming a project manager instead?"
他们说:“看,你很擅长沟通。你的软技能非常出色。我们只是不认为你是一名工程师。考虑成为一名项目经理吗?”
So was it fair? At every point, this engineer did the highest impact work that was available. The project wouldn't have shipped without her. She was the glue that held the whole thing together.
那么这公平吗?在每一点上,这位工程师都做了最有影响力的工作。如果没有她,这个项目就不会顺利进行。她是将整个事情粘合在一起的粘合剂。
Over the last two years, she got really good at technical leadership: understanding the problem domain, understanding the people, introducing standards, making the designs better. But she legitimately didn't any get better at coding.
在过去的两年里,她非常擅长技术领导:了解问题领域、了解人员、引入标准、改进设计。但她确实在编码方面没有任何进步。
What do we do with this? Is she a senior engineer?
我们用这个做什么?她是高级工程师吗?
It’s ok if you feel conflicted here! I’ve asked this question a bunch of times now, and gotten responses right across the board. Several people have said that the answer is so obvious that the question didn’t need to be asked (though they don’t agree on what the answer is), but most people have been conflicted about it.
如果您在这里感到矛盾也没关系!我已经多次问过这个问题,并得到了全面的答复。有几个人说答案是如此明显,以至于不需要提出这个问题(尽管他们不同意答案是什么),但大多数人对此感到矛盾。
One thing I'm certain of is that her manager bears some responsibility here. There was a communications breakdown.
我确信的一件事是她的经理在这里负有一些责任。通讯出现故障。
This shouldn't have been a surprise. This engineer got glowing performance reviews. She believed she was on the path to senior engineer. And you know, she did the kind of work and solved the kinds of problems I would expect senior or even staff engineers to pick up. She’s definitely got the leadership part covered.
这并不奇怪。这位工程师获得了好评如潮的绩效评价。她相信自己正在成为高级工程师。你知道,她所做的工作并解决了我希望高级工程师甚至普通工程师能够解决的问题。她肯定已经涵盖了领导力部分。
But this company doesn't consider that to be sufficient promotable work, at least not at this level. Although they didn't explicitly say so, they want code or other quantifiable technical work. And her manager never told her she was doing too much non-promotable work. Probably the manager was probably just glad that the glue work was getting done. Because someone needed to do it.
但该公司并不认为这是足够值得推广的工作,至少在这个层面上是这样。尽管他们没有明确表示,但他们想要代码或其他可量化的技术工作。她的经理从未告诉她,她做了太多无晋升的工作。经理可能只是很高兴胶水工作完成了。因为需要有人去做这件事。
Glue work is the difference between a project that succeeds and one that fails. This is why technical program managers and project managers make such an impact: they do the ultimate glue role. They see the gaps and fill them.
粘合工作是项目成功与失败之间的区别。这就是技术项目经理和项目经理产生如此影响的原因:他们发挥着最终的粘合剂作用。他们看到差距并填补它们。
In teams without a project manager, what happens? In some teams, the manager takes up the load. In others, the work gets spread among the people willing to do it, or the people expected to volunteer for it.
在没有项目经理的团队中,会发生什么?在一些团队中,经理承担起重任。在另一些情况下,工作会分散到愿意做这件事的人或期望自愿做这件事的人中。
I read this article about volunteering on hbr.org (there's an accompanying 35 page publication if that’s more your speed). It showed that, when there is non-promotable work to be done, women volunteer to do it 48% more often than men.
我在 hbr.org 上读到了这篇关于志愿服务的文章(如果您不介意的话,还有一份 35 页的随附出版物)。研究表明,当需要完成无法晋升的工作时,女性自愿去做的频率比男性高 48%。
But they also found that men volunteered less because if they waited, they knew that a woman would volunteer. In all male groups, they had no trouble getting volunteers. If there were no women there, men volunteered just fine.
但他们还发现,男性自愿参与的人数较少,因为如果他们等待,他们知道女性会自愿参与。在所有男性团体中,他们都很容易找到志愿者。如果那里没有女性,男性自愿参加就可以了。
The even more interesting part was that, when managers were asked to choose someone to do thankless work, they asked women 44% more than they asked men.
更有趣的是,当管理者被要求选择某人来做吃力不讨好的工作时,他们对女性的要求比对男性的要求多 44%。
(Article: https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions)
(文章:https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions)
I want to be clear that I'm not saying 100% of your work needs to be promotable work. It's good to build auxiliary skills and expand your horizons, and it's important for everyone to do their fair share of taking out the garbage. But a large percentage of your work should be the thing you're evaluated on. If someone's doing very little of their core job, they are hurting their career. If you're their manager and letting them do that, you are letting them hurt their career.
我想澄清的是,我并不是说你的工作 100% 都需要是可晋升的工作。培养辅助技能和拓展视野是件好事,而且每个人都尽自己的一份力量倒垃圾也很重要。但你的工作的很大一部分应该是你被评估的内容。如果某人只做很少的核心工作,他们的职业生涯就会受到损害。如果你是他们的经理并让他们这样做,你就是在让他们损害自己的职业生涯。
Non-promotable work is one of those "one person's trash is another's treasure" things. Like, if an engineer organises an offsite, that's non-promotable work, but a people manager can maybe claim it's part of their job to do team-building. If an event coordinator does it, it's probably their core job.
不可晋升的工作就是“一个人的垃圾是另一个人的宝藏”的事情之一。例如,如果工程师组织异地活动,那是无法晋升的工作,但职能经理可能会声称团队建设是他们工作的一部分。如果活动协调员这样做,这可能是他们的核心工作。
Where there's work that is genuinely non-promotable for anyone, it needs to be shared. The work needs to be tracked whatever way the team tracks its other work, and it needs to be shared out deliberately. If it just gets done by whoever picks it up, it won't fall fairly.
如果某些工作确实对任何人来说都无法晋升,那么它就需要被分享。无论团队以何种方式跟踪其他工作,都需要跟踪该工作,并且需要有意地进行共享。如果只是谁接谁就完成了,那么它就不会公平地掉落。
I invite you take a moment to think about who's doing the non-promotable work on your team.
我邀请您花点时间考虑一下谁在您的团队中从事不可晋升的工作。
Ok, back to our friend. Folks are now suggesting that she change to a role where that same work would be promotable. And I've seen this a lot of times: this message of "you're doing work that's not promotable, so change your role". I haven't seen as much emphasis on "so change your work" or indeed "so change how you tell the story of your work".
好吧,回到我们的朋友。人们现在建议她换一个同样的工作可以得到晋升的职位。我已经多次看到这样的信息:“你正在做的工作没有晋升机会,所以改变你的角色”。我没有看到如此多的强调“所以改变你的工作”或者“所以改变你讲述工作故事的方式”。
Let's talk about changing roles. I have read a lot of articles about deciding whether to do a role or not. Most of them are people who are doing a job talking about whether you're cut out to do that job. As if the ability to do something means that you have to do it.
我们来谈谈角色转换。我读过很多关于决定是否扮演某个角色的文章。他们中的大多数都是正在做某项工作的人,谈论你是否适合做这份工作。好像有能力做某事就意味着你必须这样做。
They say: can you handle giving feedback, do you like coaching, do you like people? Then you should be a manager.
他们说:你能处理提供反馈吗?你喜欢辅导吗?你喜欢与人相处吗?那么你应该成为一名经理。
Can you put yourself inside the shoes of your customer? Then, yes, congratulations you're a product manager. IT IS DECIDED.
你能设身处地为客户着想吗?那么,是的,恭喜你成为一名产品经理。事情已经决定了。
But it's like those signs at carnivals: "You must be this tall to go on the rollercoaster". "Ok, I'm tall enough, but that looks horrible."
但这就像嘉年华上的标语:“你必须长这么高才能坐过山车”。 “好吧,我够高了,但这看起来很可怕。”
"You must be this socially competent to be a manager." I am, but that is not my idea of a good time!
“你必须具备这样的社交能力才能成为一名经理。”我是,但这不是我心目中的好时光!
I have my own metric for it. If you code, you get better at coding. If you manage people, you get better at managing people.
我有自己的衡量标准。如果你编码,你就会在编码方面做得更好。如果你管理人员,你就能更好地管理人员。
So… 所以…
... what do you want to get better at?
...你想在什么方面变得更好?
What are the skills you want? It's not about what skills you already have! What skills do you wish you had? The vast majority of our learning happens on the job.
你想要什么技能?这不是你已经拥有什么技能的问题!你希望自己拥有什么技能?我们的绝大多数学习都是在工作中进行的。
But I see people not considering the roles they want because they don't feel like they already have all the skills of that job. I've had a lot of CS college students tell me they're not applying for programming jobs because they don't feel like they're strong programmers.
但我看到人们没有考虑他们想要的角色,因为他们觉得自己还没有具备该工作的所有技能。很多计算机科学专业的学生告诉我,他们不申请编程工作,因为他们觉得自己不是优秀的程序员。
Of course they aren't! They're still in college. The vast majority of our learning happens on the job.
当然不是!他们还在上大学。我们的绝大多数学习都是在工作中进行的。
They end up choosing a role that they don't want because they're scared of doing the role they do want, or because someone else tells them that they would be good at the other role.
他们最终选择了一个他们不想要的角色,因为他们害怕做自己想要的角色,或者因为其他人告诉他们他们会擅长另一个角色。
I advise people to choose deliberately. Choose a role that you'll feel successful and happy and proud to say you do, and that will teach you skills you want. Do a job you’re excited by. You will learn to get good at it by doing it. I feel like we don't admit it often enough enough that most of the time, we won't do a job well on day one. The vast majority of our learning happens on the job.
我建议人们谨慎选择。选择一个让你感到成功、快乐和自豪的角色,这将教会你你想要的技能。做一份让你兴奋的工作。通过这样做,你将学会擅长它。我觉得我们承认得不够频繁,以至于大多数时候,我们在第一天就无法做好工作。我们的绝大多数学习都是在工作中进行的。
There's another consideration though, especially when people make this decision in college or when they're junior. Taking a step away from a more technical role closes doors. It's not fair, but our industry biases are set up so that you really need to have a solid engineering resume before you take a non-engineering role.
不过,还有另一个考虑因素,尤其是当人们在大学或大三时做出这个决定时。远离技术性更强的角色就会关闭大门。这不公平,但我们的行业偏见是这样设置的,因此在担任非工程职位之前,您确实需要拥有扎实的工程简历。
Because the moment you give up that engineer title, the moment the most recent job on LinkedIn does not have the word "engineer" in it, half the industry will assume your existing tech skills are *gone forever* and you're somehow incapable of acquiring more. I don't know how this brain science is supposed to work, but it's such a common implicit bias.
因为当你放弃工程师头衔的那一刻,当LinkedIn上最近的工作中没有“工程师”这个词的那一刻,一半的行业就会认为你现有的技术技能已经“永远消失了”,并且你在某种程度上无法胜任获取更多。我不知道这门脑科学应该如何运作,但这是一种常见的隐性偏见。
Especially if your job title is any variant on "project manager". Many people will immediately assume you are not good at technology.
特别是如果您的职位名称是“项目经理”的任何变体。很多人会立即认为你不擅长技术。
Kripa Krishnan, the legendary director of cloud product operations at Google once said that while she'd experienced some industry prejudice for being female and some for having an accent, it was nothing compared to the prejudice she experienced for being a TPM.
谷歌云产品运营传奇总监克里帕·克里希南(Kripa Krishnan)曾表示,虽然她因女性身份和口音而经历过一些行业偏见,但与她作为 TPM 所经历的偏见相比,这些都不算什么。
Project managers and TPMs are routinely underestimated by engineers.
项目经理和 TPM 经常被工程师低估。
I have seen a lot of people take a role like this and, find themselves pushed towards being a non-technical manager or project manager: a step towards leaving the industry. I've seen some look back at engineer jobs and discover that they also can't get hired at the level of developer they used to be, even if it was quite recent. As if the skills they had have evaporated.
我见过很多人担任这样的角色,并发现自己被推向成为非技术经理或项目经理:这是离开该行业的一步。我看到一些人回顾了工程师的工作,发现他们也无法达到以前的开发人员水平,即使这是最近的事情。仿佛他们所拥有的技能都蒸发了。
They have to come in at a lower level than they left because people don’t believe they are capable of the job. They will invariably hear the three most infuriating words in the industry:
他们上任时的级别必须低于离开时的级别,因为人们不相信他们有能力胜任这份工作。他们总会听到业内最令人气愤的三个词:
“NOT TECHNICAL ENOUGH". What even is this. What is "technical" here? How do you do anything actionable with that? It's so domain-specific!
“技术性不够”。这到底是什么?这里的“技术性”是什么?你如何用它来做任何可行的事情?它是如此特定于领域!
If you're ever tempted to tell someone they're not technical enough, well, first of all just don’t. But be really specific about what you need them to know. Like:
如果你曾经想告诉某人他们技术不够,那么首先不要这样做。但要真正具体说明您需要他们了解的内容。喜欢:
"You need to understand and participate in the technical discussion in design meetings, so please get comfortable with the tradeoffs in this set of technology. Here's a book I recommend.
“你需要理解并参与设计会议中的技术讨论,所以请适应这套技术的权衡。这是我推荐的一本书。
Or: "Our senior engineers are all system designers. Please take some distributed systems classes and have opinions about the CAP theorem.
或者:“我们的高级工程师都是系统设计师,请参加一些分布式系统课程并对CAP定理发表意见。
Otherwise, you're basically only saying…
否则,你基本上只是在说……
"You don't really seem like an engineer. Could you be more engineer-y?"
“你看上去不太像工程师。你能更像工程师一点吗?”
It's gatekeeping. It's not actionable feedback.
是看门的。这不是可操作的反馈。
Which brings us back to our friend.
这让我们回到了我们的朋友身上。
Two years ago she joined as a mid-level engineer. Since then she's spent her time filling gaps to make the team and the organisation succeed. As a result, she's just been told she doesn't have technical accomplishments.
两年前,她以中级工程师的身份加入。从那时起,她就花时间填补空白,使团队和组织取得成功。结果,她被告知她没有技术成就。
And she'd like a promotion. Let's talk about that for a second. I'm putting a lot of emphasis on career advancement and that's not a priority for everyone. That's fine. Here's an explicit bias I have: I want this engineer lady to feel fulfilled and also to have long-term financial security. She'd like to some day retire and buy a little boat. I want to help with that.
她还想升职。让我们讨论一下这个问题。我非常重视职业发展,但这并不是每个人都优先考虑的。没关系。我有一个明显的偏见:我希望这位工程师女士感到满足,并拥有长期的财务保障。她希望有一天退休并买一艘小船。我想帮忙。
I don’t know what her right career choice is. Only she can make that decision. She should choose deliberately, based on:
我不知道她正确的职业选择是什么。只有她才能做出这个决定。她应该基于以下因素慎重选择:
* what would she love to get better at?
* 她希望在哪些方面变得更好?
* What is a job that she'll feel happy and proud to do?
* 做什么工作会让她感到快乐和自豪?
* What doors is she comfortable making hard to reopen?
* 哪些门让她觉得难以重新打开?
and unfortunately one more:
不幸的是还有一个:
* Where will she feel safe?
* 她在哪里会感到安全?
If she chooses a role she’s less excited about but where she feels more supported and less alone, I can't judge her for that. But I hope she gets to do something she loves.
如果她选择了一个她不那么兴奋的角色,但她感到更多的支持和更少的孤独,我不能因此评判她。但我希望她能做自己喜欢的事情。
Either way, I will respect her decision :-)
不管怎样,我都会尊重她的决定:-)
But, because I don’t have time to do Choose Your Own Adventure in slides, for the rest of this talk we're going to assume she decides to stay as an engineer, because I think we don't talk about the senior IC path enough and I'm a fan.
但是,因为我没有时间在幻灯片中选择自己的冒险,所以在本次演讲的其余部分中,我们将假设她决定继续担任工程师,因为我认为我们不会谈论高级 IC路径足够了,我是它的粉丝。
So, she wants to be a senior engineer and, really, she's already doing most of that job. But she's getting a whole lot of "not technical enough".
所以,她想成为一名高级工程师,实际上,她已经完成了大部分工作。但她却得到了很多“技术不够”的评价。
What do you do if you’re glue? What do you do if you're managing someone who's glue? How do you make sure not to waste this valuable skillset? Here's a four step plan.
如果你是胶水,你会怎么做?如果你管理的人是黏人,你会怎么做?您如何确保不浪费这些宝贵的技能?这是一个四步计划。
First off, there needs to be a long-overdue career conversation between this engineer and her manager. She needs to ask direct questions like "Will I get promoted next round?" "What work do I need to do to get promoted?" "Is this senior engineer work?”
首先,这位工程师和她的经理之间需要进行一场期待已久的职业对话。她需要直接问“我下一轮会晋升吗?”之类的问题。 “我需要做什么工作才能升职?” “这是高级工程师的工作吗?”
Her manager needs to be honest and direct too, based on their understanding of the career ladder.
基于他们对职业阶梯的理解,她的经理也需要诚实和直接。
They need to agree on goals, make a plan, and check in at intervals and make sure they're still on track.
他们需要就目标达成一致,制定计划,并定期检查并确保他们仍在正轨上。
Second: a job title. If she and her manager want her to continue doing a lot of glue work, is there a title that gives her tech credibility? Can she become technical lead or something? People expect a lead to do a ton of glue.
第二:职称。如果她和她的经理希望她继续做大量的胶水工作,是否有一个头衔可以赋予她技术可信度?她能成为技术主管什么的吗?人们期望一根铅就能产生大量的胶水。
Ok, there are probably some people reading this and thinking titles don't matter. And maybe you don't need them, internet person! But that doesn't mean other people don't.
好吧,可能有些人读到这篇文章时认为标题并不重要。也许你不需要它们,互联网人!但这并不意味着其他人不这样做。
Look. If you're a white or Asian dude, everyone assumes you're good at coding, just by default. You could have graduated yesterday with a degree in law, and people assume you can code.
看。如果你是白人或亚洲人,每个人都会默认你擅长编码。你昨天就可以毕业并获得法律学位,人们会认为你会编码。
For the rest of us, we don't get that free assumption. A job title saves time and energy that we don’t need to spend putting our credentials on the table. It gives us some hours back in our week.
对于我们其他人来说,我们没有得到这种自由的假设。职称可以节省我们的时间和精力,我们不需要花这些时间和精力来证明我们的资历。它让我们一周能节省一些时间。
And it gives us some freedom to do glue work without people deciding we're "not technical enough" any more.
它给了我们一些进行粘合工作的自由,而不会再有人认为我们“技术不够”。
If you're telling underrepresented folks in your org that titles don't matter, you're doing them a disservice. Titles matter a ton.
如果您告诉组织中代表性不足的人员头衔并不重要,那么您就是在伤害他们。标题非常重要。
Third, she needs artifacts of her work that show her impact and tell the story. Due to her work and her technical judgement, this thing happened.
第三,她需要作品中的文物来展示她的影响力并讲述她的故事。由于她的工作和技术判断,这件事发生了。
Her manager should be telling the same story. If you see this situation, where a glue person is the only reason something launched, publicly give them credit! And not for helping, but for leading.
她的经理应该也会讲同样的故事。如果您看到这种情况,其中胶水人是推出某物的唯一原因,请公开给予他们信任!不是为了帮助,而是为了领导。
She should be creating and saving artifacts that back up this narrative: design proposals, meeting notes, group emails, crucial points where she made the thing happen.
她应该创建并保存支持这一叙述的工件:设计提案、会议记录、小组电子邮件、她使事情发生的关键点。
Now, this might still not work. It might be six months later, and the promotion folks say no again. In that case, I have a solution that's a bit cynical. If you’re not getting promoted for glue work…
现在,这可能仍然行不通。可能六个月后,促销人员又拒绝了。在这种情况下,我有一个有点愤世嫉俗的解决方案。如果你没有因为胶水工作而得到晋升……
.stop doing glue work. I would advise her to -- temporarily -- do EXACTLY the thing on the job ladder, even if it means letting more important things drop.
.停止做胶水工作。我建议她暂时做那些工作阶梯上的事情,即使这意味着放弃更重要的事情。
She should do some easily quantifiable technical work. Write a bunch of code. Write some designs that anyone could have written. Learn how to performance tune the database. Do something that is unarguably "technical".
她应该做一些容易量化的技术工作。写一堆代码。写一些任何人都可以写的设计。了解如何调整数据库性能。做一些毫无疑问是“技术性”的事情。
She should do it even if she's not the best person on the team to do it. Even if she's rusty and she'll be a lot slower than someone else.
即使她不是团队中最适合做这件事的人,她也应该这样做。即使她生锈了,也会比别人慢很多。
But the thing is, that means she has to stop doing the other stuff.
但问题是,这意味着她必须停止做其他事情。
Coding can't fit around a full calendar of glue work.
编码无法适应完整的粘合工作日历。
So I'd advise her, until the promotion's through, to declare a lot of things not her problem.
所以我建议她,在升职结束之前,声明很多事情不是她的问题。
Stop interviewing, stop organising the off-sites, stop onboarding, stop fielding requests from users, stop anything that sounds like team building. Stop helping other people with their work. Archive mail. Quit slack channels. Do not curate the team roadmap.
停止采访,停止组织场外活动,停止入职,停止处理用户的请求,停止任何听起来像团队建设的事情。停止帮助其他人完成工作。存档邮件。退出宽松的渠道。不要策划团队路线图。
Crucially: don't catch things that are about to drop. That's incredibly hard for a lot of us, but remember that the rest of the team already does this.
至关重要的是:不要抓住即将掉落的东西。这对我们很多人来说都非常困难,但请记住团队的其他成员已经这样做了。
Stop being the unofficial lead. (If you're in the same situation and you're the official lead, consider stopping that too!)
别再充当非官方的领导者了。 (如果您处于同样的情况并且您是官方领导,请考虑停止这种情况!)
And… oof, I hate saying this, and please forgive me, but if she does a lot of diversity work for her company, I would recommend she stop doing diversity work for a while.
而且……哦,我讨厌这么说,请原谅我,但如果她为她的公司做了很多多元化工作,我会建议她暂时停止做多元化工作。
Getting promoted is diversity work. Being visibly successful is the most powerful diversity work she can do. She can be the representation someone needs. She can be in a much better position for mentorship and sponsorship.
晋升是多元化的工作。取得明显的成功是她能做的最有力的多元化工作。她可以成为某人需要的代表。她可以在指导和赞助方面处于更好的位置。
But she needs free time in her calendar to get there.
但她需要在日历上有空闲时间才能到达那里。
Only if you make a lot of things not your problem can you go from this…
只有当你做了很多不是你的问题的事情,你才能摆脱这个……
…to this. (And ideally better than this, but this is the best I could make my calendar look to do a screenshot :-))
……对此。 (理想情况下比这更好,但这是我可以让我的日历看起来像截图的最好的:-))
Those big empty spaces are good to block out for project work, coding, writing designs and so on. And that work will have a side effect, it's a virtuous cycle, which is that the person doing it will get better at coding and writing designs.
这些大的空白空间非常适合项目工作、编码、编写设计等。这项工作会产生副作用,这是一个良性循环,即从事这项工作的人会在编码和编写设计方面变得更好。
The technical term for this is *learning* :-D The vast majority of our learning happens on the job.
其技术术语是*学习* :-D 我们的绝大多数学习都是在工作中进行的。
If the skills you wish you had are part of the job you're doing all day, you get a certain amount of learning for free. Every time you hit stack overflow, you're learning something. But for anything that you're not repeatedly doing, you have to go out and choose to learn it.
如果您希望拥有的技能是您整天所做的工作的一部分,那么您可以免费获得一定量的学习。每次遇到堆栈溢出时,您都会学到一些东西。但对于任何你不重复做的事情,你必须出去选择学习。
Even for people who are getting recognised for glue work and who want to keep doing it, I really recommend you keep increasing your other skills.
即使对于那些因胶水工作而受到认可并想继续从事这项工作的人,我也强烈建议您继续提高其他技能。
If you only do glue, you will only get better at glue. You're making your team more effective but you're hurting your future self. No matter what you end up doing, you are unlikely to regret feeling more confident in core technical skills.
如果你只做胶水,你只会在胶水方面做得更好。你让你的团队变得更有效率,但你却伤害了未来的自己。无论您最终做什么,您都不会后悔对核心技术技能更有信心。
Learning is something our industry doesn't talk about a ton. All of the tech knowledge that is in people's brains, they've learned in some way. But we don’t really admit that it took time.
学习是我们这个行业很少谈论的事情。人们大脑中的所有技术知识都是他们以某种方式学到的。但我们并不真正承认这需要时间。
If you're a senior person, please, show the junior people in your organisation that you're learning and how you're doing it. Be public about what you're learning.
如果您是高级人员,请向组织中的初级人员展示您正在学习以及如何做到这一点。公开你正在学习的内容。
Some of us have the amazing privilege of having free time to learn. Others have obligations that mean they have literally zero free time.
我们中的一些人有幸有空闲时间学习。其他人有义务,这意味着他们的空闲时间几乎为零。
So make it clear that it's okay -- and normal -- to learn at work, during work hours.
因此,请明确表示在工作时间学习是可以的,也是正常的。
Turning your mid-level people into senior people is a good investment. Never waste an opportunity to have people learn things.
将中层人员转变为高级人员是一项很好的投资。永远不要浪费让人们学习东西的机会。
Even more than that, watch out for learning opportunities that you're wasting. If you're sheltering someone by always doing something for them, you're depriving them of a learning opportunity.
更重要的是,要留意你正在浪费的学习机会。如果你总是通过为某人做某事来庇护他们,那么你就剥夺了他们的学习机会。
If you have a thing you always do, that you know how to do, find someone who would benefit from learning it, and ask them -- nicely! -- if they'd like to take it over. Then get them to block out time on their calendar to learn about it, and give them your support as they do.
如果你有一件你经常做的事情,并且你知道怎么做,那就找一个能从学习这件事中受益的人,然后问他们——很好! ——如果他们想接管的话。然后让他们在日历上留出时间来了解这一点,并像他们一样给予他们你的支持。
We all only get better at what we spend time on. And we do get better if we spend time on things.
我们只会在花时间做的事情上变得更好。如果我们花时间在事情上,我们确实会变得更好。
And not just technical things.
而且不仅仅是技术方面的事情。
My amazing colleague Polina has advice on what she says when someone tries to push her into more humaning work than is good for her. They say "but you should do it because you're so good at communication." She says "Yes, I'm good at everything I put effort into. You should see me doing systems design."
我出色的同事波琳娜(Polina)对当有人试图迫使她从事对她不利的人性化工作时她所说的话提出了建议。他们说“但你应该这样做,因为你非常善于沟通”。她说:“是的,我很擅长我所付出的一切。你应该看看我做系统设计。”
So, while she's off designing systems, she's giving other people on the team a learning opportunity to become good at communication too, by putting effort into it.
因此,在她设计系统的同时,她也为团队中的其他人提供了学习机会,通过付出努力,让他们也变得善于沟通。
If you're a manager, I encourage you to help the non-glue people on your team also put effort into communication. Remember these two dudes in the story at the start?
如果您是一名经理,我鼓励您帮助团队中的非粘合人员也投入精力进行沟通。还记得故事开头的那两个家伙吗?
The Awesome Coder only succeeded because someone else on the team went and talked to other people and broke him out of the email thread of doom. He couldn't communicate well enough to ask another team for some data that he needed.
这位出色的程序员之所以成功,是因为团队中的其他人去与其他人交谈并把他从电子邮件的厄运中解救出来。他无法很好地沟通,无法向其他团队索取他需要的一些数据。
The System Designer only succeeded because someone else on the team asked what the thing he was building was actually for. He didn't have the technical judgement to step back and understand how his system would integrate with the other systems the company was building and to be clear about the problem they were all solving.
系统设计师之所以成功,是因为团队中的其他人问他正在构建的东西实际上是做什么的。他没有技术判断力来退后一步,了解他的系统如何与公司正在构建的其他系统集成,并清楚他们正在解决的问题。
Should they have been promoted? Are they really senior engineers? I don't think they are. And they won't learn to be if people keep doing their glue for them. They will get better at what they spend time on. The vast majority of their learning will happen on the job.
他们应该得到晋升吗?他们真的是高级工程师吗?我不认为他们是。如果人们继续为他们做胶水,他们就不会学会这样做。他们会在花时间做的事情上做得更好。他们的绝大多数学习都将在工作中进行。
Managers: If your job ladder doesn't require that your senior people have glue work skills, think about how you're expecting that work to get done.
经理:如果你的工作阶梯不要求你的高级人员具备粘合工作技能,请考虑一下你期望如何完成这项工作。
Glue people: push back on requests to do more than your fair share of non-promotable work and put your effort into something you want to get good at.
粘合人员:拒绝做超出你应得份额的非晋升工作的请求,并将你的精力投入到你想擅长的事情上。
Our skills aren't fixed in place. You can be good at lots of things. You can do anything.
我们的技能并不是固定不变的。你可以擅长很多事情。你可以做任何事。
💖💖💖Thank so much to the organisers of the amazing Lead Developer conference where I presented this version of these slides. Thank you also to the organizers of the equally amazing Write/Speak/Code conference who accepted the first iteration of this talk. You are wonderful folks and I so appreciate the work you do. 💖💖💖
💖💖💖非常感谢这次令人惊叹的首席开发人员会议的组织者,我在会上展示了这些幻灯片的这个版本。还要感谢同样令人惊叹的编写/发言/代码会议的组织者,他们接受了本次演讲的第一次迭代。你们都是很棒的人,我非常感谢你们所做的工作。 💖💖💖