Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Being Glue (Newer slides at

This is the old version of these slides. The newer ones are at

Your job title says "engineer", but you seem to spend most of your time in meetings. You'd like to have time for code, but then who will respond to customers, update the roadmap, talk to the teams whose projects overlap with yours, notice the things that got dropped, onboard the new folks, and ask all of the many questions that need to be asked to make the project successful?

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Being Glue (Newer slides at

  1. 1. Being Tanya Reilly @whereistanya Question for the audience: who has ever felt so unsure of their technical skills that you thought you might be in the wrong career? It's a lot of people! Who felt like that and then went on to do something you didn't think you were capable of, like you got a job or a promotion or passed a really hard class? Being sure of yourself is nice, but it's not necessary. You can have a good career in tech even if you're insecure. ----- Image: CC0
  2. 2. Hello! My name is Tanya. I'm a software engineer at Hello, my name's Tanya and I'm a principal software engineer at Squarespace here in New York City. I've been there since February and I like it a lot. Here's a strange thing about my job though: ---- Image: Squarespace.
  3. 3. I'm a software engineer. I wrote 211 lines of (work) code last quarter. ...even though my job title is software engineer, I wrote almost no code last quarter. We have a hack week three or four times a year, and during hack week all of your regular meetings and day to day work get ignored and everyone builds something fun. Last quarter, the only work code I wrote was during hack week. I love coding -- and I was about a decade in the industry before that became true -- but these days I mostly do it for fun or to make stupid games to entertain my kid. In work, it's just not the best use of my time right now. Instead I do a lot of what I call "glue work".
  4. 4. I'm a software engineer. I wrote 211 lines of (work) code last quarter. Glue work is expected in a senior role. Glue work means doing whatever it takes to make the organisation successful. I make sure we're working on the things that will take us where we need to be in a year or two. I go to a lot of meetings. I check in on projects. I review other people's designs and ask lots of questions like "What does that mean?" and "Why are we doing this?". I have a lot of 1:1s. I do a ton of mentoring and coaching. I'm a chair of our women in engineering ERG. Not much code. Because I have a title that says I have technical credibility, that's safe for me to do. People assume I can code if I need to. (I can, I swear :-) ) But suppose I did the exact same work, and I didn't have that badge to say that I'm a senior engineer whose technical skills you should take seriously….?
  5. 5. Glue work is expected in a senior role. I'm a software engineer. I wrote 211 lines of (work) code last quarter. What happens if you do glue work when you're not senior? ...this could be kind of career limiting! I have seen it happen many times! So today I want to talk about glue.
  6. 6. 1. A cautionary tale of glue! 2. But was it fair? VOTE NOW! 3. To manage or not to manage? 4. What to do when you're glue. Here's our agenda: - I'm going to tell a story of someone whose career is hurt by glue work. It's not a true story; it's an amalgam of about ten true stories I've heard from women from many different companies. - then we're going to vote on whether the outcome of the story was was unfair and I'm really interested to hear what you all think - we're going to talk about whether and when to become a people manager, product manager, etc. There are a lot of opinions out there and I'll give you one more :-) - then finally, how to frame your work if you've been doing a lot of glue, and how to make sure you keep learning and growing so you're not hurting your future self's career. Ok, story time. Imagine a software engineer....
  7. 7. Once upon a time there was 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. --- Image: CC0
  8. 8. Her new team is friendly but busy. The new codebase is very hairy and her first changes take a long time. This is extremely 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. She’s afraid they regret hiring her. After a few weeks, she’s starting to doubt that she's cut out for this. --- Image: 823 CC0.
  9. 9. But then she has a win. Then she gets her first win. She notices that the team is often interrupted by questions on Slack. She documents the answers to the questions, and the team stops getting so many interruptions. The customers are happy; the other software engineers are happy. She feels good! Ok, back to that difficult code.
  10. 10. Our customers need a thing we don't provide. A while later, 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. Engineer's main project is not any closer to being done, but helping customers takes priority, right?
  11. 11. We're duplicating work. Over lunch one day she hears that a team in the other office is working on something that's really like the thing her team is working on. She introduces System Designer on her team to the lead of the other team and the thing changes direction. Now they're working together and building something better. --- Image: CC0.
  12. 12. We are so bad at onboarding. 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. --- Images: CC0 CC0
  13. 13. We should have a style guide. And unit tests! Team members keep complaining of wildly varying code style and lack of tests in the codebase. She spends a bunch of time wrangling people into agreeing on some coding standards for the whole organisation. She keeps pushing until it's a document everyone agrees on. 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. --- Image: CC0
  14. 14. We said we'd have it done this quarter... The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Ace Coder seems blocked. Do you know what the deal is? Engineer investigates, discovers that Ace Coder needs information from another team but doesn't love talking to other humans so he keeps putting off talking to them. She’s not scared of talking to people, so she goes and sorts it out. Ace Coder is unblocked. He says thank you, writes 5000 lines of code. Since she now has a lot of state on the project, Engineer writes his documentation and launch plan. The thing ships on time. Well done Ace Coder, says everyone. Two years pass like this. Engineer keeps vowing that she will write more code soon….
  15. 15. I will code more. Soon. ….but every day, something more important comes up. 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 she always gets good performance reviews. Everyone loves the stuff she does. They team has started to treat her as an unofficial lead. She has a big picture view 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. --- This is my calendar for the week of July 16th /o
  16. 16. Who should we promote? She feels like she's gone up a level. Let's see if her company's promotion process agrees. Who should we promote? --- Image: CC0
  17. 17. The person who wrote all that lovely code! Well, obviously the person who wrote all that code! Well done Ace Coder! --- Image: CC0
  18. 18. The author of that design for the thing. 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 office! Well done, System Designer! Aaaaaand…. --- Image: CC0
  19. 19. And that's it. Wait, what? ...that's it. Wait, what?
  20. 20. And that's it. Why not me? Why not me?
  21. 21. You didn't have sufficient impact yet. ... Your project isn't finished. You're not producing much code. You didn't have enough impact yet.
  22. 22. You didn't have sufficient impact yet. ...I decreased onboarding time! But I decreased onboarding time.
  23. 23. You didn't have sufficient impact yet. I made us build the right thing! ...I decreased onboarding time! I made us build the right thing.
  24. 24. You didn't have sufficient impact yet. I made us build the right thing! ...I decreased onboarding time! I made our customers happier. Our customers say I'm the only person who helps them.
  25. 25. You didn't have sufficient impact yet. I made us build the right thing! ...I decreased onboarding time! I made our customers happier. I got us to agree on coding standards I did that thing with the coding standard and the testing guidelines.
  26. 26. I made us build the right thing! ...I decreased onboarding time! I made our customers happier. You didn't have sufficient impact yet. I got us to agree on coding standards I review all the designs. I review all of our design documents and the questions I ask make us build better things.
  27. 27. ... Yeah, but what was your technical contribution? They're like yes, this is good work. But you didn't really have a technical contribution.
  28. 28. Yeah, but what was your technical contribution? ...wasn't ...wasn't that technical? It wasn't *code* but not all technical things are code...
  29. 29. Yeah, but what was your technical contribution? ...wasn't ...that ...wasn't that technical? It wasn't *code* but not all technical things are code...
  30. 30. Yeah, but what was your technical contribution? ...wasn't ...that ...technical? ...wasn't that technical? It wasn't *code* but not all technical things are code...
  31. 31. You're great at communication. Consider a less technical role. ! And they say "Look, you're great at communication. Your soft skills are outstanding. We just don't think you're an engineer. Maybe go be a project manager instead?"
  32. 32. 1. A cautionary tale of glue! 2. But was it fair? VOTE NOW! 3. To manage or not to manage? 4. What to do when you're glue. So was it fair? Engineer did good work. 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 leadership, coordination and convincing people to do things. She also got better at some harder to quantify technical stuff: understanding the big picture, standardisation, design review. But she legitimately didn't get better at coding. What do we do with this?
  33. 33. Should Engineer be promoted to Senior Engineer? Should she have been promoted to senior engineer? ● Who thinks yes? ● Who thinks no? ● Who is extremely on the fence and conflicted? ● Who has been this engineer? One thing I'm certain of is that her manager owes her an apology.
  34. 34. You and your manager should have a shared understanding of where you're going. This shouldn't have been a surprise. She got good performance reviews. She believed she was on the path to senior engineer. And you know, a lot of her work was representative of a senior or staff engineer. If she'd spent some of her time also doing more quantifiable technical work, she could easily make the case that she's a senior engineer now. But her manager never had a conversation about how she was doing too much non-promotable work. Honestly, the manager was probably just glad that the glue work was getting done. Because… --- Image: CC0
  35. 35. Glue work takes a lot of time. Who should do it? ... 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. --- Image: CC0
  36. 36. Women volunteer more. Women are volunteered more. Source: I read an article last month about volunteering. It showed that, when there is non-promotable work to be done, women volunteer to do it 48% more often than men. But they also found that men volunteered less because if they waited, they knew the women would volunteer. If there were no women there, the men volunteered. And when managers were asked to choose someone to do the thankless work, they asked women 44% more than they asked men. --- Article: Image: CC0
  37. 37. Can anyone benefit from this work? If not, share it evenly. Some large percentage of your work should be the thing you're evaluated on. Not 100%, I think: it's good to build auxiliary skills and expand your horizons a bit. But if you're doing very little of your core job, you are hurting your career. Non-promotable 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 manager needs to track the work and share it out deliberately. If it just gets done by whoever picks it up, it won't fall fairly. --- Image: CC0
  38. 38. 1. A cautionary tale of glue! 2. But was it fair? VOTE NOW! 3. To manage or not to manage? 4. What to do when you're glue. So, back to Engineer. Folks are now suggesting that she change to a role where that same work *would be* promotable. Should she change the role or should she change the work she does? Or is there a middle ground where we can frame the glue work as promotable work? 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 you should be a product manager.
  39. 39. We don't all like the same things. It reminds me of those signs at funfairs like "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… ---- Image: CC0.
  40. 40. What do you want to get better at? Choose. So, what do you want to get better at? What are the skills you want? No what are the skills you think you already have! This is so important! I keep hearing female college students saying they don't feel like they have engineering skills so they should become product managers. Friends, of course you don't have engineering skills yet: you're still in college! Tech isn’t magical. The skills don't just descend upon you. You get engineer skills by doing the job. --- Image: CC0
  41. 41. Choose a role that you feel happy and proud to do. Don’t choose a role you don’t want because you’re scared of doing the role you really do want. Don’t choose it because you’re being pushed there, or because someone tells you should want it. Do a role that you 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 don’t need to feel confident; you just need to do it. There’s another consideration though. If you’re making this decision in college, or when you're junior… be aware that moving away from a more technical role is decreasing your options. Be very conscious of what you’re choosing. -- Image: CC0.
  42. 42. Might you want to come back? Is there a path back? There is a real phenomenon where women become an engineering manager or a technical project manager, hit a ceiling and can't find the next role, and are pushed towards being a non-technical manager or project manager. So they look back at engineering and and discover that they also can't get hired at the level of developer they used to be. 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 inevitably hear the three most infuriating words in this industry: --- Image: CC0
  43. 43. Not. Technical. Enough. The three least useful words. “NOT TECHNICAL ENOUGH". What even is this. What is "technical" here? How do you do anything actionable with that? If you're ever tempted to tell someone they're not technical enough, stop. 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 start noting any concepts you don't understand and spend time (during work hours!) on reading about them." ● Or: "Our senior engineers are all system designers. Please study distributed systems design and understand the CAP theorem and we'll give you a design project to work on and a mentor to help you." Otherwise, you're basically only saying "you don't seem like an engineer". It's not helpful.
  44. 44. How soon will your current skills expire? How soon will people assume they've expired? It really helps to have a solid tech resume before you take a "less technical" role. It lets you keep your options open. If you think there is any chance you might want to come back to engineering, the perception of your technical ability is even more important than the *reality* of your technical ability. For example, if your job title is any variant on "project manager", many people will immediately assume you are not good at technology. It is horrible and unfair, but project managers and TPMs often get underestimated by engineering types. Public service announcement here, to engineers, my people: please assume your TPMs could do your job if they had chosen your path. Do not ever be condescending to TPMs. --- Image: CC0
  45. 45. Should Engineer change roles? Back to our friend. She would like a promotion. Let's talk about that a second. I'm putting a lot of emphasis on promotion and 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 decide based on: ● what would she love to get better at? ● what doors is she comfortable closing, or at least 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.
  46. 46. 1. A cautionary tale of glue! 2. But was it fair? VOTE NOW! 3. To manage or not to manage? 4. What to do when you're glue. For the rest of this talk, I'm going to assume she decides to stay as an engineer, for two reasons: ● one is that this is the only path I can talk knowledgeably about. ● the other is that I, selfishly, want more senior non-dude engineers, so I hope she chooses this path. Either way, I will respect her decision :-) So, she's decided to be a senior engineer and, really, she's already doing most of that job. But here's the problem: she's never been a mid-level engineer. She's getting a whole lot of "not technical enough". What should she do? What do you do it you’re glue?
  47. 47. 1. Have that career conversation! First off, she needs to have a long-overdue conversation with her manager. The manager should have initiated this over a year ago, but she's going to need to drive it. She needs to ask direct questions like "Will I get promoted next round?"."What work do I need to do to get promoted?". No followup or softening of the question: ask and then stop talking. She and her manager need to agree on goals, make a checklist. She needs to get the expectations in writing, even if that means taking notes herself and mailing the manager afterwards to clarify that she got it right. She also needs to check in at intervals. Don't assume that no feedback is good feedback.
  48. 48. 2. Get a useful 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. Btw, anyone who tells you titles don't matter probably has the privilege of being someone who is assumed to be "technical". Dudes leaving college are assumed to be good at coding, like even if they studied law or something. For the rest of us, the title saves time that you don’t need to spend putting your credentials on the table. Titles matter a ton. --- Image: ton.jpg Public domain.
  49. 49. 3. Generate artifacts. Tell a story. Third, she needs artifacts of her work. If you're a people manager, a successful team is an artifact, if you're a project manager, a launched project is an artifact. If you're not, you may need concrete things. ● If you have an idea, write a one page design document. Be the person to present the idea at design review. ● If you made a thing happen in a meeting, send around the notes afterwards and make sure they reflect that YOU did it. Being the person who takes notes at meetings gets a bad rap, but it's good to have the narrative of the meeting show whatever you think is important to get recorded. ● CC groups on mailing lists, don't just mail individuals. Make sure your work is visible. Then, tell a story around those artifacts. Not a story where you're the team’s helper; you are the protagonist of this story. Due to your work and your technical judgement, this thing happened. You drove this. Action verbs. 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... --- Image: CC0.
  50. 50. 4. Not working? Oh well. Play the game by the rules. pru_mitchell CC BY 2.0 ...stop doing glue work and work to the rules for a while. They're really not going to promote you until you do the thing on the job ladder? Do EXACTLY the thing on the job ladder, even if it means letting more important things drop. If you have a lead title, maybe it's time to give that back so you have time for promotable work. Pick a date you're stopping on, and tell your manager. (Btw, it's not your job to find someone else to take over the work; you can stop without a successor!) Some ideas: stop interviewing, stop organising the off-sites. If you're the only person who helps your users, tell your manager that there's about to be nobody helping your users. Archive most of your mail. Cancel meetings. Quit slack channels. Don't catch things that are about to drop. It will feel weird, but remember that most of your team already does this. And… oof, I hate saying this, and please forgive me, but if you do diversity work, stop doing diversity work for a while. Getting promoted is diversity work. Think how much more useful you'll be to your mentees if you're the next level up. You can become a sponsor! And as a more senior person, you might also be able to change the career ladder to more value diversity work and the leadership work you were doing. Then, with your newfound free time, do some easily quantifiable technical work, even
  51. 51. if you're not the best person on the team to do it, even if you're rusty and you'll be slower than someone else. Write a bunch of code. Write some designs that anyone could have written. Learn to do some things you can't currently do. You will likely even enjoy it :-) ---- Image: CC BY 2.0
  52. 52. My three techniques for having more time: Fake meetings (PLEASE DON'T TELL). → Making time for focused work is hard. I have some techniques for doing it. 1) Block off calendar with fake meetings. You will never, ever squeeze coding time in between meetings. Trying harder won't work. Unless the code is really familiar, most of us need an hour or more of staring at it before it even starts to flow. I used to use "make time" and "focus time" and so on as meeting titles, but people scheduled over them. Fake plausible meetings work better. "wfw" here means "working from work".
  53. 53. My three techniques for having more time: Fake meetings (PLEASE DON'T TELL). Hiding. → 2) I also hide. Open plan is terrible for focused work, especially if people are used to you being a constant-meetings type of person; they expect that it's cool to walk up to your desk and start talking. Learn to work on your laptop. Work from home, from meeting rooms, from cafes. When I have something I need to read and think about, I put a one hour meeting in my calendar, print the document out and go hide. Finally, a thing that interrupts me most is my jerk brain, telling me that I should be doing something more urgent but less important, like replying to emails. ... --- Image: CC0.
  54. 54. My three techniques for having more time: Fake meetings (PLEASE DON'T TELL). Hiding. Apps like Forest. → 3) I use this app called forest. It's available on phone and as a chrome extension. You tell it to grow a tree and then if you use the phone or chrome to do something else, it kills your little tree. It's very motivational. (Seriously, it's really sad when it kills the tree. I can't kill the tree.) So all of this extra code and design reading will have a side effect, which is that you will get better at coding and reading designs. The technical term for this is *learning* :-D --- Image: Forest logo used with permission.
  55. 55. Learn deliberately. You will only get better at what you spend time on. It's incredibly important in our industry to keep learning. Even if your glue work is recognised as promotable work and you're going to keep focusing on it, I really recommend you find yourself blocks of time for learning every week. If you only do glue, you will only get better at glue. You're making your team more effective but if you're not increasing other skills, you're hurting your future self. If you want your tech knowledge to grow, you have to use it. This is not free! If you don't consciously prioritise it, you won't do it. Learn deliberately. Choose what you want to learn -- you'll know, because it's the thing that you always feel a bit nervous when other people talk about it -- and go learn it. No matter what you end up doing, even if you change roles, you are unlikely to regret feeling more confident in core technical skills. --- image by me. The cat's name is Alex.
  56. 56. Yes, I'm good at everything I put effort into. You should see me doing systems design. You should do this thing because you're so good at communication... h/t Polina Giralt! To close, here's a quote from my excellent colleague Polina about what to say when someone tries to push you into more humaning work than is good for you. 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." Other people on the team can also become good at communication if they put effort into it! 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. You can be good at lots of things. You can do anything.
  57. 57. Questions? Venting? Come find me in the hall. @whereistanya That's all I have. Thank you! (And thanks for a lovely conference, W/S/C folks!)