Frederick Vanbrabant's
delirious rantings

The last weeks I’ve been focusing a lot on the data and information models in our architecture. Organizations have so much data flowing around that it’s hard to effectively map it all out. That’s a shame because there are some very valuable learnings to be had from that data.

That’s why I wrote this post; it’s mainly to gather my current thoughts on this topic. Might as well share it with you. It’s a combination of techniques I’ve done at previous organizations (things I know work) and things I’ve been thinking about for a long time now (things that might work). So this isn’t a full-on manual, more a collection of current thoughts. I hope that makes sense.

I’ve been reading a lot of strategy books these last weeks ¹ (also two James Bond books, but that is probably not related to this post), and I’ve been trying to tie it to my everyday work of enterprise architecture. 

Most of these posts are just me finding an excuse to put my thoughts to paper to see if they make sense, so why not write a new post about what I’ve learned? It’s also a perfect time, with the end of the year approaching, to maybe reflect on the next year and how we can tackle it.

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.

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.

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?