What is the role of authority in the function of getting things done?

I bought a book about this 10 years ago, so these aren't new challenges. I can't remember a single thing from the book. When I looked at it on Amazon, it was more about project management and Agile. I am talking about decision-making and the mindsets within an organization. But I know why a PM would write a book about this, so maybe I should reread it.

There is thinking (in tech at least) that titles shouldn't matter. If you can make a case for what you are trying to get done, you should be able to accomplish what you need. Anyone who has tried this knows that results are less predictable.

Other factors in the equation include the other party's willingness to change and the time needed to build a cohesive case. The easy answer is, "Just be really persuasive" (A.B.P.).

But crafting a long, persuasive argument isn't always feasible. And it doesn't win against someone who has an investment in the status quo.

The answer is something like: you have to cultivate your persuasiveness. Then you make your best effort; if you lack the authority, be prepared to let it go when things don't go your way. This is hard to do.

If you have the authority, you can tell people to do it your way. Sometimes, that's how it has to work, and you take the lumps when you are wrong. This is especially true if you are incompetent. Eventually, incompetence will catch up with you, no matter how persuasive you are.

The challenge of authority is that when you make people do something, regardless of the result, some resent you or half-ass it. Those people are hard to work with, especially when you are competent. When you are incompetent, the whole lot of you are probably hard to work with.

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.