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 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.”
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.
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.
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.
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
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.
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.
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.
> 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.
> 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.
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...
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.
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
> 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.
> 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.
>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.
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...
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 ?
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.
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'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'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.
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.
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...
> 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.
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.
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.
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.
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.
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).
> 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?
