Hacker News new | ask | show | jobs
by ticmasta 2108 days ago
I'm a Dev Manager but started as a mid-senior developer at my current company (now about 350 people). We grew a lot by acquisition and one thing I noticed was many "cultural silos" that made it hard to build a shared, unifying identity. Myself and another developer worked to try and address this with a lot of small things focused on cutting across teams & groups: a book club-style bi-weekly discussion, "Tech Talks" from across the teams to diverse audiences, some hackathons and making online conferences (MS, AWS, Google, Etc) into company events. Literally things that "make people spend time with people outside their direct team". It's been pretty successful and pushed lots of new initiatives in some unexpected areas.

So my advice would be to look for a broader area where you see a gap or failing, and then look for ways to address this that don't need a huge investment of people or resources; guerilla activities FTW! If you can show some success, you can then pursue as appropriate/desired...

4 comments

I tried that - called it Tech Shorts (lightning talks) at small company. Found the largest issue was Passiveness in the engineering crowd. Ended up giving about 50% of the talks myself, not because I wanted to, but because there were so few people who were willing to step up and present. About 70% of the engineering team would attend (~50 people), so it was well received. Will try a new iteration next time.

What made your attempt successful, in your opinion.

I don't get paid to give tech presentations. Preparing for them would affect the work that I am responsible for. So giving tech presentations would ultimately make me look worse at my company. This explains the passiveness at my company.
This is my observation across several companies/teams. The options seem to be either sacrifice "real work" time to make a good presentation or make a half-ass presentation and have people criticize the low quality.

Do people here think "no prep" presentations could work? Where it's agreed that nobody will do any prep but simply talk about something they're knowledgeable about? Or share their screen and walk through their current project? Everyone in the audience knows that the presenter wasn't "allowed" to prepare so the expectations are lower, but people still get exposed to other engineers' work.

In medium-large companies, work and promotion are about showing off. Even if you do real work it's more important to be noticed than to do it.

In that light, I don't understand how you and the OP could consider that it's preventing to do real work. Powerpoint is the real work. And it shouldn't be difficult to justify spending 1-2 days on it, with 100 people assisting to the presentation as witnesses, unless your manager really doesn't want you to give presentations (it's showing off your team so it's good for your manager too).

I get it that it's not part of the engineer mindset of course. If I have to give some advice to strong engineers who do good work, that would be to take credit for your work.

That captures a lot of what I was trying to capture. However, the intent was for people to cover work that they are doing (lowering prep time, immediate understanding), tech they are researching (again lower prep time, immediate understanding).

A lot of technical presentations we did are no different than what you would do explaining tech within your team. A few diagrams, and understanding of the core of the tech. Scaling to more than the safety of the team is really where I think people would rather have 3 meetings with 3 different teams to do a knowledge transfer than take the risk of being in front of collecting 5-10 teams worth of engineers.

Looking over the comments, the real gap I expect is the lack of peer management support and encouragement. And expectation that mentoring and teaching peers should be part of the leadership expectations. My view are is the the strongest engineers are the ones that accelerate and multiple the work of themselves and their peers, but there are a lot people who subscribe to the "army of one" 10x engineer philosophy.

It is a part of the "engineer mindset"
This was exactly what it was.

Demo, deep dive/narrative on your work. Demonstrating something cool. It was clear the prep was not expected or needed, and it would be scrappy - just like lightning talks at conferences.

The exposure and sharing of ideas was critical.

We even had times where someone would suggest a topic during the meeting and someone would step up and do a deeper dive into it.

Understanding is all relative. You don't need to be an expert to know more than your peers. You just need to accept that your extra knowledge adds value. And be honest where your limits of understanding are.

That's where you need buy-in from management. One of my past employers had a presentation series like that above, and if you were scheduled next, it _was_ considered work that you were responsible for, and counted towards more or less a half-day.

I haven't been at my current employer long, but from what I've heard about our frequent engineering meetings and their presentations, they do the same thing.

