SlideShare a Scribd company logo
1 of 58
Download to read offline
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".
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….?
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.
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.
You didn't have sufficient impact yet.
...I decreased
onboarding
time!
But I decreased onboarding time.
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.
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.
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.
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.
...
Yeah, but what was your technical contribution?
They're like yes, this is good work. But you didn't really have a technical contribution.
Yeah, but what was your technical contribution?
...wasn't
...wasn't that technical? It wasn't *code* but not all technical things are code...
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...
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...
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?"
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?
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
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.
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.
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?
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".
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: https://pixabay.com/en/door-front-door-flower-flowerpot-1613991/ CC0.
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. 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!)

More Related Content

What's hot

Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...
Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...
Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...Ana Medina
 
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13Lean Kanban Central Europe
 
DevOps feedback loops
DevOps feedback loopsDevOps feedback loops
DevOps feedback loopsPaul Peissner
 
Agile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesAgile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesCelerity
 
和艦長一起玩轉 GitLab & GitLab Workflow
和艦長一起玩轉 GitLab & GitLab Workflow和艦長一起玩轉 GitLab & GitLab Workflow
和艦長一起玩轉 GitLab & GitLab WorkflowChen Cheng-Wei
 
Designing user experience (ux) for digital products
Designing user experience (ux) for digital productsDesigning user experience (ux) for digital products
Designing user experience (ux) for digital productsVijay Morampudi
 
PopcornFlow: Continuous Evolution Through Ultra-Rapid Experimentation
PopcornFlow: Continuous Evolution Through Ultra-Rapid ExperimentationPopcornFlow: Continuous Evolution Through Ultra-Rapid Experimentation
PopcornFlow: Continuous Evolution Through Ultra-Rapid ExperimentationClaudio Perrone
 
Introduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile FrameworkIntroduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile Frameworksrondal
 
LKCE19 Klaus Leopold - Flight Levels in Action
LKCE19 Klaus Leopold - Flight Levels in ActionLKCE19 Klaus Leopold - Flight Levels in Action
LKCE19 Klaus Leopold - Flight Levels in ActionLean Kanban Central Europe
 
Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...Chris Richardson
 
User stories — how to cook a cat?
User stories — how to cook a cat?User stories — how to cook a cat?
User stories — how to cook a cat?Vladimir Tarasov
 
Agile effort estimation
Agile effort estimation Agile effort estimation
Agile effort estimation Elad Sofer
 
An Introduction to Chaos Engineering
An Introduction to Chaos EngineeringAn Introduction to Chaos Engineering
An Introduction to Chaos EngineeringGremlin
 
Vertical Story Slicing Takes the Cake!
Vertical Story Slicing Takes the Cake!Vertical Story Slicing Takes the Cake!
Vertical Story Slicing Takes the Cake!kporemski
 
Release wednesdays and the agile release train upload
Release wednesdays and the agile release train   uploadRelease wednesdays and the agile release train   upload
Release wednesdays and the agile release train uploadChris Smith
 

What's hot (20)

Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...
Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...
Chaos Engineering with Kubernetes - Berlin / Hamburg Chaos Engineering Meetup...
 
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13
FLIGHT LEVELS OF KANBAN (KLAUS LEOPOLD) - LKCE13
 
DevOps feedback loops
DevOps feedback loopsDevOps feedback loops
DevOps feedback loops
 
Agile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesAgile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use Cases
 
Scaling Agile
Scaling Agile Scaling Agile
Scaling Agile
 
PSPO Training by Manohar Prasad.ppt
PSPO Training by Manohar Prasad.pptPSPO Training by Manohar Prasad.ppt
PSPO Training by Manohar Prasad.ppt
 
和艦長一起玩轉 GitLab & GitLab Workflow
和艦長一起玩轉 GitLab & GitLab Workflow和艦長一起玩轉 GitLab & GitLab Workflow
和艦長一起玩轉 GitLab & GitLab Workflow
 
Designing user experience (ux) for digital products
Designing user experience (ux) for digital productsDesigning user experience (ux) for digital products
Designing user experience (ux) for digital products
 
