Hacker News new | past | comments | ask | show | jobs | submit login
Being Glue (noidea.dog)
177 points by luu 8 months ago | hide | past | web | favorite | 42 comments



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.


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.


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


That's management's job, yes, but it turns out that managers get overloaded in tasks and some just drop on the floor.

1/3rd of it is providing your boss the information he needs to get his job done. (Staffing plans, status reports, distillation of technical issues and tradeoffs, etc.) 1/3rd of it is working with the rest of your team to run the department. (cross-team coordination, escalation, department initiatives, surfacing issues and solving problems.) The last third focuses on the team. Now, depending on the time of year and the composition of each team (new boss, new managers, new team members), the composition of the work can vary, but they each take up some time.

Sometimes, things just devolve into status reports and firefighting. If your manager was able to do that work, it means that the entire department was functional.

I try to do all of that. Some of it, I have to delegate.


Sounds like a dysfunctional organization where managers routinely do not have the capacity to do their jobs. But yeah, in my experience dysfunctional organizations are definitely the norm.

(There's a reason why the great manager left...)


Right, but then what's the right manager:IC ratio? Think of it more as a tradeoff and a design decision. How many managers do you want in an organization? (Assume managers make 5% more than your senior engineers.) Too many and your organization gets top heavy.

Now, I think one right solution might be to have non-technical administrative assistants for the department. My organization has three, and we still have work for more.

Finally, there's always more work to be done for any organization.


Well, if there's nobody with the responsibility/authority and sufficient time to do the kind of work we're talking about (and who is evaluated and promoted based on doing it well), it sounds like the tradeoff was not the right one if the goal is producing a good product. Because that work needs to be done, to produce a quality product (whatever you are producing).

Over my career, I have increasingly tended to believe that at the majority of organizations the goals decision-makers are acting upon are not in fact about producing a good product, for whatever that product is. That is certainly one explanation. It's not that they are obtuse about what it takes to create a good product, they just have other priorities.


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

Product managers yes, people managers no


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.


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?


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)


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.


This is weird thought where your solution to the problem is just "have the people on the team be better."

The entire phenomena exists because people that see how important these things are end up on teams led by and staffed by people who either don't see how important they are, or aren't competent enough to do the glue work.


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!


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.


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?


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?


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.


Because there is a good chance that the project manager is on a much crappier compensation ladder. So it isn't really a promotion, more like a sideways move onto a higher-stress but lower paid train.


Nothing, unless they aren't interested in being and carrying out the duties of a project manager. "Soft skills" like developing team processes, improving internal documentation, and even helping other engineers on the team can make a different and valuable impact when they're coming from the engineer themself, rather than a PM or engineering manager.

Ideally, whatever criteria used for the different rungs of the engineering IC ladder should call these out as contributions that are taken into account.


Project management usually has a component of org/people politics that aren't (quite) as present in the IC role.

At the end of the day your goal should be having impact (usually) by shipping something and people who do this glue work are literally the reason something does/doesn't ship. Routing them to job roles that don't align with what they want is the quickest way to drive them away.


Except in this case, the person chose to do the role that they apparently didn't want to do?

I get the whole "team effort" thing, but at the end of the day, you have to be a little selfish about the work you take on. If you start mopping the floors, rather than building features, don't be surprised if you start getting evaluated as a janitor.*

* note, I'm not intending to make a point by comparing eng/PM/janitor jobs in any absolute value sense. Just that the author did a job that wasn't in her description, and is bothered by the fact that it mattered.

(for what little it matters, I generally do a ton of glue type roles... but am conscious about taking them on.)


I don't think that's true, especially since it was specifically called out that this glue work is what senior engineers do a lot of.

To me senior engineers deal with ambiguity and unclear ownership in a decisive way and that sounds exactly like what the author was doing. I can easily see how you would think delivering on metrics senior engineers on evaluated on(getting things out the door) would mean advancement as an engineer.


This is very true - at one point when I worked at Amazon, my manager told me that if I was already the next level, I'd easily be exceeding expectations. But the work I was doing wouldn't actually get me there.

It ran contrary to what I had been told - do the work of the next level, and you'll be promoted to that level. It was tough adjusting, and I ended up moving into management. I got lucky in that I enjoy it, but I do miss doing the hands on work from time-to-time.


One alternative is that no one does the "glue" tasks and the project fails. Then no one gets promoted.


What is the reason for wanting to be an engineer? It can't be just pay?

I view software as one of the few creative disciplines where you can actually be creative. Most people wanting to do far more creative things tend not to realise their dreams - working in the arts, getting published as a novel writer etc. These creative types don't imagine software to be creative, or imagine it to be a cutting edge medium.

I don't meet many programmers that see it that way, they would prefer to get promoted away from writing code. With more money.

It also matters to me for my work to be in the final product, not in a design document that nobody follows. Again, people aren't generally desperate for that.

So why the reason to have 'engineer' status? This being at Squarespace which is a bit like mySpace to some extent and not really 'engineering' in quite the same way as normal 'engineering' in manufacturing.


Nothing! Except that they specifically wanted to become a senior engineer and not a manager.


Skimming over it it seems that she's talking about people who don't want to be project managers but end up doing some of the work associated with project managers/scrum masters. Obviously you can argue "why not refuse to do that work?" but I don't know where that goes.


Nothing on its face, but the article contains an entire section on why this may not be a desirable outcome.


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


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


The same presentation on video from athenahealth TechTalk: https://youtu.be/5cr2Yn_MrKg


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.


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.


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.


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.


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)


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.


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


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.


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


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

This is exactly the https://en.wikipedia.org/wiki/Dilbert_principle




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: