Startups and small organizations often invite people to have multiple roles. Sometimes they may even conflict with one another. Take Marc, for example, years ago he started establishing an agile process in his organization. Leading that process his role was to support individuals in their effort to achieve their objectives. Since then, his position has changed. He had gained more responsibilities and eventually a leadership position.

He now found himself in a position within the agile process asking him to keep a neutral position. One helping team members do their work. At the same time, he was in a leadership position asking him to have an opinion and decide on the tasks his team has to achieve.

He realized that in one-on-one conversations these roles were contradicting one another. Even more so, when the other person felt strongly about their technical competence and desire to stay in control of their work. These situations made it difficult to integrate business objectives with technical objectives. Such situations come up, for example, when major redesigns of a product have to be decided. It is a situation with little clarity. The consequences of decisions on work and return on investment can’t be easily defined and a lot of guesswork is involved.

For Marc, this meant starting by finding a way to deal with the different priorities in his respective roles whenever meeting with team members individually to work on the design process. He settled on a process that would be carried by a vision of the deliverables for the first version of their new product. His vision would ease distinguishing between business objectives and technical feasibility. Marc had to frame the business objectives before meetings. During the meeting, his task was to facilitate the discussion with his team members to develop a technical implementation.

This allowed Marc to slowly move from the main vision into a variety of subtasks without being the one defining the technical aspects. He would use his leadership role to frame the conversation. One that gave him a reference point for the outcome of the meeting. Within the meeting, he would step into a support role to assist his team member in developing his vision of the technical design of the product.

This approach allowed Marc to use his leadership role to establish guardrails for the meeting. Leaving him the space to step into his support role during the meeting.

It still asked Marc to remain aware of the differences in roles, responsibilities, and tasks. Which also meant keeping others aware of the different roles during the facilitation process. By defining when what role would be active, he gave himself an orientation. One allowing himself to see the territory he had to master and the one they would explore together.