PopcornFlow: Continuous Evolution Through Ultra-Rapid Experimentation
PopcornFlow: Continuous Evolution Through Ultra-Rapid ExperimentationPopcornFlow: Continuous Evolution Through Ultra-Rapid Experimentation
PopcornFlow: Continuous Evolution Through Ultra-Rapid Experimentation
 
Introduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile FrameworkIntroduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile Framework
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
User Story
User StoryUser Story
User Story
 
LKCE19 Klaus Leopold - Flight Levels in Action
LKCE19 Klaus Leopold - Flight Levels in ActionLKCE19 Klaus Leopold - Flight Levels in Action
LKCE19 Klaus Leopold - Flight Levels in Action
 
Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...
 
User stories — how to cook a cat?
User stories — how to cook a cat?User stories — how to cook a cat?
User stories — how to cook a cat?
 
Agile effort estimation
Agile effort estimation Agile effort estimation
Agile effort estimation
 
An Introduction to Chaos Engineering
An Introduction to Chaos EngineeringAn Introduction to Chaos Engineering
An Introduction to Chaos Engineering
 
User Stories
User StoriesUser Stories
User Stories
 
Vertical Story Slicing Takes the Cake!
Vertical Story Slicing Takes the Cake!Vertical Story Slicing Takes the Cake!
Vertical Story Slicing Takes the Cake!
 
Release wednesdays and the agile release train upload
Release wednesdays and the agile release train   uploadRelease wednesdays and the agile release train   upload
Release wednesdays and the agile release train upload
 

