Being Glue
noidea.dog
noidea.dog
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.
Frankly, at times, it scares me. I've several years to prepare, though.
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.
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.
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.
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?
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)
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.
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.
(There's a reason why the great manager left...)
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.
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.
Product managers yes, people managers no
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!
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.
So what's wrong with promoting this person to a project manager?
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?
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.
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.
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.)
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.
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.
Ideally, whatever criteria used for the different rungs of the engineering IC ladder should call these out as contributions that are taken into account.
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.
I wish I knew what X to tell her in "you need to reinvent your story to be X".
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.
- 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.
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.
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.
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)
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
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".