
Being Glue - luu
https://noidea.dog/glue
======
jawns
A couple of years ago, I approached several coworkers whom I highly respected
and asked them for frank advice about whether I should continue on a
technical, individual-contributor track or instead set my sights on a
managerial track.

I felt as if my tech skills weren't all that great, and that I would always be
playing catch-up (since programming was a career change for me). And from past
jobs, I knew I had some pretty good "glue work" and managerial skills.

But there were two bits of advice that stuck out to me and led me to continue
to remain on a technical track.

One was very practical. For someone with decent managerial skills and passable
technical skills, it is always going to be harder to transition from
managerial track to technical track than the other way around, so why not try
to go as far as I can technically before making that decision?

The other was very much in line with the advice given in this talk. I was
asked to ignore my current strengths and weaknesses and just answer this
question: In which track would you feel less jealous of those in the other
track? I realized that I would only be focusing on the managerial track
because I didn't think I could cut it in the technical track. If I knew I
could pull off the technical track, there really wouldn't be any question in
my mind. And so the advice I was given was to continue to pursue the track I
was most interested in, until one of these things happen: I go on doing it
long enough without getting fired that I realize I actually can do it; I
realize there's something else that interests me more; or I get fired and
nobody else will hire me for the role I want and then I explore other
possibilities.

~~~
hermitdev
Personally, I'd expect moving in either direction between management and
development would be difficult. I've +15 years as a developer, but 0 as a
manager. Id need a fair amount of training and some stumbling to be effective
as a manager (of developers). And I just started a new job as a dev with a
track to management to replace my manager when he retires.

Frankly, at times, it scares me. I've several years to prepare, though.

------
jrochkind1
> updating the roadmap, talking to the users, noticing the things that got
> dropped, asking questions on design documents, and making sure that
> everyone's going roughly in the same direction… have you thought about who
> is filling this role on your team?

I thought that's what various kinds of "managers" were _for_.

Granted, only once, for one year before she left, have I actually experienced
a manager doing that. I was like, geez, a manager actually doing their job
really amazingly improves our stress levels, job satisfaction, and the quality
of our product.

It does not seem to be what managers are actually trained, selected, or
rewarded/recognized for at many places, it is true.

~~~
ErrantX
I'd argue it's part of everyone's job on the team (including the manager).

Management is a specialist job. Just as software development is.

(For me managers are about two things; people leadership [inspiring the best
in people, leading their personal growth] and communication [between team and
others]).

What you describe sounds like a scrum master/project management role.

Ultimately if the team are not engaged in the direction then no amount of
manager-direction will help.

~~~
jrochkind1
Except a large part of the OP was about someone _informally_ taking on a
_specialist job_, even though it's not specially in their job description, and
then getting penalized for it career-wise.

It was a specialist job. It apparently wasn't one anyone else was _doing_. It
was a job that someone(s) _did_ have to do to make the work go right.

