@robstewart15
Ive just spent time over the last few weeks trying to explain why my productivity in terms of technical contributions has dropped but couldnt define an umbrella term that captures it all: 'Glue work'. Brilliant!
@jayellensuh1192
God... seriously cannot agree more on this. I do not work in software industry nor a developer, but this happened to me all the time. Because I am a woman and probably perceived as "nice and soft", a lot of secretarial work would fall on me and expected. If I rejected to do that type of work to spend more time on my actual job, I was seen as "not proactive" and "not helpful". My time is filled with tasks that don't help me grow as a professional but great at dealing with logistics and making things flow smoothly.
@FlashBlazbo
This sums up the reasons why I remained a technical contractor. I received much more respect from people at my level AND managers above my level. They viewed me as some form of competition against their technical skills, and against their organizational skills, and against their management skills. As a contractor, I was considered temporary, even though I had been there multiple years. Since I was temporary, there were not competing against me.
@stanislavkindiakov6334
Thank you for a great talk. Being a glue myself makes me really appreciate your approach.
@erickmagnus
Awesome talk. If your career ladder doesn't consider glue work as an input, then you should probably change that. Glue work is awesome - everyone should do at least a little bit of it.
@EmanueleDiSaverio
This talk is golden. Suggest listening carefully top to bottom.
@brig2913
Such a great talk, thank you!
@StoicalZebra751
Great career talk. Very helpful defining something I've seen many times before but never put into words. Nice work!
@pdsCV
Glue work has been my calling card since I returned to tech.
@baz_sh
Fantastic talk! Some great advice here.
@jorgetovar621
Nice talk
@najjaman
Great talk, thanks!
@ralalbatross
I want to provide a counter argument from a very highly technical perspective: Unnecessary Glue Work damages your career because you might not be very good at it and not know it, and because Technical Leads that could never code their own projects lead to dead projects. My advice is the following: If you're a junior dev, no matter what you're interested in, your job is to get as good at coding as fast as possible in as many domains as possible as quickly as you can. This will help you far more than developing so called 'soft skills' because soft skills are completely oversaturated in the vast majority of software engineering projects. The soft skills can come after you can talk to me with some confidence on what the code base actually is - I don't need you to be sorting organisational problems, trust me, I already know they are there and in some cases they are intentional to avoid political conflicts within the company. Speaking for myself, I have a hostile senior 'technical lead' whose coding skills are 15 years atrophied and who talks with such profound confidence about subjects they don't know about and with such aggressive arrogance that I've had to orchestrate political barriers between my work and theirs. I wouldn't welcome a Glue Person coming in and figuring out our work has overlap and trying to 'solve those issues' because they aren't solvable. The issue is the fact that I know what I'm doing, and they don't, and they have a pattern of abusive behaviour across the company targeted primarily at women and individuals who outperform them technically. The political gap is deliberate to protect my devs. The Glue Person who is my direct senior is the one politically ensuring that gap is maintained, so a junior Glue Person coming in with good intentions would be swiftly told to back off. There's a good reason why good developers are very wary of people using soft skills to poke holes in things they've done - it's because coding is arduous, intellectually demanding, craft heavy work in a lot of cases, requiring a lot of detail. So imagine - someone comes in, says "oh you haven't done this thing yet and it would save us so much time" and then they go and do it manually and all of a sudden, your client wants it done every week. I've seen this happen, and I actively tell my devs NOT to do it. Not because it isn't a good idea (it invariably is), but because clients never understand the time or effort complexity of the work they request, and while we as a software engineering team pretend to be client focused, we are not. We are requirements focused - clients have to have the requirements beaten out of them on a regular basis, and pretending that they even have a fraction of the understanding of the complexity of what a task involves is how you get burnout. Even if you give the client a process to follow, you are now responsible for supporting that process. So, what did our Glue do wrong? Well, soft skills are still really useful and people who are good at them are really useful, but the problem was that it wasn't her job to do those things. Were there systemic problems she helped solve? Yes, but only at an intense cost to her own time. As she did in the example given with the process she did manually, she did something you should never, ever do: ----- She turned herself into a bus factor no one asked for and no one budgeted for ----- Worse, it won't have gone unnoticed that someone who doesn't push PRs and can't made head or tails of the code base is suddenly going around trying to portray themselves as the next technical lead. The question was even asked - I'm really important, why wasn't I promoted? I'm doing all this work and no one is rewarding me for it? The problem is that she was procrastinating from the job she were hired to do - writing code, because it was a grotty old code base and it's hard. The onboarding process she never actually completed herself because she had a bad experience. She made it easier for others, but conveniently never onboarded herself because she didn't consider it her job by that point. Force multiplication perhaps, but if her onboarding process was done from the perspective of someone who completely failed to understand the code base, there's a good chance her issues spread through the company as well. Yes, she got teams together and helped them bash out a compromise, but likely added a ton of additional technical work to both teams in order to perform an integration that had, until that point, not been noticed. She also lacked the perspective to know if she'd actually made a meaningful difference, and if she did, was likely lucky in doing so. In the rare times she wasn't in a meeting or passing information around seemingly manually, she had a few hours of coding time but never feels like she wants to actually do the work she's paid to do. Coding, particularly working with grotty code bases drowning in technical debt, is hard and demanding work, and almost all code bases are grotty. What our Glue isn't admitting to herself is she's ducking the work by creating other work for herself and quite often other people as well. Like it or not, the work she's doing is easier than the work she isn't. Promoting someone who can't do their basic job is asking for trouble - if she understood the code base, she could build things, and she would not have any difficulty pushing her Glue Work as support for her promotion. To that end I agree with the main statement. If you are a Glue person and you aren't a Code Person, you need to start looking at having your Glue Work codified into your job role. An easy way to do that is to work as a tester - they can move very easily to and from a Glue Work role, but you have to Do The Work. You can't just go around enforcing codes of practice on people or pushing for unit testing. You have to do it yourself as well! It's easy to say "we should have 90% test coverage" when you have 90% of your work schedule dedicated to meetings about 90% test coverage! It's vastly better to do so after automating and pushing a successfully passing 90% test coverage on a project you're working on, as an example of best practice. Further, you missed the other bit of Glue Work - the curious engineers. who really know their shit and then are driven to fix it. Those people are really rare, but they are also Glue, and they have no more support in engineering than the average soft skills Glue Worker.
@stephaniejose4475
Great talk!
@saimanoharnethi9405
imo, I consider someone a senior engineer when they can step in and execute any task the team needs, whether it is having design conversations or coding. Spending more time not on coding is okay as long as your only reason is that you don't have time for coding and you are valuable as a driver of initiatives than mere coding, but not knowing how to code or what the code bases contain at all is not qualified enough still. Flexibility to work in any role engineering demands is what I see as senior.
@finne-dich-selbst-3395
Thank you. I have had many privileges, which have given me possibility to do glue work under the radar or even officially, but on a very competitive and technical environments it has been also a disadvantage that I have prioritized success of my team over my own success.
@davewasthere
Glue work is harder to quantify perhaps? But I think some companies are really good at recognising and promoting the glue-workers.
@bondys-video-kucing
Glue work is done silently and will be acknowledged when things were messy unglued before and management curiously looking for the difference factor
@saskiahonhoff2954
Interesting way to see these things
@libertyintech