The Cost of Silence

All engineers and professionals in the tech industry, at least one time or multiple times in professional life, suffered from impostor syndrome. Besides the impostor syndrome, as humans, we dont like to receive bad feedback. Remote work can often be a source of more silence than would usually happen in a face-to-face work environment. Everyboddy is on the call with the video off, just audio, why would you turn your video on? You are joining a new team, you don't ask questions, you wait for the last minute when you need to code something, then you "might" ask questions. It's possible you are wondering now: What do impostor syndrome, zoom calls, onboarding new team members, and asking questions have to do with such a blog post? Is it all ramblings? No. All these moments build up on something I'm calling: The Cost of The Silence. Silence is not desired; meetings that are supposed to reduce the cost of silence, like Daily meetings, fail the goal and often just bring waste and distraction. The solution is not more meetings; in fact, the solution is the opposite.

Not all problems are solved by management; in fact, a lot of problems are solved by having a different engineering mindset and mentality. Before we approach such a new mentality, let's understand what is wrong with silence.

What's wrong with silence?

First of all, there is nothing wrong with silence per se; however, what might happen during the "silence" is a potential source of many issues that fly under the radar, invisible, slowly tanking productivity, morale, and lead time. 

When you are working on some task, whether if is an architecture design, coding, tasking, automation, or whatever, how do you know the following:

• 1. You are doing the right thing?
• 2. You doing the thing right?
• 3. Your "delay," "block," and "struggles" are acceptable? 
• 4. You are not adding anti-patterns, tech debt and bad decisions?
• 5. What are you doing that is best for the customers/business? 
• 6. How do you know if others do not have the same problem? 

Let me be very clear: You don't! Unless you provide visibility of your work somehow! Without feedback, you can't tell if you do well or not. One of the many issues with companies historically is that feedback is very low on the system, and we should be increasing the feedback, not decreasing it. Assumptions are dangerous.

There are several mechanisms that can be used, in order to introduce more feedback on the system, for instance:

• Code Reviews
• Design Reviews
• Presentation/Deck Reviews
• Presentation Dry Runs
• Live Demos
• Retrospectives
• Async Chat

It's very common for big systems at scale to have technical debt and anti-patterns. Engineers often work copying and replicating "code snippets" in other words, we are replicating tech debt and anti-patterns. The cost of silence can be huge, from days to months. People often are not talking about this kind of thing, because usually companies dont run effective retrospectives that are longer than 15 minutes. Behavior Anti-Patterns keep happening, silientely and free. 

Being cost-effective without meetings

I'm a big fan of not having a lot of meetings. Protecting engineering time should be a priority for any decent manager. It's very common to think that if you want to speed up some problem-solving, you need a meeting; that can be true if you have a production issue. However, if it is not a production issue, meetings are a very expensive way to help each other. Because meetings are disruptive and sync. Chat solutions like (Slack) if used in an async form, are way more effective and less disruptive for engineers. 

Ask Questions: Sounds silly, but it's a very effective way to learn and validate assumptions. More questions and fewer assumptions are the way to go. It's better to ask a silly question about something you already know than to proliferate anti-patterns for not asking questions. Asking questions is not a sign of weakness, bad documentation, or lack of skill but it's a way to validate understanding and comunication gaps. 

Have Goals: You should have daily goals like finishing task X before EOD, reading 10 pages of the Jellyfish book today, sharing 2 links about String interning, ask 3 questions about Java GC to a DevOps Expert. 

Reduce Batch Size: Instead of working in 1 task, work sprint, work in 1 task per 1 hour. IF you have the goal to finish a task per hour, you are forcing yourself to be effective, and if you are not being it will be visible, and worst case you just lost 1 hour. If you can't easily work on smaller batch sizes, maybe you dont understand what you need to do? Maybe you have unmanaged dependencies? 

Document Failures: Failures need to be documented because if you have 100 engineers, it's very likely all 100 engineers will have the same problem. Leverage internal wikis, internal lists, and internal chats always when possible in order to learn from others; you will be surprised how countless times people fall for the same traps over and over again. IF you fix a problem, document the problem and the solution no matter how big or small it is.

Async Chat: Slack is great; however, it needs to be used async; otherwise, it is not better than meetings. Slack is a great tool because it allows searching, and you can have topics by thread and therefore centralized in the same place a lot of different discussions, it requires some moderation, but you can take a lot more out of Slack.  Slack is powerful because we can increase collaboration and feedback in the system without increasing the number of meetings and the time in meetings. Slack is perfect for engineering swarming. 

Don't drop the ball: Slack has a killer feature called "Save for Later" which turns Slack into a Kanban system, and you can see what is backlog, wip, and done. It's possible to set a time for a reminder or just build the mind to look at this at the beginning and end of the day. I check my "save for later" all the time.

Avoid common anti-patterns

Here are a couple of common anti-patterns you should avoid, they happen very often. It's important to know them so you can identify them and easily avoid them.

Big Indivisible Batches: Big projects, Big batches, and Big tasks hide big problems. Oh, my task is too big. I can't break, or I can't do it in small increments; you can always break something. IF you can't break it, maybe it's not well understood? Big projects are all or nothing, faill it all, winn it all, this is risk and counter-effective. Projects, Tasks, and work items need to be getting smaller all the time; otherwise, if you are not reducing that time and making them bigger, you will be adding more delays and more waste. 

Accept long execution times: If you are doing something and you get stuck for more than 4 hours, go ask for help; do not hesitate to slack other people. IF you have a central channel for help even better. By doing so, we are reducing the amount of time a given task can "creep" and "expand"; therefore, we will be doing a better job managing flow and getting more things done if we do this way.

It's the Standard: Be careful; your "standard" could be old school practices, anti-patterns, or technical debt; just because the way of doing things is there for a long time, and everybody does it, does not mean it is right, and you should continue to do it. In fact, in my life, the majority of the time, people say, "This is the standard," which is very likely not a good thing. 

Too Busy to Improve: I would love to do it, but I need to ship feature Z, or I need to release some patch today, or I have no time to add more tests because my manager says whatever, all excuses. Cut all excuses all at once, if you are too busy to improve is game over, we must make time to improve always.

I have no questions: There is no such thing. Junior engineers have a lot of questions, opinionated and senior engineers have a lot of questions. Asking questions is a way to learn and spike curiosity and an opportunity to learn something. Asking questions is caring; you care when you ask questions.

Break the silence, flexibility, and async-working patterns are the way to go. IF you don't believe me go take a look at Stack Overflow, Reddit, and Quora. You dont ask a Zoom call for someone on the internet, you post a question and work async, thats the nature of all internet forums. If you dont break the silence, anti-patterns and tech debt will continue to grow. Anti-patterns love silence. 

Cheers,

Diego Pacheco