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.

Workers don't expect to get promoted yearly. But when you do this to them, you send a message that you value them mostly as the trainer for a series of failed hires of their own bosses. They won't stick around when better opportunities arise. It makes you look bad, and your org pays a price.

If you keep thinking that your org needs an expert from outside and said, especially when the experts have an average of 2.5 years per job, it's probably time to rethink your hiring and internal training and promotion process.

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. They are the farm league of subject matter experts and need to learn how to be part of the process. Most public roadmaps are inefficient and unwieldy tools.

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.

When I started working in SaaS, company culture became a topic. It's steadily risen in Google Trends and appeared more often as HBR fare. And I have heard some really wild philosophies about culture in that time. Here is what I know about culture.

• Culture only comes from the top. It's not organic. It's based on who you hire, fire and how you train, and how you work. 
• Bad culture is like fire; it destroys in seconds.
• Talking about culture has zero to do with building culture.

In business and life, you can't teach what you don't have. That spells trouble for any employee. The more hare-brained a company's concept of culture is, the worse it's going to be. The less job experience the team has, the wilder the ride is going to be.

The rewarding part of leading a team has nothing to do with an org chart. It's about teaching people a skill and teaching them how to act with that skill in the world.

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.

So step one, let's answer some questions: How does Drupal work? I'm less interested in about what each function do, but how does it do common things. For example, now does it create a page upon request?

Next, what does the structure of the codebase and high-level view look like? From the user interface and the application programming interfaces, down to the lowest level. How does the app work from the user's point of view? How does data flow in the context of the architecture?

I'll try to stick to tutorials and sessions, rather than drupal.org.

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:

• How does a D10 page get rendered, how do other things work
• What do the APIs do

Japanese: Finally pass level 4 Kanji kentei, dive into Hiroyuki's YT channel, and work on some conversation ideas

Content: Yeah, barfing out idea weekly, for real.

Running: I will finish the year at about 68% to goal of 1,000km. Next year requires upping the weekly or increasing frequency. This should be achievable,  if I can be more consistent. No 2-3 week breaks. I need to work in weight training in to this year's fitness plan, asap.

Chess: More live games. 300 by year-end?

There are more work-related goals, but I'll keep them to myself.

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.

Mass-production has a harder time scaling in Saas, because some saas isn't meant to scale. And once you start the habit of throwing people at a problem, you unknowingly start becoming a services company.

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.

But fear, even if I call it discomfort or anxiety plays a part, even today. I still have to force myself to be the person who asks a question when I don't understand something. Who doesn't just spout answers. Because I hear those people all the time, and they are often wrong and everyone in the room knows it and moves on, because it's too much effort to bother with them.

Asking questions has its downsides. It opens you up to everyone knowing exactly what your understanding of something is. Keeping your mouth shut and nodding keeps your cards closer. And you can build a career doing that. I kid you not.

向け - 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.