A colleague handles a difficult review well. They explain the disagreement, ask a question that reveals the missing assumption, and help the group reach a decision. You may want to become better at that kind of work without wanting the colleague’s job, personality, or entire career.
That is a useful starting point for a role model. A specific example can make a capability visible and suggest something to practise. Inspiration can matter too: seeing someone do work you value may help you consider a goal you had not thought attainable.
The next step is to examine what the example can reasonably teach. A successful outcome does not reveal every cause behind it, and a method used by one person may depend on authority, experience, or circumstances you do not share. Role models support development when admiration leads to enquiry, practice, and an assessment of what transfers.
Identify the Capability Rather Than Copy the Person
Consider an engineer preparing to take more responsibility for design discussions. They admire a senior colleague who can explain technical trade-offs and obtain decisions across teams. The useful goal might be to develop clearer design proposals or handle questions more effectively.
Those are more actionable aims than becoming like the colleague. A person can be strong in one area and less useful as an example in another. Their communication method may be worth studying even if you would not choose their working hours or management approach.
The motivational theory of role modelling proposed by Morgenroth, Ryan, and Peters considers functions including demonstrating behaviour, representing what is possible, and inspiring goals. It is a theoretical framework for understanding influence, not a guarantee that selecting a role model produces a particular career result.
For the engineer, separate those functions. A public technical leader might make a career direction seem possible. A nearby colleague might provide examples of preparing a review. A mentor might offer direct feedback on an early attempt. The same person can serve several roles, but none has to do all of them.
Be clear about what you want to learn now. A narrow goal gives you a way to select examples and assess progress. It can also make a request for help easier to answer: asking how someone prepares a consequential design review is more specific than asking them to explain how to become successful.
Look for Reasoning, Including What the Example Does Not Show
Observation can reveal useful practice. The senior colleague may distinguish a decision from an update, circulate alternatives in advance, or explain a trade-off through a concrete case. Note what they do and what response follows.
Avoid assuming that the visible action caused the whole result. The colleague may already hold relevant authority, have built trust over time, or be discussing a proposal whose main choices were settled earlier. Those conditions can affect how the same approach would work for someone else.
Ask about preparation where an appropriate opportunity exists. What question were they trying to resolve? Which alternatives were considered? What information changed the proposal? What would they have done if the group remained divided?
A retrospective explanation is also partial. People may remember some influences more clearly than others, and a successful story can make a path appear more deliberate than it was. Treat the account as useful evidence to compare with observation, rather than a complete causal history.
Public examples have limits but can still help. A talk, paper, recorded discussion, or worked case can expose reasoning that is not available through a local colleague. Its distance does not make it worthless. The important issue is what is actually shown and how relevant it is to your goal.
Similarly, proximity does not guarantee a good model. A colleague may achieve a result through authority or conduct you should not imitate. Evaluate the method and its consequences, including what other participants experienced, rather than treating local success as automatic evidence of sound practice.
Compare the Conditions Before Adopting the Method
A senior engineer may be able to stop a release or commit specialist time. A less experienced colleague may need to raise the same concern through another owner. Copying the action without accounting for that difference can create confusion or exceed the person’s remit.
Identify what the method requires. Does it depend on a particular skill, access to information, permission, or support from another team? Which parts are available to you, and which require preparation or approval?
For the design review, you may be able to improve the problem statement and compare options immediately. You may need support to assess a security implication or obtain a resource commitment. The development plan should distinguish those tasks instead of interpreting every limitation as a lack of confidence.
The goal itself deserves examination. You may admire a visible leadership role while preferring the technical work that the person now does less often. Ask what the role involves routinely, what trade-offs it creates, and whether those responsibilities match what you want to develop.
Success can also depend on opportunity and timing. A career move that worked in a growing team may not be available in the same form elsewhere. The example can still reveal useful skills without providing a repeatable sequence of promotions.
This is one reason to compare several accounts. If people reached similar responsibilities through different routes, the variation may reveal which capabilities are broadly useful and which conditions were specific to one path. Development should remain open to that variation rather than become a test of loyalty to a single person’s story.
Use Several Models and Keep Your Own Judgement
Different people can demonstrate different strengths. One colleague may prepare rigorous analysis, another explain uncertainty clearly, and another help less experienced staff contribute. Combining relevant examples can provide a broader basis for learning than adopting one person as an ideal.
Research has also examined perceived attainability. Gartzia and colleagues’ field and experimental work investigated motivational effects of attainable role models. Its findings support considering how a model is perceived, rather than assuming that greater fame or achievement always provides more motivation.
Attainability should not become a rigid rule that a model must share your background or immediate environment. Different experiences can expand what you consider possible and reveal approaches absent from your current setting. The question is which connection helps you understand a next step.
You can also learn from an example you decide not to follow. Observing an avoidable conflict or an unsustainable workload can clarify the kind of practice you want to develop. Keep that assessment specific and fair, recognising that you may not see all the circumstances.
A mentor relationship requires agreement about participation. An admired colleague is not automatically available to coach, review work, or sponsor a promotion. Make a bounded request and respect the answer. A short conversation about one decision may be useful without becoming a formal mentoring arrangement.
Professional conversations can help you gather these perspectives. Their value lies in what you learn and how accurately you interpret it, not the status of the contact or the number of people who agree to speak with you.
Turn the Observation Into Practice and Feedback
The engineer might choose one change for the next design review: state the decision required, present two feasible alternatives, and make the remaining uncertainty explicit. That is a practice they can carry out and examine.
Before the review, ask a suitable colleague to assess the proposal against the intended purpose. After it, consider whether participants understood the choice, whether necessary questions emerged, and whether the result reached the implementation plan. Feedback should concern the work rather than whether you sounded like the role model.
An observable improvement can be modest. The next review might reveal an important dependency earlier, even if the group still needs another decision before proceeding. That can represent progress in preparation without proving that the whole method is effective. Compare the result with the question you intended to improve and ask what should be retained or changed.
This helps avoid turning development into a performance of resemblance. A useful method may work in your own voice and need different preparation from the model’s visible approach. The evidence concerns whether the work improved, not whether the imitation looked convincing.
A first attempt may be imperfect. Identify whether the difficulty concerned preparation, technical knowledge, facilitation, or decision authority. Those explanations suggest different next steps. Repeating the visible behaviour more confidently may not address the cause.
Keep a proportionate record of what you tried and learned. A short note can help you compare approaches over time. Development need not be reduced to a numerical score, but it benefits from evidence more specific than feeling inspired.
Progress also depends on opportunity. A manager can help by providing appropriate tasks, access to feedback, and support as responsibility increases. An employee should not have to perform a role indefinitely without the authority or recognition needed to sustain it.
Review the model as your goals change. A practice useful when learning to contribute may need adaptation when you are responsible for others’ participation. The person who first inspired you can remain valuable without defining every later stage of your development.
Role models matter because they can make a possibility or practice easier to see. Their value grows when you examine the reasoning, compare the circumstances, and test a relevant method in your own work. The outcome is a more informed way to develop your judgement, while retaining responsibility for the choices you make and the effects they have on others.
