Behaviour and protocol

Code Code reviews Consulting 101 Feedback Good meetings practices How to facilitate team meetings Inclusive language Values

Career

360 review Continuing education policy Engineering manager career ladder Roles Software engineer progression framework Technical skills sheet

Employee manual

Abtion's pomodoro Employee benefits Internal days & community Intro Parental leave policy Safety and security Schedule, time tracking & calendar Sickness & unplanned absence Travelling Vacation & planned time off Work from anywhere policy

Project management

Technical setup when starting a new project Client discontinuing hosting or sla Converting projects from development to maintenance mode Estimating Go live checklist Handoffs Invoicing guidelines Procedure for traffic Sla

Setup

Audio setup Create amazon bucket Database backup setup Gpg signing Pairing setup

Technical practices

Bug triaging Css How and why we do design research Kick off meeting Pair programming Tdd testdriven development Workflow

Templates

Readme.standard

Tools and services

Access and permissions Purchasing licenses and memberships Sharing sensitive information Stack and services Wordpress
=

Behaviour and protocol

Consulting 101

Introduction to Consulting

As a consulting company, we are fortunate to have collaborated with a wide range of companies over the years from solo entrepreneurs to large Danish corporations. Key to this success is that we acknowledge that every client is different and has different needs. We believe that training people and bringing them closer to the client ensures that we can give clients better advice and products.

Our goal with this document is to give ideas on how to approach clients and projects.

This document is divided into the following sections:

Communicating with a client

  • Understand client preferences in communication and process.
    • By continuously engaging with clients, we can learn about their preferences and operational styles.
    • Example: Some clients prefer regular Show and Tell-meetings to stay updated on project progress.
    • Some clients want comprehensive explanations, while others prefer a more concise approach.
    • You could always ask the client how they prefer to communicate.
    • A client might not know what their preferred style is so it can be beneficial to try different approaches.
  • Keep communication transparent and public.
    • To ensure that the entire team is on the same page, it helps to keep communication transparent. Like a public Slack channel or Asana task.
    • When communicating about a specific task, it makes sense to keep the communication on the specific task in Asana. That way the information is available for everyone - also future team members.
  • Respond to client messages clearly and on time.
    • If you need time to eg. analyse a task or estimate changes, it is beneficial to communicate that to the client.
    • Example: “Thank you for your message, I will take some time to analyse and get back to you by tomorrow.”
  • After a meeting, summarize key points and next steps in Slack or in Asana.
    • This helps to ensure documentation and a shared memory on what has been decided.

Understanding the client’s perspective

  • View and assess the platform from the client’s perspective to better understand their needs.
    • You might find new features or improvements that the client has not thought of.
    • Some teams have had success with a “Test the product as a user” day.
  • Focus on delivering features that not only meet technical specifications but also help the client’s user experience.
    • Example: “This feature was updated to speed up your process. It will help your team to achieve results faster.”

Communicating technical stuff

  • Tailor communication to the client’s technical understanding.
    • If the client is non-technical, you could use metaphors or analogies to explain the technical concepts.
    • You could always ask the client how technical they would like the explanation to be.
  • Provide realistic estimates and pose potential challenges and solutions.
    • Example: “We have estimated the SSO login as an XL-task. The documentation for the SSO is new to us, so we would have to spend some time researching. Alternatively, an email-based login would be an L-task.”
  • Explain system issues, highlighting the reasons for unexpected outcomes and the steps taken to fix these.
    • Example: “The issue occurred because the user could input text, and we were expecting numbers. We’ve updated the input and added additional tests.”

Planning for the future

  • Be proactive in identifying and addressing potential issues or enhancements.
    • As consultants, we’ve learned to leave things better than we found them, but if you find something that takes more time to improve, it can help to communicate this to the team. It could end up being a feature request.
    • Example: “I noticed a strange pattern in the data and wanted to make sure that this is not an error or would otherwise impact the project.”
  • Keep a list of potential improvements or issues.
    • This could be a list of “Version 2.0” features or technical chores that could be addressed in the future.

Aiming for solutions

  • Ask questions to understand the client’s needs and propose solutions that align with their goals.
    • A client might ask for a specific feature, and if we understand the reason behind the request, we might be able to propose a better solution.
    • Example: “Could you explain the problem you are facing in more detail? This will help us to propose a solution that fits your needs.”
  • Avoid outright denials when addressing client requests; instead, propose alternative solutions or phased approaches.
    • By softening the response, you can help the client to understand the complexity of the request and propose a solution that fits their needs.
    • Instead of “That’s impossible.” you could say “That’s challenging. Could you elaborate on the problem you are aiming to solve? Perhaps there are alternatives that might work.”
    • Instead of “It will take too much time.” you could say “This is a complex feature. If this is critical for the project, we can research and estimate it before we move on.”
    • Instead of “Do you really need that?” you could say “Let us put it in the ice box and assess it when we have finished the business critical features.”
    • You could also suggest a Proof of Concept (POC) to demonstrate if the solution is feasible.

Additional resources

  • The Trusted Advisor by David H. Maister, Charles H. Green, and Robert M. Galford