Why work transparency matters
Let's discuss what can be useful when watching how other people work and whether it makes sense to showcase what you're doing.
Work can be either transparent or non-transparent. We call it "transparent" when we can see the work progress. Non-transparent work is like a black box — there's some input, and after a certain time, there's some output, but we cannot see what happened in between. First, let's talk about the pros and cons of each of these strategies, and then I'll suggest some practical tips on finding the right balance.
Pros of work transparency
Enables better planning. When we can see the work progress, we can plan better. It could be about setting customer expectations, cross-team coordination, or deciding what to do next.
Reduces risks. Software development is, to a great extent, exploratory work. We can't plan everything in advance — some things always come up only after we start working on a task. Below is my favorite illustration from Basecamp showing that a significant portion of work is figuring out what to do. Regular check-ins with teammates may help us identify problems in earlier stages when it's easier to fix them.
Helps to identify progress blockage. As developers, we know that it always takes longer than we initially thought — an observation known as Hofstadter's law. Sometimes, problems come up even in the least expected areas. Brainstorming with teammates can be extremely useful in your problem-solving process. But, to be able to brainstorm, people need to understand the context. Therefore to get help, we need to explain what we're working on.
Improves learning. Watching how other people are working is one of the most efficient learning techniques of all times. This is how people have shared knowledge for centuries, from master to apprentice, and it still works great today.
Reduces anxiety. For most people, uncertainty is stressful. Reducing uncertainty is a basic human need, which is especially pronounced in some managers 🙂 They become nervous when waiting for task completion for too long and want to know what's going on. Ideally, they'd like to learn that the task is already completed, or else, what the status is. If we can say that we made good progress, it makes them feel better; if the progress is good, of course. If it's not so good, then, that's another story; we'll discuss it in a minute.
Cons of work transparency
Distractions. To be productive, developers need prolonged periods of focused work. Distractions affect their productivity. Reporting on work progress could be a distraction. Beside that, too much work transparency may attract unsolicited advice or unwanted questions, interfering even more.
Unfinished work might not look good. As we mentioned earlier, if we can tell managers or customers that we made good progress on their task it makes them feel better. However, sometimes the progress doesn't look good yet. People may be reluctant to show results if they think they need more work before they can proudly show them. For example, some designers would much rather avoid showing half-baked work, and they have reasons for that.
Feeling of being continuously watched. Sometimes, efforts to ensure work transparency can go too far and be perceived as an intrusion into privacy and spying. An infamous example is Upwork's Work Diary — a software that captures screenshots every 10 minutes. Many people hate working in such conditions, which is entirely understandable.
Risk of micromanagement. When a task assignee frequently checks with others to make sure that they are going in the right direction, it can damage self-sufficiency, the ability to take the responsibility to make decisions by themselves. As a result, the work process will go slower than it could be, and quality may suffer.
Finding the right balance
It would be best to try and find a balance to optimize all the benefits listed above and, simultaneously, help avoid distractions and other issues. Here're some practical tips on what we can do:
Focus on results. Watching how people spend their time isn't worth it. Checking what eventually gets done, though, is better. Some people can work non-stop for a few hours, making gradual and steady progress. Others can spend a large part of their day on Twitter and YouTube and then have a productivity spike during which they can get a lot done. And that is fine. All that matters is what they achieve at the end of the day. Focussing on results helps in two ways:
- First, it helps to respect privacy — and I'm not even talking about legal privacy compliance. Even perfectly legal work monitoring tools and processes can create an atmosphere of distrust and constant — and unnecessary — pressure;
- Second, if we primarily focus on results, we are less likely to be fooled by people pretending to be busy working.
Ask what problems people have encountered. If you see that progress is not so good, try to postpone your judgment of why you think it's not so good. Better ask the person who worked on it — what problems they encountered? Software development is one of the most complex human activities, and problems may arise in the least expected areas. Sometimes, the situation may require help from others, and sometimes they just need a bit more time. Don't rush to tell them what to do until you get all the input.
Find the right cadence for your team. If people report work progress too frequently, they won't have enough time to achieve anything meaningful, and reporting becomes an annoying distraction. On the other hand, if there's not enough reporting, we may not benefit from its advantages — better planning, early error correction, and minimized stuck progress. Optimal cadence varies; one team may have daily check-ins, another weekly, etc. If you haven't found your perfect schedule yet — feel free to experiment. Start with something that looks reasonable, then try to do it more or less frequently until you find your sweet spot.
Value open communication. Public work discussions not only help work transparency but can also facilitate learning and improve the quality of project decisions. Today, most engineering teams use some chat — Slack, MS Teams, Discord, or similar tools. Public group chats are extremely useful tools that enable open communication. Unfortunately, people are often shy to discuss their day-to-day work questions in group chats and prefer direct messages, so they do not fully benefit from open communication. This topic is so important that it merits a dedicated article.
Lead by example. If you're a team leader or a project manager, establishing team rules could be much easier if you follow them yourself. However, unfortunately, this isn't always done. For example, if you, as a manager, require your team to submit daily or weekly reports but you fail to report about your own work yourself, that may feel unfair to them. Fortunately, that situation is easy to fix — lead by example and follow the rules you're trying to establish. Besides feeling fair, it also gives a manager a much better understanding of whether the rules are reasonable or not.
Avoid unnecessary access restrictions. I've seen companies where people have to provide bulletproof arguments to justify that they cannot get their work done without access to certain information. It is a terrible work environment, depressing and unproductive. I've seen extreme cases where one paranoid security guy with too much power could almost paralyze the work of entire departments of a large company. Don't repeat these mistakes. Of course, there could be sensitive information to which access should be limited, but the reasons for such restrictions must be clearly stated, and there should be no "we restrict everything by default" rule. Access to the source code, issue trackers, project documentation, work chats, and other collaboration tools should be granted to everyone working on the project. Nothing bad happens if developers can see how designers work in Figma, and designers can see the developers' source code. It's not a problem if folks from a neighboring department can see how our API works under the hood. Open information fosters collaboration, and closed information creates obstacles. Even at Apple, a company known for its atmosphere of secrecy for many years, there's now a movement to overcome its secrecy culture since it greatly harms productivity.
Status meetings, or daily stand-ups
Status meetings are ubiquitous, and some teams hold them daily. A typical agenda for such meetings is having three questions answered by each team member: "What have I accomplished here? Are there any blockers? What am I going to do next?" The idea behind such meetings is to improve work transparency, identify bottlenecks, and help with short-term planning. While the goals might be perfectly legitimate, I've seen many developers annoyed by such meetings. Often, they simply have to repeat the information already available to the whole team, which doesn't feel productive, so they resent the waste of time.
Let me provide some examples. Almost every engineering team uses an issue tracking system, like Jira, Trello, YouTrack, GitHub or GitLab issues, etc. If a team keeps the records in their tracking system accurate — why ask who is working on what? Can't we just see it in the issue tracker? Or, why ask what they did yesterday if we can see their commits and pull requests on GitHub and read their task updates in Jira? Isn't it obvious that a pull request that is stuck in review for a few days is a blocker? Why repeat this information in a meeting?
Of course, not all problems fall into the categories mentioned above, and the information in the issue tracker is not always accurate. I'm far from proposing to avoid having meetings altogether. Live communication is valuable, and if we can get rid of boring discussions of trivial questions, we'll have more time for the really important stuff.
This was one of the main reasons why we created Teamplify. We wanted an automated team assistant that could help us save time on trivial discussions. It makes it easy to understand who was working on what; whether there are any bottlenecks; it helps to keep the information in issue trackers accurate; it reminds us about due dates and other important dates, such as vacations and holidays, and more. You can watch it live — how we're working on Teamplify in Teamplify, or try it for free.
Bottom line
As in many other situations in life, balance matters. It might not be a good idea to make all the work completely transparent, but working always in "black box" mode isn't good either. Focus on results. Ask what problems people have encountered. Try to avoid unnecessary distractions and trivial questions. Beware of the dangers of micromanagement. Value open communications. Lead by example showing how to report about your work. Don't abuse access restrictions. Hopefully, this could make your work environment both happier and more productive.
