Make ICs and your lower management team onboard new VPs and C-levels at your peril. I spoke to three great ex-coworkers who moved on to new jobs, stating they didn't have it in them to be consistently turned down for promotions while they essentially running a school for a steady stream of new bosses.

1. They are generally using the product the most and encounter issues at scale that need to be listened to.
2. They are one of the "least-important and most-important;" their interactions with customers can influence the customer's adoption. Their feedback about your buggy products can not only tank that product's adoption but also trust in the org's ability to make products.
3. Company culture: Don't ask your team to add their feedback to the public roadmap. Your team's feedback can't be thrown into a bucket with tire-kickers, new users, and specific user personas.

I've worked for many companies that never spoke about culture, and their culture was fantastic. I still do my best to emulate what those companies had. We took pride in our work, admired each other, and treated each other with respect. We put the customer first and worked hard to succeed. Some didn't. We went into bankruptcy, fighting together to survive until the end.

Creative ideas are long-lasting. But corporations err towards the safe, dreary, and mundane. It's easier to have no ideas and worry about recessions in the middle of the pool with the others.

As I thought, a tutorial based approach isn't going to work. And following docs in drupal.org is not going to be a satisfying experience. Open source docs have this tendency to want to fling you to 2007, often with the direction to "Please read this" and a link to some barely related page. I haven't written any object oriented php and I don't want to get too bogged down into it immediately.

Re-learning Drupal: I know what doesn't work in general, and what doesn't work for me. I haven't figured out a great way to pick Drupal back up, but it needs to be somewhat novel, because I don't retain tutorials, and my coding time, at best, is going to be 6-8 hours per week. I still fall back to What Smart Students Know as one of the better ways to learn. It's great because it starts backwards with learning the overview, then iterating in increasing levels of complexity. So, rather than start with building a module, I'll start with visualizations of:

Creating a “pile as many people into a slack channel as possible and thus dilute the accountability” model that happens. Accounts demand accountability:  people are specifically on the hook for the overall management and health of the account. They need to ask for help and engage and disengage with other teams as needed. When 10 or 50 people are weighing in, it's never good for the client.

Well, so far. My first attempt ended in a reset and force push. Thank god for dev sites. Try again tomorrow.

Among the more existential regrets I have is about not committing fully to what I want. It's easy to assign it to fear, but it's often about the lack of awareness that I now have, that I didn't have in retrospect, for whatever reason. Getting from point A to B just didn't seem possible.

向け - for, in, within

• 金融業界向けの事業統括 - business management in the banking industry

に向け - in order to

• お客様の課題解決に向け - in order to solve customer's problems

お負け：「密に」

• 親子の関係を密にする - develop close relations between parent and child.