Secret ingredients to quality software

SSW Foursquare

Rules to Successful Sales and Account Management - 52 Rules

You can have the best developers in the world, but if you haven't got a good sales process, no-one will ever use them. It's up to the Sales Manager to get this right.

Once you've got the job, software projects are delicate activities and the client needs love. It's up to the Account Managers to keep everyone on the same page, especially if there is no Scrum Master.

The Account Manager is responsible for invoicing, resource management (booking developers) and conflict resolution.

  1. Any opportunity that has not yet been converted to a sale will be at one of the following 6 stages:

    1. Initial Phone Call

      • The client has made contact but no initial meeting has yet been made
    2. Initial Meeting – Booked

      • You've arranged an initial meeting and it's booked in
    3. Follow Up Meeting – Booked

      • In some cases, more than one initial meeting may be required before work or speccing commences
    4. Spec Review Proposal – Waiting for Approval

      • After the initial meeting, if the work requires it, a specification review is proposed
    5. Spec Review – Booked

      • The speccing phase has been approved and booked in
    6. Project Proposal – Waiting for Approval

      • After the spec review, the client has been given a proposal for a chunk of work. Once this is approved, the opportunity is closed as won

    The old Sales Pipeline was 9 steps, whereas this new one is 6 steps.

    old sales pipeline
    Figure: Bad Example – the old sales pipeline

    new sales pipeline
    Figure: Good Example – the new sales pipeline

  2. It's often quoted in marketing circles that it costs between 60% and 600% more to sell to new clients as opposed to existing ones. It makes sense then to nurture your existing client relationships.

    There are two strategies that need to be employed here:

    Keep your current clients happy

    Feedback has been received from larger clients in the past that they expect regular check-ups and guidance from senior staff. A nice informal way to arrange this is to buy your client lunch once a month. You can review the project for half an hour, then grab a bite to eat. The review should cover the project as a whole, any niggling problems, and discuss any upcoming projects. You should do this review free of charge.

    As a Project Manager, one of the most important things you should focus on to keep clients happy is communication. For active clients, a week must not pass without a phone call or some other contact. A lot of the time this will be emails from the developer. Almost all disputes arise when you don't speak to a client for a period of time. This allows any annoyances to fester and any misunderstandings can turn into real problems.

    A "client relationship problem" is when you have said "no" to a client and they let you know that they strongly disagree. In that case:

    • Tell them the reasons for your stand
    • Tell them that developers will sometimes do the wrong thing - clients have different opinions of what that is
    • Tell them you are authorized to split a problem, offer them the solution and ask if they are happy with that solution

    If they're still not happy you may need to refer them up the chain of authority.

    Stay in touch with past clients

    Have a system in place that allows you to stay in touch with past clients, even ones you may not have spoken to in a while: send a useful newsletter to subscribers so your business keeps fresh in their mind. That way when they suddenly realise that they need some work done, you're right at the top of the list. Secondly, have a follow up system in place so that client get a call every 3 months after a job is completed. Make it friendly, not pushy. You should use a line like 'I'm just checking in to see if everything is still running smoothly.' Setting up a system like this will result in more repeat business and less need to spend money on marketing.

    Always be interested in your clients' lives outside of work: find out about their hobbies, sports interests, kids etc. If you come up with the perfect idea for a present for an important client, get it approved by your manager and send it off.

  3. Do you manage your inbound leads effectively?

    With the amount of money companies spend on marketing these days, it's vital that, when you receive a phone call enquiring about your services, you know how to handle it.

    Be prepared for inbound calls. You should have a script that your phone operators keep close at hand to make sure you ask the necessary qualifying questions. The aim is to determine if you are a good match with the prospect - that way you don't spend time on dead ends and can give more time to the most likely leads.

    Once you have qualified the lead, your aim for the remainder of the call should be to arrange a face-to-face Initial Meeting with the client.

    1. Agree on a time for an initial meeting.
    2. Send a Pre-Initial Meeting email.
    3. Send an appointment to the client and everyone attending the meeting (copy the email above).

    meeting request
    Figure: Send an appointment for your initial meeting

    If the client wants to commence ad-hoc work (e.g. Consulting) without a meeting, you should immediately:

    1. Enter a contract with the client.
    2. Enter the contact information for the lead into your corporate database.
    3. Book it in by sending an appointment (set regarding to the client if you're using CRM)
  4. Do you know the non-Scrum roles of a project?

    Medium to large software development projects have people on them with varying roles and responsibilities. In order not to double up, or miss something, it’s important to define what each should do.

    Scrum already covers the roles of the Developers, the Product Owner, and the Scrum Master, but from a consultancy’s side, there’s also the Tech Lead and the Account Manager to consider.

    roles in bricks squared
    Figure: 5 roles in a Tech Project

    Account Manager

    Tech Lead

    • Spec Review - Primary communicator with the Product Owner
    • Project - Primary communicator with the Product Owner
    • Responsible for the architecture and technical direction of the project
    • Displays ownership of the project, and keeps the code quality high, and technical debt low
    • Helps the Account Manager with technical areas of conflict management
    • Keeps on top of the budget and timelines
  5. Do you perform a background check?

    Not all clients are created equal, and sometimes it's a good idea to do a quick risk assessment before commencing work.

    If a new client calls up in a rush and you've never heard of them, what steps do you take before jumping straight in to billable work?

    The easiest method is to check they are a legitimate company via a quick Google search:

    • Do they turn up in the results?
    • Do they have a webpage?
    • Does the webpage look legitimate (not just thrown together)?
    • Is the "Contact Us" address and/or phone number the same as the one they provided?

    Wanted Poster **Figure: Make sure you know who you're going into business with

    **With this information you can then rank them from "Not a Risk" all the way up to "Huge Risk" (the kind with neon flashing lights and all) and decide whether or not to go ahead with the business deal.

  6. Do you have clear Engagement Models?

    It’s important to have clear options for how a client can engage your services.

    You need to be clear on any differences between them in both billing and project management:

    • Time & Materials: Work to the client's specification, billing for the number of hours you accrue. The benefit of this type of development is flexibility – the client is able to add, remove and reprioritise development tasks during development.
    • Prepaid Time & Materials: Time and Materials clients have the option of a prepaid discount – buying blocks of 40 hours per resource in advance entitles them to a $15 per hour discount on the hourly rate of each developer. See the specific terms on our Terms & Conditions.
    • Fixed Price: Fixed price contracts necessitate having a specification signed off before work commences. This spec can't be altered, so additional items must wait until the fixed price contract is completed. The benefit of this type of development is that your expenditure is fixed. Fixed price projects are charged at a 20% premium to the project cost based on the standard hourly rates.
    • Recurring:  The client commits to a minimum monthly spend in return for a substantial discount on the hourly rates. This work is managed the same as Time and Materials work.
  7. Do you know how to justify your rates?

    Unless you're the <1% of companies who competes based purely on price, you will need to be able to explain why your services are more expensive than 1 or more of your competitors.

    In the bespoke software space, this is easy, as your clients are not buying something generic, and quality matters. Here's how we do it:

    we cant justify your price
    Figure: High price should be balanced out by higher value

    From our research, our rates are in the top 1/3rd of our Australian competitors, and I understand that this can seem high, so let's try to highlight a few reasons why we more than justify these high rates:

    Statistically, more than half of all IT projects fail...

    • SSW has been around for over 30 years and has only ever had 2 failed projects!

    We ensure this through the following:

    • Our Lean Startup methodologies mean we focus clearly on the Minimum Viable Product
    • A strong and strict Scrum process gives visibility into priorities, progress, and problems to the whole team and the Product Owner
    • Our arduous hiring process ensures we only have the most technically proficient consultants with the best communication skills
    • A strong focus on rules and best practices ensure that we are consistently delivering high-quality solutions
    • Our community involvement (User groups, Hack Days, MS Events, etc.)  helps us to rub shoulders with the other thought leaders in our industry  and stay ahead of the game
    • Our strong partnership with Microsoft (our owner is 1 of only 3 Microsoft Regional Directors in Australia) makes sure we have support when we need it
  8. Be prepared for the initial meeting because first impressions are the most important. Preparation cements your professionalism and underscores your eye for detail and capacity to deliver.

    Preparing for the meeting includes:

    • Ensuring the sales staff attending the meeting are familiar with the relevant technologies
    • Reviewing the clients' website or other available information, taking special note of the nature of the client's business. It's also useful to remember the office locations (e.g. one office, nationwide or international) and the year of commencement of business
    • Reviewing any specification documents the client may have provided.
    • Having a wireless card to access the Internet if you cannot connect to the clients network. In fact, it is preferred you do not connect to the clients network due to time and security issues
    • Having the Standard Sales Presentation. Remember, while clients don't want to think this is your first job, they rarely like to listen to how many CommBanks, NRMAs or Pfizers you've done work for. Clients generally prefer the focus of the meeting to be their business. You will however consider any previous projects which bear similarities to the project on offer, you do need to prove our competency
    • Have all the information that was recorded during the initial call
    • A hard copy of the Consulting Order Terms and Conditions may be useful for them to review when the meeting is concluded
    • Plenty of business cards (that haven't been sitting in your wallet for three months!)
    • Turning up early!
  9. The first meeting is on you. While you have 1 - 2 hours to provide the prospective client with enough information to decide whether to pursue a Spec Review, the focus of the initial meeting is the client, their problem, and how you might build a solution.

    The best way to action this is to ask questions, listen and take notes: Clients appreciate someone genuinely considering their needs. A brainstorming session is a fantastic way to give and receive feedback immediately. Even if the client decides not to use you, you should provide them with useful information and a positive impression.

    Here is what to do on a initial meeting:

    • Listen - Understand the client's motivation for engaging software consultants. Clients 'want a software application built', but understanding the motivation for getting that software built will assist you in making a successful bid for the project. Three examples could be:

      • To replace an outdated, hard to maintain existing system that's core to the business.
      • Building new 'nice-to-have' functionality to allow the client to offer a new service to the market.
      • Assisting a start-up company with a speculative venture.
    • Listen - Understand the 'pain level' of the client
    • Listen - Determine whether scope, time, quality or cost has the highest priority for the client and what level of project management they require. E.g. if a project must be delivered by June 30, a high level of management will be required to ensure enough resources are supplied to achieve this
    • Listen - Understand as much as you can about the processes/business rules the system has to manage. Every level of detail you can correctly comprehend and confirm back builds your credibility as a good communicator and supplier!
    • Listen - Assess the overall scope of the project, i.e. is this a 'small', 'medium' or 'large' project. The attending Architect should start guessing how many man months this project might be. This information will help you assess how long the spec review should be. These initial thoughts should not be shared with the client at this stage as they are most likely incorrect.
    • Listen - Determine the client's $ budget and who controls it. E.g. Are you dealing with the business owner or a line manager in a corporation? Do they have a fixed amount to spend? Do they have a time period to spend it in?
      Make sure you ask for their budget - it's important
    • Listen - Find out if this is the sort of project you can do and want to do
    • Listen - Qualify the client to make sure they can afford what they want
    • Consider technology options
    • Introduce your team, explain how our involvement can help them, and whether you have a 'good fit'
    • Explain your rates, including pre-paid
    • Explain the strengths and challenges of a Time and Materials or Fixed Price approach
    • Explain our Scrum development method including the importance of a Specification Review
    • Potentially explain their role as the Product Owner and show a bit of the Product Owner video
    • Ask for the sale: "This project is right up our alley and we'd love to be involved, is there anything stopping you from scheduling a Specification Review?" This will focus the mind of the client on the next step
    • Leave a bit of marketing collateral behind. Branded Notepads or USB sticks are ideal.
  10. There is always something we can learn from our interactions with clients.Initial meetings are a great opportunity to learn how we can fine tune our sales skills. Because there are always 2 SSW representatives in initial meetings with clients (usually an account manager and a developer) you should hold a debrief after the meeting on the way back to the office.

    Questions that you should ask each other are:

    1. Did I do or say anything wrong?
    2. Was I listening to the client or was I talking too much?
    3. Did I give the client my full attention?
    4. Is there anything I could have done better?
    5. Do you think I connected with the client?
    6. How can we improve our sales process from what we learned in this meeting?

    You should be as honest as possible with each other during the debrief but always use the sandwich rule. Any good ideas or suggested changes should be emailed to the Product Owner.

  11. Do you incentivize a quick Spec Review sale?

    Generally speaking, the more time that passes after an initial meeting, the less likely the spec review is to be booked, as momentum falls and the client's enthusiasm for the project wanes.

    For this reason, it's a good idea to try and get the spec review booked in straight off the back of the initial meeting, or as close to as possible.

    Chance of sale decreasing
    Figure: The chance of a Spec Review be successful decreases over time

    This will often lead to a cycle of you calling and emailing your client to try to book it in, with the client getting less and less responsive as they gradually lose interest and as other things take up their attention.

    The best way to ensure they strike while the iron is hot is to incentivize doing the spec review quickly. You should set a fixed timeframe, say 7 days, by which time they need to have made the booking, and that booking has to be within 30 days. If they adhere to this, they can have the spec review at half rates.

  12. It is quite common for a company to do a specification review, and then take the resulting estimates back to the business, and spend a long time getting other quotes or weighing up their options.

    This often means it's hard to get information out of the client as they tend to go dark, and also makes it hard for you to adjust the offer to ensure they get what they really need.

    For this reason, it's a good idea, at the end of the spec review, to schedule a follow-up meeting for a week or so later, right off the bat.

    1. Go through spec review document and answer any questions
    2. Talk about approval process at the company… who else needs to get on board? What do they need to see?
    3. Talk about budget

      1. Is the estimate acceptable
      2. Do we just do the MVP
      3. Do we need to find a cheaper way to give some of the value if they can’t afford the MVP
    4. Talk about prepaid, resourcing and scheduling

    Another benefit of this is just having the upcoming meeting can often prompt a decision to be made faster. You can do this meeting over Skype or in person, so long as you can share screens.

  13. Giving fixed features and a fixed delivery date is very hard. Giving a fixed price is hard too... this is because of the 'Cone of Uncertainty'.

    The basic reason is...

    Over time, our ability to accurately predict a project's remaining time estimates gets better.

    As a team, our understanding of the amount of work remaining on a project becomes more accurate as the project moves along.

    At the project’s initial conception, there is a lot to be learnt and consequently the estimates are likely to be inaccurate by a large margin. Half way through, however, the team has a much better idea of what will and will not be in scope, the technical issues are starting to get ironed out, and the estimates of the work now remaining become far more accurate.

    396294 Cone of Uncertainty
    Figure: The further away an event is (task, user story, job), the harder it is to know how big (effort, time) it is

    Bad example: Waterfall project.

    Estimating everything up front, when you know the least about what you will be doing (potentially 6 months of work).

    Good example: Scrum Project.

    Only estimating the top items in the backlog, that could be reasonably done in the next sprint (1-4 weeks of work)

  14. Before you engage in any billable work, the two parties must enter into a binding written contract. This ensures contractual obligations are clear on both sides, mitigating the potential for disagreements down the line and protecting both you and the client in the event of a disagreement. Binding contracts can take the form of Terms and Conditions, Emails and Instant Messenger or even verbal agreements.

    • Terms and Conditions - A signed copy of standard Terms and Conditions are mandatory before billable work commences as they explain the terms on which you work and the rates which will be billed. Some clients may also have their own set of Terms and Conditions which you should consider signing if agreeable. It is also common for clients to ask you to sign a Non-Disclosure Agreement (NDA) which you should always consider. Long term clients should re-sign the Terms and Conditions every couple of years. Signed Terms and Conditions should be stored in your CRM system against the relevant client (you could enter it in as an attachment to a note).
    • Proposals - At the conclusion of a Specification Review, you should provide a proposal to the client. This will include all of the relevant information you have discovered during the Specification Review process. The proposal may take the form of a PowerPoint presentation (preferred) or a Word doc. However, the proposal is not a contract. It does not supersede the Terms and Conditions. In effect, the proposal is a sales document which describes broadly the scope of the work to be done and our capacity to complete that work. In an Agile project, it is not a working document from which the project is managed. The project will generally be managed using Scrum, with a backlog in TFS.
    • Ad Hoc Emails, Instant Messenger and Verbal Agreements - The most common form of mini-contract is a confirmation email. Electronic communication such as email and Instant Messenger are extremely useful in getting decisions confirmed quickly but it is important to follow strict standards to ensure any agreements are clear to everyone. You should not generally rely upon verbal agreements, always confirm anything agreed verbally in writing.

    The following are important rules to follow:

    Email, IM and (confirmed) verbal agreements are utilized extensively during a project where newly discovered work, delays, or other work outside the initial scope is required.

  15. Often clients will see a multi-page T&C document with a box at the end that says sign here, and they will think that is the only important page and so sign it and send it back. However this can be a problem when you've got to provide evidence as to the content of the whole document they signed. To fix this issue, you can get them to re-send you through the entire document, but sometimes you don’t want to rock the boat. Here is another solution:

    1. Print out the section of the contract/T&C's the client sent
    2. Print off the balance of the pages from the relevant document (e.g. from the website) - of course it has to be the same document the client sent you a part of
    3. Scan the documents together as one document
    4. Email that entire document to the client

    Note: to do this directly in PDF (without using a printer or scanner) use (2 actions a day are free)

    Dear Client. Because you only sent me the last page I printed the other pages and scanned all the pages as one document for convenience. If there any problems, please let me know

    Figure - Good example: An elegant and helpful solution

  16. When a prospective client gets a quote for a huge price it's like giving them a slap in the face. Break your proposals into a series of releases, where each is 1 or more sprints, and clients can choose to proceed with a smaller financial commitment (such as just getting the mock-ups done) than if they were committing to the whole project. Often, small financial commitments will lead to bigger ones.

    This approach also allows you to side-step common delaying tactics of prospective clients by making it easier to get the project moving.

    AccountManagement FaceSlap
    Figure: One big price is like a slap in the face

  17. Once you have completed the initial meeting and provided a quote, you have to be careful to keep moving towards your goal of making the sale.

    In business, everyone is busy. The prospect you met with has a million things to do, and they may be relying on a decision from someone who also has a million things on their plate. It's easy to get stuck in a 'continuance cycle'. A continuance is basically a stalling tactic.

    A prospect will tell you that they're still interested, but they haven't gotten around to making a decision for one reason or another. An advancement is a step that takes you closer to closing the sale. You should always aim for an advancement rather than a continuance. An advancement might be an agreement to complete mock-ups for the application. Often, small financial commitments will lead to bigger ones.

    A great example of this practice is having a Specification Review being a stepping stone towards the full sale.

  18. So you had a good initial meeting (like a 1st coffee with a new girl), and you have agreed to have a Specification Review (aka first date).

    For the majority of new clients, a Specification Review (also known as a Spec Review) will be your 1st paid engagement with them, and gives the client a smaller first commitment. This is to work out the requirements and put together a broad time and cost estimate.

    It is a simple 4 step process:

    1. Once you have decided that this is a project you want to work on, you have to convince the client to book in a Spec Review

      • This is a 1-5 day exercise for 1-2 people. The general rule is 1 man day per expected 2 week sprint.
      • This process is timeboxed, and so appears to the client as a fixed price.
    2. Make sure you get Terms and Conditions signed before you start work on this.
    3. Specification Review - You will create a backlog of tasks, and some form of document (word or ppt) to present to the client explaining your proposed approach.

    ms ppt word logos

    1. Present the Spec Review results to the client (in a meeting with all stakeholders) on site if possible, or over the phone if not, but never just by email.

    Figure: Good Example - The backlog is constructed during the Spec Review

    Figure: Good Example - CRM Record showing the sales stage of the Opportunity after the Spec Review has been booked

  19. The number you give to a client says a lot about how much room there is to move. Knowing the difference and when to use them can be a valuable tool in securing projects.

    Fixed Price Projects

    For a fixed price project, exact figures should be used. This makes sure there is no ambiguity between what the client is thinking and what you are thinking.

    A round figure gives the impression that it was just plucked out of thin air and you can go lower.

    Note: Whether round or exact, make sure your dollar amount is excluding GST, and has "+GST" after it.

    The project will take about 6 months to complete and cost $200,000+GST

    Bad Example - You've just made that number up, you can go lower

    An exact figure gives the impression that you've done your research and there isn't as much room to move.

    The project will take 6 months to complete and cost $204,080+GST

    Good Example - Everyone knows exactly what they're in for

    Time and Materials Projects

    For a variable price project, round figures should be used. This gives room for the project scope to be varied with additional items and lends itself more to an agile approach.

    The project will take 6 months to complete and cost $204,080+GST

    Bad Example - This makes it very hard to vary the project as the client will always have this figure in mind

    A round figure gives the impression that this is a ball park estimate and that the price will likely change. 

    The project will take about 6 months to complete and cost approximately $200K+GST

    Good Example - Give the client an indication of how much it will approximately cost without committing to the figure

  20. You won the job with a great 1st Date (aka Spec Review), but no marriage can last without ongoing effort.

    Left to their own devices, most developers will slowly make more and more unmaintainable code, that is only comprehendable by themselves. This isn't a big problem for them as they are in it every day and know how it all fits together, but if they're not coding to a set of industry standards, you'll find this code very hard for anyone else to maintain.

    Figure: Bad Example - Would you want to maintain this code?

    This can be fixed by having regular software audits with a Solution Architect to keep the developers accountable.

    Each month, the Account Managers call all their current clients that have had a substantial amount of work done and offer them a Software Review.

    This makes more maintainable software with better architecture using industry standards.

    More information: The process:

    1. In the pre-sales, you should have already explained the concept of Software Reviews.
    2. Look at a report to show your main current clients (best seen by who was invoiced in the past month)

      • Tip: This is also a good thing to have up on the wall as a reminder of who your main customers are at the moment.

    Figure: A sample report to see your top clients

    1. Choose your top clients based on who's had a substantial amount of work done (e.g. Say 10k in the last month)
    2. Call them. Ask them how their project is going and if they have any concerns or anything they’d like changed

    3. Offer them a Software Review with one of your top consultants. This will ensure that best practices are being followed for all your major projects and help to ensure the quality of the solutions developed
  21. Do you know how to manage objections?

    When attempting to sell a solution to a potential client, you will invariably come up against some objections. It is essential that you are prepared to handle these objections so the client is confident in your skills and has no reservations about choosing you over someone else. The main reason clients raise objections is because they have concerns about your experience "fit" with their needs.

    We recommend you use this objection handling model.

    1. Ask the question - "What concerns do you have about working with us?"
    2. Acknowledge the objection - say, "Thanks for raising that", or, "Thanks for letting us know about that"
    3. Probe - ask, "Can I ask you a few questions about the concerns that you have?" "If I could resolve this issue for you, could we move forward? "You can't always solve objections on the spot - it's ok to say, "Is it alright if I speak to one of my developers about it and let you know about that later today?"
    4. Answer - Pick the best response to their objection (see below)
    5. Confirm that they are happy with your answer - "Do you now feel comfortable with our approach towards your project?"

    A typical objection we get is - "Why do you put 2 developers on the project? This is going to be more expensive isn't it?". This is basically how we handle this question:

    • Explain the benefits:

      • "We can complete the project sooner. Is that important to you?"
      • "You get more expertise - One guy is more focussed on UI, the other guy is stronger with databases"
      • "You get better quality code because the guys are able to "put their heads together" to solve a problem - this saves maintenance costs down the track"
      • "We can continue working if 1 guy gets sick"
    • If they are still unsure, you can offer a small discount off the hourly rate, or offer some free support - it's all about managing risk.
  22. You shouldn't charge a client for using your own product as part of the toolkit you take (e.g. we use Upsizing PRO when doing an upsizing job). This is because it's just like a plumber using his wrench. You take it away with you when you leave.

    However, you should charge clients when you install or provide one of your products for the ongoing use of the client e.g. Code Auditor, Link Auditor, etc. which the client's staff will use after you leave. This is just like a plumber buying a particular piece of pipe to fix a sink.

    Generally, you should avoid discounting product prices to clients since this would devalue the product.

  23. Some clients really want a discount. Most will be happy with a discount for pre-paying. Others won't go ahead until they feel they have got something more.

    If a client asks for a further discount, try to add value by offering something else.


    • One of your products at no charge
    • A Senior Consultant for 2 hours to complete the following tasks:

      • Code Review
      • UI Review

    Also bear in mind that offers like 2 for 1 are better than 50% discount because:

    • You sell for the price you wanted instead of losing money - adding an extra person or a licence is inexpensive
    • You are adding value to what you are selling e.g. more people will turn up to the event
  24. An important source of comfort for any client is a feeling that they are in control and they know the basics of what is going on. The fundamental part of this is who is working for them and how much it is costing.

    Therefore, if you change the developers on a project or if one or more of their rates change, it is very important to inform the client, before sending them the next invoice, where they will find out and could think that you're being shifty.

    We have standard templates for these situations in our intranet shared documents. You can see an example here:

    Hi Marlon,

    As per our conversation, I wanted to let you know that Eric was promoted to Solution Architect earlier this year. We held back his rate change until the end of this phase of the project, but we will be implementing his new rate as of 9/1/2019.

    His new standard rate is $285/hour+GST. Don't forget SSW offers a competitive rate to those clients pre-paying time in blocks of 40 hours per Project Team Member.

    I trust you've been happy with Eric's contribution to your project so far. We look forward to working with you soon.

    Let me know if you have any questions; always happy to talk.

    Regards,Ulysses Good example of an email informing the client about a rate change

  25. It's important for Account Managers to stay involved with client projects past the sales stage and into the implementation stage. The best way to do this is to call them once every 2 months or so once the project gets going, just to guage their overall satisfaction and happiness.

    The best way is to set yourself reminders to do this using FollowUpThen.

  26. Events such as training courses, user groups, tech breakfasts and boot camps can be a very useful way to get your highly skilled, impressive consultants in front of potential consulting clients.

    You should make sure you have some upcoming events in each main area that you hope to get work from, preferably that showcase your core competencies well.

    upcoming events
    Figure: Good Example – Upcoming events in the main areas you want to get consulting work

  27. Sometimes the prospect is not ready at the end of the initial meeting to engage you for a spec review or ad-hoc work. Even if this is the case, it's really important you leave the meeting with a crystal clear future about the next stage and when that will be. Every prospect needs an intelligently scheduled follow-up activity.

    So, at the end, ask the prospect:"When would be a good time to meet next?"Next Friday"Cool, speak then"Figure: Bad example: The client really won't remember this "When would be a good time to meet next?"Next Friday"Do you have your calendar?"Sure, hold on"What time suits best?"Let's say 3pm"Cool, Do you want to send the appointment or should I?" Figure: Good example: Asking them lots of questions and setting a specific time and date for the next meeting (or phone call)
    This will ensure that the follow up meeting or phone call gets a much better chance of happening... Basically the prospect sets this up and will feel a certain indirect obligation.

    The other way to schedule a follow up is using Followupthen.

  28. Small increments of work add a lot of administrative overhead to work, drastically reducing company profit from client work. As a general rule, make sure any billable client appointment has a 1 day minimum and should preferably be in day long increments.

  29. Running training courses can be a great way to make sure your site always has new content and show that your company is active publicly. As well as being good for branding, it can also be a great source of lead generation for consulting work.

    In order to capitalise on this, you should have a developer in any training course who is there to help out and get to know the attendees, whose job it will be to meet up with some of the attendees a couple of weeks after the course to catch up for a coffee and a chat. This could be the speaker or another personable developer if required. It’s important that this is not just a sales person, as it needs to be someone who can give further advice on the training topic at a later date if needed.

    Keep these meetings fairly informal, with the agenda basically consisting of:

    • How did you find the course?
    • Is there any way we could improve it?
    • What are you doing with what you learned?
    • Is there anything else you’d like to know?
    • Does your company have a need for any consulting work?

    The last question is key as it could lead to substantially more work, but you should make sure the person you’re meeting with gets some good value out of the meeting itself, so this does not just seem like a sales exercise.

    It's also a good idea to mention that this will happen at the end of the course so that the call doesn't come out of the blue. The speaker could say something like:

    *"Thanks for attending today. You can email either of us after this.

                    Also in the next few weeks 5 of you will be picked at random for a 'Retro Coffee'
                    It is about 20 mins. Bring your problems. We will chat about the course and what you still need to know."*

    Read how this rule is also useful for presenters on Do you do a Retro Coffee after presentations?

  30. Developers should carry out "Client Love" every week.

    There are a few ways to achieve this...

    1. From an overall team perspective, you can check in with the Scrum Master about how the Scrum Retrospective meetings are going. You can see an overview in the Review/Retro email.
    2. From an individual developer perspective, you can check their time sheets on Friday to look for extra initiative shown.

    See Rules To Being Software Consultants Dealing With Clients.

  31. Most companies have staff varying in experience and price.

    While all staff pass strict recruitment procedures including technical and communication assessments, all staff have different skill sets. For example, some have a broader level of knowledge and some are more proficient at project management.

    When determining which staff are appropriate for which projects you need to analyse the needs of the project. Some may not require management skills, (for example if we are providing resources to another technical organization), while some projects may require only a narrow field of knowledge, (e.g. creating Xamarin forms).

    For any major project, a broad spectrum of individuals may be required which will utilize each level of staff.

  32. It’s easy when looking at availability reports and skill matrices to dehumanise the developers you’re assigning to work. Make sure to always keep the human touch by doing the following:

    1. Always call the dev before assigning them to a new client
    2. Make sure they’re happy with the technology
    3. Make sure they’re happy with the time commitment (e.g. X days a week for Y weeks)
    4. Find out if they need a handover
    5. Although generally client work always comes 1st, there may sometimes be internal bookings that might need to take precedence.
  33. Signing contracts - A Non-Disclosure Agreement (NDA) also known as a Confidentiality Agreement can sometimes have a lot of legal implications and you should be careful before signing one.

    What is an NDA

    non-disclosure agreement (NDA), also known as a confidentiality agreement (CA), confidential disclosure agreement (CDA), proprietary information agreement (PIA) or secrecy agreement (SA) or 'non-disparagement agreement' is a legal contract or part of a contract between at least two parties that outlines confidential material, knowledge, or information that the parties wish to share with one another for certain purposes, but wish to restrict access to only the participants of the agreement.

    Be Sensible

    All parties are entitled to have legal representation with an NDA, but there are a few simple gotcha's we detail below that we think can keep all parties safe, without any unnecessary dramas.

    Remember an NDA is there to foster a sense of trust between the parties, and although it's wise to follow the advice mentioned below remember that to take legal action as a result of a breach is costly and time consuming. It will also no doubt end a reciprocal business relationship.

    If a client needs an NDA and are happy to sign yours, this is the optimal situation as you know what's in it, and so can't be caught out. You should always have a boilerplate one stored in your own fileshare (ideally SharePoint) that you can send out as needed.

    If they demand you to sign their NDA

    look out for these potential tripping points:

    1. If the agreement is not mutual you need to be extra careful. One sided agreements makes one of the parties lose out
    2. Indemnity clauses - Always request that any indemnity be deleted
    3. Time limits - make sure there is one so this doesn't last for ever
    4. Funny jurisdiction (at least it should be in the country you are in)
    5. Specific damages (e.g. $1,000,000 per breach)
    6. Check that people are not individually liable
    7. Check what is listed as confidential information
    8. If you have access to a legal resource - send to them
  34. Working onsite has a number of benefits such as increased communication with the client and increased perception of value. However, if a developer is onsite for an extended period, they can start to feel disconnected from your company and their co-workers.

    The solution is to bring them back to the office 1-2 days a week to reconnect with everyone and still feel like they're part of a larger organization.

    This should be organized up front with the client when making the booking.

  35. Every now and then, a client will purchase training or event passes and be unable to attend. In this scenario, 2 things should occur in order:

    1. They should be offered an alternative. This is important as if they needed the training, they may well appreciate being given the option. This requires a conversation with the client and the alternative options are:

      1. A different date that the same course is being run.
      2. A different course that interests them.
      3. An equivalent dollar value of developer time to come onsite.
    2. If they decline and ask for a refund instead, then this should be processed immediately. This is absolutely vital as delaying giving a client their money back rapidly decreases their opinion of the integrity of your company.

    As an example, this means that the Accountant can always issue a refund for an event immediately, without any further approval needed from the boss, so long as at least 1 alternative has been verbally offered to the client (normally by the Account Manager)

  36. Communication is a critical part in project management and it's essential to provide as much information as possible to your clients so they know the project's progress.

    You should provide the following report to clients:

    • Project Progress Report: This report helps clients to review the current project progress, check the status of the project and whether they are over or under estimates.

    rulestobetterprojectprogress2 Figure: Project Progress Report

  37. Once a customised training engagement has been completed, it is important you follow up with your client for the following reasons:

    1. Get feedback on how the trainer went
    2. See if the client has any other consulting or training requirements

    A few days after the training occurred, call the client and ask the following questions:

    1. Are you happy with the training provided?
    2. What did the trainer do well?
    3. What could the trainer improve?
    4. Did you learn what you expected to learn?
    5. Would you recommend SSW?
    6. Do you need help with anything else?

    After you complete the interview send an “as per our conversation email” to the client and CC the trainer. The email should include the answers to the questions above and any recommendations for the trainer.

  38. When you sell a training engagement you should invoice the client as soon as the training is confirmed by email, as training is always fixed price and the cost will not vary like a time and materials engagement.

    Sending an invoice before the training begins acts as a confirmation of the training and allows the invoice to be paid a little earlier than usual.

  39. Do you always propose all available options?

    Sometimes, a client will tell you that they’ve already thought of the easy solution, but that they want you to investigate the more expensive (but more optimal) option - this is so they know much more it would be and can decide which option to go with. They may have already had the cheaper option scoped out by another company.

    The trap here would be to the only scope out the expensive option, ignoring quoting the cheaper alternative. Instead, you should scope out and price up *both* options, so that if the client prefers your approach, but thinks your expensive option is not feasible, they can still use you for the cheaper option.

    Here's how much the full rewrite of your solution would be: $ XXX

    Figure: Bad example – no option to use your company if they don’t want a rewrite

    The price to refactor your existing code base would be: $ XXX The price to do a complete rewrite would be: $ YYY

    Figure: Good Example – whatever option they choose, they can still use your company

  40. Ideally, all projects should be managed using Scrum, with sprint planning, reviews, and retros, daily scrums, sprint backlogs etc., but some client engagements are too short to justify this.

    In these cases, as a minimum, there should be a backlog and a Kanban board, and the developer should still be doing daily Scrums with the client.

    In order to ensure this, you should schedule a "Mini-Review" once a week for any client jobs that are too short or ad-hoc for a full scrum process. The client and the developer need to be in this meeting, and sometimes it might make sense to have it at the usual daily scrum time.

    In this meeting, you should check the following:

    1. Look at the board
    2. Look at the backlog (if just using Kanban this might be the same as the board)
    3. Ask what has been done since the last Mini-Review (or the start of the project)
    4. Ask what will be worked on next
    5. See if the current booking remaining is sufficient... i.e. book in more time as needed

    Ideally, the account manager would be a good person for this.

  41. It’s important that your salespeople work together to help each other through blockages, and also that they keep each other accountable so that no one drops the ball for an extended period.

    You should organize a weekly meeting for all Account Managers. The focus should shift each week between 2 topics:

    1. Opportunities

      • Look at all current opportunities and make sure there is a plan for a continuance. Agree to close off any that are no longer viable
      • Discuss if there is any industry news or hot topics that could be interesting or that might be good for client conversations
    2. Current Projects

      • Look at the way your current resources are being used and make any adjustments necessary. In the case of a consulting company, identify if all bookings are up to date, and potentially if under-used resources need retraining or re-allocation
  42. As a consultancy, your developers expect to see a variety of projects in their time working for you, and if they get stuck on any one client for too long, they may decide to look elsewhere for that variety.

    In order to keep them interested, it’s a good idea to cycle them off and on to particularly long projects. This should be proactively offered to developers, as they may not realise it’s an option.

    You also need to make sure this is not a nasty surprise for the client, so it’s best to add it to your contract or Terms and Conditions  so it’s understood from the start, and can always be referred back to later. To soften the blow, offer to cover the costs of the new developer for the handover period (normally 1-2 days)

  43. Do you upsell your products or services?

    Great consultants see opportunities and know that once they’re in at a client, they become a trusted advisor, and anything they say will have more weight than the same message coming from a Sales Person or an Account Manager.

    Not all software developers are comfortable with “upselling,” but it is important to be on the lookout. There are 2 key scenarios:

    Once a software developer sees an opportunity, they should have a corridor conversation and see if they get a positive bite from the customer. If they do then they should hand it over to the Account Manager to track in CRM (from there the client should be massaged until the new work is booked in).

    1 - When selling a product, upsell your most valuable service

    Most prospects come to your organization to seek a solution to a problem or need. By doing so, they place a certain amount of trust in you and your judgments. They trust a software developer can alleviate their problems, address their needs, and sometimes suggest an alternative plan of action.

    Say you are talking to a customer having problems with a product e.g. Upsizing PRO! - if they are still having problems with upsizing to SQL Server, they probably need some help beyond what our program can provide. Therefore tell them about how SSW has upsized smoothly, so many databases for so many clients, and that we can help them. Though this example may not come across as an up-sell, little suggestions like these can bring in more consulting plus it shows that you're on the ball and looking out for your customers' needs.

    Customers normally appreciate this sentiment. You need to remember that prospects don't always know exactly what they want or need and that's exactly why they've gone to the experts - YOU.

    2 - Consultants should always be visible when they spot an upsell/cross-sell opportunity

    When an Account Manager sells a solution to a customer, they are generally not trusted and have a bunch of competition.

    When a developer sells the same solution to a customer they are generally trusted and have no competition - It is easier for a dev to upsell/cross-sell.

    Upselling is when you go to McDonald's and ask for a soft drink and they say:

    "Would you like a larger soft drink for only 20 cents more?"

    Cross-selling is when you go to McDonald's and ask for a burger and they say:

    "Would you like fries with that?"

    This is the same as when a dev goes to a client to build an Angular application and they notice their dodgy excel reports and say:

    "You really could do with a great reporting solution that could give you insights into your business. After this work, I could look at PowerBI for you. What do you think?"

    Some developers see lots of opportunities for upselling, and once they get a positive bite from the customer they hand it over to the Account Manager to track in CRM. From there the client should be massaged until the new work booked in. This is important as Account Managers can then track and report on opportunities that have been won or lost.

    Scenario: You overhear the client talking about implementing Azure AD. You do nothing and continue with your work.

    Figure: Bad example - of upselling

    Scenario: You are having an initial meeting with a client about developing a new in-house application. During this meeting, they mention a few additional projects to be completed. These include implementing syncing between their on-premises AD with Azure AD. You advise them that you have some SysAdmins that could assist in this work, and ask if it is ok for your account manager to call them.

    Figure: Good example - of upselling

    3 - Advice from trenches

    From the above video, you can see that the software consultants at SSW completed a Microsoft Form with the question: Your advice: Pretend you are talking to a junior dev about this concept of upselling. What do you say to them? Here were some stand out answers:

    Screen Shot 2020 09 10 at 10 16 58 AM
    Figure: Good ways to upsell

  44. The goal of a modern complex software project is to build software with the best software architecture and great cloud architecture. Software developers should be focusing on good code and good software architecture. Azure and AWS are big beasts and it should be a specialist responsibility.

    Many projects for budget reasons, have the lead developer making cloud choices. This runs the risk of choosing the wrong services and baking in bad architecture. The associated code is hard and expensive to change, and also the monthly bill can be higher than needed.

    The focus must be to build solid foundations and a rock-solid API. The reality is even 1 day of a Cloud Architect at the beginning of a project, can save $100K later on.

    2 strong developers (say Solution Architect and Software Developer) No Cloud Architect No SpendOps

    Figure: Bad example of a team for a new project

    2 strong developers (say Solution Architect and Software Developer) + 1 Cloud Architect (say 1 day per week, or 1 day per fortnight, or even 1 day per month) after choosing the correct services, then looks after the 3 horsemen:

    • Load/Performance Testing
    • Security choices
    • SpendOps

    Figure: Good example of a team for a new project

    Problems that can happen without a Cloud Architect:

    • Wrong tech chosen e.g. nobody wants to accidentally build and need to throw away
    • Wrong DevOps e.g. using plain old ARM templates that are not easy to maintain
    • Wrong Data story e.g. defaulting to SQL Server, rather than investigating other data options
    • Wrong Compute model e.g. Choosing a fixed price, always-on, slow scaling WebAPI for sites that have unpredictable and large bursts of traffic
    • Security e.g. this word should be enough
    • Load/Performance e.g. not getting the performance to $ spend ratio right

    Finally, at the end of a project, you should go through a "Go-Live Audit". The Cloud Architect should review and sign off that the project is good to go. They mostly check the 3 horsemen (load, security, and cost).

    MS Cloud Design Patterns Infographic SSW Edited

  45. Do you know when to go for a Tender?

    Tenders, RFP (Request for Proposals) RFQ, (Request for Quote) plus other various names, are all a way for an organisation to conduct a buying process with set rules and a supposedly level playing field. For the most part, certain elements of Tenders can be counter-intuitive to building great software. In many cases, it needs the buyer to know exactly what the end product will be. Plus the buying process can require the tendering company to spend large amounts of time with a very low chance of success, unless you follow a few principles.

    Government departments are a classic example of an organisation that needs to produce Tenders. There is a fiduciary requirement when spending public money that the purchasing process is transparent and allows all suppliers to compete on a level playing field. These can be very time consuming and expansive documents and they limit contact with key stakeholders and decision-makers.

    Why is it a problem for software consultancies?

    Most Tenders have a few things in common when it comes to software. They are very rigid and are structurally counter-intuitive to the agile method of building software. Often, Tenders have rigid rules and look for a fixed price with complicated and time-consuming processes to alter the agreed-upon framework.

    What is the problem for sales teams?

    There are never any guarantees of winning any work regardless of the efforts taken to win business, but Tenders often invite significantly more competitors that you would generally need to compete with. Secondly, Tenders are written documents that are supposed to level the playing field - this is not always the case.

    Generally when a supplier and vendor relationship is formed, there are 1000's of data points - reputation, past client success, culture, displayed skills, communication style, internal disciplines, plus many other intangible items. Tenders often don't ask questions where the relevant strengths of a supplier can be demonstrated - you are forced to only answer the questions asked.

    Tenders can favour an incumbent supplier - or suppliers with an intimate knowledge of the client.

    Be selective with tenders you reply to

    Tenders are time-consuming for a sales team and generally need a process like a Spec Review performed at no cost, in order to complete a response and, as a result, decision to submit a tender needs to follow a few key principles:

    1. Do you have a pre-existing relationship with the key stakeholders, or does the tendering process allow you to build a relationship where you can not only complete a document, but some of the intangibles are taken into account in person-to-person meetings.
    2. Although organizations will generally be guarded about information about the competitors, if there are any more than 4 known competitors and the above no. 1 point about the relationship is not strong enough to make the vendor feel that they will be naturally shortlisted, do not respond. You are probably only there to make up the numbers.
    3. Look carefully at the process to make changes and how detailed the scope is. Also, see if a spec review can be undertaken to fine-tune the estimates and scope. Plus make sure the process of Agile development is something that can be undertaken.

    Tenders can be a waste of time, with low skilled assessment by purchasing people who can overly focus on cost and a narrow set of requirements. Only go for them if you have a good chance of winning.

  46. Do you treat freebies as real customers?

    In the course of business, you may occasionally provide some services or products to selected customers free of charge or at a discount rate. Often, because you're waiving one rule (the "please pay me" one!), people assume all other rules of service are waived - you should avoid that assumption!

    1. Freebies/discounts need just as strict controls as regular projects

    When you are giving something away at a discount or for free you are expecting a loss compared with a regular client. If you fail to follow regular processes not only will you incur an even greater loss you provide a lesser standard of service and put greater risk on the success of the project.A discount or freebie should follow all the standard processes such as:

    Consider the follow scenario:

    You have a concreter buddy who offers to do your driveway for mate's rates. He won't accept full price (because you're friends) and he thinks he's doing you a favour. The problem is, he won't commit to a timeframe because he has customers that ARE paying full price. You're quite happy to pay full price, because you know he does great work and you want to support his business. In the end, no one is happy. You have an extended wait to get the job done for a discount you don't want and he feels pressured to do extra work in his spare time.

    A better approach is for the concreter to offer the discount AND book you in as a normal customer. He can give dedicated time and professional service and you get the job done with minimal delay. You can also provide excellent feedback and suggestions on the service he delivers, being both a friend and a customer. It is a much better outcome.

    2. Feedback on events, products, or services

    Often the people you choose to provide a freebie are the best people to provide feedback on your product or services. When you waive all your standard processes, they have no opportunity to review how you conduct your business. So if you're offering a freebie (or any discount), you should ensure every normal standard of business is followed (including sending $0 invoices!) and make sure you get valuable feedback to help you run your company better.

    Figure: Good Example - Asking for feedback

    Zero Invoices:

    When entering timesheets for free work, set your rate to $0.

    zero timesheet
    Figure: It is a good idea to set your rate to $0 and show it on the invoice

  47. Once your internal testing is complete and you believe the fixed price project is finished, its important to clearly communicate the beginning of the warranty period.

    Send an email like this:

    From: Account Manager or Dev To: Client CC: SSW Team  Subject: [Client name]: Fixed Price component

    Hi XXX,

    As per our conversation, we confirm that we have now finished the application, and so commences the 7-day warranty. The last day of the warranty will be XXX.

    During this time, any defects or variations from the scope (as defined in the Specification Review document) will be fixed at no charge. See section 10 of for more details.

    If you find things that you’d like done that are not specified in the document, we’re happy to do those on a Time & Materials basis after the warranty period has ended.

  48. Towards the end of the warranty period, it’s important to ascertain whether the client would like to continue any further work on a Time & Materials basis, and let them know that, if not, it’s likely their developers may be booked for another client.

    Your 1st choice should just be to book the developers for some ongoing T&M days, but, failing that, send the following email:

    From: Account Manager or Dev To: Client CC: SSW Team  Subject: [Client name]: Transition back to T&M

    Hi XXX,

    As per our conversation, XXX is the last day of the warranty period. You have not currently booked any of the developers for any ongoing work, so please be aware that they may be booked to another client moving forwards.

    In the instance that you need more work done after they’ve already been booked out, we can still support you with other developers as needed, but be aware this may incur some ramp up time. If you want your original developers, you may have to wait until they finish whatever project they get allocated to next.

    If you need to be able to guarantee quick turnaround times, maybe think about signing up for a Support Plan:

  49. Schedule a Specification Review

    For almost all projects, there is a need for additional requirements gathering. Some clients don't have any kind of specification, while the specifications you are given can sometimes be lacking in detail or incomplete. Accordingly, before you can provide an estimated price for completing the project, there is another step that requires the engagement of your resources - the Specification Review .

    It is the responsibility of the Account Manager during the initial meeting to present the benefits of a Specification Review for the client. Following the initial meeting, the Account Manager will send a brief proposal in the form of a Post initial meeting email through to the prospective client for a Specification Review.

    Note: Make sure everyone who was in the meeting from your company checks the email before it's sent.

    It may be necessary to conduct a second initial meeting with a technical specialist attending as well.

    You may also find that some clients are unable to progress to a Spec Review until they have a vague ballpark. In these cases, the salesperson is to make the decision whether an extra 4 hours will be spent investigating the solution before the ballpark is given. This should then be sent as part of that "Post initial meeting" email mentioned above, with Spec review info swapped out for ballpark estimate info as required.

    A salesperson has 16 hours per month of developer time they can invest in this pre-sales investigation, so this time has to be used wisely.

    adam cogan ceo in a business meeting
    Figure: Pre-sale meeting - use time wisely

    Never offer a fixed price at the conclusion of an Initial Meeting, and this engagement model must be chosen before the Specification Review is done.

    More on the Specification Review rules.

    Brief Proposal MrNorthwind
    Figure: Send a brief proposal

    Ad-Hoc work/Consulting

    In case the work is thought to be less than 3 developer days and the scope is well understood, it may be worthwhile for the developers to commence work straight away without a Specification Review. Normal standards for work should be followed, such as daily scrums. This type of work is called 'ad-hoc' work.

    You may also immediately commence ad-hoc work if the client is a technical client and you are providing resources for an existing project under the sole direction of the client.

    • Do you incentivize a quick Spec Review sale?
  50. It’s easy sometimes to accidentally undersell something or someone by using potentially derogatory words that may give a client the wrong idea.

    This can be especially bad if you’re using potentially triggering words or phrases:

    XXX is more junior/less experienced/less skilled than YYY.

    Bad Example – Why are they paying for a junior, a less experienced, less skilled person?

    XXX is more affordable than YYY.

    Good Example – Avoids trigger words like “junior” and has a positive spin and an upside for a client.

    XXX needs more time to learn this technology.

    Bad Example – Why are they paying for someone to learn?

    There’s always a short period of upskilling in any project until everyone’s fully proficient in the whole stack.

    Good Example – Normalizes the issue

  51. The easy thing is to just quote the price in your local currency. Go the extra step and convert it to a currency they understand.

    If you are not sure what currency to use, just use US Dollars, which is the international currency.

    Of course, if you are dealing with somebody regularly, then you should know their preferred currency.

    E.g. Chinese company billing someone in Brazil:

    Our price is CNY 1,000

    Figure: Bad example - the client will need to convert it

    Our price is CNY 1,000 (about USD $160)

    Figure: Good example - USD gives a clear understanding of the costs

  52. When your team has completed an important milestone successfully, they should be rewarded with a morale boosting event such as lunch, dinner, the movies or bowling.

    Figure: Email to accountant/team members and client informing of project success and reward event |

    Note: For smaller milestones, you can still give the team recognition though a "Ring the Bell" email.

We open source. Powered by GitHub