At my team we "ticket" presentation prep just like dev work. So if you wanna do some sort of story point / ticket anlalysis per dev is no different.
Make it 5% of the work time. Make it part of the job (I also doubt you're working 8hrs at full productivity mode)
That attitude is asking to get a "needs improvement" on your APR.
We have something similar at my current place where every week or two someone presents.

It ends up being the same people presenting and I don’t think it is because people are afraid of public speaking, but instead people don’t care about the talks.

At most 1-2 people (~20 person eng team) will ask a question, engage with the speaker, say thanks, etc. but most people either don’t attend the video call, or do so with video and microphone off for the entire time.

I long for a group of engineers who care about honing their tools, finding better solutions, making things reliable and efficient, etc.

It becomes draining to have the same people present over and over again.

/end rant

When talks are given through video I actually attend a lot more than when they are in person. I put them on, turn off my music, and listen while working. I've actually learned a lot of stuff this way. Of course I'm not putting 100% effort into work, but that's fine. And if it is a talk I'm not interested in that percentage of focus on work is much higher.

Just because people are lurking doesn't mean they don't find value in your talks.

> but instead people don’t care about the talks.

Are you taking into account this kind of comment by Dan Luu[1]:

"Most people consider doing 30 practice runs for a talk to be absurd, a totally obsessive amount of practice, but I think Gary Bernhardt has it right when he says that, if you're giving a 30-minute talk to a 300 person audience, that's 150 person-hours watching your talk, so it's not obviously unreasonable to spend 15 hours practicing (and 30 practice runs will probably be less than 15 hours since you can cut a number of the runs short and/or repeatedly practice problem sections). One thing to note that this level of practice, considered obessive when giving a talk, still pales in comparison to the amount of time a middling table tennis club player will spend practicing."

From that, you might ask your presenters to do 2-4 hours of rehearsal, and for the talk to generate $2,000 of value before it's worth running / worth attending.

I feel many talks are "what the presenter wants to talk about" not "what the audience wants to hear". At least at a tech conference or on YouTube you can self-select so those two overlap. Inside a company, less so, so it's more important that they are done well, actionable, preferably short. They can't solely be mandatory. or solely fun for the presenter. And they certainly can't be spinning a tale of a utopian future for the company which is worse for me personally, or teasing me with a future tool or process or change which is better for me personally but which the company won't permit or won't get behind or actively opposes.

[1] https://danluu.com/p95-skill/

> Passiveness

A lot more people have some degree of social anxiety than one might think, especially in IT.

Lightning talks originate—and work well in—the sort of tech-bro workplaces where there’s an Xbox, foosball table, and bar in the breakroom. Half the “culture fit” criterion of hiring for those places is just an attempt to filter out potential hires with any amount of social anxiety; so the average level of it in such places is low.

But other than in that little ecological niche, you’re not likely to see many engineers who are fond of public speaking, even when they have something they know and would love everyone else to learn about.

On the other hand, though, many of these same more anxious people are fond of writing. Unlike public speaking, which is a live performance, a written piece can be composed—worked out slowly, checked for errors, re-drafted, thrown out with no repercussions, etc.

Many engineers who aren’t at-all interested in giving a lightning talk, might instead quite like to blog about what they’re doing in some official capacity. And they would like it even more, I expect, if they didn’t have to have final responsibility for what was presented (because there’s always still the anxiety that someone might spot a flaw in your argument that you didn’t); but rather if their prose was handed off to a managing editor for the blog, to work up into a final article.

Which means that a lot of these same engineers would be fine composing a lightning talk, as long as they didn’t have to be the presenter, and also weren’t put on the spot to answer questions afterward†. Find someone in your org who just loves talking—maybe a salesperson, maybe your CEO!—and have the engineer in question work with them to transfer the knowledge necessary to give the presentation. As a bonus, the presenter gets to be educated in this stuff from the source, one-on-one; which can very much help improve the depth of their knowledge, when that same person is communicating with your customers!

† Q&A is a very valuable part of a talk, and the knowledge required to answer arbitrary questions really has to come from the engineer themselves, rather than a presenter. I’d suggest still doing Q&A with the engineer, but asynchronously, so you’re not putting the engineer in question “on the spot” in front of an audience. Maybe set up a mailing list or group-chat channel, that everyone attending the talks can subscribe to, to ask questions relevant to the latest talk. Then there’s no time-pressure on the engineer’s part to respond, but everyone still gets to ask questions, and to hear the answers to others’ questions.

> A lot more people have some degree of social anxiety than one might think, especially in IT.

I was interning at this place and the team lead would come and ask the interns what they were doing (at least once a week) and ask really in depth questions. It was extremely nerve wracking because this was the only interaction I had with him and he kept a air of "hard ass" around him. Every few weekly meetings he'd ask the interns for more information and put us on the spot.

It sucked. BUT by the end of the internship I think we all felt a lot more confident speaking and defending our work. So I guess his plan worked, and honestly I'm happy to have had that experience. I think it made me not only a better worker, but a better employee. At the end of the day, we all are in sales in some form. So I do not like the idea of someone else giving the talk, because that's not the person that gets the training from it.

What I'm trying to say is that talks like these really should be used to help your team members with anxiety. A bit of low risk exposure therapy. Speaking is a skill and it is an extremely useful one to every person at every stage in their career. You are supposed to train your employees and sometimes that means making them a little uncomfortable.

As someone who's decently comfortable with public speaking:

Your employer is not your therapist and conflating the two is one of the most terrifying things I have ever read on HN.

Calling this "conflating your therapist and employer" is an unfair accusation and clear reductio ad absurdum.

It is training. You are expected to train junior engineers, not just in tech but also in soft skills. Public speaking is a soft skill. It is also something they do in schools. You have to do classroom presentations and reports. I don't think you would make the same argument for them.

Your job should be making you a better employee than you were when you came in (and not just in your hard skills). This is especially true for junior positions. You will be expected to defend your work to your boss and employers. No one is saying to give a talk to an open audience. But you should be able to clearly justify your work.

> talks like these really should be used to help your team members with anxiety. A bit of low risk exposure therapy.

> You are supposed to train your employees and sometimes that means making them a little uncomfortable.

Reductio ad absurdum only applies if the source does not already convey that message. This literally says that your employer should be providing therapy for anxiety. (Not providing a therapist, literally performing therapy) There's no ambiguity there. It's in the original text, right there.

Anxiety and soft skills are related but soft skills are a thing to learn and be taught and anxiety is a condition. If anxiety is in the way of learning soft skills the solution is not for the employer to provide therapy.

+1 here.

An individual's team/employeer/peers/manager should create the space for your to lead people (which in a lot of cases means stepping out in front of a lot of people), and to be supportive relative to the experience.

Individuals need to take responsibility for their personal growth and find avenues (twitch, toastmasters, meetups, etc) to get stronger that doesn't rely on your employer.

Another option is pre-recording your presentations. Shoot for a 15 minute presentation, followed by questions and conversation. Think a dev recording their screen, showing the work and talking over what they're doing, mixed with a few powerpoint slides.

This gets over the hump of public speaking, creates an artifact that can be sent out as a follow up, and gets to the goal of having shared knowledge of a topic and a sense of community outside of normal silos.

> because there’s always still the anxiety that someone might spot a flaw in your argument that you didn’t

What's the need to always being 100% right. There are very few situations where there is a 100% right solution. Most are optimized 80-90% for a particular problem set. Indicating that "within our context, we believe this is the best solution" goes a long way in creating that opportunity for discussion and deeper understand of either gaps in the context for the problem, or adjacent problems that may leverage the work.

Wanting your blog to go through an editor isn't about needing to be right; it's a "defence against the dark arts" of paparazzi quoting your words out-of-context with the intent of getting you pilloried by the Internet.
I think that's a pretty myopic view... Personally, I think taking more chances to positively affect your workplace "technopolitical ecosystem" ultimately improves your ability to do your job.
This doesn't surprise me at all. The intersection of engineers and public speakers is pretty tiny. It's not recreational; it's high pressure. You need to find something fun and laidback. Something low stakes, like a semi-weekly video game competition.
It's not high pressure, really it isn't. It's the same as when you talk in a team meeting, just more one-sided.

The pressure that people feel is mostly self imposed. Most of the time the audience is there to learn given they have a gap. Most people are projecting their fear onto the presenter. Unless you are an actual leader of an organization, you are just one of the team.

(I'm a reformed strong introvert)

I'm not sure if your comment is directed at me or used for rhetorical effect. Either way it's confusing and a little bit offensive.

The first thing is that there's a signal here that you believe there's something defective about introversion (i.e. that introversion is something to be reformed). To those who don't know, it's just a neutral personality trait (one of the Big Five--low extraversion) with its own pros and cons. There's nothing wrong with it and it can be happily embraced.

The second part is that you seem to have the common confusion of conflating introversion with poor public speaking (or at least an aversion to it). They're unrelated. Introversion just means interacting with people expends energy. The actual aversion to public speaking comes from lack of skill, anxiety, and awkwardness. I grant you that those things might be more prevalent in introverted people because it is easier to keep to yourself and not build those skills, but they're still two different things.

Finally, saying it isn't high pressure comes across as somewhat lacking in empathy. People feel different ways about different things, and invalidating those experiences is not helpful.

Personally, I have improved my public speaking a lot over the years by forcing myself to do talks, toastmasters, host meetups, etc. Now I'm pretty good at it and comfortable with it, but there was a ton of pressure and anxiety around it before. Even though it's better now, that doesn't make those experiences less real for myself or anyone else.

I'm interested in anyone's experience doing this with a remote team. We do this (in a small but distributed team), and it's as much about keeping shared technical knowledge up-to-date as getting together.

But it can easily turn into just-another-zoom-call. Ideas?

We did week long hackathons across the company and anyone could join any team. In fact people were encouraged to switch roles and teams for the hackathons. Especially QE becoming devs or devs handling BA type roles.
That sounds great! Have done similar things and recommend.