What are the most important things to keep in mind when giving feedback to a mentee in Systems Design?

Think about how input data to the system could be invalid, out of range or failed, and include protections against those in the system requirements.

The steps and techniques in systems design can appear very cumbersome, obtuse, and needlessly detailed. So I would say the most important first step is to offer the mentee the big picture. At the end of all these details, what will be achieved? What's the point of this? I've had the experience where, before joining, people did what they were told, but had no understanding of why it is so important, so they just did it half-heartedly as if it was on the side of what their real work was. But once they understood how fundamental it is, they have now integrated it in every aspect of their work.

I make it a priority to start by clarifying the goals of the project or task at hand. Having clearly defined objectives helps the mentee understand the purpose of their work and align their efforts with the overarching vision. This ensures that both mentor and mentee share a common understanding of goals, making the feedback more contextual and pertinent to the specific objectives of the design project.

As a System Designer we have to understand the business requirements first based on that only need to take the further decision.

When doing tradeoff, do not only focus the benefit the system brings , but also think about the cost if it goes wrong. Just like the saying from an old Boeing guy "not only what it can do for you, but also what it can do to you."

We system designers tend to fall in love with our creation, especially when the problem solved is tough. Encourage an understanding not only of the problem the system is solving, but the motivation of the end-users relative to the system in their daily lives. Someone putting on a headset to enter the metaverse in search of a specific experience is a very captive audience and motivated to explore the system. Someone punching the clock, with system usage constituting just a fraction of their job, has a very different motivation. Make sure to understand the personae not just in terms of their skills, education, etc., but also consider where your system, your beautiful, beautiful system, ranks among their priorities at any given moment.

Without the why, it's just criticism, not mentorship. My best mentors are full of insight into things that I cannot see yet, as I have not yet gone through the following situation, or I am not involved in a higher level meeting that would change my perspective. Mentors are a cheat code into the insight that they share.

Be Specific and Concrete: Provide specific examples to illustrate your feedback. This makes it easier for the mentee to understand the areas that need improvement or the aspects they have excelled in. Focus on Objectives and Goals: Align your feedback with the goals and objectives of the systems design project. This helps the mentee understand how their work contributes to the overall success of the project. Consider the Design Principles: Evaluate the design based on established principles such as modularity, scalability, maintainability, and performance. Help the mentee understand how their design aligns with these principles and suggest improvements accordingly.

While focusing on why, keep in mind : - The End Goal i.e. what it would add value to the customers and do I have clarity regarding the same. - Work Backwards i.e. once you have the clarity work backwards towards Tech Architecture keeping in mind scalability, fault tolerance and latency.

Emphasizing the "why" in feedback is crucial in systems design mentoring because in my experience, I believe this is the point where you can make a key difference in the learning curve of your mentee. It empowers them to understand the underlying principles, fostering a deeper comprehension of the decision-making process. This approach not only imparts knowledge but also encourages critical thinking and adaptability, which is really important in navigating the ever evolving landscape of systems architecture.

My general advice is when seeking for a solution to a problem - always come up with three ideas. Maybe you can probe all three, at least reflect and discuss all three ideas, then settle for one. However, the secret is to evaluate your decision later and be open to correct it.

The Best Way is involve your mentee in actual systems design projects where they can actively explore and compare different alternatives as part of the design process. This provides practical experience and reinforces the importance of considering multiple options.

Encouraging alternatives is essential to fostering true solution-independence, again one of the key principles of Systems Design. When the Mentee focuses on alternatives, it keeps them thinking about the vastness of the Solution Space, and the importance of not needlessly restricting it. Two radically different solutions may fulfill the same set of requirements, and that's great. What often happens is the System Design corresponds to an existing solution, often lifted straight from a vendor spec. Or, when 2-3 solutions are given, only one is realistic. This is unhelpful. You want your alternatives there as a get-out-of-jail card when you chosen System Design fails.

Die Frage nach den Alternativen hilft es zu vermeiden, dass man sich an einer L?sung festmacht. Selbst wenn diese eine gute L?sung ist, sollte man sich klar machen, es ist nur eine der m?glichen L?sungen.

Encourage your mentee to delve into diverse design options, urging them to analyze the merits and drawbacks of each. Prompt them to provide reasoned justifications for their choices and underlying assumptions, fostering a thoughtful approach to decision-making.

