Fantastic. Iām a fan of many agile ideas but good to see you guys doing what works for YOU, rather than a strict adherence to a methodology.
A follow-up then, given you donāt have a defined/committed list of tasks, how does that play out with the product owner who has to interface out to the customers/marketplace and so canāt easily predict when feature X will land? (We had this issue at my last place⦠Sales in particular always want to know WHEN, and we have to say SOON!)
I loved reading through this article⦠to the point where I have actually implimented the runbook format in my department as the documentation is currently shocking.
Who can help? ā Who can I talk to if I have questions with this process? Who can I escalate to?
Symptoms ā How can I quickly tell that this is what is going on?
Pre-checks ā What checks can I perform to be 100% sure this is a sensible guide to follow?
Resolution ā What do I have to do to fix it?
Post-checks ā How can I be 100% sure that it is solved?
Rollback ā (Optional) How can I undo my fix?
I was wondering how you handle procedures and other documentation at Monzo? Do you use a similar format and is there any guidelines you use for that?
We have some new software and hardware releasing in Q3 and I cant get my head around the best way to document all aspects for my team to support it.
Not trying to be glib, but hire a technical writer. Thatās what they do for a living! (check out www.istc.org.uk for examples, many do procedures and internal docs as well.
Oh I would if I could but Iām at the bottom of the chain. I stress its importance to management but nothing comes of it. I know I cant create anything perfect, but if I can make life easier for my colleagues, then great.
We tend not to make commitments about when a specific feature will land, but we definitely challenge ourselves to meet āinternal deadlinesā. We might say āHow can we get this feature out to staff by X date?ā or āWhat could we do to get this into Labs before the next release?ā
We manage app releases using release trains, so itās common to hear people talk about features being slated for a specific app release ahead of time. If we donāt make a release or an internal deadline, we try not to be too hard on ourselves but instead reflect on why we didnāt make it and focus on finding the fastest way to getting back on track.
Most of our documentation (including our policies and proceedures) now lives in Notion. Knowledge management is one of the main areas weād like to focus on as a team of Engineering Manager. Itās definitely been hard to keep everything in sync (and in one place!) as weāve grown. Weāre looking at working with some technical writers and content strategists both on our technical documentation and our company-wide knowledge.