Handling invisible work

Your boss should know because you should tell them. Listing you contributions is expected.

Got to sell yourself. Give demos on the safety nets, tell your boss about how your mentoring is going, highlight operational excellence improvements.

At my company I see the engineers that are missing dates, struggling, needing more resources, pulling from other teams, constantly giving status updates. They get company-wide Thank Yous for their effort and ultimate success at the end. While my team is invisible and drama free. We get nothing. I still prefer the latter.

I log it on a ticket, mine or theirs, and I add a comment summarizing the effort. As a Senior, mentoring is literally in my job description, along with all the other invisible efforts. I write up tickets, I log hours.

Document it to make it visible.

using the latest library or framework : modernization, security awareness.

enforce strict typing : quality improvement.

unfortunately sometimes they need metrics and that is where the actual problem is.

I don't have an answer for you, but just want to say that I can completely relate. I spend a lot of my time dong this invisible work. It's visible to other members of my team, and it's appreciated. But my manager, who works remote, doesn't seem to understand or relate to what I do. I do try to explain it, but management doesn't seem to 'get' it. The work is a lot of CI, software packaging, and distribution work. The CI work helps my teammates by ensuring a lot of issues get caught by CI on feature branches before they get merged. The packaging and distribution work helps to improve the customer experience of installing, setting up, and updating the software. I've started rigorously logging my time (not a job requirement) so that I can provide an answer to 'what have you been doing anyway?' if I get that question. Sadly, my latest performance review reflected the fact that management doesn't seem to get what I do day to day at work.

It is invisible work. No one is going to argue with you that it is isn't important.

But if you actually want visible work, you will want to be on those projects that actually directly impact the company's bottom line and your peers are mentioning your name to the people who are making those company wide announcements.

What I do is track all my work on my own kanban board (I use Trello, our scrum teams use Jira). Our scrum teams do quarterly planning and I pay attention to where I'm needed most in assisting which teams during this planning, which provides me objectives and key results that eventually will not be "invisible."

Year end with my manager for me is summarizing my completed items on my personal board, which is really just an audit trail of all visible and invisible work -- and the personal kanban board has the added benefit of keeping myself on track to all the little requests coming in from teams or developers, and the regular maintenance and tasks I already was going to do.

I've been in that boat also. I think at the end of the day, your organization/company is either one that looks for, acknowledges, and validates this kind of work, or it's not. And when it's not, that's a problem that's bigger than just you.

I think part of it has to do with the myth (imo) that all valuable work is quantifiable and should be quantified. And so if performance reviews focus on quantified accomplishments, it will always devalue it completely miss these kinds of efforts. These are the same kind of organizations and companies that often struggle to reward "keeping the lights on" kinds of engineering, especially when it's something that doesn't technically belong to any particular team.

And it's also kind of a catch-22. I think of it as, "if you fix a pothole well enough, how do you convince someone who doesn't believe in potholes that there used to be a pothole? If the company is looking for people to build from the ground up, how do you get them to see how much value there was in investing in the foundation?" But also, "if you're not even getting rewarded for fixing potholes, why would you build a project to count and measure potholes just so the reduction in potholes can be quantified for performance review? Sometimes that counter would be harder than the fix…"

At the end of the day, I've been there, and I don't have an answer for you. But I suspect that this is a problem that's bigger than just you. Good luck

Make your work visible by tracking them as stories, tasks. Except code reviews, The work that you mentioned can fall either under tech debt or tech solutioning. You can track most of them. There is also a notion of percent contribution towards stories or tasks. As you higher in hierarchy, this percentage decreases because you tend to focus more on mentoring people and creating/following processes rather than complete story points.

Happens to me too, all the time.

I spending most of my sprints doing the work that reduces the overhead for everybody else, but isn’t captured in a PR/ticket necessarily.

Often the work spurs up from frustrations working on a ticket, and saves everybody that comes after me from those same frustrations later.

Recently I worked on a branch that forked from another developers PR. I wanted to show them the changes (lots of them) they could make to take advantage of the features of the framework we are using (because they totally missed it) without seeming like a jerk with 20 comments on a PR. So a whole day was spent rewriting their work in a side branch just to link it in the PR. That’s not a ticket of mine, it basically did the work of their ticket, but the goal is to mentor and build up skills but it’s non-quantifiable.

Nature of the game, and your leadership and team will assign worth to it if it’s meritorious regardless of whether or not you have some metric to associate with it.

I also handle a lot of the invisible work you mention which is definitely taken for granted. I'm the strongest developer on a small team and our project's "engineering lead" is unqualified in many ways and he doesn't get into the weeds at all. A lot of the work falls to me, but non-technical folks on the project and folks outside the project attribute the project's success to the engineering lead.

I guess I'm wondering what to do when all of this invisible work is taken for granted, not attributed to you [...]

