Frederick Vanbrabant's
delirious rantings

Communication for team leaders - Ownership

And we’ve come to the last post in the series of “communication for team leaders.” This one is about ownership.

You can find the other posts here.

• https://frederickvanbrabant.com/blog/2024-10-11-communication-for-team-leaders-context/
• https://frederickvanbrabant.com/blog/2024-10-31-communication-for-team-leaders-trust/

And these posts are based on a part of my talk, “I just became a team lead, now what” (https://www.youtube.com/watch?v=oWtSbTded0o).

The red line in these posts

A smart reader like you has probably found the pattern in these posts; they all have a focus on keeping people engaged and motivated. This is a very important part of leadership. If you can’t motivate your people to stand behind their work, you will never get good results. At best you will get passable work; at worst you will get an open vacancy.

Communication for team leaders - Context

This will be the first post in a series of three called “Communication for Team Leaders”. The first focuses on context and why it’s crucial in daily communication and task-giving.

These posts are based on a part of my talk, “I just became a team lead, now what” (https://www.youtube.com/watch?v=oWtSbTded0o).

You can have a fantastic team of subject matter experts and brilliant technical people, but if they don’t talk to each other, you will never get a good product or outcome for a project. I don’t think this is a new statement. Soft skills have been a focus of conference talks for a while now. We keep talking about empathy and how we bring messages, yet I haven’t seen a lot of practicality in those talks, and as a result, the adoption in companies is fairly low. I hope I can bring some practicality to this topic with these posts.

I think we should reimagine how we see architecture principles

To me, it always seems strange that in a world that thrives on innovation and constant change, every architectural department tries to implement a rigid set of principles that stay in place for years.

From software design patterns (think SOLID, DRY, …) to the more strategic layer (think TOGAF, PRINCE2, …), these principles seem to have been around forever. Is anything really timeless and forever the same?

Architecture in an agile world

Before we start talking about architecture, it’s a good idea to lay out the foundation of this discussion first. I know there are a million articles about agile and how it will all save us from certain doom and is a money-making machine, but let’s stop the marketing drive for a second and have an honest look at it.

The Goldilocks strategy: Finding 'Just Right' in Good, Fast, and Cheap

Picture this: it’s a Tuesday afternoon. You are called into a meeting room by your teamlead. He’s conversing with a client about a big new project they want to develop. After a bit of an introduction about the scope and features of the project, a very unrealistic deadline is proposed. Not only that, but you know from the past that this client has the reputation of having a very limited budget, so the amount of people that would work on the project would be a skeleton crew.