Humans hold the key to collaboration no matter how good the software tools(bloomberg.com)
bloomberg.com
Humans hold the key to collaboration no matter how good the software tools
https://www.bloomberg.com/news/articles/2022-12-15/focus-on-employees-not-tech-to-build-high-performing-team
85 comments
https://archive.vn/O2wk9
Technology is often very, very distracting, and everyone feels it. I've noticed that we've hit a point in my team where juniors don't even feel comfortable asking questions in a team channel, because they think it might add to the noise. It isn't just that they don't want to "look dumb", but they genuinely don't want to bother a senior engineer. So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case. (I have no idea how common this is, but I suspect, at very big companies, there are similar dynamics.)
One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions.
Tech really isn't a direct cause of real social problems, but often just presents distractions, which can add up over time. Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point. But the real solution isn't to really ban new tech, it's just to learn how to identify and avoid letting it distract us further.
One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions.
Tech really isn't a direct cause of real social problems, but often just presents distractions, which can add up over time. Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point. But the real solution isn't to really ban new tech, it's just to learn how to identify and avoid letting it distract us further.
One thing I found that helps in some cases, that I wish was said (and actually practiced) when I was a junior developer, is, “my main job is to help you get comfortable with everything and help you be successful. Everything else about my job is basically just filler for whenever you don’t need my direct attention. Never ever feel like you’re inconveniencing me because helping you is my job.”
> Everything else about my job is basically just filler for whenever you don’t need my direct attention
That might be taking it a bit too far?
That might be taking it a bit too far?
As someone with people who report to me, my #1 job is to make sure they’re effective, happy, productive. Empowering them generates more productivity than me quietly doing stuff myself.
If you have people who report to you and your main job is enabling them, you’re a manager not an engineer. Which is fine, but also it’s an important distinction to make.
My #1 job takes maybe 30% of my time. Be careful with semantics fixation.
> Don’t get caught up in semantics
What does that mean?
What does that mean?
Labelling someone “engineer” or “manager” is not really useful. So why go out on a perilous precipice of doing so, especially when one lacks almost all the details necessary to make an informed assessment?
I think its pretty useful distinction. I know everywhere is different, but everywhere i have worked the roles have been very distinct. Engineers, especially senior ones, mentor people of course, with that being a significant part of their job, but that is really different from having someone report to you.
My previous contract ended abruptly but then a month later they needed me again because their current onshore offshore team was very large and growing by the day but incapable of non-trivial engineering tasks, all the way up to the engineering managers. They were essentially the hire paid copy/pasters. I said I'd return under the condition that I will golf all day. They hired me back on, I made the thing they needed, then they dumped me again abruptly for another onshore offshore engineer.
So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.
So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.
I entirely disagree both with this point and with it’s apparent subtext that being an engineer is better and being a manager is worse. I take it that you are one who takes great pride in “being an engineer”. That’s a separate topic (for instance, one can be an engineer in a management job).
We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.
Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.
We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.
Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.
Sure, but is constant "direct attention" the best way to empower engineers? I would argue that systemic improvements (e.g. onboarding process, good documentation, team communication or company culture) are more impactful since they scale better and address the root of the problem. Of course, you need both, but saying that everything other than hand-holding is "just filler" shows a lack of understanding of good leadership.
I have people that report to me. This is true a lot of the time. The other thing I do is getting people to use the thing my team built - or figuring out what they want my team to build.
It’s not, if your job is to onboard a new engineer. Those first few months make all the difference. If the “other parts” of your job prevent you from maximally optimizing the productivity of your new coworker, the compounding negative returns on that onboarding engineers time is incredibly expensive.
Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives
Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives
Agree. At the end of the day, someone is paying for the jr and sr person. Is that what they want? If so, then it is fine I suppose. They do need to state this clearly however.
You can also just create a slack channel just for questions (eg #eng-onboarding), where the sole purpose of the channel is those questions. Lowers the barrier a lot. Even better, you'll see even senior folk pop in to ask questions about parts of the stack or codebase they aren't familiar with.
Ugh this sounds like specific reddit spaced and I dont think it did end well.
TBH you land in a situation where you have 40 channels in the company you have to follow and it drains so much energy just to be in the loop.
Super hard to focus on anything if you know you can get pinged somewhere and you have to check or reply in timely manner.
Add to that emails and PRs and you spend 2/3 of your work day just enabling other ppl or answering questions.
Soo tiresome.
TBH you land in a situation where you have 40 channels in the company you have to follow and it drains so much energy just to be in the loop.
Super hard to focus on anything if you know you can get pinged somewhere and you have to check or reply in timely manner.
Add to that emails and PRs and you spend 2/3 of your work day just enabling other ppl or answering questions.
Soo tiresome.
Budget your time in more specific buckets. I let all email and non-direct slack dings wait until I am in between tasks, such as when I get back from a beer lunch. In my previous job, I stopped checking email all together because it was mostly all these dumpster fire notifications for others to put out or ignore until it blew up entire parts of the sector.
Agreed. This is yet another source of distraction for actually getting things done, and turns into side discussions of tangential topics far more often than a useful source of information. Beats wasting everyone's time asking questions in a standup, but should at least be understood to be very asynchronous with no need for timely replies lest it become an attention hog. Might favor just setting aside time for devs to add to a wiki document about their area of the system than just being always available for individual questions.
Agreed. This is yet another source of distraction for actually getting things done
Yes and no. Yes, some individuals might suffer in the short term from the friction. No, the lack of that friction is not good for the team.
The context (i.e., article) is collaboration. That's not about individual GTD, it's about the health and long term well being of the team.
Granted, there are non-team situations but if size and or scale are involved that's less likely. A non-dysfunctional team has overhead. Skip that and while you may not have a dysfunctional team, you'll have a suboptimal one. Either way, that creates friction. The messy shitty kind.
Yes and no. Yes, some individuals might suffer in the short term from the friction. No, the lack of that friction is not good for the team.
The context (i.e., article) is collaboration. That's not about individual GTD, it's about the health and long term well being of the team.
Granted, there are non-team situations but if size and or scale are involved that's less likely. A non-dysfunctional team has overhead. Skip that and while you may not have a dysfunctional team, you'll have a suboptimal one. Either way, that creates friction. The messy shitty kind.
Sounds like you have some major Slack trauma, sorry to hear. There are many ways to use Slack and to have a channel for people to get their questions answered without having people "spend 2/3 of your work day just enabling other ppl" (for instance, setting expectations on response time, having people volunteer to spend their time helping onboard other folks, etc). Like any process, it doesn't work unless thoughtfully implemented.
We've got that channel, and many, many other "help" type of channels, like "help-who-do-i-talk-to" as well as "help" for many different teams, subjects, etc. They work pretty well, but, there's just a lot of communication, and I think the new grads and very young engineers get overwhelmed.
Ultimately, communication between thousands of people is just hard, and technology solutions aren't going to solve all problems perfectly. And again, I want to stress that in general, Slack has been a pretty nice tool. We still just need to do other practices to make sure nothings flying under the radar.
Ultimately, communication between thousands of people is just hard, and technology solutions aren't going to solve all problems perfectly. And again, I want to stress that in general, Slack has been a pretty nice tool. We still just need to do other practices to make sure nothings flying under the radar.
> One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions
We have had really incredible returns from what we call “hack sessions” which are like you said, essentially hosted by at least one senior engineer. We find something in the moment to discuss, or someone shares their screen and we debug together. If no one has anything, I personally start quizzing people on deep technical details and it usually only takes a single question before the topic naturally evolves toward optimum teaching. By now people look forward to them as a place to bring their friction, so lack of topics is rare.
We have had really incredible returns from what we call “hack sessions” which are like you said, essentially hosted by at least one senior engineer. We find something in the moment to discuss, or someone shares their screen and we debug together. If no one has anything, I personally start quizzing people on deep technical details and it usually only takes a single question before the topic naturally evolves toward optimum teaching. By now people look forward to them as a place to bring their friction, so lack of topics is rare.
> It isn't just that they don't want to "look dumb", but they genuinely don't want to bother a senior engineer. So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case.
This doesn't sound new at all. It adequately describes my experience as a junior long ago, back when you had to walk into the senior's private office and interrupt what they were doing.
This doesn't sound new at all. It adequately describes my experience as a junior long ago, back when you had to walk into the senior's private office and interrupt what they were doing.
Yes.. there are definitely online-people, and offline-people, or text-async-comm people vs personal-comm-people: for one the one way of communication is more convenient, for others the other, and for some there is barely a difference.
But this is imo fully orthogonal to Juniors not daring to ask questions, and depends on personality, the environment, the mentors, and maybe also the online- or offline-affinity vs the most prevalent tools, but as far as I observed that is the least impacting it...
But this is imo fully orthogonal to Juniors not daring to ask questions, and depends on personality, the environment, the mentors, and maybe also the online- or offline-affinity vs the most prevalent tools, but as far as I observed that is the least impacting it...
We have voluntarily gone back to the office one day a week now, because we find collaboration easier when tech gets out the way and you can just talk to someone directly.
Surprisingly, the team has all loved it and we are discussing adding an extra day.
Surprisingly, the team has all loved it and we are discussing adding an extra day.
What about remote teams ?
I'm in that boat actually. It really just comes down to the people, like always. The teammates that meet together show respect for the remote folk, so it works. But I've definitely been at places that didn't really have that sensitivity for others, and it sucked.
My previous gig has an onshore offshore team that I interfaced with. Then they would interface with the offshore team. And the offshore team had its own very offshore team (not sure which shores we're on). I felt lucky that most of the onshore offshore team didn't like me much which meant all I needed to do was create the features that they tried and failed to do. It was a symbiotic pile.
I think a big part of this is we need a new work culture. Slack makes it easy to communicate but we don’t have good patterns in the work place broadly speaking for remote work. So everything is a Zoom meeting, or a virtual chat dump to a channel. We need to embrace more async communication and proper scheduling on team by team basis that works to get open air dialog as needed. These alone help remove barriers.
We also need to document everything more so than before, and by orders of magnitude. We just don’t have this as common workplace protocols yet
We also need to document everything more so than before, and by orders of magnitude. We just don’t have this as common workplace protocols yet
> One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions.
Just wanted to say thanks for doing that. I think it's a great thing to set aside time for, for all parties of senior, mid, and junior.
> Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point.
Nail on the head, although the VR folks are trying to maximize it more.
Just wanted to say thanks for doing that. I think it's a great thing to set aside time for, for all parties of senior, mid, and junior.
> Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point.
Nail on the head, although the VR folks are trying to maximize it more.
> Like, we're not there to do anything specific, just work on something together.
I keep lobbying for "office hours" like this at every single one of our retrospectives and it gets zero traction. My juniors have mentioned how hungry they are to learn more about the craft and they love it when I drag them into conference rooms for impromptu brainstorming/lecturing, but even then I get no votes for implementing office hours. I'm eternally puzzled.
I keep lobbying for "office hours" like this at every single one of our retrospectives and it gets zero traction. My juniors have mentioned how hungry they are to learn more about the craft and they love it when I drag them into conference rooms for impromptu brainstorming/lecturing, but even then I get no votes for implementing office hours. I'm eternally puzzled.
This is what I do, semi regular working sessions where I mostly watch/do my own work
>So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case. (I have no idea how common this is, but I suspect, at very big companies, there are similar dynamics.)
I always think of this quote[0] from the great Byrne Hobart[1]:
>Slack is a bit like Adderall. Ask someone about it the week after they start using it, and they can’t praise it enough. Talk to them six months later, they’re back to baseline but now they have an addiction. And talk to them years after the fact, and they’re just regretful.
[0]: https://byrnehobart.medium.com/works-war-on-slack-97ef94264d...
[1]: https://twitter.com/ByrneHobart
I always think of this quote[0] from the great Byrne Hobart[1]:
>Slack is a bit like Adderall. Ask someone about it the week after they start using it, and they can’t praise it enough. Talk to them six months later, they’re back to baseline but now they have an addiction. And talk to them years after the fact, and they’re just regretful.
[0]: https://byrnehobart.medium.com/works-war-on-slack-97ef94264d...
[1]: https://twitter.com/ByrneHobart
That is not how Adderall works. Get some exercise and take some magnesium with it.
There are way too many academics, curators and theorists in the collaboration theories world. Way too many VCs and tech start ups have taken them too seriously.
It's like the old joke 'an economist can tell you a 1000 ways to make love but has never touched another person'. The reality with collaboration strategies (which I was heavily involved with last decade) is that it all about context, scale, the people involved, the goals, overcoming silos and rivalries etc. The technology enablers are not wildly important except to choose tools that don't impede.
Playing wackamole with 57 varieties of Slack channel to make sure you are not missing anything vitally important is not efficient collaboration and a huge time suck. As long as the academic chattering classes keep convincing VCs to pour money into yet more collab start ups there will continue to be new generations of not very useful tools and the low bar of msft teams and email/doc culture will continue to survive. Glacial pace, groundhog day film like deja vu experiences in this world as I'm sure many have experienced on HN...
It's like the old joke 'an economist can tell you a 1000 ways to make love but has never touched another person'. The reality with collaboration strategies (which I was heavily involved with last decade) is that it all about context, scale, the people involved, the goals, overcoming silos and rivalries etc. The technology enablers are not wildly important except to choose tools that don't impede.
Playing wackamole with 57 varieties of Slack channel to make sure you are not missing anything vitally important is not efficient collaboration and a huge time suck. As long as the academic chattering classes keep convincing VCs to pour money into yet more collab start ups there will continue to be new generations of not very useful tools and the low bar of msft teams and email/doc culture will continue to survive. Glacial pace, groundhog day film like deja vu experiences in this world as I'm sure many have experienced on HN...
> an economist can tell you a 1000 ways to make love but has never touched another person
I was always partial to Brendan Behan's famous quote:
> “Critics are like eunuchs in a harem; they know how it's done, they've seen it done every day, but they're unable to do it themselves.”
I was always partial to Brendan Behan's famous quote:
> “Critics are like eunuchs in a harem; they know how it's done, they've seen it done every day, but they're unable to do it themselves.”
Is that considered one of the best quotes ever? Because I am using it but will likely botch it each time yet still get the point across.
I can’t speak to it being “the best ever,” but it’s the one I heard. It would not surprise me, if others used it, and maybe, added “spice.”
Ok I agree that software is not the primary enabler. But let's just pause on these tools. For you :
- On the one hand, mainstream collaborative tools are "low-bar", and Big Tech is responsible for its "Glacial pace".
- On the other hand, "new generations" are growing too wildly, and "are not very useful", and "academic chattering" is responsible for it.
The second point is supposed the be the "market" solution to the first. You seem to think this is not the case, because of misguided academics, curators and theorists. Would you care to cite some (of the worst) examples ?
- On the one hand, mainstream collaborative tools are "low-bar", and Big Tech is responsible for its "Glacial pace".
- On the other hand, "new generations" are growing too wildly, and "are not very useful", and "academic chattering" is responsible for it.
The second point is supposed the be the "market" solution to the first. You seem to think this is not the case, because of misguided academics, curators and theorists. Would you care to cite some (of the worst) examples ?
I think one of the big issues that collaboration and productivity apps miss is that they’re supposed to be tools that help and accommodate each individual user according to what is best for them.
I have really bad adhd and so I think I end up noticing it more because I’ve had to build all the tools I rely on myself and realized how not at all powerful the existing solutions actually are at molding themselves to the user’s needs rather than vice versa.
- I need progressive reminders for deadlines, increasing in frequency when the measure of percent completed and time to deadline gets worse.
- I need undismissable reminders, if an important message comes in and I miss it it’s gone forever.
- I need 15, 5, and 1 minute warnings for meetings.
- I need daily reminders of the things I should be working on that automatically expire so they don’t become noise.
- I need my tools to yell at me if I try to push a commit with a not descriptive enough message, don’t tag a card, and then auto move it to MR once I take it off draft.
- I need when people post messages in the channel looking for reviews that it adds to my daily reminder list and goes off it once it’s merged.
- I need reminders on Friday that I should spend the afternoon prepping cards for handoffs instead of working them.
- I need to yeet random messages into different lists so I can remember things like “found a big make card for it” or “idea for 20% time.”
- I need a weekly report of all the commits I made, cards I touched, and conversations I had so I can take them to my 1-1.
- I need a thing to pull out emails to specific groups and forward them to our group slack otherwise no one will see it.
- I need non critical alerts to also show up on my daily reminder list that drop off it once it’s ack’d or a card is made for it.
- I need alerts when there’s activity on my MRs that are sent as messages and go to my list rather than one of my (literally) 50k weekly emails.
- I need the group lunch order to ping me when it’s actually time to order instead of when it’s announced.
All the tools in their default states don’t actually do anything for you. They create more work and mental load than take it away.
I have really bad adhd and so I think I end up noticing it more because I’ve had to build all the tools I rely on myself and realized how not at all powerful the existing solutions actually are at molding themselves to the user’s needs rather than vice versa.
- I need progressive reminders for deadlines, increasing in frequency when the measure of percent completed and time to deadline gets worse.
- I need undismissable reminders, if an important message comes in and I miss it it’s gone forever.
- I need 15, 5, and 1 minute warnings for meetings.
- I need daily reminders of the things I should be working on that automatically expire so they don’t become noise.
- I need my tools to yell at me if I try to push a commit with a not descriptive enough message, don’t tag a card, and then auto move it to MR once I take it off draft.
- I need when people post messages in the channel looking for reviews that it adds to my daily reminder list and goes off it once it’s merged.
- I need reminders on Friday that I should spend the afternoon prepping cards for handoffs instead of working them.
- I need to yeet random messages into different lists so I can remember things like “found a big make card for it” or “idea for 20% time.”
- I need a weekly report of all the commits I made, cards I touched, and conversations I had so I can take them to my 1-1.
- I need a thing to pull out emails to specific groups and forward them to our group slack otherwise no one will see it.
- I need non critical alerts to also show up on my daily reminder list that drop off it once it’s ack’d or a card is made for it.
- I need alerts when there’s activity on my MRs that are sent as messages and go to my list rather than one of my (literally) 50k weekly emails.
- I need the group lunch order to ping me when it’s actually time to order instead of when it’s announced.
All the tools in their default states don’t actually do anything for you. They create more work and mental load than take it away.
I need you to customize my tools!
Seriously, I always loved the “bicycle for the mind” perspective on computers as personal personalizable productivity devices
There are few endpoints that can’t be traversed with a bicycle
But software today is a fractal pattern of walled areas within walled gardens. Each location connected with preplanned paths and guardrails. Each construction zone filled with tools that can’t be used elsewhere.
Forging new simple short paths across the diverse information in our lives (such as your “simple” productivity ideas), keeps getting more difficult
Seriously, I always loved the “bicycle for the mind” perspective on computers as personal personalizable productivity devices
There are few endpoints that can’t be traversed with a bicycle
But software today is a fractal pattern of walled areas within walled gardens. Each location connected with preplanned paths and guardrails. Each construction zone filled with tools that can’t be used elsewhere.
Forging new simple short paths across the diverse information in our lives (such as your “simple” productivity ideas), keeps getting more difficult
Wow. That sounds like hell. You do have my honest sincere sympathy. I just keep a simple prioritised to-do list and it works for me. I have used it to manage everything from large projects to small personal projects.
I’ve yet to find a project management system that’s lower impedance for developers than index cards for the backlog and sticky notes for task progress. PMs hate it because it requires them to stay directly involved and do their own data aggregation instead of just autogenerating reports that are of absolutely no value to the people actually doing the work.
I am a huge fan of index cards! For those curious, I wrote up an example of I use them: https://williampietri.com/writing/2015/the-big-board/
I'm working with a new team and for a while the priorities have been murky. But we got everybody in a room and I broke out the index cards and sharpies, making everybody write down things they care about and put them strict linear order. It was way more effective than any online tool I have ever used.
Since we work remotely I'll be putting those cards into an electronic tool (KanbanFlow if I get my druthers; Jira if I have to). But the level of participation and the speed of getting to consensus via index cards is unmatched.
I'm working with a new team and for a while the priorities have been murky. But we got everybody in a room and I broke out the index cards and sharpies, making everybody write down things they care about and put them strict linear order. It was way more effective than any online tool I have ever used.
Since we work remotely I'll be putting those cards into an electronic tool (KanbanFlow if I get my druthers; Jira if I have to). But the level of participation and the speed of getting to consensus via index cards is unmatched.
When I ran Engineering for a startup with 6 different software teams, I resorted to index cards + sticky notes on the exterior wall of my office. It was a great visual display of status that everyone, including those not in the tech org, could understand. The Engineers found it very satisfying to physically move the tickets themselves.
My #1 proven-in-battle management tool is a humble prioritised to-do list. I have used it for managing large teams and for personal projects. It is simple. It works. Love it.
I know it's heartbreaking to accept, but there are some problems in the world that apps cannot help with.
Apple c. 2010 disagrees [0]. They registered "There's an app for that" as a trademark. I lost my phone in an Uber yesterday so now I have no apps.
[0] https://www.wired.com/2010/10/app-for-that/
[0] https://www.wired.com/2010/10/app-for-that/
Oops, isn't there an app to recover lost phones in Uber cars?
[deleted]
Roger. It's equally true that humans still hold the key to collaboration no matter how shitty the software tools try to be.
Why would anyone think otherwise? Why would it be heartbreaking?
Edit: The parent was sarcasm, I jumped to a conclusion because I see so much hatred for tech
Edit: The parent was sarcasm, I jumped to a conclusion because I see so much hatred for tech
It was a sarcastic comment alluding to the caricature of the tech bros who see nails everywhere for their hi-tech hammers.
"cannot help with" seems very unlikely to me, especially if "apps" is not constrained to that which currently exists, but even if constrained.
Can you (or others) list a few examples?
Can you (or others) list a few examples?
I'm speaking in the present tense. Even if "apps" would be able to solve all our current problems in a hundred or a thousand years [1][2], I really don't have anything to say about that. I have no idea.
[1]: Which imo would be delusionally optimistic to believe in
[2]: And which would surely create new types of problems in the process
> Can you (or others) list a few examples?
For starters, the posted article illustrates one example.
[1]: Which imo would be delusionally optimistic to believe in
[2]: And which would surely create new types of problems in the process
> Can you (or others) list a few examples?
For starters, the posted article illustrates one example.
"there are some problems in the world that apps cannot help with" --> "able to solve all our current problems"
I wonder if an app could help with this process that sits very deep in the stack, and has zillions of other services running on top of it.
I wonder if an app could help with this process that sits very deep in the stack, and has zillions of other services running on top of it.
This is still relevant https://pbs.twimg.com/media/EDrZEKCWwAAG_Ty?format=jpg&name=...
It looks like this classic has finally run down the curtain and shuffled off this mortal coil, but it is still relevant: https://web.archive.org/web/20220328095158/https://interneti...
We consciously call those who use our services "collaborators", we're on equal-footing, to the point of not trying to say "service" (when it is). This week we just met with a potential group of users of our open-source software, that we also offer free as a service. In the area they are exploring it has some shortcomings, and is the newest of the bunch in terms of features, overall use in that manner, etc.
When we asked, "Why aren't you using X, or Y (you should consider them, they are good too!)?", and "What features are compelling you to use 'us'?", the answer came back "we like you, people, you talked to us, we know others who use your tools, and we like them too". Features, lack there-of, etc. just were not the clincher, even when we said repeatedly said "but we can't do that!". The important bit was they perceived they were joining a community of like-minded folk, who they liked. Not surprising, it's our mission to promote this very idea, but it was also the first time we heard it stated so bluntly.
When we asked, "Why aren't you using X, or Y (you should consider them, they are good too!)?", and "What features are compelling you to use 'us'?", the answer came back "we like you, people, you talked to us, we know others who use your tools, and we like them too". Features, lack there-of, etc. just were not the clincher, even when we said repeatedly said "but we can't do that!". The important bit was they perceived they were joining a community of like-minded folk, who they liked. Not surprising, it's our mission to promote this very idea, but it was also the first time we heard it stated so bluntly.
Humans hold part of the key, human organization another, quality/design of tools around human organization do the rest.
Modern tools are made to "keep user on our platform", witch is a very BAD thing for collaboration, modern tools tend to be all walled gardens, as a result collaboration with the world is VERY BAD and so on.
Let's imaging an international payment system NOT designed around brokers with a gazillion of proprietary platforms but a COMMON API, let's say similar to OpenBank, where ANYONE, not only financial institutions participate. Than payments would be far simpler for anyone, so they do their part to help collaboration for some activities. Let's say we cooperate with plain text files, so we do not have formatting issues, version issues etc common on crappy WYSIWYG platform. Another part of collaboration became easier and so on. YES, this tools are part of the game because they are part of the workflow, it's not just specific sharing tools. Physical environment is part of the game as well: if we are in comfortable places with comfy tools we collaborate better.
There is no holistic approach takeable by single companies, simply the platform model is nice for the platform owner business but harmful for the society and the more we advance the more we cut small part of it to allow collaboration. It's about time to admit that and start change course a bit more seriously...
Modern tools are made to "keep user on our platform", witch is a very BAD thing for collaboration, modern tools tend to be all walled gardens, as a result collaboration with the world is VERY BAD and so on.
Let's imaging an international payment system NOT designed around brokers with a gazillion of proprietary platforms but a COMMON API, let's say similar to OpenBank, where ANYONE, not only financial institutions participate. Than payments would be far simpler for anyone, so they do their part to help collaboration for some activities. Let's say we cooperate with plain text files, so we do not have formatting issues, version issues etc common on crappy WYSIWYG platform. Another part of collaboration became easier and so on. YES, this tools are part of the game because they are part of the workflow, it's not just specific sharing tools. Physical environment is part of the game as well: if we are in comfortable places with comfy tools we collaborate better.
There is no holistic approach takeable by single companies, simply the platform model is nice for the platform owner business but harmful for the society and the more we advance the more we cut small part of it to allow collaboration. It's about time to admit that and start change course a bit more seriously...
For a minute I thought you were making a case for crypto
This is because collaboration is multidimensional. Software really struggles to replicate that. It's a hard problem.
Tools facilitate the process, but can’t replace it.
I wonder if there’s a measure for how well 2 GPT chat prompts collaborate with one another?
I wonder if there’s a measure for how well 2 GPT chat prompts collaborate with one another?
this brings to mind the recent announcement of cicero, which plays diplomacy:
https://ai.facebook.com/research/cicero/
https://ai.facebook.com/research/cicero/
[deleted]
> It’s important to frame the plethora of technological platforms and applications which have flooded increasingly into the workplace as only ever as good as the human minds using them. Nothing can replace this—the technology is a utility to augment the creativity and dynamics of what happens when people work together.
(emphasis mine)
i think this disregards the synergistic effects technology can have.
in particular, "good software" can formalise and make explicit processes which humans otherwise struggle to manage through tacit communication and "norms".
more than augmenting, we extend our capacities through technology. in many ways this defines our species.
(emphasis mine)
i think this disregards the synergistic effects technology can have.
in particular, "good software" can formalise and make explicit processes which humans otherwise struggle to manage through tacit communication and "norms".
more than augmenting, we extend our capacities through technology. in many ways this defines our species.
So true, when to interrupt or work together or stay focused is the biggest productivity challenge for teams. Technology is just a communication medium today, intent is the holy grail of collaboration.
> The metaverse isn’t working yet because it’s putting technological design before function.
I think a little of this is inevitable. You have to date the cruel mistress of physics a little to discern the bounds of what’s realistic before you can really get into function.
But more alarming/concerning to me is that we’ve become entrapped in a perverse local optimum in funding these efforts.
Too often of late it turns into putting some form of surveillance economy over function, prematurely stifling the cycles needed to iterate on function.
I think a little of this is inevitable. You have to date the cruel mistress of physics a little to discern the bounds of what’s realistic before you can really get into function.
But more alarming/concerning to me is that we’ve become entrapped in a perverse local optimum in funding these efforts.
Too often of late it turns into putting some form of surveillance economy over function, prematurely stifling the cycles needed to iterate on function.
Collaboration is tricky. How much time you spend on it is really important. My rule of thumb is 5% of your time is optimum. More than that and the benefits start going down. Too much and you kill productivity. I have worked for a dysfunctional company that was so busy collaborating that nothing ever got done. Most large organisations seems to “work” that way. Lots of meetings, reports, feedback and other “collaborations” resulting in nothing getting actually done.
[deleted]
What about the limitations of a human mind, and its needs for healthy patterns of frequency and intensity of tasks, are they considered in the design of these tools? Maybe one of the keys is here.
Can't wait until we replace middle managers with chatgpt
I don't think we need ML for that. Replace your middle managers with the template below!
I'm sorry you are having problems collaborating with {name}. I can see how {name}'s behaviours like {example} can make you feel {feeling}. Maybe you could try out {3 examples from a random Medium article}. I will also create a {some ceremony} meeting so we can talk how we can all be better aligned in the future.
I'm sorry you are having problems collaborating with {name}. I can see how {name}'s behaviours like {example} can make you feel {feeling}. Maybe you could try out {3 examples from a random Medium article}. I will also create a {some ceremony} meeting so we can talk how we can all be better aligned in the future.
but bad Software can encourage/reinforce bad practices and discourage good practices.
A good example for this is Slack which is to some degree a manifestation for bad practices for technical communication (is okay for small talk I guess).
A good example for this is Slack which is to some degree a manifestation for bad practices for technical communication (is okay for small talk I guess).
Ugh. Why was this posted here?
> All of which brings us back to the human in the machine age. As long as collaboration technology is underpinned by collaboration management in the next phase of work, the teams that come together can get their work done. Whether in-person, in-cyberspace or in between.
This is obvious.
Plus it's an ad for their book. Such a poorly written article with so much fluff. Can we let this die off and move off the front page?
> All of which brings us back to the human in the machine age. As long as collaboration technology is underpinned by collaboration management in the next phase of work, the teams that come together can get their work done. Whether in-person, in-cyberspace or in between.
This is obvious.
Plus it's an ad for their book. Such a poorly written article with so much fluff. Can we let this die off and move off the front page?