Similar to Being Glue (Newer slides at https://noidea.dog/glue)

Projects Colman2010 Part2
Projects Colman2010 Part2Projects Colman2010 Part2
Projects Colman2010 Part2Shai Wolkomir
 
Arc2625 report file wong zhenfaijames0317890
Arc2625 report file wong zhenfaijames0317890Arc2625 report file wong zhenfaijames0317890
Arc2625 report file wong zhenfaijames0317890iamjames5
 
DI InterviewIntroductionThe field of computer science is .docx
DI InterviewIntroductionThe field of computer science is .docxDI InterviewIntroductionThe field of computer science is .docx
DI InterviewIntroductionThe field of computer science is .docxcuddietheresa
 
Assignment3 1
Assignment3 1Assignment3 1
Assignment3 1s1190177
 
Ha5 project charter_100314 (1)
Ha5 project charter_100314 (1)Ha5 project charter_100314 (1)
Ha5 project charter_100314 (1)BenWhite101
 
The Personal History Statement is expected to focus on your pers.docx
The Personal History Statement is expected to focus on your pers.docxThe Personal History Statement is expected to focus on your pers.docx
The Personal History Statement is expected to focus on your pers.docxgabrielaj9
 
Resisting The Feature Creature
Resisting The Feature CreatureResisting The Feature Creature
Resisting The Feature CreatureChristian Heilmann
 
Computer engineer cover letter
Computer engineer cover letterComputer engineer cover letter
Computer engineer cover letterhowardlewis841
 
Project charter Task 1
Project charter Task 1Project charter Task 1
Project charter Task 1ElliotBlack
 
Case study—Establishing product documentation as practice in agile
Case study—Establishing product documentation as practice in agileCase study—Establishing product documentation as practice in agile
Case study—Establishing product documentation as practice in agileSudhir Subudhi
 
Building real things for real people 2009
Building real things for real people 2009Building real things for real people 2009
Building real things for real people 2009Justin Ferrell
 
The Other Side of Your Interview
The Other Side of Your InterviewThe Other Side of Your Interview
The Other Side of Your InterviewDaniel Doubrovkine
 
Ha5 project charter_lewis
Ha5 project charter_lewisHa5 project charter_lewis
Ha5 project charter_lewisLewisB2013
 

Similar to Being Glue (Newer slides at https://noidea.dog/glue) (20)

Projects Colman2010 Part2
Projects Colman2010 Part2Projects Colman2010 Part2
Projects Colman2010 Part2
 
Arc2625 report file wong zhenfaijames0317890
Arc2625 report file wong zhenfaijames0317890Arc2625 report file wong zhenfaijames0317890
Arc2625 report file wong zhenfaijames0317890
 
DI InterviewIntroductionThe field of computer science is .docx
DI InterviewIntroductionThe field of computer science is .docxDI InterviewIntroductionThe field of computer science is .docx
DI InterviewIntroductionThe field of computer science is .docx
 
Assignment3 1
Assignment3 1Assignment3 1
Assignment3 1
 
Ha5 project charter_100314 (1)
Ha5 project charter_100314 (1)Ha5 project charter_100314 (1)
Ha5 project charter_100314 (1)
 
Brucewang
BrucewangBrucewang
Brucewang
 
My Profile
My ProfileMy Profile
My Profile
 
The Personal History Statement is expected to focus on your pers.docx
The Personal History Statement is expected to focus on your pers.docxThe Personal History Statement is expected to focus on your pers.docx
The Personal History Statement is expected to focus on your pers.docx
 
Resisting The Feature Creature
Resisting The Feature CreatureResisting The Feature Creature
Resisting The Feature Creature
 
Computer engineer cover letter
Computer engineer cover letterComputer engineer cover letter
Computer engineer cover letter
 
Project charter Task 1
Project charter Task 1Project charter Task 1
Project charter Task 1
 
Case study—Establishing product documentation as practice in agile
Case study—Establishing product documentation as practice in agileCase study—Establishing product documentation as practice in agile
Case study—Establishing product documentation as practice in agile
 
How to hire software engineers - given at pymunich.com
How to hire software engineers - given at pymunich.comHow to hire software engineers - given at pymunich.com
How to hire software engineers - given at pymunich.com
 
Project Charter
Project CharterProject Charter
Project Charter
 
Building real things for real people 2009
Building real things for real people 2009Building real things for real people 2009
Building real things for real people 2009
 
The Other Side of Your Interview
The Other Side of Your InterviewThe Other Side of Your Interview
The Other Side of Your Interview
 
Ha5 project charter_lewis
Ha5 project charter_lewisHa5 project charter_lewis
Ha5 project charter_lewis
 
Prototypes
PrototypesPrototypes
Prototypes
 
Hassan mokhtar
Hassan mokhtarHassan mokhtar
Hassan mokhtar
 
Europython how to make it recruiting suck less?
Europython   how to make it recruiting suck less?Europython   how to make it recruiting suck less?
Europython how to make it recruiting suck less?
 

Recently uploaded

ANSI(ST)-III_Manufacturing-I_05052020.pdf
ANSI(ST)-III_Manufacturing-I_05052020.pdfANSI(ST)-III_Manufacturing-I_05052020.pdf
ANSI(ST)-III_Manufacturing-I_05052020.pdfBertinKamsipa1
 
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdf
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdfONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdf
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdfKamal Acharya
 
Lab Manual Arduino UNO Microcontrollar.docx
Lab Manual Arduino UNO Microcontrollar.docxLab Manual Arduino UNO Microcontrollar.docx
Lab Manual Arduino UNO Microcontrollar.docxRashidFaridChishti
 
Artificial Intelligence Bayesian Reasoning
Artificial Intelligence Bayesian ReasoningArtificial Intelligence Bayesian Reasoning
Artificial Intelligence Bayesian Reasoninghotman30312
 
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...Lovely Professional University
 
Supermarket billing system project report..pdf
Supermarket billing system project report..pdfSupermarket billing system project report..pdf
Supermarket billing system project report..pdfKamal Acharya
 
Teachers record management system project report..pdf
Teachers record management system project report..pdfTeachers record management system project report..pdf
Teachers record management system project report..pdfKamal Acharya
 
Intelligent Agents, A discovery on How A Rational Agent Acts
Intelligent Agents, A discovery on How A Rational Agent ActsIntelligent Agents, A discovery on How A Rational Agent Acts
Intelligent Agents, A discovery on How A Rational Agent ActsSheetal Jain
 
Research Methodolgy & Intellectual Property Rights Series 1
Research Methodolgy & Intellectual Property Rights Series 1Research Methodolgy & Intellectual Property Rights Series 1
Research Methodolgy & Intellectual Property Rights Series 1T.D. Shashikala
 
Arduino based vehicle speed tracker project
Arduino based vehicle speed tracker projectArduino based vehicle speed tracker project
Arduino based vehicle speed tracker projectRased Khan
 
Furniture showroom management system project.pdf
Furniture showroom management system project.pdfFurniture showroom management system project.pdf
Furniture showroom management system project.pdfKamal Acharya
 
Electrical shop management system project report.pdf
Electrical shop management system project report.pdfElectrical shop management system project report.pdf
Electrical shop management system project report.pdfKamal Acharya
 
Research Methodolgy & Intellectual Property Rights Series 2
Research Methodolgy & Intellectual Property Rights Series 2Research Methodolgy & Intellectual Property Rights Series 2
Research Methodolgy & Intellectual Property Rights Series 2T.D. Shashikala
 
Lect_Z_Transform_Main_digital_image_processing.pptx
Lect_Z_Transform_Main_digital_image_processing.pptxLect_Z_Transform_Main_digital_image_processing.pptx
Lect_Z_Transform_Main_digital_image_processing.pptxMonirHossain707319
 
2024 DevOps Pro Europe - Growing at the edge
2024 DevOps Pro Europe - Growing at the edge2024 DevOps Pro Europe - Growing at the edge
2024 DevOps Pro Europe - Growing at the edgePaco Orozco
 
Multivibrator and its types defination and usges.pptx
Multivibrator and its types defination and usges.pptxMultivibrator and its types defination and usges.pptx
Multivibrator and its types defination and usges.pptxalijaker017
 
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisSeismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisDr.Costas Sachpazis
 
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWING
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWINGBRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWING
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWINGKOUSTAV SARKAR
 
Quiz application system project report..pdf
Quiz application system project report..pdfQuiz application system project report..pdf
Quiz application system project report..pdfKamal Acharya
 
E-Commerce Shopping using MERN Stack where different modules are present
E-Commerce Shopping using MERN Stack where different modules are presentE-Commerce Shopping using MERN Stack where different modules are present
E-Commerce Shopping using MERN Stack where different modules are presentjatinraor66
 

Recently uploaded (20)

ANSI(ST)-III_Manufacturing-I_05052020.pdf
ANSI(ST)-III_Manufacturing-I_05052020.pdfANSI(ST)-III_Manufacturing-I_05052020.pdf
ANSI(ST)-III_Manufacturing-I_05052020.pdf
 
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdf
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdfONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdf
ONLINE VEHICLE RENTAL SYSTEM PROJECT REPORT.pdf
 
Lab Manual Arduino UNO Microcontrollar.docx
Lab Manual Arduino UNO Microcontrollar.docxLab Manual Arduino UNO Microcontrollar.docx
Lab Manual Arduino UNO Microcontrollar.docx
 
Artificial Intelligence Bayesian Reasoning
Artificial Intelligence Bayesian ReasoningArtificial Intelligence Bayesian Reasoning
Artificial Intelligence Bayesian Reasoning
 
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...
Activity Planning: Objectives, Project Schedule, Network Planning Model. Time...
 
Supermarket billing system project report..pdf
Supermarket billing system project report..pdfSupermarket billing system project report..pdf
Supermarket billing system project report..pdf
 
Teachers record management system project report..pdf
Teachers record management system project report..pdfTeachers record management system project report..pdf
Teachers record management system project report..pdf
 
Intelligent Agents, A discovery on How A Rational Agent Acts
Intelligent Agents, A discovery on How A Rational Agent ActsIntelligent Agents, A discovery on How A Rational Agent Acts
Intelligent Agents, A discovery on How A Rational Agent Acts
 
Research Methodolgy & Intellectual Property Rights Series 1
Research Methodolgy & Intellectual Property Rights Series 1Research Methodolgy & Intellectual Property Rights Series 1
Research Methodolgy & Intellectual Property Rights Series 1
 
Arduino based vehicle speed tracker project
Arduino based vehicle speed tracker projectArduino based vehicle speed tracker project
Arduino based vehicle speed tracker project
 
Furniture showroom management system project.pdf
Furniture showroom management system project.pdfFurniture showroom management system project.pdf
Furniture showroom management system project.pdf
 
Electrical shop management system project report.pdf
Electrical shop management system project report.pdfElectrical shop management system project report.pdf
Electrical shop management system project report.pdf
 
Research Methodolgy & Intellectual Property Rights Series 2
Research Methodolgy & Intellectual Property Rights Series 2Research Methodolgy & Intellectual Property Rights Series 2
Research Methodolgy & Intellectual Property Rights Series 2
 
Lect_Z_Transform_Main_digital_image_processing.pptx
Lect_Z_Transform_Main_digital_image_processing.pptxLect_Z_Transform_Main_digital_image_processing.pptx
Lect_Z_Transform_Main_digital_image_processing.pptx
 
2024 DevOps Pro Europe - Growing at the edge
2024 DevOps Pro Europe - Growing at the edge2024 DevOps Pro Europe - Growing at the edge
2024 DevOps Pro Europe - Growing at the edge
 
Multivibrator and its types defination and usges.pptx
Multivibrator and its types defination and usges.pptxMultivibrator and its types defination and usges.pptx
Multivibrator and its types defination and usges.pptx
 
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisSeismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
 
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWING
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWINGBRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWING
BRAKING SYSTEM IN INDIAN RAILWAY AutoCAD DRAWING
 
Quiz application system project report..pdf
Quiz application system project report..pdfQuiz application system project report..pdf
Quiz application system project report..pdf
 
E-Commerce Shopping using MERN Stack where different modules are present
E-Commerce Shopping using MERN Stack where different modules are presentE-Commerce Shopping using MERN Stack where different modules are present
E-Commerce Shopping using MERN Stack where different modules are present
 

Being Glue (Newer slides at https://noidea.dog/glue)

  • 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: https://pixabay.com/en/glue-tube-isolated-sticky-adhesive-304256/ CC0
  • 2. 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.
  • 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. 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. 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. 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. 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
  • 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: https://www.maxpixel.net/Handshake-Team-Building-Shaking-Hands-Silhouette-3303 823 CC0.
  • 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. 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. 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.
  • 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: https://pixabay.com/en/silhouette-wheel-cyclist-bike-3357493/ CC0 https://pixabay.com/en/girl-woman-dancing-disco-160931/ CC0
  • 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: https://pixabay.com/en/silhouette-teamwork-business-3120378/ CC0
  • 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. 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. 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
  • 17. 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
  • 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: https://pixabay.com/en/silhouette-jumping-running-men-3145318/ CC0
  • 19. And that's it. Wait, what? ...that's it. Wait, what?
  • 20. And that's it. Why not me? Why not me?
  • 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. You didn't have sufficient impact yet. ...I decreased onboarding time! But I decreased onboarding time.
  • 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. 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. 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. 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. ... 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. 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. 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. 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. 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. 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. 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. 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
  • 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: https://www.pexels.com/photo/time-watch-clock-hours-9352/ CC0
  • 36. 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
  • 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: https://pixabay.com/en/balance-scale-justice-law-judge-154516/ CC0
  • 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. 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.
  • 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: https://unsplash.com/photos/VTt_Jn1LrOg CC0
  • 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: https://pixabay.com/en/bottle-swag-lights-dreams-548903/ CC0.
  • 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: https://unsplash.com/photos/pKeF6Tt3c08 CC0
  • 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. 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
  • 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. 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. 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. 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.
  • 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: https://www.pexels.com/photo/board-chalk-chalkboard-close-up-415068/ CC0.
  • 50.
  • 51. 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
  • 52. 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
  • 53. 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".
  • 54. 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: https://pixabay.com/en/door-front-door-flower-flowerpot-1613991/ CC0.
  • 55. 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. https://www.forestapp.cc/en/
  • 56. 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.
  • 57. 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.
  • 58. 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!)