• I attempt to make my work visible. In standup I'll mention when I help somebody.
• In planning, I ask "how much support do we expect X to need from the team?" where X is a developer that needs my time to complete his ticket. I really hate when I'm given invisible work in order to unblock or assist someone else.
• I create zero-point stories/tasks that highlight invisible work I'm doing that is important but not on anyone else's radar.
• Bring up this invisible work in 1:1s

With that said, as part of my annual performance review I've mentioned all of the invisible work I've done but the best I get is occasionally exceeds expectations.

Are you sure your manager doesn't know? Make them aware. If they are a good manager they recognize the value of this work and won't discount it at all. If anything, enabling others to work more efficiently is one of the key distinguishing characteristics of staff developers. They don't just do work or coach, they shape the development culture by making it easier to do the right thing systemically.

My rule of thumb with my team is if it's going to take more than a day, make a ticket for it. That makes it no longer invisible.

Either way keeping your manager roughly informed (just high level) can help them make sure you're given enough time to do these tasks and are prioritizing correctly. I definitely expect staff level to be able to keep their eye on the bigger picture and not stray too far on their side quest. Many can find that balance, but others can't. If anything, I find staff will undervalue the invisible work (as you might be) and discount it as 'real' work... and will often work more time to make sure they're doing enough 'real' (visible) work. A good manager can help you amplify what you're doing by connecting you with others who might benefit from what you've working on, stop duplicated efforts (if they hear someone else trying to solve the same problem), etc

You and your team will have to make it visible.

Write tickets for new work. Enforce it in CI. Advocate for it.

"Nobody Ever Gets Credit for Fixing Problems That Never Happened"

Usually by getting credit for projects that you were associated with but didn't do much hands on work with.

I status my boss on these things. Either in 1 on 1s or you can put tasks on the task board for it. Items like “Creating document for Coding Standards”.

We have a swimlane in our sprint that captures this type of thing as tasks. As the tech lead there're a lot of unplanned tasks that get executed as part of sprint, not all of them can be captured but things like improving tests etc can.

You could even capture PR as a subtask of a story if you like, though we typically don't.

You just need to find a meta that works for yourself and the team.

On my 1:1 with my manager I call it "glue work". I'm trying to collect as much evidence as possible. At least in my company "being glue" is expected from staff and appreciated.

Keep a sheet on your laptop or Google docs where you jot down all this invisible work so you don't forget about it when you do your scheduled reviews.

You should have it in the sprint as its own line of effort or which ever version of terminology you want to use, we maintain an epic for it that never closes and generate tickets and tracking against it so it’s visible, same as self learning on a subject, I’ve had to verbally beat down product managers and Project managers on this subject a hand full of of time over the years, we specially when some body comes up with a great idea for new technology shinney x.. I lets see what that pod actually just cost.

As others have said this is starting to be called glue work. It’s really important stuff and it does have an impact. Do document this glue work. Where you can track the impact of it (numbers if possible are great e.g reduced build times, increase coverage of key area by x)

Tanya Reilly I think coined the term has a great blog post about it here: https://noidea.dog/glue

At my company someone started a glue channel to talk about how we track and recognise it and then later did a presentation at our regular eng org all hand’s.

I keep 2 documents. One lists all the things I have done this year including all the invisible stuff - coaching, leading tech, quality, etc. The other is a mostly static list of my responsibilities with sub lists for each that I can pull out on shared screen any moment and overwhelm anybody who even attempts to go there.

People management, mentoring/coaching, quality culture, business analyst - ticket writing, technical leadership, hands on coding, troubleshooting, general management - planning, estimation, roadmaps, project management, agile culture, cross team coordination, blah, blah 2 pages long.

In our department we track feature work, but also non feature work. We track sprint by sprint what the ratio is. As new stuff comes up during a sprint we add it to track it. 

Responsibility for prioritizing work is split between the team lead and the product owner. They work together to make sure product and technical needs are both being met. 

The sprint report for stakeholders often (but not always) has write ups for technical items. They'll also be reporting that up to me and I'll be reporting a condensed version from all the teams up to my boss. 

As you noted, this kind of work is important,  which means it should be tracked.  We're pretty happy with the method we've settled on, but obviously there's lots of ways to do it.

What I have found that works best is to better estimate your capacity during sprint planning. Devs are generally expected to complete around 6 hours of work per day and leads / seniors are expected to complete about 4. It's expected that leads / seniors will be pulled into more meetings and have other distractions. If you are concerned with getting "credit" then mention these things in your stand-ups and retros.

Sounds like some of this involves writing code. That work should at least be ticked and tracked along with regular feature work.

No work is invisible if you measure the outcomes and talk about the improvements with the team and your manager. That being said, the outcomes of some things can be hard to measure (like mentoring), but other things are more obvious (like E2E tests).

