That is what GP says, too. GP was saying the advantage of in-person is agility and course-correction, which require intense discussion.
> The missing piece is that leaders need to plan, execute, and communicate effectively.
Maybe with perfect leadership this is tenable, but when responding in a quickly evolving situation, I can see the advantage of in person. It just doesn't seem realistic to expect leadership to do all the planning. Engineers "at the bottom" often have better perspective and should be at the planning table.
My personal perspective: I'm currently 100% remote and enjoy the improved throughput. I also have had to get better at planning, as you point out. But when I have to do heavy coordination, video conference fatigue gets real. I'd prefer to be in person for those days with >3 hours on video.
I worked in-person for the first 7 years of my career and remote for most of the last 7. This was true until the pandemic. It's not true anymore. Even in-office workers at my current hybrid workplace are using huddles and threaded chats to meet and decide things faster than scheduling a room or walking up.
The only thing that was consistently faster in-office was the espresso machine, and even that flipped around when the Bambino came out around 2019.
Literally none. PMs are disciplined, there's top-down and bottom-up accountability, there's good transparency of work status and blockers, and people can take days off, miss meetings, and still contribute to decision making because all the work is done in a shared space that everyone in the company can see.
We don't even need standups most weeks because everyone knows where everyone is just by looking at the related tickets.
The closest things to "problems" are in bridging front-end design and back-end implementation collaboration because they use different tools, but that was at least as big of a problem when it was turning whiteboard mockups and Post-its into engineering tickets.
All of the above can be avoided with remote work. However it is a lot easier to pick those things up in the office.
You know both premises can be true at the same time, right?
In my experience it's basically impossible to "plan, execute, and communicate effectively" in these environments, because if people knew what the plan was or how to execute it, someone would already have done it.
The company relies on quick and efficient feedback between employees, leadership, and potential customers. That's the part that's much harder with remote work. In a startup, if you tell an engineer to do something and it turns out it's impossible, you will see him grimace and cuss you out in person, and you can adjust the plan accordingly. With remote work, you don't get that body-language feedback, and he'll probably say yes while looking for other jobs and posting about how incompetent his manager is on Hacker News.
That sounds like an amazingly poorly run startup with horrible leadership.
The startups that I've seen that are successful purposefully try to fix that problem. We flew people out to customers, had them shadow them to see how they worked, and had a group of customer advisors. Out of all the startups I've been involved with the remote ones have done the best.
Honestly, the manager you're describing is incompetent. Why is that manager relying on reading body language instead of building enough trust with their engineers where the engineers would just say "that's impossible?". It seems like that manager is doing a poor job and is using remote work as an excuse for their own lack of ability.
But jokes aside, I think this is really unkind. You're never going to have perfect people or perfect situations. Saying a process works great under the best conditions is only looking at things inside a small sliver of reality.
> In a startup, if you tell an engineer to do something and it turns out it's impossible
I see a problem with that approach. To me, it's not about you telling the engineer what to do, they are not a tool to execute your bidding, they are a colleague with ideas how to achieve the goal you are striving for.
What is great about remote is that it kind of forces you to write down your ideas in some format, in PRs, in proposals, in documents. That gives the space and time for others to chime in, at their own pace, without your "body language" or your "room presence" shutting them down. Granted, it's not the American way with a top-down approach to startups, but if your working model is you simply tell your engineers what to do and they execute it, then imo you are missing 90% of their value.
> you will see him grimace and cuss you out in person, and you can adjust the plan accordingly....you won't get that body-language feedback
I have never had anyone at work "cuss me out", whether that's been remote or in the office. That sounds like a very unhealthy culture to me.
Additionally, I stipulate that looking for inscrutable clues in people's faces can instead be replaced with building a culture where you reward people for speaking (or writing down) their mind and all contributing towards the common goal, and there is a healthy amount of discussion (preferably written). As a technical manager, your role is to provide a clear goal to your teammates, and work with them to a good solution, not analyze their body language and making decisions based on that...
> yes while looking for other jobs and posting about how incompetent his manager is on Hacker News.
I'd be doing the same if my manager's main job is observing my every facial expression and I am not allowed to say no or at least explain why I don't think the task that's been presented to me is possible to be achieved in the proposed way.
To add to that, a lot of engineering types are also very neurodivergent and just do not communicate on that level the same way as other people, leading to copious misunderstandings and miscommunications when it's not a "say what you mean, and mean what you say" sort of environment. That probably makes a certain other type of person uncomfortable, when their main skill is social hacking and not necessarily efficient management, planning, or collaboration.
It really doesn't for some people. I have coworkers who will never communicate through text; after the first 1-2 messages they always say "let's just have a quick conference call", and then it ends up endless as they talk. I personally mostly avoid them as much as I can.
My point is, there are different types of people, and some are more competent, some less. Organizing our work life, cities, traffic and everything around Joe the react dev, so he can have a structured way of working (like kindergarten, same time, same day, nice routine) where his manager can see in his body language that Joe is a tool, that's insane to me.
All the power to people who'd like to spend the workday with Joe the react dev physically, but I prefer having my distance from people like this, which remote is great for.
Before the "closure of the commons" in England, wage labor world-wide was virtually non existent. It took a series of very harsh and restrictive laws and concerted effort of capital and lords over many generations to force the peasants and independent craftspeople, to leave their fields and workshops and join wage labor in the mines, and later, the factories. Offices were really invented much later, but are an artifact of that same type of thinking, and so are managers, a new type of "work" all about managing how others do the work. With that said, all through and through and up to today, body language has been an important thing of how people perceive information and how they communicate. That's not something I dispute. I dispute that we need to be at a place for 8-10 hours a day so we can read each other's (and our leader's) facial expressions, in order to do good work. If people can't have the time or ability to clearly express their views in a written format, and instead I have to stare at their faces to guess what they mean, I don't want to be working with those people.
Programming is deep and creative work. You need to sit and think deeply, in that way it's NOT comparable to factory work (which is the field where most "modern" managerial techniques come from). You don't do the exact same thing all over, repetitively, without a thought, despite how Agile, Scrum, or any kind of managerial trash is trying to convince you.
The manager of today's office very often is nothing but a glorified taskmaster:
- daily checking if you are on time with this and that
- giving you this or that small piece of work that later needs to be pieced together to make a finished product
The same way, in factories, craft was lost because people were doing only a their small part before finishing the product, many modern office environments push for and think of programming as "factory work", thereby destroying the craft, producing cheap items, that were often lacking in quality.
I like to think and do programming work as the result of the craft of many independent professional craftsmen, who will organize in groups when needed, and work deeply independently or in self-organized groups, rather than a factory floor with a taskmaster looking for clues into other people's faces whether their daily quota is finished or not. So let the craftspeople organize however they want, they can read each other's faces and debate the merits of this and that on Zoom, and they can find a fit for their product and go to meet in person if they desire to do so. You don't need a manager for that or to force people to go to a specific location so you can observe them.
Don’t hire people who don’t value synchronous communication. People who want all communication to be async and don’t plan to respond promptly to messages (like the work/life balance crowd on HN) will not produce a dynamic team because that’s not the strong point of async communication.
Do quick calls when text conversation gets too long, build a team where you can expect people to actually make an effort to show up to the calls. For us we also have strategy calls with video regularly (but not too frequently), and make sure everyone is aligned to the plan and concerns are resolved before building. Make sure the team understands that for anything where they are unsure what to do or have any ambiguity around requirements, that they proactively ping the right people.
Doesn’t mean you need to be on all the time and that async communication is not valuable, but you need everyone to know when it is and isn’t the right way to go. So long as people are making a best effort to value communication speed it works out.
Hire people who are motivated enough to form opinions, and confident enough to say they really think. Most people are not invested in their work, or not invested in the problem space enough to bother making the mental and research effort to form valid opinions on your problem space. This is fine for when things just need to get done (not everyone on the team needs to be a decision maker), but foster those who are ready to invest. Make it clear it’s a good thing if they do form opinions and are willing to express their doubts about the strategy to others/leadership.
For us we also have very clear owners of different aspects of our operations and product. Someone will make the final decisions on those aspects. This doesn’t mean they make all choices, they can choose to defer to someone they trust to make the call. But someone needs to be clearly responsible, and others need to know that if a conversation is not resolving that they can pull the right person in to resolve it efficiently. People need to agree to disagree at some point once those responsible make a choice.
This general approach works for us, people don’t tend to hate their managers if they understand why choices are made, feel that their concerns are heard, and are aligned ideologically with the approach and way of working. But it does require choosing the right people and setting a higher bar for yourself on alignment.
Basecamp has always been remote and asynchronous and they seem to be doing well.
If we create an environment where engineers feel comfortable enough that body language isn’t required as the sole feedback indicator in this scenario, perhaps the entire workplace would benefit.
There's a reason why generals who lead from a desk aren't really trusted, or why when executives skip off to New Zealand it corrodes morale in their organizations.
I feel this to the core.
That's a big if
Do you have an email address or a contact method?
In my experience, remote workers are significantly more productive than on-site employees IF the culture is one of employee empowerment and trust. If you expect people to be mature, communicate effectively, and get things done AND you give them the tools and support to do it then being remote is absolutely no barrier. It just gives people an extra hour or two a day to think about things and do a little extra work because they are not commuting.
The missing piece is that leaders need to plan, execute, and communicate effectively. They need to empathize with their teams and work with people as individuals, which means extra time and thought and attention. Face-to-face work covers up for a lot of incompetence because that person is standing in front of you. Remote employees can't hide behind a herd and remote leaders can't hide behind an org chart. You don't need to spend millions of dollars on a building to cover up for poor leadership and weak culture.
For reference, I run a team of 10 remote employees and am responsible for highly technical engineers that support sales for a team that generates 8-figures of annual revenue on SaaS and on-prem software.