I disagree with this to an extent. If one is constantly critiquing a mentee's work, then the mentee cannot grow. The mentor is better off showing an approach and allowing the Mentee to work through it themselves.

Because Systems Design is such a large and blunt instrument, it could be easy to get discouraged. The Mentee has never seen a full development cycle, and they don't see how missing key details can make them pay dearly later. So I would say the feedback needs to be multipronged: 1. Course-correct early and often, learning by doing is a bad idea. Review each step and correct it immediately 2. Let the Mentee review your work. Reviewing others' work is essential to learning. They may also find flaws in your own work. All work needs reviewing, so letting the Mentee review your work makes the Mentee more open to having their work reviewed 3. Focus on explaining the bigger picture when correcting the Mentee's work.

Offering specific and actionable feedback is crucial because it provides clear guidance that mentees can understand and implement. Specific feedback highlights particular aspects of their work, making it easier for them to identify areas for improvement. Actionable feedback goes a step further by suggesting concrete steps or changes that the mentee can take to enhance their performance.

Understand where they are at in their progression of learning and also ensure that they know there are several ways to design systems and come up with the same end result. Stay away from manufacture based design, instead go with resolution based design.

Il est important de prendre en considération la rapide évolution technologique, avec de nouvelles propositions émergeant chaque année. Ainsi, il est recommandé d'établir une feuille de route évolutive afin de rester constamment à jour.

Failures are stepping stones to success and during the early phase of career, mentees need to learn to accept their mistakes, learn from these and improve. Learning process is gradual and hence every mentee should grow at their own pace of learning and avoid comparison with others.

The hardest thing to teach someone is to think "outside of the box". However, there are some things you can do to encourage this type of thinking. Encourage people to document all of their bug fixes. When the find an error, document the fix. When people are thinking about how things work they are much more likely to have creative solutions to future integrations!

I think the most important part of training someone in Systems Design is to make clear that this isn't a skill they are learning for their job, but a skill they are learning for the rest of their career, and applies well beyond just work. For instance the Mentee may buy a house one day, making them a System stakeholder. They may decide to become an Architect. They may have some complex problem in their private life and the complexity management aspect in Systems Design may be that crucial skill that gets them unlocked and empowered. What's really important is to show how all these skills in Systems Design are highly cross-compatible.

I think the most important thing to try to share with any mentee or a junior colleague is that a System is not a goal on its own, but a means to an end. So any good system design starts first by understanding the problem, the tradeoffs and the boundary conditions. So they need to learn that before starting architecting the solution, they should be sure they understand the goal it required and the acceptable cost to achieve it. Followed as a good second is to always try to streamline and simplify the system. An extremely complex system sounds cool, but is never a reliable one. A good reliable system should only be as complex as it’s needed. If it’s not simple enough they need to go back to the first part about understanding the problem.

Need to emphasise the importance of considering real-world constraints in their design. This includes factors like budget limitations, time constraints, and available technology stack. Discussing these constraints will help your mentee create a more practical and feasible design. And also highlighting the significance of security and privacy considerations in system design. Discuss about encryption, access controls, and other security measures that should be integrated into the design to safeguard sensitive data and ensure compliance with relevant regulations.

I think the mindset to adapt and evolve is also important. Let's say the initial assumptions have changed. It is important to acknowledge and accept that under the new requirements the existing design might not survive and the only way to fix is to discard the whole approach and go back to the drawing board. I see people getting stuck at this stage and not able to go forward or even back. In short, embrace growth mindset, celebrate iterations, value failures.

Wichtig ist der Respekt und die Person als solches. Und als solche ist aber auch klar, dass nicht jeder für alles ein H?ndchen hat. Es gibt immer Dinge, die andere besser k?nnen. Das heisst: Akzeptiere Deine M?glichkeiten, Deine Interessen, Deine Limitierungen. Manche davon sind von aussen gegeben, aber andere eben eigene. Aber es muss da schon zusammenpassen, um wirklich gut zu funktionieren. Sich selber oder anderen etwas vormachen ist nicht hilfreich.

The paradoxical, yet incredibly common, mistake is to start with solutions before even having a clear understanding of the problem. Effectiveness and client-centricity only exist if we step out of our comfort zone and reflect on the problem, no matter how uncomfortable it may seem, and only then do we seek possible solutions.