Ask HN: What did you do to improve your company?
Hi! I work at a mid-sized tech company as a Software Engineer. There are, probably, tons of things we can improve in our processes, infrastructure, technologies, etc. But sometimes it's hard to see the place with most impact from within, especially if you are pretty long in the company. That's why I'm looking for some inspiration.
So, how did you improve your company? By that I mean: processes, tech stack, optimization, etc.
173 comments
[ 5.5 ms ] story [ 201 ms ] threadThe book is: High Output Management by Andrew Grove.
It is a dated book but many of the procedures described are still valid today (obviously using real digital tools).
I highly recommend you to read it. Improving a company often means improving the way people in the company work and interact while also increasing the quality of life of these people.
I think many of the practices described in this book are about these very things.
Good luck improving your business and sorry for my English (I'm Italian).
For example there are dashboards to track the progress of certain tech debt we are resolving, like replacing icons (oh god that looks horrible on mobile [0]). On the process side of things, we have a lot of people reviewing code and I built this dashboard where you can see the availability of reviewers and how much reviews they have done in the past days. This might help distribute load and also allow reviewers to see when they are doing too much [1].
When we were hiring more last year, we actively looked into improving our hiring experience. That was a group effort, but Training other folks to do technical interviews was very insightful and contributed back to our process.
Tech stack wise there are a few skeletons in the closet. Generally once you start digging, you find a lot of weird things. We work together to define metrics in order to assert which improvements have the highest impact. Always important to go in the right direction, little steps, and verify that you are going in the right direction. For example we focused on decreasing our JavaScript that is loading on every page, until we realized CSS cruft was blocking Rendering more than the JavaScript. Then we switched focus to that. Now after we identified what to fix, we focus on the JS again.
[0]: https://leipert-projects.gitlab.io/is-gitlab-pretty-yet/icon...
[1]: https://leipert-projects.gitlab.io/maintainer-workload/
A not so long time ago, I convinced developers to use the automated QA system as part of their development process. The QA folks had automated almost everything, so it was much faster to test by submitting a QA job. Moreover, QA owned the metrics around performance goals, so developing to the test meant fewer surprises.
It's been very helpful for our client-facing folks who have to copy a lot of user data.
Surely they have also been available on mac and Linux for as long? Can it possibly have been a good investment to write your own?
Another example is really basic automation. You probably have people/teams around you that are not developers. They probably are spending time doing really basic repetitive tasks. One team I work with regularly would take a spreadsheet, then for each row create a folder and docs in Google Drive. I wrote them a Google Apps script that could do the task with a click. Not quite as impactful as the checklists, but each script like that saves someone a couple days a year.
(And, unfortunately, a small number of folks will practically hate you for it, since you're taking away their "easy" work.)
Tons of fun for me, saves some time for someone else, created consistency for everyone.
For example, I wrote some shell scripts, gradle/TC plugins, when my company moved to kubernetes/openshift. We did not have devops, paas standardization then. The scripts are now getting used in many projects in a couple of departments. And it was just word of mouth adaption. It is as not very fancy stuff nor is it a company wide standard. But it is useful and it hides/gets rid of complexity which new projects/developers no longer have to worry about. Danger area: trying to be too generic, parameterize everything, you end up with frameworks and processes. As a senior dev, I generally aim at solving my problem and if possible making the solution usable in the immediate vicinity. Keeping it minimal and simple makes it usable for others when the problem is not exact match.
- Organized a professional development group to promote book clubs, meetups, etc within the company
- Helped marketing/sales folks update web pages to fix errors or "generic business language"
- Encourage and lead efforts to use off-the-shelf tools instead of homegrown internal tools
- Took meeting notes for all-hands meetings and published them internally
- Build relationships with non-technical staff so that you can later give them feedback about processes they control
These are some things I've done over 10 years at my company, so it's a long process!
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...
What made your attempt successful, in your opinion.
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)
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.
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.
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.
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.
Your employer is not your therapist and conflating the two is one of the most terrifying things I have ever read on HN.
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.
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.
> 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.
As for anxiety, you should talk to people with it. It is a spectrum. Being nervous and anxious is not a medical condition but the human condition. Being unable to breath and having heart issues (i.e. a panic attack) is a medical condition. There's a clear spectrum here and and equating nervousness to an anxiety disorder is trivializing the condition that people actually suffer. Clearly I'm not saying you should be forced to do this if you have a real condition (ad absurdum). But if you're just uncomfortable and nervous, welcome to the human condition. While you enjoy your stay I would appreciate it if you don't trivialize medical issues. If you do have medical issues: please seek professional help, and I'm sorry if you interpreted my message as inclusive of you.
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.
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 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.
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.
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.
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.
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
Just because people are lurking doesn't mean they don't find value in your 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/
But it can easily turn into just-another-zoom-call. Ideas?
How can I reach you?
Document pain points is a big one, everyone says them, but not always are they fixed or prioritized. Something to fix those will work - like creating, documentation, sigh.
People skills and politics, not even technical. :(
As our team was grew, it was very common to publish a PR, and right before merging realizing you had a conflict with someone else who'd merged to master ahead of you, using your sequence number.
I made a small change to the system, replacing the sequence numbers with unix timestamps and added some previously non-existant tests to cover the migration utility.
Unfortunately the subsequent PR took weeks to be approved by the team/eng leads because there was a lot of hand-wringing about this change. Once it was merged though we never thought about it again, it worked exactly as I'd hoped and nobody ever had to make a final "fix migration name" commit again.
To play devil's advocate, probably part of the reason for the sequence number approach is so if that PR that merged ahead of you conflicts with your migration you're more likely to notice if you have to rename it. I don't think that's particularly common though, and the problem should surface when the CI build runs your migrations prior to permitting the merge to master ( a good CI setup requires you to pull master into your PR if it's out of date, which ensures the combination didn't break things.)
It can be a hard choice, but one that sets an example for your colleagues: there are some situations which a person cannot abide ad infinitum.
If the situation pushed you so far as to resign, then you made an important choice.
My company is large, and coordinating all this data was typically done over email or jira.
I designed and built a test data API service with a web UI, now in heavy use across many departments and three business units.
I love tech communities, and started internal and external meetup groups, found ways to stream online, managed to get the tech blog running. All things that I love doing : making other tech people more brilliant than I am successful.
Keep doing it, be consistent.
After a while, it will be seen, recognized and you will be followed :). The cool thing is that because it's something you like, it doesn't sound like work!
Good luck and let us know what you've found in a while !
Editing to include URLs: - Original site: www.devhub.com - Spin-off: www.rallymind.com
From the beginning, rsync.net offered standard ftp service along with ssh tools. It pleased me to offer an old fashioned standard that "just worked" and allowed some weird corner cases to function for people.
Simultaneously, I wanted a "clean" nmap. I wanted to see port 22 and nothing else. So, we disabled ftp (and with it, inetd on all of our FreeBSD storage arrays) and reduced our attack surface as well as the number of processes we need to run and audit.
We made this change about 18 months ago...
The organization I worked at had no direction. Low morale. Lots of complaining. No leadership from people in management positions.
A colleague and myself tried some of the things mentioned by others below to build camaraderie, etc. Minimally effective.
Then, we started talking to colleagues.
"What's going well?" "What challenges are you facing?"
Listening alone, letting these people know their voices were heard by anyone, went a long way in building relationships, alignment, and getting things done.
Then we took what we were hearing, developed an initiative, pitched it to leadership. They rubber stamped it without really paying attention or asking questions.
We executed.
People were shocked. Their voices had been heard, and something had been done to address common concerns they had. I don't know how to measure or describe this impact, but it's the most significant thing I have ever accomplished.
The common concern was lack of direction and changing direction with new change initiative one/two/three/four times per year.
We created an initiative for teacher created and led professional development. We used students for live class recreations where teachers could analyze in real time. It was coordinated, structured, and sequenced in a way no teacher's in our district had experienced.
At the same time we took all of the feedback we got from every teacher we interviewed (and we interviewed all of them) and created a vision statement for both teachers and students. We took it back to the teachers and showed how each person's feedback was reflected in the vision. We got the district to adopt the vision. Then we held leadership's feet to the fire and didn't let them do anything that didn't align with the vision. We put the onus on them to explain how any decisions did align.
We used the vision to design professional development, adopt curriculum, craft special education services, and more.
This started as a K-6 initiative, which was wildly ambitious at the time. In the following years the middle school got on board, and then the high school followed suit, led not by administrators but by the teachers themselves. Something we never in our wildest dreams thought would happen.
Five years on the direction is the same and positive change continues.
The modern era of education reform goes back to the Soviets launching Sputnik, so 60 years. It has been omnipresent reform efforts in K-12 education since then. Lots of change, little improvement.
We created not only a durable change, but a positive one that is still pointed in the same direction five years after we got this off the ground.
There's more detail about what we did in a reply below you.
My team created a standard adhoc script template to help with this. The goal of the template was:
1) confirm script is deployed to the correct database 2) inserts record into log table (start date, end date, description, etc...) 3) updates log table when script completes / fails
We asked the script runners / dba's to reject any script that doesn't use the standard template. They reviewed and contributed to the template and were totally onboard.
The majority of our script writers use sql prompt, which allows for sql snippets - so everyone is used to starting out with this standard template as they write these scripts.
No issues since we implemented this. And I can confirm when and where scripts ran quickly.