In the Guide to Internet Computer Project Success I introduced a people, process, product framework for tackling the change management aspects of a project. In this article I'll give you five tips for building a people centered project which will in turn increase your chances of delivering a people centered product.

To be truly successful a software development project must put people first. Your project will require people to achieve the project goals and your product will require people to use it. The most successful products are the ones that appeal to the most people. Apply the following five principles to make your project people focused.


Principle #1: Prioritize people above all else.  

Your project has many stakeholders and your project won't survive without them. Your project should always consider how to balance the many, and often competing, interests of your stakeholders. This includes your project team (internal stakeholders) and your user base (external stakeholders). This is no small task and a balancing act for sure. However, if you put people first then you will increase your project's chance of success. One way to ensure that you prioritize people is to embed this principle into your vision statement.

In the Guide to Internet Computer Project Success Action Item #4 was to develop a vision statement. Expand on your vision statement by ensuring that it captures your desire to put people first. Here are some tips for writing your vision statement.

  1. Make it concise, one or two sentences, so that it is easy to remember.
  2. Make it specific so that it is easy to follow.
  3. Make it forward looking so that it gives your team direction.
  4. Make it long-term so that it won't change often.
  5. Make it challenging so that it motivates your team to excel.
  6. Make it inspiring so that your stakeholders are motivated by it.

Action Item #1: Develop or update your vision statement so that it captures your commitment to your stakeholders. Let this vision statement be your guide.


Principle #2: Make communication your primary mode of operation.

Most, if not all, challenges can be conquered with communication. Communication is how we come together to achieve common goals, work through our challenges, and build a high-performing team. Communication is the "grease on the gears" which enables high-speed low drag teams to achieve top performance.

It is important for you to know what the critical points of communication are within your team and with your customers so that you can build your processes around these. Design your communications to fit the size and complexity of your team and customer base.

Two of the four Agile Manifesto values are primarily about communication. The first value is to prioritize individuals and interactions over processes and tools. The second value is to prioritize customer collaboration over contract negotiation. These two principles provide great guidance for how you should approach communication with both internal and external stakeholders.

Individuals and Interactions: Treat your team and customers as individuals and interact with them through honest and sincere communication.

Customer Collaboration: The most productive customer relationships are ones that are motived by collaboration and not by contractual obligations.

Action Item #2: Make a list of the ways that you will make communication with your team and with your customers a core principle.


Principle #3: Understand the roles that your team members fulfill in the software development life cycle.

In order to optimize your team's execution it is important to understand software development roles and how information flows between team members. Your team does not need to have an individual in each role, but each role should be represented by a member of your team. So for example, one person may fulfill the roles of Project Manager and Business Analyst while a second person fulfills the roles of Architect and Developer. For some projects a single person might fulfill all of the roles. There are additional roles not covered here. However, these roles will cover what the typical small team developing in the IC environment will need.

Project Management: The project manager is the team leader and organizer. They clear the path for the rest of the team by planning ahead, knocking down obstacles, identifying risks, facilitating mitigations, and absorbing many other leadership and administrative tasks for the team. Do you have someone paving the way for high speed travel?

Business Analyst: The business analyst is the representative for the customer. They take the perspective of the users by documenting the requirements so that the rest of the team can design, implement, and validate that the requirements are being fulfilled. The business analyst may even do some or all of the UI/UX mockup designs depending on their skillset. Do you have someone who is an advocate for the user/customer?

UI/UX Designer: The user interface/user experience (UI/UX) designer translates and or implements the requirements into an easy to use interface which gives the user a pleasant user experience. This is particularly important with IC products which often need to hide some amount of technical complexity from the end-user. Do you have someone who is focused on making the user experience outstanding?

Architect: The architect translates the requirements into an architecturally sound design that will also meet various non-functional requirements such as performance, fault tolerance, security, maintainability, and extensibility. This role is extremely important for building on the IC. The IC requires some new ways of thinking about application architecture. Do you have someone who is focused on making sure your product will scale, be secure, and maintainable?

Developer: The developer implements the architect's design while following coding standards and common patterns. The developer often does unit and integration testing to ensure that their deliverables are relatively stable and free of any obvious defects before more formal testing. Do you have someone who can take great ideas and designs and turn them into reality?

Quality Assurance Analyst: The quality assurance analyst compares the implementation to the requirements to first ensure that all requirements have been fulfilled. They perform various types of testing which are designed to find certain types of defects. While end-user, also called user acceptance testing, is extremely important, it's also important to have someone with a knack for breaking things. True testers think a little differently than the rest of the team. Since so many of the products on the IC are dealing with valuable transactions it is really important to find those defects. Do you have someone who is focused on protecting the team and the users from defects?

