Connects Strava in Discord and reposts athlete and club activities into Discord channels, including time, distance, pace, map and weather. Open-source at https://github.com/dblock/discord-strava.
Joey who opened https://github.com/artsy/README/issues/427 is one of the best 10x engineers I’ve ever had the privilege to work with. If it’s important to him to rename all branches from “master” to “joey” I’d add my plus 1.
tl;dr The README became possible because Artsy is open-source by default, and someone just decided one day to create a repo and some content, and didn't need permission to do so. It's also the repo that most new hires read before they even apply to the job, and they don't need permission to make changes either. GitHub workflow is how everything gets done.
Does one of these documents (or any other source, not necessarily from Artsy) explain this concept of "open-source by default" and permissionlessness in and of itself?
I know the book "Turn the Ship Around" which talks of the difference between a culture of asking permission versus announcing intentions etc. Is it sort of like that?
We failed early. Had a wonderful demo day. Tons of sign ups. It started getting a bit long. Someone decided to shorten each session (max 2 minutes) and choose which ones were worth demoing. So you basically asked for permission to demo. Sign ups stopped. Nobody wanted to demo anymore. Demo day died and took a year to restart properly.
In general, establish “how”. Everything is in writing and GitHub workflow. When someone says “can I?” the answer is “why are you asking and haven’t done it (submit PR) yet”? This moves permission to a public discussion.
Think in terms of must have, should have, nice to have, not allow/disallow.
Managers already have the power to veto, so they don’t need to approve, allow or disallow. Managers need to say that to everyone all the time - “you have an idea, why haven’t you done it yet?”.
Everyone needs to do things very visibly and over communicate to enable gentle redirects and avoiding getting to veto.
Losing control is hard. Communications team wanted to review and control the engineering blog. I said hard no multiple times with every new comms leader. Asked them to comment on PRs.
Don’t fix problems that don’t exist. If someone wants a knob that looks like permission, ask them what problem they are trying to solve.
That sounds pretty similar to another place I worked that I have very mixed feelings about. There are a lot of paradoxes that need to be resolved there that weren't quite worked out.
For example: While an IC could technically just start doing something that he felt should just get done even if no manager had assigned him that task, it would have taken time away from tasks managers had in fact assigned. Now, while managers weren't allowed to reprimand that IC for doing unassigned tasks on their own initiative, they could reprimand him for not making enough progress on the assigned tasks. Some managers would do this systematically: Like if some work done by one of their underlings popped up somewhere that seemed to have taken a lot of time, they check extra hard (and push extra hard) on whether that individual is also making enough progress on assigned tasks. So, the individual is facing a choice of: Either I don't do any tasks from my own initiative and work normal hours, or I show a lot of initiative and work crazy hours. And people were working "all-in" contracts where they couldn't claim overtime pay.
Prima facie, it's still nice for people who are young and eager to prove themselves by working crazy hours. But the effect isn't what you'd think, namely that they'd get stellar careers out of it. Rather, it made managers less accountable when doing things like incurring technical debt and let them "off the hook" with regard to getting work done that's necessary to do but also a thankless task where the relationship to business objectives is not so visible. For example: automated testing, tooling, code quality, and so forth.
Managers always pushed extra-hard on super-tight project scopes and timelines, incurring technical debt and leaving it to individual developer initiative to pay back the debt. For example, towards the end of a project an IC might say to a manager "Okay, the functionality is there. Now let me just spend another week here to write some unit tests." The manager might say: "Sorry, no can do, I have another important project I need you to do and get started with right way."
We basically had one IC who worked himself silly keeping the test suite in good shape, writing unit tests for everybody else who hadn't written any. He was doing incredibly important work. But all the people around him got much better careers out of just doing highly-visible high-impact work that important managers needed to get done. When that IC, predictably left, unit tests were simply no longer maintained.
It's like when Bill Gates comes into a 3rd world country and just starts running healthcare out of his own pocket, and the government of that country is like: Thanks man. Now we (the "legitimate" rulers) no longer have to take care of this stuff, and are free to send even more of that tax money off to our swiss bank accounts.
There is also a paradox around "working in the open" and "overcommunicating" while being receptive to "gentle redirects", namely: What you actually want from bottom-up-ness and from empowering individuals is a pool of many people thinking independently and bringing their individual creativities to the task. But what you actually end up with is installing "group think" in every individual's mind. Because an IC who works openly in a way that goes against the grain of what managers want will just start hearing a lot of noes, sometimes soft-noes ("redirects"), sometimes hard noes ("vetoes"), and whenever that happens it works against that person's career. So the IC starts to internalize their managers' (or the whole group's) thinking, and starts to only do things that line up with that groupthink. -- See the book "Disciplined Minds" for a deeper explanation of how that comes about.
In one cycle, I even got performance feedback as part of the yearly performance evaluation which was saying "Unfortunately, we can't give you a raise this cycle. With regard to your stated career objective of stepping up from IC to manager we need to unfortunately tell you that this will not be happening this cycle. Here are some of the reasons: ..." And then the stated reasons are basically opinions that I have voiced that go against groupthink. Like if I spent a lot of time writing unit tests while everyone else thinks unit tests are a waste of time, it might say "You need to learn to be more pragmatic and waste less time on unit tests." I can't tell you how mad this made me. You can't, on one hand, preach this openness rhetoric and encourage people to always voice their opinions, and then use their opinions against them and punish them for "thoughtcrime".
Game-theoretically, the the strategy of playing as a "political animal" dominates the strategy openness. So it creates better outcomes for you, regardless of whether others are also playing as political animals or are being open.
So, personally, I really felt I got suckered into playing the "openness" game, making myself vulnerable, while the people in the informal/actual power structure just exploited my vulnerability to cement their own power and impose their will on everyone. It's not an experience I care to repeat, and I won't make that mistake again.
I am sorry you had this experience. No approach, closed or open, will ever substitute better leaders that aren’t taking advantage of you. Your experience is likely and sadly very common.
I was working at Artsy while the OP was CTO (:wave:) and tried to help out a bunch on fostering a good attitude towards OSS - there's quite a few notes in both artsy/README and the blog
As someone who works on an open-source fork of the open-source software mentioned in the post, I am now exclusively referring to the open-source version of it as Apache (APLv2) -licensed. Maybe that's how we fix this confusion?
