why?

git init // the origin story

Engineering management is broken.

It’s the typical engineer story. We push through what is arguably one of the hardest degree programs. Late nights cramming equations and formulas, optimizing speed and complexity, and learning to read technical docs. Soft skills? Ain’t nobody got time for that. I took one psychology class in college — and only because I had to.

Then, when you get to the point in your career where you’re thinking about leading a team, helping make higher level decisions, and growing beyond engineering, what do you do? If you’re like most people, you fumble along for the first few years figuring things out on your own, and eventually you somewhat get a handle on things. If you’re lucky, like I was, you’re given the freedom to experiment and learn from your own mistakes. But if not?

Who is teaching engineers how to be managers?

I’ve spent the last six years becoming a better engineer while learning valuable management lessons, now leading two global teams of 20+ engineers.

I made every mistake you can name. Micromanaged? Check. Failed to delegate? Absolutely. Procrastinated? Every week.

But I learned. I learned new things about myself, learned how to motivate a team, and learned what type of leadership style best fits me.

While I was thankful to have mentors, what I longed for was someone else who was going through what I was going through. Someone to share the experience with, ask questions, and brainstorm.

That’s why I started this newsletter. Each week I’ll bring you one nugget that you can use to learn what management might look like from your engineering perspective. If you reply with questions, I’ll respond.

It’s time to stop waving management off as something you learn on the job.

It’s time you learn for the job.

-Vigs

P.S. I’m committing to at least one git pun in every email. Too many management newsletters are dry and boring. Let’s revert that.

Reply

or to participate.