[notes] On clear/effective communication, providing sufficient context/detail, etc

Some collected notes and references with regards to clear/effective communication, providing sufficient context/detail, etc.

Feedback: while it might feel like it saves time to use shorthand/be high level/ambiguous/non-specific when communicating; it ultimately leads to confusion, miscommunication, wasted time back and forthing, and frustration; which ends up taking more time than it would have to be a little more specific/verbose up front.

I understand if we don't have documentation for stuff like that, I can look at the code and reverse engineer it.

But what I can't get from the code is the relevant historical context/organisational knowledge that goes with it.

You said: "Historically the process created the user"

To me, ""Historically the process created the user" implies that you have historical knowledge that I don't have, that some 'process' created the user. In your brain you likely know exactly what you mean when you say 'the process'. But i'm not in your brain, nor was I around to have earned that historical context myself; which is why I ask questions to try and get a more specific/detailed/actionable answer out of you, or I go and spend more time/energy trying to reverse engineer it myself, which has the effect that your comment didn't end up adding much useful assistance, even though to you/with the knowledge in your head it might have felt like it should have

The other part of the question that I asked relates more to our 'business level' rules of things: what, at a technical level, does XXX's "stop non-admin from installing" relate to.

Eg. what does 'installing' mean to you/us at a business rules level.

Is creating a AAA 'installing'? Or is something that happens in BBB and/or CCC 'installing'?

Or nothing to do with any of these, or something else entirely?

I can spend an eternity looking at the code, reverse engineering, guessing, etc; but at the end of the day, if I don't know the higher level business rule definition of what it means, I can't really align the code to meet that need.

I know XXX is trying to find that balance between moving quickly and taking the time to discuss/clarify.

nods yeah, I understand that. It can be hard to find the balance, particularly when it feels like being 'quick' about something should intuitively lead to things happening quicker. But unfortunately that only works when everyone is on the same page to begin with; and in many cases, assuming that that's the case leads to issues. Providing a little more of that up front context/etc can save time/miscommunications all round

My preference is generally written communication as it captures the details such that I (or others) can refer back to it in future, and serves as a 'point of record' for capturing 'intangible organisational knowledge' that otherwise can stay locked up in individuals heads. It also tends to work better in an async style, so that all parties don't need to be present/active at the same time to progress the conversation.

Chatting/video call/etc can be useful when there is some specific details that needs to be figured out, or the discussion is more complex/etc; but often it can be an inefficient use of time, and often also leads to that information discussed/figured out being 'trapped' in the heads of those that were present, or 'lost' over time, with no solid source to refer back to

Have you shared your generalised feedback with the rest of the team about nobody responding to messages? it's a good one and can hopefully incentivise people to start stepping up and into the convo more, without it all falling on XXX

I haven't shared that, as it feels like it would also just fall on deaf ears 😜

But also feels like something that shouldn't really be 'on me' as an 'individual contributor'. It's those sorts of 'micro scope creeps' that lead to me ending up taking on all of the responsibility for trying to get an org into patterns of efficient/effective communication/process/etc; which when combined with a lack of 'authority' for people to listen to it + general human tendencies of not liking change/taking a while to be able to get to it; just ends up contributing to me burning out.

Hadn't looked at REDACTED at all, though looking at it just now, a title of "REDACTED" with no other context/content isn't a valid issue to be assigned to me in a sprint. It's going to need to be way more explicit than that.

It may as well be "do stuff with the things"

This is an issue i've noticed fairly consistently across our Jira issues, and something that really needs to be improved upon if we want to be a functional engineering organisation

placeholders for me to capture details into

Makes sense, and placeholders are fine, but placeholders without details aren't 'ready', therefore they shouldn't ever appear on a sprint board.

Remember, Jira is primarily for planning right now - a product management roadmap - which means it is a scratch pad for prioritising to support investigation/estimation of effort to do i.e. adding detail to issues

Eh.. that is only partially true, and that should only be true for the ungroomed backlog. Sprints should only contain fully complete/fleshed out issues that are ready to be worked on. If we're not doing that, then we're shooting ourselves in the foot before we've even started, and we need to not do that.

It's in the sprint to get an estimate of effort

That's generally not something you would add an issue to a sprint for, and even if we decided that that is the way we want to do things, then the issue STILL needs to have that relevant context added to/explained on it

A short/easy/good rule of thumb/sanity check to live by to ensure that you're correctly capturing the relevant details: If it doesn't exist in the issue, it doesn't exist.

I think it sounds like you need to establish a shared understanding of how to use Jira. Or potentially some more jira states

That’s why I’m providing feedback on how to improve the processes in line with industry standard / best practices

Not that it’s something I should even really need to be doing for someone who’s played the PM role REDACTED for years and years

I don’t really have the time/capacity to go and fully articulate and teach the basic concepts of a role that isn’t mine, in full, right now

Given appropriate feedback and guidance, the PM should be going and learning what is expected within that role and upskilling themselves to align; asking questions where required to check in, etc

HackDevTranscend / meta

[notes] On clear/effective communication, providing sufficient context/detail, etc #10