Blog Alexis Monville (en)

Tag: team

  • Time matter for a team

    Time matter for a team

    The fact that time matter for a team is not a controversial matter. I think we would all agree on that. The other aspect of time that we will all agree quickly on is that, not all time will matter the same way.

    We will not value an hour stuck in a traffic jam the same way as an hour hiking on a trail, or an hour shopping, or an hour playing with friends, and so on…

    So when it comes to how an individual contribution could be the most effective, what is the time that matters the most?

    When asked, people usually look at three different types of time:

    • Synchronization time,
    • Collaboration time,
    • Focus time.

    Synchronization time

    Synchronization time is when team members share their progress, challenges, learnings, so they all can stay on the same page, aligned toward the same goal.

    During synchronization time, we can identify opportunities for activities that will fall into the two other types of time. It could be an opportunity of collaboration on understanding and solving an issue or a possibility of training in a specific area to take two examples.

    Collaboration time

    Collaboration time is when two or more people work together to accomplish a specific activity. Activities could be different, like pair or mob programming, writing, designing, reviewing, and so on.

    Focus time

    Focus time is when team members work alone, ideally without interruptions so that they can work on one thing in an ideal state. Like writing an article to share knowledge (and initiate a feedback loop that will bring more learning opportunities in return).

    Why it Matters?

    I believe it matters for a team to agree on the practices they will adopt to benefit from the three types of time. Those practices can evolve over time, and as a consequence, their team agreements evolve accordingly.

    The practices vary upon the physical organization of the team. Practices have to be different when the team is collocated in the same room, spread over a building, in multiple offices or locations, spread over multiple timezones.

    A practice that works well for synchronization when the team is collocated, like a quick 10-minute morning check-in in front of a kanban board, will not work when the team is distributed over 15 timezones. In the latter case, synchronization still matters, but another synchronization practice will have to be defined for the team.

    It is the same for the collaboration time and focus time. Practices are different depending on the collocation or distribution of the team. The main aspect is that it has to be defined!

    Do you and your team have defined practices for the three types of time? And what are you preferred practices?

    As usual, please comment, tweet or direct emails! Thank you!

  • Maybe we can love division after all

    Maybe we can love division after all

    One year and a half ago, I noticed that my daughter was using an app to improve her Spanish and her English. Of course, there is an app for that! There are even several apps!

    The one she was using is Duolingo. I decided to give it a try and started learning Spanish from scratch. Over the last year, I observed multiple evolutions of the application meant to motivate people to stick to their practice and continue using the app.

    One evolution they introduced lately is “division”. You start in the “bronze” division. A division is a group of 50 people. Over the week, the first 10 of them will go to the higher division, the “silver” one. Once you reach the “silver” division, the first ten can go up, and the last five are relegated to the lower division. The number of XP (eXperience Points) you gain during the week defines your ranking. You can gain XP by attending a lesson, and how successful you are during lessons.

    Of course, with 300 million learners, you can imagine that there are several “bronze,” “silver,” “gold” divisions running in parallel. But it seems it does not affect the behavior of the learners. I realized quickly my habit of doing three lessons per day got me immediately to the top of the first divisions, but after a few weeks, it was harder to get to the top 10, and I needed to increase my practice. So, it worked… And now, to stay in the current division, I need to do a little bit more than three lessons a day.

    Of course, I am doing it every day to keep my “streak” 🙂 Another incentive to help you keep up with the habit!

    I saw a lot of content management systems that are ranking the top contributors. The problem is that when you are a newcomer, the top is something inaccessible so it cannot motivate you to do anything. The weekly top could also be unreachable, so maybe divisions could solve that problem?

    Why do you want people to contribute, and how useful will be their contributions remain questions you will have to answer.

    How does it work with my learning of Spanish?

    I keep up with the practice, and I was able to understand a lot of things during my last travel to Spain. But I am not yet comfortable enough to speak. Compare to my starting point, the progress is enormous for just a few minutes invested each day.

    So what do you want to learn next?

     

     

     

  • Do Cultural Differences Really Block Agile Adoption?

    Do Cultural Differences Really Block Agile Adoption?

    When agile adoption struggles, cultural differences are often the first explanation that comes up.
    Different countries. Different mindsets. Different ways of working.

    But are cultural differences really the problem?

    In this episode of Le Podcast on Emerging Leadership, I explore this question with Jérôme Bourgeon, an agile coach at Zenika, based in Singapore.

    Looking beyond national culture

    Jérôme and I share a similar conviction: national culture is rarely the real blocker when agile practices fail to take root.

    What we see far more often is that:

    • trust does not yet exist
    • beliefs remain unchallenged
    • and the local company culture works against the change

    Building trust, in particular, can take very different amounts of time depending on context. But that difference is not primarily explained by nationality.

    What really influences agile adoption

    In our conversation, we discuss several elements that have a much stronger influence on agile adoption than country-level culture:

    • Company culture matters more than national culture
      Jérôme refers to Frederic Laloux’s model from Reinventing Organizations to explain how organizational worldviews shape behavior.
    • Beliefs matter more than practices
      What people believe about work, authority, learning, and responsibility has a direct impact on how agile practices are interpreted and adopted.
    • Trust is a prerequisite, not a byproduct
      Without trust, frameworks remain mechanical and fragile.

    Using Appreciative Inquiry to move forward

    We also explore the power of Appreciative Inquiry as a way to approach change differently.

    Rather than focusing on what is broken or missing, Appreciative Inquiry helps teams:

    • build on what already works
    • surface what people care about
    • and create movement without forcing alignment

    This approach is particularly useful when working across perceived differences.

    Accepting meaningful differences

    Not all differences need to be resolved or normalized. Some differences are deeply important to people and deserve to be respected.

    Agile adoption becomes more sustainable when teams can:

    • accept these differences
    • make them visible
    • and design ways of working that acknowledge them

    A final invitation

    If you are working in a multicultural environment or facing resistance to agile adoption, this episode offers a different lens.

    Instead of asking “What culture are we dealing with?”, it invites a more useful question:
    “What beliefs, relationships, and conditions need attention right now?”

    If this topic resonates with you, feel free to reach out and share your experience or propose a question for a future episode. We can even record the answer together.

    Le Podcast – Season Two

    Le Podcast – Season One

  • Team Agreements

    Team Agreements

    In the book, Changing Your Team From The Inside, I touched several times the notion of Team Agreements.

    Team Agreements are critical to the success of a team. By writing your team agreements, you define your standard. You set the baseline that you will improve in the future.

    In the team agreements, you answer the question: How do we behave?

    What aspects do you want to cover in your team agreements?

    How do the team handle information?

    • What kind of information do we need to achieve your work?
    • How do we share the information inside and outside of the team?
    • How do we know what everybody is doing?

    How do the team communicate.

    • What are the tools the team uses to communicate?
      • Phone or video conference: why do we prefer phone calls or video conference for some conversations?
      • Instant messaging: for what kind of message, what time of the day…
      • Email: do we use emails inside the team or do we communicate using the tool we use to track our work? Do we use bcc?
      • Do we always reply to all calendar invitations?
    • When do we want not to be interrupted? How do we signal that to others? How do we handle external interruptions? Do we nominate an interruption handler?

    How do we collaborate.

    • How do we produce documents, code…
    • When do we use pair programming or mob programming?
    • Why do we have meetings? What are their purposes?
    • How do we behave in meetings? How do we handle devices? How strict are we on time? On attendance? On multitasking? On side conversations?

    How do we provide or receive feedback.

    • Do we have a specific time, setup, tools… to provide or receive feedback?

    How do we handle conflict?

    How do we manage performance?

    How do we hire new team members?

    The list of questions could be infinite. The practice is beneficial when you start small and when you review your agreements regularly. This is a place for the team to experiment with various approaches and to improve.

    For example, with a team in which half the people are collocated and the other half distributed all over the world, we change our way of handling meetings. The agreement is now that we behave as if everybody was remote and join the video-conference from our offices. Why are we doing that? Because we noticed that when the conversation become passionate in the meeting room, we were ignoring the “remotees” that were enabled to have a say in the discussion.

    It is also very useful to define team agreements for meetings that will gather people from different teams or organizations. To do that, try the Social Contract, shared on the Open Practice Library.

    Featured image is by

  • Could your team be managing itself?

    Could your team be managing itself?

    I was engaged recently in a passionate conversation ignited by a simple comment: “A team has to be managed.” The comment made me think I wasn’t on the same page as my interlocutor.

    I was discussing the importance of designing organizational roles that won’t become bottlenecks (roles that won’t prevent the organization from delivering efficiently or to adapting quickly to changes). In classic organization design, we tend to think that designing boxes on an organizational chart and putting great people in charge will solve all our problems. That approach could work in static environments, where what you have to deliver is defined once and for all.

    But if your environment is continually changing, you need to adapt your value proposal to those changes. Your organization needs to be adaptable.

    My interlocutor was on the path to designing the boxes of a new organization. On his radar were managers that will have full responsibility for certain groups and team leaders with full responsibility of the teams making up those groups. Static groups, static roles, static functions.

    But you can’t achieve a capacity for adaptability in your organization if you rely on overloaded people dealing with multiple responsibilities. I suggested an alternative: Self-organizing teams designed around roles that are not bottlenecks, roles that team members could take either full-time or for a portion of their time.

    Unfortunately, my interlocutor jumped to the conclusion that my goal was to remove all managers and team leaders from the organization—as if self-organizing teams and management were somehow mutually exclusive.

    Not exactly.

    Managing the self-organizing team

    The Open Organization Definition lists five characteristics as the basic conditions for openness:

    • Transparency
    • Inclusivity
    • Adaptability
    • Collaboration
    • Community

    I’ve recently discussed the importance of making work visible when attempting to achieve transparency and collaboration at scale. Here, I’m more concerned with adaptability—creating teams without single points of failure, teams better able to adjust to changing conditions in dynamic environments.

    I agree that a team has to be managed, and I think many of the activities we see as the sole responsibility of the managers or the team leaders could, in fact, be delegated directly to the team—or to team members that could effectively deliver the activities serving the team.

    So from my perspective, a team has to be managed, but a large part of that management could be done by the team itself, creating a self-managed team.

    Let’s review some of those activities:

    • understanding the business and the ecosystem the organization evolves in
    • understanding why we provide solutions, products, features, services and formulate a clear vision
    • defining what needs to be delivered and when it should be delivered
    • determining how it will be architected
    • identifying how it will be implemented
    • defining how it will be documented, demoed, tested
    • distributing the work between the team members
    • delivering the work
    • implementing the documentation, testing
    • presenting the demo
    • collecting the feedback from users and stakeholders
    • ensuring that the result of the work is continuously flowing to the customers or users ensuring that testing is automated and triggered for each and every change
    • improving the way the team is working and increasing its impact and sustainability
    • improving the efficiency of the larger system formed by the different teams
    • supporting customers and partners who use the product
    • fostering collaboration between users, customers, and partners in the defining and implementing the product or service
    • defining the compensation of team members
    • controlling the performance of team members
    • supporting and developing people in the team
    • hiring people

    When I look at those activities, I see some that could be delegated to a system put in place by the team itself—like the distribution of work, for example. The distribution of the work can be made obvious for team members by simply making the work visible to everyone.

    I also see activities that are difficult to move away from managers, like managing the compensation of team members (because it would require building a compensation system that’s more transparent, which is difficult when you don’t start from scratch due to preexisting discrepancies in the compensation of people).

    I see activities that are focused on users and the why and what the team is delivering. On some teams with which I’ve worked, those activities are delegated to a team member taking, for example, the role of User Advocate or Product Owner (to use the Scrum terminology).

    I see activities that are focused on how the team is working. Those activities are delegated to a team member taking, for example, the role of Team Catalyst or Scrum Master.

    In both cases, their role will be to ensure that the activities are done by the team, not necessarily to handle everything by themselves.

    By looking at the activities in more detail, I can envision many of them being handled by team members as part of their current role, or in a new role.

    Giving managers or team leaders the ability to consider the activities for which they’re accountable and the activities they can delegate to the team can remove the bottlenecks and single points of failure that currently exist in some organizations.

    Which activities in your organization could a self-organized team handle best? What have I left off my list? I’m interested interested in hearing from you.

     

    The post was originally published on opensource.com on August 14, 2018.

  • The top requirement for high-impact teams

    The top requirement for high-impact teams

    What is the top requirement for high-impact teams? When I was recently asked this question, I started making a list.

    • You need to know why you are doing what you are doing, and everyone on the team needs to know what that is.
    • You need to trust the people on the team. Trusting them is connected to personally caring for each member of your team.

    Assuming your team has a great purpose and people who trust and care for each other, will that guarantee a high impact? Maybe not.

    From my perspective, the one thing that is essential on a high-impact team is for everyone to understand the workflow—from the beginning to the end. And not only to have a clear, shared understanding of all the steps but to have the workflow visible to all team members at all times.

    How to make your work visible

    If you build software or do other work in the virtual world, it’s not easy to make your workflow visible at each step. Here’s a process I came up with some time ago when working with a team that was in charge of delivering a website for a luxury products company. The expectations for the user experience were incredibly high. Some would say ridiculously high.

    We started to investigate our team’s workflow by beginning at the end. On the upper far-right side of a large whiteboard, I wrote the word DONE in large letters and asked two questions:

    • How do we know that our work is done? The website is behaving as expected by the customer on all the defined platforms.
    • What changed between now and before? We implemented a new feature or a fix to an existing feature, and the result of this implementation is that the website is behaving as expected by the customer on all the defined platforms.

    These questions gave us information about the steps that had to happen before considering a work item “done.” We need to test the website on all of the platforms. And we need to implement a feature or a fix.

    On the whiteboard, I wrote TEST to the left of DONE, and IMPLEMENT to the left of TEST.

    In the whiteboard’s upper-left corner, I added a new column called INBOX. I explained to the team that we would use cards on the whiteboard to represent all the work items we had to do. When a new card (i.e., work item) enters the workflow, we would place it in the INBOX column.

    • What needs to happen between the INBOX and the IMPLEMENT column? Before we begin working on the issue, we need to assess its severity. We need to understand the new feature and how it will affect our personas.

    I added an ASSESSED column between the INBOX and IMPLEMENT columns.

    • How do we know what we need to implement? There are two types of work: planned work and unplanned work.
      • Unplanned work is the fixes that are detected by the users, the customers, or our teams. We are committed to delivering the fixes in a defined timeframe according to the severity of the issue.
      • Planned work is the new features that are defined with the representatives from the customer teams.

    To distinguish between the types of work, I added a horizontal line across the columns to create an area in each column for Fixes (unplanned) and Features (planned) work.

    Here’s what the whiteboard looks like:

    High-impact teams workflow

    We identified another issue we needed to address: The list of defined platforms had changed regularly, so we decided to make that list visible on a wall in the team room and use it as a checklist for the implementation and test activities.

    How it works

    A card enters our workflow in the INBOX column:

    • If the card describes an issue to fix, the team assess its severity and places the card in the ASSESSED column of the FIX swimlane. The card is timestamped and assigned a due date, then all the cards are sorted by due date and severity.
    • In the case of a feature to implement, the team evaluates what the ask means, discusses the implementation approach, and places the card in the ASSESSED column of the FEATURE swimlane. The customer and the team agree on the relative importance of the feature compared to the other features already in the column.
    • On the list of defined platforms posted on our team room wall, the team also discussed and displayed the assessment criteria for bugs and features on each platform.

    What’s the benefit?

    This example walked you through how we identified our workflow and made the work visible. In the interest of brevity, I simplified what was a multi-day planning process.

    The fundamental principles to make work visible are: Start with the desired end state, ask questions to understand what needs to happen to reach that state, and iterate to reach the beginning of the workflow. This must be a team activity because each team member will have his or her own view of the different steps.

    The immediate benefit for the team is it is obvious what needs to be worked on next, so each team member can pick the next card knowing that he or she is doing the right thing for the project. The indirect benefit is that it shows where in the flow we are overinvesting–we can see it because the cards are pilling up in the column just to the right of our overinvestment. In this case, we must limit that space according to the capacity of the team and focus on keeping a continuous and even flow of cards.

    What do you think?

    By making the work visible, the team knows where to invest its energy to have the most impact. This is why I think making work visible is the top requirement for high-impact teams. What do you think is the #1 factor in a high-impact team? Please post your answer in the comments or tweet @alexismonville or @opensourceway with the hashtag #ChangingYourTeam.

    The post was first published on opensource.com on July 31, 2018.

  • Care Personally

    Care Personally

    Care personally and challenge directly. That is how Kim Scott defines Radical Candor. At the end of November, I decided that I will offer her book to some of my colleagues.

    A book is an opportunity for learning through discussions with others. I already discussed the advantage of a book discussion club, and by offering a book, I wish to have those conversations, with each person. And yes, I am also planning a book discussion club.

    When you give a book, some conversation could start surprisingly fast, like last year when I gave “Joy” to colleagues, and one of them told me immediately: “Is there a message? Do you think I make my employees unhappy?”. This conversation took me by surprise and I probably just mumbled meaningless words to try to escape it.

    Sometimes it seems that the conversation will never start. So either, you can forget about it, or you can push to have it. Sometimes it is just that people don’t read, don’t read business books, have other things on their reading list, and that’s ok.

    With Radical Candor, I had the first conversations quite rapidly. The first one was about the 2 x 2 matrix used in the book. You are up on the vertical ax of the matrix when you care personally. You are on the right of the horizontal ax of the matrix when you challenge directly.

    The conversation evolved around the principles described by Dale Carnegie and how they fit the matrix. (in “How to win friends and influence people,” his book first published in 1936, and still reedited today.)

    I will take two examples:

    • Become genuinely interested in other people
    • Give honest and sincere appreciation

    Become genuinely interested in other people, is, of course, an excellent way to demonstrate that you care personally. And, as you can see in the matrix, if you are doing it without challenging people directly, you will fall in the “ruinous empathy” quadrant.

    Give honest and sincere appreciation, is, this time, more tricky. If I consider that I will only speak about the positive behaviors that I can see in other people, I will fall in the bottom left quadrant “manipulative insincerity”. If I don’t care personally, and I give honest feedback, I will fall into the “obnoxious aggression” quadrant. If I care personally and that I am honest, this time I can act in the upper right quadrant.

    The way you will give feedback is of course key to the success of your message. Kim Scott explain this point with reference to what Ben Horowitz called the shit sandwich in “The Hard Thing About Hard Things” another book that I enjoyed. The shit sandwich is his way to qualify a classic way to give feedback: start with complimenting, then pass the difficult message, and finally value the strengths of people. The problem with the approach is that experienced people will see you coming and each time that you will start with a compliment, they will wait for the difficult feedback.

    The point is that if you care personally for people, you will develop a relationship that enables to give and to receive honest feedback without the need to give a not so nice sandwich.

    Once, I was in the audience at a conference, and one of my colleagues was giving a talk. The guy is excellent, I love his way of thinking, he can present an appealing overall vision and go deep to the right level of details when it’s appropriate. The talk was ok, and I was frustrated. Why? Because he made basic public speaking mistakes that he could have easily avoided. I wait that the long line of people wanted to thank him, and to talk with him vanished, and I told him: “Great work Steve! I have some feedback, do you want them now or later?”.
    Steve: “Now would be fine.”
    Me: “Do you want them direct, or do you want me to dress them up a little bit?”
    Steve: “I am a big boy, go for direct.”
    At this stage, I would have gone for direct anyway, and I guess you understood that I cared enough for that.

    I will relate another conversation I had about the book in a future article about Rock Stars and Super Stars.

  • Trust Factor

    Trust Factor

    Trust, as a foundation for efficient and sustainable teams, is a recurring topic on that blog. In Beyond Measure, I covered the simple exercise proposed by Margaret Heffernan to initiate a relationship between team members. I tried to nudge you to try The Evolution of Trust from Nicky Case. And, of course, I regularly referenced The Five Dysfunction of a Team, as a must-read to build a team.

    Paul J. Zak, the author of Trust Factor, explains how the scientific work conducted on Oxytocin, aka the love hormone, helps to understand how the culture of an organization is working.

    You can benchmark your organization on the eight key factors presented in Learning from the neuroscience of trust by answering the 16 questions of the Ofactor Pulse test (I encourage you to read the book and respond to the test when triggered).

    Questions are based on observable behaviors, which make them relatively easy to answer. For example, one is: “My leader treats setbacks and mistakes I make as a valuable opportunity to learn and try something new”. From “Strongly Agree” to “Strongly Disagree”, you can find where you stand.

    Your overall trust score could push you to dig more, and the full ratings a good idea of where to start investigating the potential changes in your behavior to create the conditions you want.

     

  • Learning from the neuroscience of trust

    Trust is the foundation of the human relationship and the foundation of an effective team. I recently shared how our behavior will create or destroy trust in the article The Evolution of Trust, and more about trust as the foundation of a team in the article The Five Dysfunction of a Team.

    Paul J. Zak, the author of Trust Factor, shares in The Neuroscience of Trust the 8 management behaviors that will foster trust.

    We could use the 8 behaviors as discussion points with teams to improve our way of working. The question could be, How are we doing on:

    1. Recognize excellence: personal public recognition from peers that occurs immediately after the fact, tangible and unexpected has the largest effect on trust.
    2. Induce “challenge stress”: stretch goal, but a still achievable goal, assigned to a team will intensify focus and strengthen the social connection.
    3. Give people discretion in how they do their work: autonomy and self-organization, is another important contributor, being trusted creates trust.
    4. Enable job crafting: trusting people to choose what they will work will ensure focus and motivation. The author gives the example of Valve, the gaming software company, I recommend their employee handbook to have an idea of how they work, and inspire the conversation with your teams.
    5. Share information broadly: uncertainty and stress undermine teamwork, openness, transparency and daily synchronization are the proposed antidotes.
    6. Intentionally build relationships: encourage people to care for each other will make them happier and more productive.
    7. Facilitate whole-person growth: meet frequently and give constant feedback on personal and professional growth.
    8. Show vulnerability: asking for help, and acknowledging what we don’t know, help to build credibility.

    Could this discussion be the Retrospective on Trust for your team?

  • Hierarchy and Decision Making

    Erin Meyer covers how cultural differences in leadership styles create unexpected misunderstandings [Being the Boss in Brussels, Boston, and Beijing of the last issue of Harvard Business Review].

    Looking at how people behave towards hierarchy is not enough to understand what kind of leadership style they will expect. A second dimension needs to be taken into account: attitude towards decision making.

    Coming from France, I was making a simplistic association of hierarchy with the top-down decision making and was puzzled by the Japanese who were clearly experts in getting to a consensus while they were still hierarchical.

    Of course, generalizing the expected behavior for an entire country is not fine grained enough, and you could expect different behavior from people of those countries.

    The key is to understand that hierarchy and decision making are 2 different dimensions to discuss when you are building the team agreement on how you work. And when you are working with teams that are made with team members coming from all over the world, this is key to the success of the team.

    For example, my understanding of Self-organization is egalitarian and consensual, and it’s for me the opposite of the top-down and hierarchical approach. The managers and team members, involved in a transformation towards a self-organization model, could struggle with defining their roles, especially if they are more comfortable in the 3 other quadrants.

    Do you have your team agreements written down?

     

  • The Evolution of Trust

    The Evolution of Trust

    When forming a team, or starting to work with a team, I usually start with the foundation of a team: Trust.

    I even used several times, the book from Patrick Lencioni: The Five Dysfunction of a Team, obviously because the “Absence of Trust” is the base of the pyramid.

    I remember playing 2 times, with large teams, a game based on the game theory, and a variant of the prisoner’s dilemma. The effects with one of the team were really great, for the one, where one of the participants betrayed not only the other team but also his own team, the results were not so good, for him and for his relationship with others in the larger team.

    So I am always struggling with the idea of bringing that game to build trust, because we could have someone in the group that will betray the others, and after that, it is difficult to deal with it. One of the participants told me one time: “at least, now, we all know”.

    The idea of the article has been triggered by the brilliant work from Nicky Case: The Evolution of Trust.

    The recommendation (The ask?) is for you to play with it, and to get other people to play with it.

    This could help you and others to better grasp how we build or destroy trust.

    Ready to play?

    It’s here: http://ncase.me/trust/

  • Team Identity

    Team Identity

    The sense of belonging is an important experience to have. Belonging means that we are accepted as part of, as a member of the group, the team, the company.

    We want to be part of a team because what defines the team identity is appealing to us. The team is defined by its vision and its working agreements.

    When you are building software the open source way, you can identify 3 main categories of team identity:

    1. Upstream project
    2. Downstream product
    3. Jobs to be done

    1- Upstream project

    The team members belong first to the upstream project. They will tend to prioritize what they think is the best for the upstream project. They will be progressively disconnected from the people that are using the technology they build. They could even miss new needs and be surprised that people switch to another technology that is not so different/better/other qualifiers…

    2- Downstream product

    The team members belong first to the product they build. They will tend to prioritize what they think is the best for the product. They will tend to forget that building the open source way is a great way to understand why people want to use the technology by confronting your point of view and requirements with those of the other members of the community. The extreme is that they will end up being alone, and disrupted by another product.

    3- Jobs to be done

    The Jobs to be done theory has been described by Christensen and his colleagues. I wrote an article about one of his book: How to measure our life and I will probably write another one about Competing Against Luck.

    In short, the Jobs to be done theory explains why people are making choices, hiring or firing a product or service, by focusing on the understanding of the jobs, the problem they are trying to solve.

    The teams that identify themselves to the jobs to be done are stronger because they can work on technologies in the open, curate technologies that they need, invest in new technologies that could replace their current core technologies, without losing their identity. They can envision their solution as a sole product, or integrated into other products knowing that the most important thing is the jobs to be done. They can partner with other knowing precisely what they are partnering on without feeling that they could lose/win something in the partnership. They can focus on their users and solve a specific problem, a specific “jobs to be done” without the temptation to expand the scope of what they are doing.

    I guess that the jobs to be done should be the first thing you want a team to agree upon.

    Thoughts? Please comment, tweet, email…

     

     

     

    The header picture is from Ryan McGuire.