Invisible Work Syndrome
Are you or have you worked in a company where you’re the only person able to understand the complexities and structure of the code behind your product? It can be very confusing at times. I most of the time find it very hard to explain certain technical things and workflows to those who have never experienced writing code themselves.
This is more common in startup companies, where the teams are built with one responsibility area per person, and it can work perfectly for some, but in some cases it can also be quite confusing for your colleagues to truly understand your responsibilities and the requirements for certain tasks.
The Task
Let’s say we’re building an in-house project management system which is pretty early in development, and everyone is working hard to build the proof of concept for the system.
You’re in the daily adrenaline meeting, and you decide with the team to start working a feature in the general task list: Inviting new and Communicating with existing team members.
Your colleague comes up to you and tells you where he thinks is the best place to invite people from, and then what screens should be displayed to the user at each stage.
Your brain’s cogwheels start turning as you’re thinking about the requirements for the feature to be implemented, and you come up with the following task list:
- Create an Invitation model which supports unique invitation id’s that can be sent by email
- Assign that Invitation to belong to a user, and later on the invited user
- Create a controller that can create, validate and accept sent invitations and handle the data correctly for when the members are using the feature
- And so on.
But! Let’s stop there for now, since that’s pretty much the needed stuff without any of the front-end development, right?
After a while, you get all the behind-the-scenes stuff working, sigh in relief, and now you only have to create the buttons and lists for the visual look and feel of the invitation system.
You tell your coworker that you’ve made great progress with the feature and that you’re happy how it’s going to work. He then eagerly asks to see your progress.
Oh, well, you see.. I mean I’ve completed all the required tasks for the system to work, but it’s just not done for the actual site yet.
What does that mean? Have you actually done anything for the task, or are you just slow at doing your job? You’ve been doing invisible work.
Invisible work is the hardest thing to explain to someone who doesn’t understand how things get built, and also makes you feel sort-of alone in the world. If you’re really excited about something you just created for the code side of the project, and that something going to improve a part of the site, it sucks if the only words you can use to describe it are: speed, efficiency, security. Invisible work.
Of course you can take your time explaining the steps you’ve taken and how the things work, but in most cases it might seem like a dead end since all you’re going to get back is an okay or a question about when the rest of it will be done.
A little bit later that feature is now implemented, and you seem to have gotten the wrong idea about one thing in the invitation process, and are asked to make a simple change to how the button displays the information for the inviter.
More invisible work, you now have to create the functionality for the button to display the information before you can actually have it shown to other people. This continues until everyone is happy, or when you run out of time allocated for the task.
I’m not the best estimator of required time to complete a task, and can definitely get better at it, so I can give accurate estimations of when people can look at results. That I know.
You can also fight the invisible work syndrome by creating prototypes for other people to see, before you start working on the more challenging backend and database-related tasks. I like to complete the harder parts first to keep things as flexible as possible.
Think about how you approach project related tasks in a culture with no other developers and learn to adapt into the environment, by either making them aware of the technical requirements before hand, or by giving them what they want to look at first, and then tell them it just doesn’t work yet. Much better than saying “I don’t have anything for you yet”.
Back to work!
