Apple is not a company where general managers oversee managers; rather, it is a company where experts lead experts. The assumption is that it’s easier to train an expert to manage well than to train a manager to be an expert.
Something I have to keep reminding people of: “Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem.”
The nice part of working on open source is I can finally share some of the amazing work my team has been doing. Here’s some forthcoming Suricata contributions by Sascha and Frank with more on the way.
Once we expect leadership to come from everybody at work, engineers don’t have to switch to management anymore to be able to lead and be rewarded for it.
“I am successful if I’m saying the right “No”s to my manager. If the ICs that report to my manager end up feeling like “I told you so”or “We knew this was a bad idea”and that wasn’t surfaced for a discussion, that’s on me.”
Something to remember when embarking on a journey to improve large and complex systems of humans and technology: small changes can make big a difference and afterwards nobody will really remember how bad things were.
You may find yourself suddenly leading a project as an IC and if that is the case, please take this guide by Gergely Orosz with you. It will prove very helpful.
An uncannily thorough treatment of why DARPA works and how you might go about replicating it. Maybe people at the European policy level should read this instead of trying all these initiatives where everything good dies in a committee.
“Viele Unternehmen sehen zu viele theoretische Risiken statt einfach zu vertrauen, dass Menschen grundsätzlich mit Freiheiten verantwortungsvoll umgehen.”
Talking with people about their career and professional development options is one of my active areas of improvement at the moment. If I’m generous I’d say I’m at level 2.
I love the examples in this bit about great engineering cultures: teamwork as default, quality is personal, results driven meetings & retrospectives are fun
There are the leaders that — like samurai — embrace death. They see their role as protecting and empowering the people below them who do the real work and it’s an honor to serve the team’s interests even if things do not go well for them personally.
Remember that in any organisation, people make decisions — decisions are about trade-offs, and decisions can be influenced, overturned, and changed. More importantly, organisations evolve— the way decisions were made yesterday might not be the way they get made tomorrow!
Edge C2 is a nice ideal position to move towards in this article about military agility that contains a bunch of useful elements including an interlinked OODA loop and a visualization of the Trust Equation.
As a bystander you can observe a retrospective and hope to see some of these symptoms listed by Adrian Howard of a good one. But keep in mind that you should be happy to hit some of these and getting all of them right probably means you have reached the summum of team work.
Not just one thing that every dev should know but a bag full of hard won non-technical multipliers that will improve all of your interactions in this podcast episode with Jesica Kerr.
A good definition of product judgement which is absolutely essential for project success. I’ve seen groups without this head off in the wrong direction too often to count and have usually had to jump in myself.
Companies insisting on long hours is probably only one thing holding women back, but this article goes deep on that one question and uncovers a panoply of assumptions and attitudes.
“When people say that telecommuting isn’t as efficient or as effective as working co-located, it’s probably because they don’t know how to do it well, not because it’s not doable. The thing is, it’s all learnable if people want to learn it. And I’d say it’s important to learn. Even before coronavirus, I’ve always felt that knowing how to manage well remotely was a competitive advantage.”
“The piece of advice that I give to new managers—and this sounds simple but it’s really hard—is you have to really listen to your people. They are telling you what they want, and you have to hear it. At the end of the day, it’s not about you. It’s what this human is telling you.”
“The best engineers can toggle back and forth between manager and IC roles. Make sure your technical foundation and fundamental skills are solid enough to pull that off.”
It’s not that often that you see a guide how to hire engineering managers, let alone people at the DirEng/VPE level. That makes this guide by Rushab Doshi rare and useful.
You are indeed probably not communicating enough. My advice is to just communicate more. If you are communicating too much (highly unlikely that you would reach that point), people will let you know.
Not surprisingly I agree with these reasons to do give management a try. It can be a very rewarding thing for the right person at the right place/time.
The difference between peacetime and wartime productivity is when things are so explosive and all your systems break down and when you get out the other side everything is changed. It’s an essential and very educational mode.
A good summary of Grove’s High Output Management and a strong argument to read it: “To paraphrase the book, the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions.”