This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-10
Channels
- # aleph (4)
- # announcements (27)
- # aws (12)
- # aws-lambda (1)
- # beginners (207)
- # boot (4)
- # calva (8)
- # cider (9)
- # clj-kondo (9)
- # cljs-dev (27)
- # cljsrn (6)
- # clojure (104)
- # clojure-android (3)
- # clojure-dev (9)
- # clojure-finland (2)
- # clojure-italy (18)
- # clojure-spec (8)
- # clojure-uk (100)
- # clojurescript (43)
- # clojutre (1)
- # core-async (49)
- # cursive (18)
- # data-science (3)
- # duct (24)
- # events (2)
- # fulcro (27)
- # immutant (1)
- # off-topic (32)
- # om (2)
- # onyx (2)
- # pathom (14)
- # pedestal (2)
- # planck (3)
- # re-frame (38)
- # reagent (7)
- # reitit (10)
- # rewrite-clj (7)
- # ring-swagger (3)
- # shadow-cljs (32)
- # spacemacs (63)
- # test-check (16)
- # tools-deps (5)
- # vim (21)
@lady3janepl I've started "deep work" this morning. On reflection I think that non distracted hours are non-negotiable. So I think the real conversation point is counter balance tools. Over the weekend I played with generating a who knows what knowledge graph, the idea being to direct conversations to the right people when you need help. But perhaps the tool should instead be focused on getting people to contribute their learnings so that company knowledge can be accumulated and reviewed?
start crashing a bus into nodes of your knowledge graph
also đ
Morning
Yeah, I think putting knowledge down in a central/shared location is very important. Main hurdle here though is reviewing everything on a fairly regular basis to make sure obsolete knowledge is removed/updated and emerging gaps are found/covered to avoid confusion over time. Documentation is hard đ¤ˇ
logs are good for recording your last thoughts. Wikis are good for recording the current consensus
we currently use an internal blog for a lot of our stuff, but I do miss having questions answered and things resolved and a clear statement of our current understanding
Conflicting opinions seem like they should both be in logs and readers can decide based on that.
I'm saying that the logs can hide conflicting opinions and a lack of consensus and that there is no way for someone to decide from that (or even decide if there is still a lack of consensus)
incl. who creates the log (power over what goes into it, if it's not automatic), and who reads the log (reader bias for most recent records etc)
yep, power and resistance are inescapable. Generally, when I've started a wiki at a company it was an act of resistance. đ
đ Assuming they are kept up-to-date https://clojurians.slack.com/archives/C064BA6G2/p1560155274158800
re wikis and current consensus
100% agree đ
>Documentation is hard đ¤ˇ
I suppose a lot of this also depends on the area/domain being documented
having a graph of who knows what would allow you to see: 1) orphaned areas (and managing soon to be orphaned areas when someone is leaving) 2) people who are overloaded, people who have not been given enough responsibility 3) people who tend to overlap
and then internally there are also networks of who counts on whose support, which is completely informal and cuts across the normal company structures
and also the last time I asked an HR person about this, she told me she: 1) studied it at uni 2) would never dream of attempting to map it inside a company because it's horribly invasive.
yes, Formula 1. they have a case study. I've never been sure how much of this was just marketing and how much was actually useful. Got them a good acquisition price tho. https://quantumblack.com/work/auto-development/
I did a research project that did something lightweight and similar
it was⌠well, interesting in terms of how social groupings fell out
the text mining part was past our remit though
and the whole thing was super invasive regardless
oh, it is massively invasive and deeply problematic. It might be OK if you state up front and repeatedly that emails might be used for this. Then people could keep other private conversations out of their email.
yeah I mean we had to get ICO oversight and all sorts, and it was a university research project, but I was super freaked out by it tbh
Yeah, to infer the important topics from the document, and relay that into the graph.
also for automation maybe something like: specify which repos / areas of code an article is responsible for, and automatically list out-of-date articles to be updated by their respective authors once that code was modified later than last modification date of article
hey, let's revolutionise the world of organisational knowledge management, in Clojure đ
There's quite a lot of automation value we can get from analysing code. You can analyse my projects and realise that I've worked on lots of code using yada, and automatically highlight me as someone to ask.
I haven't looked at what is out there yet, because I don't want to be too influenced by other solutions :)
I wonder if there's anything in recording processes? E.g. Recording the terminal session every time someone does a deploy means that the log is reasonably up to date. (Although slow to parse)
This is part of the push towards chat ops. Wire things up so your log / system of record is slack/IRC etc. And wire up all ops tasks to bots either watching the channel(s) for commands or pushing the commands run to the channel(s).
I'm saying that the logs can hide conflicting opinions and a lack of consensus and that there is no way for someone to decide from that (or even decide if there is still a lack of consensus)
this is true in any documentation tho. Including logs.
yes, Formula 1. they have a case study. I've never been sure how much of this was just marketing and how much was actually useful. Got them a good acquisition price tho. https://quantumblack.com/work/auto-development/
my 2c - a lot of comms problems are intractable, hire good people, try and focus on comms skills aaaaand⌠it will all still fall over
ÂŻ\(ă)/ÂŻ
thatâs where good leadership comes in
@alex.lynham how do you see the good leadership as fixing the comms problems?
trying to connect up conversations
I mean, this is why I found doing that role unsustainable for my well-being
so ymmv
Logs have the benefit that they happen automatically. However they can be impossibly hard to read and follow if you werenât part of the conversation; (or sometimes even if you were). Real decisions and current thinking needs to be captured and curated. The logs are a fallback, and nice to have around⌠but they donât really capture or communicate knowledge. Knowledge is best captured and communicated through good writing. However thatâs expensive, which is why the logs are nice to have too⌠but theyâre the cheapest and (usually) worst option for the reader đ
and @otfrom itâs worth saying that it means that you become a bus factor of 1 - not for knowledge but for behaviours if other people donât see why you do as valuable, cc @lady3janepl and the âglueâ phenomena
Knowledge sharing is something that benefits the entire team, but is not within most people's core responsibilities
the number of times I stumbled into situations where two teams were diverging, and nobody above or below my level had noticed or cared was⌠insane
@lady3janepl don't get me started on the tragedy of the commons (and how it is a myth)
this sums it up pretty well: https://mronline.org/2008/08/25/the-myth-of-the-tragedy-of-the-commons/
tl;dr the tragedy of the commons is just right wing propaganda to support privatisation and rent seeking
A problem is that often people with the knowledge a. don't have time or b. can't be arsed, to inform others
but thatâs why for a good portion of my time at the old place I didnât even get assigned a team, I just was left to use my judgement as to who needed help or who needed visibility⌠and a lot of what I was doing was just trying to help people find the right people to talk to, it was mad
@alex.lynham that sounds like a good way of frustrating someone
that's a valuable role, as long as you can get someone above you to recognise that it's a valuable role
but ime large organisations simply fracture into vertical groups and there is not a sane way of bridging them. even smaller ones can do it.
did you at least get a good title like a coach so they knew they had to listen to you?
all these things are also dependent on you wanting to do them, job titles aside đ
there is that. đ At least if the title was "coach" then it would give an idea of what the job would be like and whether or not you'd like it.
yeah I think it was one of those where nobody knows they need it until they need it
if youâre that shape of person you end up doing it :man-shrugging:
I suspect âtis my lot in life, in the long run
I think all things being equal in a large organisation; organising into verticals tends to be better than organising into horizontals - itâll lead to more duplication of effort; but less dependencies. Also some would argue the ideal is a balance between chaos and order. Dee Hockâs chaordic âorganisationâ.
@rickmoynihan ah, the return of silos. There are some real advantages to it. There are some real downsides too.
oh absolutely â though the same can be said of being purely horizontal. Iâm really only talking about a hypothetical case of pure vertical vs pure horizontal (if such a thing ever existed). My real preference as with most things is to think hard about it, and not to treat the differences like a religion đ.
Macromedia was kind of interesting in that regard: it was mostly organized into silos but had three cross-cutting teams that work with all the siloes.
Each product team was autonomous but there was an overall production strategy team that was also technically deep and it worked with all the teams on common architecture, infrastructure, shared components, etc. There was also an overall experience design team, that cross-cut over everything Macromedia exposed to the public. And then there was my architecture team that worked across everything outside of products (all the back office systems for the entire company) but also with the product teams whenever they needed to interact with IT/company infrastructure. Such as the "news & community* widget that was part of most products' UI back in the early Studio days.