I just talked with a very good friend working as Senior Engineer about what I would recommend him to learn as the next steps.

He is quite a product-mindset person. He is genuinely interested in why we do things from a customer perspective.

So, next steps? ...

1/13 To have a more significant impact on the products, I suggested learning about:

- Fast Flow of Change with @TeamTopologies
- Situational Awareness with #WardleyMapping
- Domain Modelling to support Fast Flow of Change with #DDDesign

2/13

1/ One thing I share with the people is about the _dimensions of decision and influence_ and why it's important to at least have _two dimensions_ of influence

Let's see a technical leadership position you have:

- People dimension
- Technology dimension

Nomenclature might vary 2/ Definitions:

⚠️ This varies between companies. I'm oversimplifying the definitions!

- People Dimension: Managers
A role dedicated to people management, growing people, managing expectations, and alignments.

The area of influence is people's behavior and expectations

1/ Side Project C started 🚀

It came after understanding the paradigm shift from Organizing teams, where we see a tendency toward @TeamTopologies, #DDD, and #DynamicReteaming as new emerging practices vs the old paradigm. 2/ With a higher #TeamTopologies adoption, it creates new sorts of needs for managers.

Needs that I'm currently facing and I'm currently solving with Excel files to gather team's feedback and improve my organization sensing

1/ Thread with the material I'm using to learn about #WardleyMapping 🗺🧭

I discovered about Warley Mapping when I went to @ddd_eu in 2018 and Simon was presenting the next talk 👇

@ddd_eu 2/ During the same conference, I attended the open discussion with Dave Snowden, Andra Sonea, and Simon Wardley.

I was amazed at how they were able to communicate complexity. Yet, I was so far into understanding the concepts!

1/ I cannot stress enough the importance of junior people in the organization

I'm amazed by how much you learn when working with them. They really show where the organization/team can do better. It can be uncomfortable because they are sharing your weaknesses 2/ Don't think that they should know better to do the job, but why do we create a place where juniors cannot contribute or they have a hard time providing value? What can we do better to help them perform and learn faster?

1/ I'm doing some reflection on how #DDD can help you spot a Platform as a Product Team from @TeamTopologies wrongly applied 2/ Indeed, I think we created a Platform Team because the intention was to reduce cognitive load on teams on a specific part.

BUT, on the recent learnings, we think it might be a Bounded Context by itself, a Supporting Subdomain at least.

1/ "We expect that anything can happen and we are never prepared for anything"

This sentence resonated a lot with me

Regardless of the risk management, regardless of being adaptative, regardless of how prepared do you think you're, World keeps surprising you 2/ As a manager, your job is to make the teams, product, and business more resilient and adaptative to survive in several situations.

Yet, I never felt that we reached a level where we can say

"We're safe!"

It's not viable.

1/ We have been debating with some colleagues about the importance of learning about our decisions within the organization, and how the fast rotation of talent that's happening lately is affecting the decision-making outcomes quality. 2/ Here we had the supposition that the feedback cycle between a decision is made and understanding the consequences are long enough. We always thrive for fast feedback loops, yet we acknowledge that that's not always possible.

1/ When you start doing project development, you find yourself with tight deadlines, a lot of tradeoffs in quality, and money spend.

You start feeling that you might be doing something wrongly. You feel that you're not delivering business value

Thread 🧵 2/ You learn about Agile, and why deliver working software as soon as possible. You adopt Scrum, but with a project mindset. So, it's a fake Scrum. It's more like a 2 weeks waterfall.

Yet you adopt a very important ceremony important, the Retrospective.

I share this diagram with other leaders a lot.

It shows that a team goes in different phases and so your leadership style should do.

It's a common mistake to give autonomy to a team that needs direction. I explain the leadership style depending on the team state

Thread 🧵👇 The diagram is based on Elastic Leadership: Growing Self-Organizing Teams.

A 100% recommended book for anyone in a leadership position.

Attached link 🔗
amzn.to/3Gr2TCT

We have been practicing #NoEstimates for 8 months. Here are some learnings 👇 We started in a legacy code in which the people that created that service left the company some months ago and we needed to deliver some critical features

No business knowledge, no technical knowledge, a mess ahead

Business: Will you be on time?
Me: No clue yet, give me 2 weeks

I got this situation for Lead Time of 4 Key Metrics when a requirement involves two different teams and how to use the 4KM more effectively

The situation is a requirement for a customer that requires two different systems and therefore two teams. How would you measure here the Lead Time when one team takes longer than the other?

Do you consider Team B Lead Time to be 5 or 10 days? Measuring one way or the other opens different ways to manage work.

I don't add "it depends" option because I know it always depends 😜