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.

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.

2) Then we're going to talk about fairness, both in the outcome of the story and in how work is distributed

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 :-)

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.

5) And finally, I want to talk about learning and growing, which is something I don't think our industry talks about enough.

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.

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.

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?

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.

Well done Awesome Coder, says everyone.

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.

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.

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.

(Article: 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.

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.

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.

Project managers and TPMs are routinely underestimated by engineers.

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.

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.

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.

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."

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.