Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.
This is indeed almost always leadership you need in your organization. An engineer who want to manage, maybe be careful about their skills and motives.
A bit shallow, but there's good advice to get started. Very often the quality of the communication medium is underestimated.
Good tips for time management indeed. I apply some of those but think I will borrow some extras from this article.
Nice little exercise to quickly figure out if the skillset of a team properly matches their project.
If you spend your time in dull meetings and then run like a headless chicken... it's definitely a sign you should cut down on the meetings and keep only the ones focusing on solving actual problems.
It's indeed a vicious circle. Also it seems easy to fall into this particular trap, I see it in many places.
This is indeed a very good way to approach planning. You shouldn't be shackled to a too detailed strategy. The broad goals are the real value, then it's about seizing opportunities to advance your position.
Interesting way to frame the question for leadership roles.
Interesting tips to reduce the power dynamics in organisations.
It's indeed not easy to go from individual contributions, to team level leadership, to organisation level leadership. Many things need to be learned or relearned at each step.
There's clearly a tension on that topic and the expectations from engineering managers tend to change over time. I like the proposed answer here and the distinction made between writing code and being in the code.
The proposed three traits are definitely spot on. Too much confidence is a red flag, some balance needs to be found.
A couple of interesting ideas. This fluid focus concept definitely require communication around it when applied.
Interesting exploration on the difficulties to switch a team to XP. I'm not fully aligned with some of the fine details pointed there... That said there is a core truth that "XP is about social change" so if you mandate it as a managerial decision it can't be XP anymore.
Interesting ideas about leadership lacking in impact. Indeed it should be seen as a communal function, it's not about individuals leading each in their own directions. Think about it in a systemic way.
Good points, this is indeed often where we are struggling when we move to a leadership role. This changes the nature of the work at least in part and we need to adjust to it.
Nice example of organization to foster more autonomy and ownership in engineering teams. Clearly needs to be adapted to the project context but gives quite a few ideas. It strikes a nice balance at keeping both an individual and a team view of the responsibilities.
Interesting tips to keep learning on the technical side of the job as you get more managerial responsibilities.
A bit biased toward stable product teams only. Still, there are good tips which are more widely applicable here. This gives a good idea of the management of a distributed team of remote workers.