
Founders/Leaders, how do you communicate with your team? - carrozo
Curious about content, cadence and tools, as looking to build something in this space.<p>What works? What doesn’t? How has that changed as you’ve grown? What’s missing?<p>Quite a few questions there, but would love some feedback.
======
Jugurtha
Conversations during work. One one ones (I used to go for a walk with some
members and we'd just talk. It was extremely practical especially during some
hard times where you change the frame/context/place of the conversation and
take it outside the office. The amount of things that would have went untold
is impressive when you're far from a laptop you can hug and interruptions).

Emails. Putting thoughts processes, plan/roadmap, in writing exposes them to
be deconstructed, torn down, reconstructed, debated, and assimilated.
Strategy, business model, which features and why, what to ignore, what to
focus on, tradeoffs, meeting notes they didn't attend with investors, prospect
clients or partners, accounting or legal.

Wikis and knowledge bases. Each project has a wiki and whenever someone learns
things that directly serve the project, they add it. To make sure I do it, I
add issues to taskwarrior to decrease the friction to ingest/acquire info and
useful things[0] with issues that say "Add X to Wiki" with tags and by
project. Then move them from taskwarrior to the Wiki in a batch.

Working on a company Handbook which is a sort of "Operating Manual" for the
company that contains as many details as I can on everything one needs to know
to operate it (from legal information, bank accounts, hiring procedure and
onboarding, firing, where to pay taxes, how to fill checks, etc.). I wrote
these down when I used to do things myself so anyone who would help on these
matters would know where to start.

Sharing what I learn with them and learning what they've learned in impromptu
conversations or mini hacking sessions or code snippets. Talking shop, code
reviews and refactoring, debugging together. Getting help from them debugging
something and vice-versa.

Emails. Again. Writing things down. I'd think something has settled in until
I'm proven it hasen't yet.

[0]:
[https://news.ycombinator.com/item?id=21545767](https://news.ycombinator.com/item?id=21545767)

~~~
carrozo
Thank you for taking the time to write such a thorough and considered reply
detailing your thorough and considered internal comms!

I'd love to know more about your email habits; seems super important to you as
you've mentioned it twice. You mention a lot of the content you cover - do you
do a weekly update that ties together all these disparate strands?

~~~
Jugurtha
I mentioned it twice because it's a reference to repeating things to make sure
they sink in. Also, it is easier to be analytic on someone's writing than
verbal discourse. _Verba volant, scripta manent_. I can't back-pedal and say
"Oh, I didn't mean this, I meant that" or "I never said that". I can't accuse
someone of misunderstanding me, because I bear the burden to be clear. If my
thought processes are flawed, the flaws are glaring and exposing them is
easier if my thoughts are written.

Also, writing allows others to have time to thing about it, construct
questions, etc.

I don't send emails weekly or on a schedule for now. I send three types of
emails:

\- Synthesis: when a critical mass of information and insights has been
reached that I feel we have to consolidate that into writing. What the product
is, what it allows people to do, who it caters to, why it is needed, why we
believe that, what are the components, what is the initial stack or
architecture. This is the result of frequent conversations and spontaneous
brainstorming, shower thoughts, night and week-ends musings, recurring
frustrations, etc. All we have talked about or imagined is synthesized in that
email, that will find its way into the wiki and the product's documentation.
It takes the form of a product pitch/pitch/documentation before the product is
finished or started. We'll talk about it as if it existed.

\- Shift emails: Sent when taking a turn, notwithstanding whether information
has reached critical mass or not. As we move along, the
product/offering/company shifts. Mini-pivots if you will. Shift emails are
essential because we can't afford to have someone building tomorrow's product
and another building yesterday's product because they didn't "get the memo".
These emails serve to align people and make sure we work in the same
direction, whether for a week or a day or a month doesn't matter. Whether
we're going the wrong direction doesn't matter much. It is easier to change
course if there actually is a course we're following. It's good it is in
writing because it's easier to correct something that's written as the thought
process is externalized, than it is to correct words in the air.

\- Announcements/Status: Meetings with potential investors or partners, why we
are meeting someone, what's the objective, and meeting notes so what has been
talked about is captured and the actions to be taken can be checked for
done/depend on other action-person/cancelled, etc. Changes in work regimen
(for instance, I just sent a message to work one day remotely to test a
hypothesis of non linearity of recovery time vs commute-free days) after
floating the idea that it might be interesting to have one day we work
remotely. We usually work remotely from time to time, but not all at once.

Sometimes, we'll have a lengthy conversation on our channels and the exchange
is either dense with points, counter-points, and ideas that it will find
itself synthesized and in the wiki.

The reason we are doing something, what the problem is, why it's a problem,
and what we plan to do about it, are points that I consider important to
share.

One thing I have forgotten to include is commit messages and code
documentation. We write commit messages to include root cause analysis, why
something was changed and how, the lessons learned, the thought process/flawed
reasoning/assumption that introduced the bug. I view commit messages as
something I can learn from and improve how we make software. When we started
doing this, the flaws became blatant as we were fixing similar bugs or making
similar changes. Patterns emerged and we fixed the root causes. Here's a banal
example:

    
    
      commit 382afdc5eed2478d8cfa4b6fe5e64eb26e7fdff3 (tag: v1.0.58)
      Author: Jugurtha Hadjar <XXXXXXXXXX>
      Date:   Tue Jan 2 02:13:10 2018 +0100
      
          Closure for #153, #310, #311.
          
          The difference between #310 and #311:
          
              The first case was in the context of `create_form`, which means that it
              wasn't until you wanted to create a Task Template that you had a problem.
              i.e: it wasn't until `TaskTemplate.create_form` was executed. Which means
              you just had a builtin ValueError that's easily fixed.
          
              The second case was in the context of *class instantiation in TaskTemplate.__init__*,
              which means that the instance of the class can't be created, which means that adding
              the TaskTemplate route to admin in `app.py` will fail, and with it the routes added
              after it.
          
          So why was this different? They both should have been ValueError for trying
          to unpack the wrong tuple to the wrong variables.
          
          The reason is that, after cleanly handling the case where a database is down by
          catching the proper exception (sqlalchemy.exc.OperationalError), that is #153 in commit
          3327929d74911b999638e4902a9662366dd42c7d, several other handlers were added.
          
          In a subsequent commit, the exception handling in a try..except clause was delegated
          to a custom handler, `db_down_handler`, and the exception caught in the try..except
          clause was changed to catch Exception and silencing it without logging.
          
          Silencing exceptions is fine as long as you know why you're doing and explicitly do
          so with a safety net of sorts (like logging/warning).