Your communication processes should be unique to your team and how your team has divided up the core software development roles.

Action Item #3: Make a list of the formal and informal ways that your team should share information between the core software development roles.


Principle #4: Seek to understand and then to be understood.

Within every project and team you will encounter conflict. I have found the best way to resolve conflict is to first understand the perspective from the other side. Even if you don't agree with that perspective it makes finding common ground much easier. Once you have common ground then it is easier to be understood.

It is common for teams to cycle through four phases known as forming, storming, norming, and performing. If you recognize this it will make the storming (conflict) phase much easier to get through. You should inform your team of this cycle as well. When everyone knows what to look for it makes communication about conflict much easier.

Forming: This is the phase where the team is coming together. There may not be much conflict during this phase since everyone is usually excited about the project and doing something new.

Storming: At some point, and often at multiple points, during the project the team will encounter some conflict situation that causes the team to "storm". The internal storm is the most difficult because it can be the most destructive if not recognized soon enough. The external storm can bond a team, but can also be distracting to the team if they don't navigate it in a positive way.

Norming: As conflict is resolved the team will fall back into some "norms" or normal modes of operation. This is when everyone starts to enter their flow state as individuals and as a team. Now all the team needs to do is step on the gas.

Performing: Once the team norms are well understood and accepted then the team can move on to top performance. I've seen very small teams run circles around large teams once they entered this phase.

Be on the lookout for conflict and don't let it fester. Have a plan in advance for how your team will handle conflict in a productive and non-destructive way.

Action Item #4: Develop a process for resolving conflict in a productive way.


Principle #5: Your team will need leadership and management.

Leadership and management are two different skillsets. However, the same person can posses both leadership and management qualities. For small teams this is actually preferable so that you get both from one individual. It is extremely important that you know the difference between leadership and management so that you can apply them at the right times and in the right way. At the highest level you can remember the difference with the phrase "we lead people and we manage work".

As a program/project manager I am at my best when I am able to operate in both a leadership and management role. The trick is dynamically switching between these roles depending on the situation. I see my leadership role as a servant and supporter of the entire team. As a servant I'm there to support the team with whatever they need in order to excel in their individual roles. I see my management role as an organizer for the entire team. As an organizer I'm there to help the team stay focused and track progress so that we can set and achieve reasonable but challenging goals. In both roles I'm just another member of the team with a specific set of skills and responsibilities to the team.

Leadership: Whether you are the "official" leader of the team or not you can be a leader. My preferred type of leadership is servant leadership. I see the team hierarchy as all scrambled up. No top and no bottom. Everyone is a leader and should be empowered in their role. Some of the key skills of a leader are:

  • Visionary - Leaders inspire others with their vision of the future
  • Encourages Change - Leaders challenge that status quo and thrive on disrupting it in search of something better
  • Encourages Risk - Leaders encourage and reward smart and calculated risk taking and learning from failure
  • Builds Relationships - Leaders build relationships by coach people, empowering them to make decisions, and celebrating their success

Management: One of my pet peeves is being micro-managed. There are some people that prefer to be managed in that way. They find comfort in being told what to do and even how to do it. I don't advocate for that kind of management. However, every project does need to be managed in order to track progress and set reasonable but challenging goals. In a management role I help the team stay organized and pave a path so they can go fast or sometimes run defense so they can go slow if needed. Some of the key skills of a manager are:

  • Goal Setter - Managers set goals that work towards a vision
  • Encourages Stability - Managers prefer and encourage stability and controlled execution
  • Manages Risk - Managers prefer to reduce risk by mitigating it
  • Builds Processes - Managers prefer to build consistent processes that are predictable so that they can control and direct the execution of work

Action Item #5: Talk with your team about the team's source of leadership and management and why both are necessary and valuable if applied correctly.

I am truly excited to see all of the new teams forming to deliver new products and services on the IC. I'm making it my mission to help IC project teams be more successful. I hope these five principles with action items will help your team. Reach out if you have any questions.

Peace - Brian


Brian Galler
Brian Galler

Technical Program & Project Manager, servant-leader, and backpacking adventurer. A believer in The Internet Computer and a max ICP staker. A lifelong computer nerd who is finding a renewed sense of purpose in the blockchain community.

Connect with @BrianGaller on Distrikt

Connect with @Brian_Galler on DSCVR

Follow @BrianKGaller on Twitter