The robustness principle of human communication

If you work in software, you may have heard of The Robustness Principle, aka Postel’s Law. It states that when designing software systems, programmers should:

Be liberal in what you accept, and conservative in what you send.

In software, this means that you should always send data in a format that is as conformant with the spec as possible. And, you should always accept data that is not conformant but for which the meaning is clear. This leads to robust systems.

In human communication the same thing applies. I have an internal version of Postel’s Law that I think about fairly often:

Accommodate mediocre communication from others, and do not tolerate it in yourself.

It took me a long time to learn this. Too long. When someone said something confusing that I mostly understood (but wasn’t communicated well), my lizard brain reacted strongly. I fixated on how they were communicating instead of what they were trying to tell me.

Having now been on the receiving end of that type of reaction for awhile now, I am proud to say that I am a recovering violator of this rule.

Note that, like Postel’s Law, there are some valid criticisms to be had here. For example, most programmers know that if you don’t enforce a standard and are too accommodating of malformed input, at some point the standard can become less effective in general and developing applications against it is much more of a chore. cXML and EDI come to mind.

Just like communication – if you simply tolerate poor communication from others 100% of the time, then nobody will improve and, well, you’re stuck in an organization with people don’t know how to communicate. And that will truncate your career.

Generally the advantages of this approach far outweigh these downsides. People feel heard by you and are comfortable talking to you. They feel less judged. Able to be more honest and direct.

Give this a shot and tell me if it helps!

What CTO means to me

One of my favorite things about the role of CTO is how different the role is at different companies. Early on it basically means technical cofounder or at least first technical team member. As the company grows, it can evolve in either the technical direction or management direction or a hybrid of both. Some CTOs are more like lead architects and oversee solely the technical decision making on the engineering team. Greg Brockman has a good take on this, as does my favorite CTO thought leader Camille Fournier (you’ve read her book, right?).

Suffice it to say, it’s a role that can be many things depending on the needs of the company and the strengths of the individual filling the role.

For me, the role is a combination of:

  • Leader and manager of the engineering team, and sometimes the entire product team (depending)
  • Member of the executive team

I used to joke that the acronym actually stood for Chief Translation Officer because of how important it is to speak the various jargon dialects across the company. (“Reworking the model” for Excel-wizards is “pay down technical debt” for engineers.)

At its core, my responsibility as CTO is to work w/ the members of the executive team to help set and understand the objectives of the company, to translate those objectives into a technical roadmap, and then execute that roadmap successfully.

Part of this skillset is not just engineering management but general management. Effective communication to all parts of the company, fostering a non-adversarial relationship between the product and engineering teams w/ the rest of the company, and striking the right balance of Andy Grove’s black box w/ transparency. It means knowing (or learning) how to hire and manage all types of people – engineers, designers, product managers, tech leads, and so on.

One last note. I’m not here to build a command-and-control organization. Command-and-control is pre-industrial revolution. It’s for unthinking robots who don’t want to make decisions or exercise responsibility over their fates. Other companies do that well – not us. We don’t give orders – we provide goals and we get out of your way.

We’re building a team of people who know what the goals are, have displayed competence and good judgement, and as a result have the autonomy and responsibility to make sound decisions.

Sound interesting? Drop me a line:

Disagree and commit

Someone once told me that as a member of the executive team at a growing technology startup, whenever there is a Big Decision that must be made, you have three choices:

  1. Agree and commit
  2. Disagree and commit
  3. Don’t let the door hit your ass on the way out

Obviously this is a bit tongue-in-cheek, but I’ve found it hugely clarifying over the course of my career.

Agree and commit

This is the happy path. Healthy debate has occurred, and the decision was made according to the path you preferred. You’re on easy street and immediately leap into next steps.

Disagree and commit

This isĀ hard. You argued your perspective. You used your credibility and the best of your persuasive abilities. You brought data to the discussion that backs up your argument. You provided lots of evidence. And the team went in a different direction.

You’re at a critical juncture. How you conduct yourself and move forward will speak volumes about your leadership style. Now is the moment when you will either:

  1. Proliferate politics and frustrate your team by remaining ambiguous about your team’s goals, inhibit progress, throw up roadblocks to the team’s momentum, or
  2. Foster a focused team rallying behind a clear direction.

Obviously if this happens frequently enough, you may just need to part ways. But I’ve found for the vast majority of Big Decisions, disagree and commit is the right path. You deepen your professional relationships, build empathy and respect for other points of view, coach or assist your direct reports (and learn from them) on this process, and ultimately learn a ton about yourself and your values.