Photo by Nick Fewings on Unsplash
Yesterday things got heated on one Jira ticket between an Account Manager (AM) and a Presales Engineer (PE).
First a bit of a context.
I lead and manage the Solutions Architecture team for a data acquisition and data engineering services firm. On a day to day basis, people come to us with their data requirements, we look at them and propose a feasible scope and costing that aligns with their budget, timeline, business goals.
It’s also worth mentioning that this firm is a globally distributed team of close to two hundred people, all working remotely even before the pandemic.
As with most custom B2B software consulting services, requirements gathering, scoping, and costing are iterative in nature where more often than not we need to hold the customer’s hand in thinking through their requirements.
With the evolving requirements, we negotiate on scope, adjust the costing accordingly, and last but most importantly: document the proposal in a consistent and comprehensive way to capture and reflect everything that has been discussed.
Things get messy. It is not uncommon to be nurturing and developing projects with one customer for months. And keeping track of all of these requires high degree of context switching.
Adding to this, there are sometimes extra layers between the different roles and stakeholders: the buyer, the user, the sales rep, the engineer, the delivery engineer, the PM. Things easily turn into The Telephone Game.
Managing expectations on steroid.
We use Jira as our single source of truth. “If it’s not on Jira, it doesn’t happen“, is one principle I ask my team to keep in mind.
So, I’m sure you know what Jira is. But for the sake of clarity, doesn’t hurt to say that Jira is one tool in a suite of Atlassian’s cloud-based project management tool. The tool relevant to this story is this ticketing system, where different teams can create, accept, and track “tickets”.
Now back to the ticket. 51 comments since 4th of August. Changing data sources, data models, collection and processing frequency, coordinating and aligning with operational teams to assess feasibility, compliance, technical notes, calling out assumptions, changing stakeholders.
In this situation, the customer signed a proposal containing data model definition that doesn’t actually match what they wanted. Now AM is trying to understand the cost implications if we go back to them with an updated proposal and PE can’t seem to give a satisfying or enlightening answer to AM. I believe both PE and AM understands this and are both frustrated that their messages are not getting across. But the way they communicate on the ticket are ineffective and ripe for miscommunication.
G: I am referring to delivering against the schema which has been signed for. As with the [another project’s] case, if the customer refuses to re-sign and instead holds us to account for the contract which was signed, what are the cost implications of this? As mentioned, it would be prudent of us to understand this – unless it has and I’ve missed the revised estimation file.
A: The contract they have signed has the data that I fetched myself from the site, so we are very very safe. It’s just that they shared the schema themselves, and it wasn’t properly vetted by me before. They would be expecting this schema but have signed the contract regardless.
A: Now, the files I attached above contain schema that the client provided and is expecting and we have also pruned it to remove fields that we can’t extract from this site.
A: The effort/infra estimates would still be the same, regardless of what we deliver (The schema in SOW vs Schema shared above). I hope this clarifies the situation !
What is wrong with these?
AM’s comment can be simplified into: “if the customer decided to stick to the contract they already sign, will we be able to deliver within the proposed cost?”
PE’s comment can be broken down into:
* The schema in the contract that the customer had signed is feasible. I created it based on what we can extract from the site. My cost estimation was based on this. This schema, however, doesn’t actually match the customer’s latest request on [enter date] (link to the attachment).
* I didn’t properly vet this latest request (my bad), thus they did not make it to any contract document.
* I have reviewed that latest file shared by the customer, adjusted our version that we proposed, and attached the updated schema here [link]. I’ve also removed fields that we can’t extract from this site, so not everything in the customer’s file will be included in this updated schema.
* The cost estimates hold up either the customer decides to stick to the signed contract or accepts this new contract with an updated schema.
After clarifying with PE and AM (two out of five people who have commented in the ticket so far), I posted this:
Summarising here for the sake of clarity.
- The schema in the SOW that the customer had signed is feasible, but it doesn’t actually match their expectations.
- We have now created a valid schema that aligns with what the client shared (we only include fields that we can extract).
- Applying this new schema won’t affect our costs to deliver (what has been estimated is fine).
- Essentially: we’re well covered either the customer decides to stick to the signed SOW or accepts this new SOW we’ve updated.
- Now we can either update the SOW to contain the version that aligns with the schema that the client shared.
Always summarise. Summarise what was discussed off-Jira, add meeting notes. Think what it is like for all the other eyes waddling through the ticket.
A good structure for your summaries:
- What has happened
- What should have happened
- What now
Be mindful of the medium. Jira comment system is akin to logs; it is linear. It does not support a threaded discussion where it’s easier to contextualise your comment. Always make your comment as atomic and standalone as possible. Mind the communication latency with these asynchronous tools.
- Out of context: “The estimated effort of 2.5 days should still work”.
- Better: “The estimated effort of 2.5 days should still work to add the requested fields”.
- Even better: “The estimated effort of 2.5 days should still work to add the 6 requested fields because they doesn’t require additional HTTP requests”.
Refer and link to other tickets, past comments, and emails. Elaborate on pronouns (it, they, we, he, she, which schema, which SOW, is contract the same as SOW?).
Use appropriate text formatting to emphasise points and enhance readability. Use headings to create sections, use bullet points.
Use simple words. Punctuate.
Make your intention clear. Are you commenting to inform, to ask, to suggest, or to confirm? Be specific, be explicit, address the full context, not only the last comment. Ask effective questions.
Document your understanding, document your assumptions. Don’t use “I think” to share facts. Be aware of which ones are facts and opinions.
Make use of Jira’s custom fields to put summaries of the project’s key features. For example the customer’s budget, their use case, the technical components involved in it, the type of offering we are proposing, technical savviness of the customer.
With knowledge work shifting more and more towards distributed and collaborative, communicating effectively on a remote working environment is an important skill to hone.
Designing a streamlined communication infrastructure is as important as ever. We need to be mindful in managing data and information flow to reduce cognitive load.
Make it easy for people to get information without processing all the data. Help them make sense of things quickly.
Yes English is not PE’s first language but he is well above average and I have seen this issue with my native American team member.
Writing clearly in English is a skill you can get better at. Communicating across culture in different forms and through medium is a skill you can get better at.
Also published on Medium.
