Feeling Unsure of Technical Skills Despite Valuable Contributions

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: https://pixabay.com/en/glue-tube-isolated-sticky-adhesive-304256/ CC0

Hello! My name is Tanya. I'm a software engineer at
http://careers.squarespace.com
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.

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

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….?

Glue work is expected in a senior role.
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.

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

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: https://pixabay.com/en/girl-woman-dancing-disco-160932/ CC0

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:
https://www.maxpixel.net/Handshake-Team-Building-Shaking-Hands-Silhouette-3303
823 CC0.

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.

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?

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: https://pixabay.com/en/meeting-management-manager-employee-2771620/
CC0.

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: https://pixabay.com/en/silhouette-wheel-cyclist-bike-3357493/ CC0
https://pixabay.com/en/girl-woman-dancing-disco-160931/ CC0

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: https://pixabay.com/en/silhouette-teamwork-business-3120378/ CC0

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

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

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: https://pixabay.com/en/teamwork-businessman-businesswoman-3499960/
CC0

The person who wrote all that lovely code!
Well, obviously the person who wrote all that code! Well done Ace Coder!
---
Image: https://pixabay.com/en/happiness-freedom-success-3506137/ CC0

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: https://pixabay.com/en/silhouette-jumping-running-men-3145318/ CC0

And that's it.
Wait, what?
...that's it.
Wait, what?

And that's it.
Why not me?
Why not me?

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.

...I decreased
onboarding
time!
But I decreased onboarding time.

I made us
build the
right thing!
...I decreased
onboarding
time!
I made us build the right thing.

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.

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.

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 review all the
designs.
I review all of our design documents and the questions I ask make us build better
things.

...
Yeah, but what was your technical contribution?
They're like yes, this is good work. But you didn't really have a technical contribution.

...wasn't
...wasn't that technical? It wasn't *code* but not all technical things are code...

...wasn't
...that

...wasn't
...that
...technical?

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

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?

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.

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: https://unsplash.com/photos/e6f8IaRQY7M CC0

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: https://www.pexels.com/photo/time-watch-clock-hours-9352/ CC0

Women volunteer more.
Women are volunteered
more.
Source: https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions
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:
https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions
Image: https://pixabay.com/en/action-brainstorming-business-3435773/ CC0

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: https://pixabay.com/en/balance-scale-justice-law-judge-154516/ CC0

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.

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: https://www.pexels.com/photo/roller-coaster-ride-1172687/ CC0.

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: https://unsplash.com/photos/VTt_Jn1LrOg CC0

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: https://pixabay.com/en/bottle-swag-lights-dreams-548903/ CC0.

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: https://unsplash.com/photos/pKeF6Tt3c08 CC0

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.

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: https://unsplash.com/photos/KYxXMTpTzek CC0

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.

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?

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.

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:
https://en.wikipedia.org/wiki/Accolade#/media/File:Accolade_by_Edmund_Blair_Leigh
ton.jpg Public domain.

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: https://www.pexels.com/photo/board-chalk-chalkboard-close-up-415068/ CC0.

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

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: https://flic.kr/p/TcvWgd CC BY 2.0

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

having more time:
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: https://pixabay.com/en/door-front-door-flower-flowerpot-1613991/ CC0.

having more time:
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. https://www.forestapp.cc/en/

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.

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.

Questions?
Venting? Come
find me in the hall.
@whereistanya
glue@noidea.dog
That's all I have. Thank you! (And thanks for a lovely conference, W/S/C folks!)

Feeling Unsure of Technical Skills Despite Valuable Contributions

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Feeling Unsure of Technical Skills Despite Valuable Contributions

Similaire à Feeling Unsure of Technical Skills Despite Valuable Contributions (20)

Dernier

Dernier (20)

Feeling Unsure of Technical Skills Despite Valuable Contributions