Invisible Work
After nearly 13 years as a technical program manager, I’ve learned that program managers and engineers are different people. And thank goodness for that—because our roles could not be more different. I’m generalizing of course—but, as a program manager, the idea of sitting at my desk for an entire day quietly working on a problem and interacting with no one fills me with nameless dread. Sure, it’s appealing when you consider how little time we have to ourselves and how our modern workforce is focused on speed of output, rather than quality of ideas. We even invented agile so we could ship ideas more quickly. We’re often working on a million things at once and doing bits and pieces of real work in between our meetings. But, that’s a topic for another day.
The point is that, while working quietly on a strategic project for 8 hours uninterrupted sounds intriguing in concept, I know after a day of that I’d be ready to throw up my hands in exhaustion. I want to engage with others. I want to get real eyes on the problem. Who cares if I think it’s good? Is it practical? Is it actionable? How can we get that good idea out there?
Role Differences Between Program Managers and Engineers
As a program manager, I’m accountable for project progress. I want to know where we are in the delivery cycle, forecast any pending roadblocks, and engage with people to ensure we remain on schedule and under budget. I want to work efficiently, and efficiency usually means speed. I want to talk to people to get more information—that’s way more appealing than reading it in some dry report in bits and pieces in between my many meetings.
Engineers simply want to be left alone. They want to do the work. They don’t want to talk about the process of doing work. And, especially if the program manager lacks technical understanding or is not good at their job (and therefore simply obsesses about mundane status updates instead of painting the big picture for the team), the engineers wind up getting annoyed.
The Problem with “In Progress”
One of the key sources of tension between program managers and engineers revolves around the definition of “in progress.” The problem with “in progress” is that it doesn’t always provide enough information. “In progress” could mean that you opened an application and typed your first keystroke. It could also mean that the feature will be pushed to production in less than an hour. Ticket creation rarely provides this level of specificity. Unless program managers attend every standup, they don’t have insight into the true status of that “in progress” ticket. And, even if program managers are diligent about attending every meeting, those conversations represent “lost time” from an engineer’s perspective—time spent talking status instead of performing the work.
Attempting to obtain more detail on “in progress” could be construed as micromanaging, which does not cultivate the trust that is required to make a team successful. But what about those factors that are outside of your team’s control? For example, let’s say someone calls or Slacks an engineer asking for a “quick favor.” Your hard-working and conscientious team member wants to be helpful. Work ensues. If this happens once a day, then all right. It’s probably a wash. But what if it happens ten times a day? Or ten times an hour? Suddenly, your nice and helpful engineer is spending time on work that the program manager knows nothing about. Businesses expend a lot of effort to allocate people to the appropriate roles based on estimated level of effort. What if your level of effort is being skewed by a phenomemon of invisible work? In addition to the business impacts, this behavior also has ramifications on team morale. To address these “quick favors”, the team starts gradually working longer and longer hours to meet their deadlines and also accommodate these additional tasks that are not being forecast or planned effectively. How can the program manager help the engineer address this invisible work?
Potential Solutions For Tackling Invisible Work
One potential technology solution for addressing this conundrum is a product called LinearB. LinearB correlates Jira issues with real-time Git activity so that program managers can dive into the details of what is being worked (without having to bother the engineer.) I like the concept of this product, which seeks to meet the needs of both program managers and engineers (which is no small feat.) In addition to alleviating the need for time-consuming status meetings and umpteen Slack messages, the product also helps to address the invisible work phenomenon by showing the number of Git branches that are unmatched with Jira tickets during the sprint. This helps the engineer quantify this formerly unquantifiable work and gives the program manager the tools needed to rightsize scope or staffing to address these requests.
If you’re skeptical about the utility of the tool, the LinearB team has even posted a set of “anti-FAQs” anticipating these concerns and helping you decide whether the product might be a good fit for your team. I love the honesty! Any concerns I had about how the data collected could be used for ill (i.e., micromanaging or even “spying” on employees) were alleviated after I consulted this page. LinearB did not design their services this way and, like most things, the power to effect change and improve people’s professional lives (not to mention the organization’s bottom line) likely outweighs any risks that could arise in execution. The team has even put in place guardrails to protect against this behavior.
If my organization used Git, I’d be eager to sign up and test out this tool. If you have feedback, or if you’ve used LinearB before, let me know your thoughts in the comments!
