thewanisdown

I know this isn't new information, but lately I've seen a lot of people here lamenting the lack of Build Volume support in Docker, when it's been supported since Feb 2019 (albeit "experimentally").

Hopefully this can help a few of you speed up your build pipelines.

It does, now. The whole build system was uprooted with the change from legacy build to buildkit. One of the current "experimental" features is build volumes.

Look at Crucial Conversations. Don't take it as gospel, but it's a good starting point.

Stick to facts. Clearly state your expectation, and show how they are not meeting that expectation. Then place the ball firmly in their court. The goal is not fixing the issue for them, but getting them to take responsibility for fixing it themselves.

Refrain from creating a "shit sandwich" by putting the critique in the middle of praise. That makes the conversation ineffective. These conversations are never fun, but they are important to have, and you eventually get used to it.

In most cases, the majority of my customer engagement is early in the process. Lots of discussion up front to inform the development. It tapers off through the iterations.

Traditional "feedback" only goes so far. Most customers don't actually know what they want. I spend the most engagement time discovering their process and pain points in order to help them figure that part out. Isolate one (or a few) customers that will regularly participate and provide high-quality feedback and focus your relationship building on them.

The feedback of the masses is more like an (unreliable) compass.

Start practicing CYA (Cover Your Ass) diligently. Follow all of the rules, document everything (email follow ups for any any conversation), and be tactful at all times. Give him no space to find fault, and have proof. Discuss your concerns with HR if you can.

Personally, I would be looking for an exit, either mine or his.

I don't believe they are inconsistent, but I also have the advantage of knowing my own life intimately. I suppose the context makes a difference.

There are very few "rules" in this game, so feel free to manage differently. You have 100+ on your team, so I'm sure your methods worked well for you, as mine have for me.

You seem to be taking something about this thread very personally. I'm sorry for that. I hope you have a good day.

With regards to the military, good leadership works in any organization. I do not speak to my engineers the way I would speak to a platoon, but I lead them the same.

Quite a few years running teams up to 300, now about 3000.

DNA evidence works well.

In all seriousness, I recommend not referring to them as "reports" at all. Call them "My Team", "us", "we". It creates a sense of collective ownership.

When talking up, I use specific names, or "the team" to reference tasks or successes, and "I" when we talk about failures. I own what goes wrong, they own what goes right.

Holdover from the military. I can see you're framing it as "beneath", which would be very inappropriate, but it references "under your charge". Thanks for pointing out that it could be misconstrued.

I am sorry to hear you have not enjoyed your time leading a large group. It certainly has its challenges, but I assure you it can be quite fun and rewarding.

Fortune 500 companies are held together by paperclips, bubblegum, and a whole lot of wishful thinking.

Sometimes metaphorically, sometimes literally.

It's a different mindset, but I still think it's fun. For me, the key with that size of a group was focusing on the development of the leaders under me. When I make sure they are set up for success, things go smoothly.

The hardest time in my life was trying to micromanage a large group. Once you let go, and focus on the bigger picture, it's quite fun. Challenging, for sure, but very fun.

We have an internal website with user-maintained groups/content. Every week, you get an email with major updates from the teams you want based on the important information they've been telling themselves. That's been useful for culling and focusing the information flow to each person.

In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.

That sounds like managers who haven't been trained.

Leadership is a skill like any other. You can't just promote someone into it. They have to be trained for it.

If it's what you like. You'll be just fine.

In the grand scheme of things, that degree just opens a few extra doors early in your career. It's still up to you, and your personal drive to succeed, to get anywhere past that.

You have passion, and that is a massive advantage. Stoke the fire.

Extreme Ownership https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs-eboo...

How to Win Friends and Influence People https://www.amazon.com/How-Win-Friends-Influence-People-eboo...

The Phoenix Project https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

Don't worry about "tech specific". Core leadership principles are universal. The first two books on the list show the principles, and the mindset you should approach them with to be successful.

The 3rd book will help set the tone for leading in a modern tech environment, and what kind of business decisions you should prioritize.

We treat technical debt the same as any other issue. Put an issue on the board, decide on timing, assign it to a release, etc. I think the problem for some is that they don't realize they are creating technical debt.

The core trade-off is "what does the business need now" vs "what are the long term goals". I only consider the technical debt that will block us in the future.

At any given decision point, you need to understand when technical debt is accrued and track it like any other issue. If you don't actively acknowledge technical debt from the onset, you place your business goals at risk.

In general, I see that the most politically charged projects are also accruing the most technical debt. They have high pressure, short time-frames, and scope creep out the wazoo. Those take the most of my time, and are extremely prone to failure unless there's a human shield to keep the heat off.