Shouldn't someone have that, indeed, specialist job, and do it? Whether you
call them a "project manager" (that's got "manager" in it), a "scrum master",
or some other kind of "manager" \-- why are these crucial _coordination_ tasks
being left to whatever developer happens to step up to do them, at cost to
their career?

I've always thought it was the manager's job to do things like, especially,
"updating the roadmap, talking to the [stakeholders], noticing the things that
got dropped, asking questions on design documents, and making sure that
everyone's going roughly in the same direction."

Many of those things can be categorized as either removing barriers to
implementers getting work done, or making sure the implementers are getting
the _right_ work done. Isn't that what (various kinds, including "project")
managers are for? Indeed it is a specialist job.

If they aren't doing that -- what _are_ they doing?

~~~
ErrantX
I just struggle to see how a team in which everyone is not on the ball over
e.g "noticing the things that might have been dropped" can ever be high
performing.

Its a managers job to train and build their teams skills in these areas, not
to be the grunt...

(agreed on the project managers; but it wasnt clear if thats what you meant in
your initial post)

~~~
jrochkind1
Is it "grunt work", or is it a "specialist job"?

I don't think it's grunt work. I think it's work that requires skill,
professional judgement, finesse, continual learning, consistent attention over
time, is crucially important, and can be very rewarding.

To bring it back to the OP, disrespecting it as "grunt work" is what gave the
hypothetical character portrayed in the OP a career dead-end as a reward for
performing vitally important skilled work well, and on their own initiative
since the organization hadn't provided for it.

------
jtanderson
This is one of the things academia actually gets right in a lot of
institutions (and very wrong in others, of course). But instead of "glue work"
the formal name for it is "service"; typically it _does_ carry weight when the
time comes for promotion and tenure. The proportion to which it matters of
course varies by institution (R1 vs teaching vs regional, etc.), but it's
usually documented or presented to candidate hires as x% of your time is
expected to be "service work" pre-tenure, the remaining portion is divided
between research and teaching. This way, going into it, we at least
acknowledge the tremendous necessity of being glue, and also set out to
explicitly reward people for doing it.

Of course then part of the problem of finding a good fit as a university
professor is one that allocates the balance between service, research, and
teaching that aligns with your own goals!

------
rgbrgb
I think the key insight is that you _can_ spend all your time as an engineer
doing softer less technical work, but if you’re doing that as a junior
engineer you should maybe just consider management. That type of work is not
going to level up your technical abilities and make you an impactful
_individual_ contributor but it will level up your management abilities.
Likewise, it's usually counter-productive to spend all your time coding if
you’re a new manager.

The most effective way I've seen for this to progress is for the more senior
engineers to spend less time coding and more time doing project level spec and
design work with the balance shifting over time. Usually a senior engineer is
going to be better at the spec work because they have more context and domain
knowledge. I would be critical of throwing everything in the category of
"glue" though, because delegating purely non-technical work to someone non-
technical is also an important skill for engineers.

------
ComputerGuru
_And they say "Look, you're great at communication. Your soft skills are
outstanding. We just don't think you're an engineer. Consider becoming a
project manager instead?"_

So what's wrong with promoting this person to a project manager?

~~~
TYPE_FASTER
Maybe the person doesn't want to be a PM. She filled gaps she saw and helped
raise the team up, instead of doing the work she wanted to do, which is quite
possible in a modern self-organizing agile team. Instead of rewarding this
effort, leadership saw the lack of technical productivity as an indicator she
can't do the work.

One of the best PMs I've ever worked with was a technical individual
contributor until he was told given the feedback that he is really really
really good at organizing and leading, and that's what he should do.

There are two different approaches here: 1. You can't do technical work, so
try this other role that you've been doing already because hey, it turns out
we need that role and 2. Hey, we've noticed you've been independently filling
a gap we know or didn't know we had. Nice work! Want to transition to that
role full-time?

~~~
ineedasername
They may not want to be a PM, but that is what they have become. It shouldn't
be a surprise that they don't get promoted into another role that requires an
even higher level of non-PM technical work.

If the "glue" in this scenario actually doesn't want to do the glue work, and
wants to get promoted into technical SE roles, the appropriate thing to do
would be to "manage upward" and make the organization aware of the need for
more PM/Product Lead types of resources, while at the same time ensuring their
own technical output is solid. I agree it is absolutely a crappy situation to
need that glue work to be done and have no one tasked with doing it, but
ignoring a portion of the work that is actually in your job description is
counter productive if you want to get to an even more senior role that
requires more of that work you haven't been doing.

In short, the fact that someone has to become the glue to begin with means the
organization has some structural issues. The path to take raising awareness of
that problem, not ignoring a portion of your responsibilities.

------
thanatropism
I wanted to give this link to a coworker. We're not coders at all but over
time she got stuck doing "glue" work that's somewhat like management (she
basically can tell us all what to do -- I trust her to say "we need to jump
out the window") but not really a management role. But there's too much coding
context for her to get it.

I wish I knew what X to tell her in "you need to reinvent your story to be X".

~~~
telotortium
Maybe email the author of this blog post and ask for her advice.

------
IndrekR
The same presentation on video from athenahealth TechTalk:
[https://youtu.be/5cr2Yn_MrKg](https://youtu.be/5cr2Yn_MrKg)

------
0x445442
The big problem with "glue work" is it's often as important as the "real work"
but it doesn't fit neatly on the Jira board.

The other problem with "glue work" is it's often viewed as, well, glue work
when in reality it's necessary work every bit as important as the "real work".

IMO the distinction has been amplified by the agile/scrum/devops train wreck
where engineering no longer exists and it's the next person up to pull that
next story to the "In Dev" column.

And then the real tragedy comes at review time... I see you didn't complete as
many stories as your peers on the team this past year. Yeah that's true, I was
busy doing glue work that made the app build easily, integrate with all the
external systems, deploy from dev to stage to prod seemlessly and trigger a
quarter the pager duty alerts than other apps in the org.

------
bobm_kite9
As a contract worker, I feel I have to be quite careful about this.

\- Ideally, I do work that can go on my public website, but working in
Investment Banking, that doesn't happen a huge amount.

\- Next, I look for work I can _at least_ put on my CV. Some new skill, or a
project that will make sense.

\- Third, I look for things that will keep my skills current. A lot of the
"glue" mentioned in the article fits in this box. I'm ok with it if I feel
it's also improving me.

\- Then, there comes the stuff you have to learn but don't want to, like the
vagaries of some internal process, like provisioning VMs or filling
timesheets. I try to avoid this where possible, because it's knowledge that I
won't find useful beyond my current contract. Sadly it's often essential..

It's certainly worth managing this, rather than just leaving to chance.

------
ineedasername
The article makes a fair point, but if the promotion being denied to the
"glue" is one that should be doing lots of coding, then it doesn't make sense
to promote the glue.

It doesn't matter that the glue was performing the most high-impact tasks at
the moment, they were tasks that generally fall into the project
manager/product lead category. If these activities are tending to fall onto
people in SE roles, that probably means the organization is too lite on
project manager roles, or they aren't properly aligned with and/or integrated
with the SE teams, and _that_ is the bigger issue that needs to be addressed.

Otherwise, If an organization is self-aware enough to recognize the "glue"
issue to begin with, then it should be self aware enough that an SE doesn't
have to become glue. The SE can raise the issue with management that they need
more PM activity to coordinate glue tasks.

~~~
majormajor
Handing off technical coordination and leadership to PMs is a recipe for
problems, IME. A TPM isn't going to spot that two different other engineers
have different mental models of the proposed specs. A TPM isn't going to spot
the edge cases that could turn into future bugs without carefully revisiting
the design. A TPM isn't going to put your rollout plan together so all the
services do all the things in the right order. I've seen organizations that
will tell you, when you reach a certain point as an individual contributor,
that "they aren't paying you just to code anymore," and that covers a fair
amount of "glue."

And that "you don't want a PM/TPM doing it" thing is covered in the linked
article to, but it fits what I've seen, male or female. The PMs and TPMs I've
worked with were not deep in the code of the projects they were working on, so
it would be impossible for them to be technically deep enough to do all that
glue work. You need someone putting engineer-level time into engineer-level
stuff. I'll let my TPMs and PMs run down a lot of other stuff for me, but not
the detailed engineering problems. That's my responsibility as an engineer,
not something I can offload just because it's "not coding." Which takes me
back to saying you should foster - and promote - well-rounded "not just coder"
engineers.

~~~
ineedasername
You're absolutely right, but the article cites many examples of tasks that are
properly within the PM domain. And for those that aren't, it should be the SE
team &/or management dictating that such responsibilities be shared rather
than devolve onto a single individual.

A single individual taking it on themselves is self-defeating. It keeps the
organization dysfunctional at the same time that the individual is ignoring a
significant chunk of assigned duties (coding)

------
wishrider
I've heard about a city that measures the number of mobile phones in an area
to estimate the demand for public transportation. But I don't remember which
one it was.

~~~
wishrider
Oh sorry, wrong thread, I thought I was in the thread "How well do London
buses match the timetables?"

------
jstewartmobile
Post hoc rationalization. The powers that be typically go out of their way to
shield you from this kind of stuff when you're "too valuable on the floor".

Last software shop I worked at, they promoted a guy to "project manager" for
being the ineffective programmer that no one had the heart to let go.

~~~
abeger
> _The powers that be typically go out of their way to shield you from this
> kind of stuff when you 're "too valuable on the floor"._

Many times, the "glue" person is picking up The Powers That Be's slack, e.g.
"Well, this needs to get done and Manager Bob isn't going to do it for reason
X, so I'll make sure it gets done".