Setup a tracker/spreadsheet/whatever and note down everything you do.

When talking to your boss, present a high level overview of all tasks and ideas/improvements that could be made.

You could also produce a presentation outlining the good work you and your juniors are doing (give credit where it's due) to show management you are delivering.

In my career, I have made myself invaluable by making myself replaceable. By this, I mean I share my knowledge, train and mentor junior team members, create documentation of team procedures, organize our doc library and knowledgebase. I add comments to stories to briefly mention why we made certain design decisions. I mention what I am doing, and how it raises product quality, to my manager during our one-on-one meetings.

I have worked for small startups and big companies. I have survived a dozen rounds of layoffs. I think it is because management knows my high standards of team and product quality and how my methods save time in the future when we see easy it is to find answers in the docs.

I have 1:1s with my manager and ilk often say " because if I don't say you'll never know, but I'm doing X,Y and Z with, these things to achieve some goal."

You have to be verbal and vocal about these things or they become a brick tied to your feet.

It's not really invisible work because it's impacting (improving) overall team output & quality.

If all you're concerned about is how to account for it in the sprint, the solution is to simply reduce your velocity and/or add tasks for your individual contributions.

If you're concerned with management not recognizing the value or priority of your work, then it comes down to your communication & reputation. They need to be able to trust that what you're doing is actually important, and more valuable than the alternative work they want to task you with. That trust needs to be earned and cultivated by you. You also need to be aware of the business needs, so that you can properly balance them against the engineering needs that your trying to accommodate.

I tend to keep a work log ( some call it a brag document ) where before the end of the day I go over notable things I did today. It can be anything from helping this person with this and that to did this to save us form a potential "fire hazard". Then I can use it during my 360 review and go over it with my manager.

It has helped me a lot especially since my manager is off-site so they can't really see the day to day activities I have with my team, except for the calendar.

There’s a book called Making Work Visible and it helped me a lot with this problem.

If there are no user stories for it create one and then upload the artifacts as proof of work. It's a pain but your best option.

Do people just not use subtasks anymore?

Track EVERY little thing you do with subtasks on other people's tickets or your own stories. PM's love it.

Report the invisible work.

I swear subtasks are the most under utilized thing in SWE. If I get a story I create as many subtasks as I can possibly think of for every aspect it will touch. From dns to css. Sometimes I get other people to add subtasks they think I might have missed (esoecially during grooming). I might have 30 subtasks per story but I'm closing at least 5 of them a day. The pm's also know if they try to change scope on me they get 10 more subtasks added to the ticket.

Seriously if a story takes longer than a day bust that shit up into every subtasks you can think off. It will teach the PMs to stop shoving epics into stories.

My manager has stopped writing code mostly and it's been a blessing because he has focused on this invisible things and product. We are now building things that matter and not random things product thinks of without data backing that it is a good decision. 

That's not invisible work. You can link to the commits specifically. Of course, if the product is still having quality issues then your work isn't really working.

when folks ask what you even do anyway.

Where is this coming from? Like, it's probably not a person on your direct team because they'd see your code and PR comments. How you solve it will depend on who is asking this, but you probably need to communicate what you do explicitly ("helped Bob deliver feature X", "created alert Y that we resolved before user impact".)

Put invisible work in as separate, pointed stories on the backlog. Make the work visible and make it into a budget item.

You may have to go to war with agilists who feel backlogs should only have features, and that’s a battle you have to go fight to the death.

How are you measured? I'm in a non engineering company (Telco) and I'm measured the same way other management are. Are you classified as management?

As a lead you should for a big part get evaluated on the performance of the team you are leading. Your job is too make them perform well and look good. That invisible work contributes to that.

If your boss knows what they are doing he will see that your team is performing well and evaluate you based on that. If you are working on individual tickets or invisible work should not matter to them.

My main drive to do the invisible work is because doing individual tasks does not scale well. You need to offload more and more of that on your team so you can focus more on making them more efficient. I'd rather do IC work but I also want to get things done and this seems to be the only way for me.

Automation is your friend here. Don't do the toil, use linters, templates, workflows etc to replace you with tooling

Write guides, create demos, create basic starter files, etc. Create deliverables.

Then do the presentations during any and all meetings. Make sure you inform EVERYONE that you created all these deliverables and did the work.

How are you in "lead/staff" role and not know how to deliver IMPACT?

I work for a three letter agency where engineers are sometimes audited. "What did you do July 31st 2022?" is a tough question if you don't log your work. I have a physical notebook on my desk where I take notes.

There are other great suggestions about demoing your work. Nobody asked, but it's something the team could benefit from knowing about, so tell them about it.

The work around the work is important too

Read "A Staff Engineer's Path", it tells you exactly how to deal with this stuff.

Also, everything you achieve should go into a "brag document".

Oh man what an entitled bitch