End-to-end Visibility in Engineering
The following piece is a direct extract of the deep-dive of one of our core engineering principles at Canyon. It is provided as-is, so do your own research before using it 🤓.
💡 What is visibility?
Visibility is about making all information and progress made within the company fully transparent and available to everyone. This spans levels from the strategic level (e.g., ensuring everyone is aware of the vision, having a transparent equity grid) to the very operational level (pushing to GitHub regularly).
Visibility has many advantages that have been proven countless times by experience. When it comes to company culture for example, the DevOps platform GitLab has spearheaded a culture of visibility that has enabled it to become the largest all-remote team. When it comes to shipping code, "Making Work Visible" is one of the founding principles behind the DevOps approach (see The DevOps Handbook for example).
Visibility is not something that is driven only by the leadership team - it only works if everyone contributes. You are thus expected to build visibility in your contributions at all time.
🙏 Why it is important?
🚀 For the company
- Since writing things down is a key part of visibility, the company benefits from an ever-increasing body of knowledge. New problems can leverage past decisions because their thinking process has been made explicit from day 1, as well as their issues and post-mortems
- Since centralising all the information in common tools is a key part of visibility, the company benefits from insurance that work will never be lost on a team member's computer, either because they are using a local version of a document / code or because they lost their device and their yet non-synced work
- Since everything is written down, it is way easier for a new employee to get onboarded, but also for existing team members to catch-up on work that has been done
- Visibility unlocks collaboration: if all progress and issues are only present in your head, it's hard to be able to help you and leverage collective intelligence on open issues
- Visibility helps avoiding coordination problems where several people would be working on the same issue without noticing - this is why using the issue tracker correctly is extremely important
👪 For the team
- Since we are operating in a mostly remote environment, it can be hard for other team members to understand what each person is working on - using the issue tracker to show what you're working on and linking documentation and decision papers helps everyone understand the work of others and contributes to greater team cohesion
🙋 For you
- Since visibility involves writing everything down, you get the issues out of your head and become much more productive. Getting rid of this mental clutter is one of the very first principle of Getting Things Done, the famous productivity book. By the way, this aligns with the vision of our company: driving operations effectively starts by providing visibility on projects and data
🎯 For your team lead
- Since your team lead role is to support you to deliver outstanding work, she or he needs to understand (a) your progress and (b) your problems. If you don't over-communicate on these, it is hard for your team lead to step in and give you a nudge / help prioritize or unlock hurdles
- Note that since we're working in a trust-first environment, we always assume that people are benevolent and willing to do their best. We're not focusing on input (e.g., are you logging working hours) but on output (i.e., are you delivering something). The aim of building visibility is hence not to monitor the fact that you're working but ensure that you're on track to deliver and help you whenever needed
- Since our goal is for everyone to be fully empowered in their job, you can be sure that if you build 100% visibility in your daily work (e.g. regularly documenting progress and flagging issues), your team lead will not disturb you and you'll enjoy 100% coding flow all along the way
✅ How to achieve this practically
Use the issue tracker at all times and respect the process documented in the diagram
Push regularly, at the very least 1x per day. Even if it is WIP (just flag it accordingly in your commit).
Whenever you're working on a project / bet, document all your thoughts in a decision paper in Notion, listing the following elements:
- Open issues (use the @ ping handlers to solicit input from team members)
- Overall progress in the reflection (tick boxes)
- Interesting resources
- Solutions chosen and their rationale. In particular, whenever a decision is chosen during a meeting, please document it in writing so that team members that were not there during the meeting can also benefit from the thinking