Do Glue Work for projects that you are leading, projects that you are accountable for. As a senior+ engineer that is all your projects. So should you prioritize glue work for all of them?
From my experience, there is a delicate balance. There’s Glue work that you need to get right every time, else risk getting fired. E.g. Technical specifications for your project. There’s glue work that you need to put on the back burner every time until it becomes a visible problem that management will appreciate you take care of. E.g tech debt, addressing strands that are getting dropped. Then there is glue work that you do to make your own life easier. E.g. Onboarding docs, demos etc.
I will do “glue work” that’s important. But not urgent that I can squeeze in between my other obligations without blocking anyone.
I need to make sure I am “working at my level”. But I don’t need to constantly be worried about promotions.
Which gets us back to the most important rule of a software engineer's career: make sure that the person writing your reviews really likes you.
To be honest, before 2020 aa a software engineer, I spent my entire career working in unknown companies with no real leveling guidelines.
I fell into my only role in BigTech as an L5 (mid level) cloud application architect at AWS Professional Services in 2020 and now a Staff Software Architect (5th and highest IC) at a smaller consulting company.
The leveling guidelines for a “staff” where I am now are about the same as a “Senior” at AWS ProServe or a similar position at GCP
That being said, the leveling guidelines at AWS for my department were straightforward
- L4 junior - expected to be able to complete tasks/storues with little guidance
- L5 mid level - expected to be able to complete work streams and lead a work stream where the business requirements are well defined. But the technical requirements aren’t and you work with the customer to complete the requirements. You were expected to be a subject matter expert in one or more verticals.
- Senior - more ambiguous - neither the business or technical requirements are well defined and you have to work with the customer to discover the business problems/opportunities, define strategies and then plan an implementation and coordinate multiple work streams with the project manager, customer, etc. They could also be over multiple projects.
- staff - over multiple seniors, usually a team lead and they deal with strategies over a practice (https://aws.amazon.com/professional-services/)
I’ve had one offer as a staff engineer for a product company (as oppose to a consulting company) at the company that acquired the startup I worked at before going to AWS. I would have been over strategy for all of the acquired companies.
I ended up turning it down. I understood the requirements of operating at that level in cloud consulting. But not product development. The technical requirements didn’t bother me as much as the organizational requirements.
Historically, companies really don't know what they are doing, especially on issues like this. Glue work often encompasses tasks viewed as feminine and its de-emphasis hurts women's careers (and men who happen to focus in glue work too): https://medium.com/@granellacamila/a-few-months-ago-i-discov...
> In a study published by the American Economy Review, the researchers discovered that women volunteered more than men for tasks considered glue work, hence, less promotable tasks in general. However, the researchers have also found that men waited longer to volunteer for tasks when there were women on the team. Furthermore, women were more volunteered by managers or colleagues than men. These kinds of tasks have a direct impact on women’s career development through time.
It took two world wars for some companies to get over their biases and actually let women join the workforce. It's no surprise then that companies would continue to devalue glue work, even if it hurts their bottom line.
In defense of deprioritizing glue work, engineers can invent an infinite amount of the it, burning time and salary, if you let them.
In a large company, aren't workers incentived to please their immediate manager and whatever higher metrics/appearances they're exposed to.
Neither of these guiding incentives necessarily has much to do with the mission of company leadership.
Isn't the job whatever the incentives say it is?
Maybe the difference between incentives -- and what the author is saying is the job is -- are related to the corporate inefficiency that the author talked about? (For example, an org chart path of imperfectly aligned, imperfectly competent managers means whatever your manager values is "inefficiently" traceable to the mission of company leadership?)
Your manager alone can’t promote you in BigTech. Your promotion has to be approved by a committee based on a promo doc.
You can both make your manager happy by doing “glue work” that makes them look good and not have anything worthwhile to put on your promo doc that the committee will find suitable for a promotion.
https://blog.pragmaticengineer.com/software-engineering-prom...
Someone said it here, but all engineering work is glue work. Might as well value those thinking smarter about it.
Company had to lay most of us off and my current job is similar but a way bigger company so the productivity gains are less apparent. But I will continue to seek out the glue work jobs as long as I can find them.
Even before I understood those concepts, I made it a point not to just be a “ticket taker”.
For some reason lots of people seem to have this misconception that startups are somehow more meritocratic than big corporates. I found the opposite to be true.
Your job working at startup is to get into that group and be one of the boys.
Also becoming one of the boys is not about technical ability at all: it's marketing. What you need to do to get in the boysclub will depend on the group, but I have never seen a startup where it was about being good at what you do.
Conversely, there seems to be this misconception that corporates are boring, slow, full of useless processes. But my experience is that "slow" may be another word for "healthy", and "useless processes" may be a way to call "the cool kids can't make the rules". I find it more rewarding.
And if you have a ton of energy to work on projects that you find exciting, better do it in your free time and own it. Startups are a Ponzi scheme: unless you are one of the founders, you won't get compensated for all the extra work. So make sure you "own" (or at least benefit from) it: maybe it means that you have to do it at home and never talk about it at work, maybe it means that you can do it open source in your free time, and the best is if you can do it open source at work.
First step: be a man.
No but seriously in my experience this is a pre-requisite.
Disclaimer: You pay the cost in (a) social capital and (b) tech debt from the occasional shortsighted decision, so use this approach tactfully and judiciously.
But seriously, I think probably I need to be technical co-founder, or a trusted first/veryearly hire. Then, as we grow, I'd try to hire rare smart and aligned people, so we can empower them to make decisions without them quickly fudging up the highly effective company that the "old fogies club" started.
I don't really see a need to share that to non-boys; it seems to usually be boysclubs. Never seen that happen with non-boys, at least.
> I think probably I need to be technical co-founder, or a trusted first/veryearly hire.
No, that's not about that. I have been that multiple times, still ended up with a boysclub. You have to be a "cool kid". Like in schools, there is no one rule for that. Sometimes you'll have to be good at sport, sometimes look badass, ...
And then again, if you end up being the leader of the group... maybe you are the one doing to the others what you were trying to avoid. In my experience, those people always genuinely believe they are loved and admired, even if the first thing employees do when they have beers "privately" is complain about how much they hate those leaders.
I guess that's the problem in being in the dominant position: you are biased, because you are in the dominant position.
maybe not, but if there's anything I can do to spend my time on a functional projects that are getting real things done instead of punching the clock with people who dont care and already know that its failed, I will choose to do that. I dont care if that helps someone in some way that perhaps they dont deserve.
If you are a competent team lead and are a technical person who understands the substance, you understand relatively well what "glue" is needed and is valuable for your team and the company. Then when some engineer does that glue work, you reward them! You might have the glue items as part of the normal work item management, or then not, it depends.
When you have retrospectives, you can always review "our builds were failing 50% of the time in January but now in May, it's only 10%, big thanks to X for fixing A!". Or it can come up in personal reviews etc.
You don't forward everything to your boss or product manager to decide. They don't review your team's code either. But you of course have to communicate that you will have less capacity for a while to do features, since you're working on an internal thing. Then after that the team will have more capacity for features than before.
This is the kind of work the team lead is expected to do, to keep the machine working. They are not doing a good job if they only follow orders and the machine stops because somebody didn't specifically tell them to oil it. Or if the machine is destroyed because periodic maintenance was not performed.
It's of course bad if the team ends up spending most of their time building fancy internal things that don't produce value. It is tempting to end up building cool stuff. That is then the team lead's responsibility to steer away from. It's a balance.
https://www.levels.fyi/blog/swe-level-framework.html
You don’t get ahead by doing “glue work” or maintenance programming. That’s the main reason that Google has the attention span of a crack addled flea and at one point has 5 different messaging apps and cancels initiatives left and right.
You can’t put anything related to glue work on your promo doc.
Ask ourselves, calculate one's efficiency is already hard, how to calculate one's effectiveness on other's efficiency. Just like author said.
> If individual employees are willing to lift their local team to 80% or 90% efficiency by burning their time on glue work, companies will take that free value
They take it for granted without really calculating the benefit. That is part of the reason why a small, gifted, and high-efficiency startup can operate and take over these giant company.
It all depends on what you want to achieve
I’m a support build naturally, I lift others up to my level and make sure that everyone is able to do their job better. This is never rewarded, even at companies that claim to reward glue work. I don’t know what to do about it. Maybe I’m just specced to be a manager and don’t know it yet or something.
It’s very frustrating.
> Practical, naive engineers gravitate to this work because it’s obviously useful
Ha! No. Quite the opposite.
It doesn't sound glamorous for product, and they don't get the value of it most of the time.
And if they are deliberately against it - they are stupid indeed.
a.k.a non-sociopathic work
Such a massive oversimplification. If you spend more than 8 seconds thinking about this, it's obviously stupid.
>first, you’re inevitably going to burn out
Uhh, OK? So I should bump up against inefficiency rather than fix it, so I don't burn out? Ridiculous article. Wouldn't be surprised if this article started life as a LinkedIn post.
