I'd get rid of the manual process of driving to the office every day and replace it with collaboration tools to let people telecommute full time. We actually use such tools, but have a "no remote workers" policy. Occasional work from home is fine, just not full time.
One thing I've noticed in this thread and in other HN comments is a change in the way people talk about remote work. What used to be considered a perk seems to have turned into a right, and even a class issue (the corporate masters oppressing the workers).
Personally, I don't really buy it. There are trade-offs with remote workers. They are harder to collaborate with, and they generally require more process to manage. On a huge team you might need all that process anyway, but if you only have 5-10 devs in the same office you can operate pretty lean. Stick a couple of them at home 5 days a week, however, and things need to be more actively managed.
Tech workers today are doing alright. We make six-figure salaries, have our health care paid for, and, because we are in demand at them moment, are frequently pampered by our employers. So feel free to leverage that demand to insist on working remotely if that is what you want, but don't treat it as something you are owed out of fairness or suggest that a company is stupid if they don't adopt it. There are many companies and engineering managers who want their employees on site for good reasons, not just to "mind" them, and it is probably for many of the same reasons that startup incubators and accelerators generally require relocation.
>"Tech workers today are doing alright. We make six-figure salaries, have our health care paid for, and, because we are in demand at them moment, are frequently pampered by our employers."
You may and I may, but the vast majority of tech workers do not make six-figure salaries. Ironically, you may be insulated from that fact due to limited geographic mobility in terms of professional life.
I think it's intended to be taken more figuratively. Tech workers won't make 6 figures everywhere, but are likely paid way above average just about everywhere.
> One thing I've noticed in this thread and in other HN comments is a change in the way people talk about remote work. What used to be considered a perk seems to have turned into a right, and even a class issue (the corporate masters oppressing the workers).
Well, housing in areas with tech jobs has gotten really expensive. As in, $500k USD minimum for a decent house. It's insane, and remote work is the easiest solution with the least politics involved.
Basic 2-bedroom condos in the general vicinity of an East Bay BART stop seem to run $700-900k; SF proper with any hope of a short walk or bike ride to downtown, $1.3 - $2 million. There are $500k houses, but they're in Richmond.
I think to be $500k, a condo would have to be far from transit in the East Bay, but such places are mostly single family homes.
Remote work is not a perk nor is it a privilege only a certain class of people should feel entitled to.
Commuting has become absolutely insane. Mandating people to sit around in an office for a condsiderable amount of their time regardless of if they produce anything of value is equally insane.
Remote work is a solution to many current societal problems (not the least of which is pollution).
> We make six-figure salaries, have our health care paid for, and, because we are in demand at them moment, are frequently pampered by our employers.
But (as 'eli_gottlieb pointed out) the only people who can do that are those who can afford to relocate to San Francisco or perhaps a few other places, and the initial cost of that is increasing commensurate with demand.
We have, in the tech industry, found a very good way of creating interesting and well-paying jobs that will outlast a lot of the coming automation. We have so many of those jobs, and they keep being created, such that, as you say, workers are in an unusually good negotiating position compared to other industries.
Meanwhile, the housing supply in San Francisco is much closer to fixed; of course if they don't decide to build housing it's very fixed, but even so there's only so much land there. So if the demand for workers continues to be high, the price of housing will continue to increase.
It is a class issue to extend these benefits to people who otherwise couldn't afford the initial investment to relocate to San Francisco in this market and the emergency fund to keep living in San Francisco past unicorn-collapse-of-the-week while looking for new work. If we figure out how to increase supply to keep up with what looks like unquenchable and long-term demand, we'll be solving a major crisis for thousands of small towns that aren't San Francisco.
I don't need remote work for myself; I have the good fortune to be a 10-minute (NYC) subway ride from my tech job. I want remote work for all the people who could be my coworkers.
>If we figure out how to increase supply to keep up with what looks like unquenchable and long-term demand
The answer, as it always has been, is sprawl. We can't sprawl with cars anymore: land is too valuable to park on. So we're bidding with our time: moving to further-out transit stops, walking farther to the stations, tolerating increasing crowding on the trains (losing the ability to work and read). People who nominally make $50+/hour are spending 2, 3 hours a day commuting from their $2500/mo apartments.
I don't mind being a passthrough for the transfer of wealth between tech investors and real estate investors. I am growing increasingly resentful about the hours of my life that I'll never get back, shuttling back and forth from where housing is affordable.
I could technically live close to work, but not with an emergency fund. Maybe with roommates, but that's even worse.
Can you tell what the reason behind that policy is? Whenever I hear something like this I like to challenge it by the following:
Working remotely should be the default, not the outlier.
If your organisation requires personal presence something in your organisation is broken (management processes, the way people interact, obsolete tools etc.). Fix that instead of patching what's broken by mandating personal presence.
Chances are not only will your employees be happier but you'll also uncover potential for optimisation.
> Working remotely should be the default, not the outlier.
> If your organisation requires personal presence something in your organisation is broken (management processes, the way people interact, obsolete tools etc.). Fix that instead of patching what's broken by mandating personal presence.
Maybe I'm not enough of a smartphone-enabled digital native for the 21st century, but there are actually social benefits to seeing and interacting with people in-person. Work is a social activity.
> Chances are not only will your employees be happier but you'll also uncover potential for optimisation.
No, I really doubt it. Maybe it would make a few people happier, but I really doubt it would be general. I've worked remotely with people and they never feel fully-fleshed out vs. the coworkers I regularly interact with in person. It would kinda be nightmarish for my entire workday to be like that.
The "optimization" aspect is probably even more unappealing, and reeks of the kind of narrow and aloof thinking that lead to Soviet continuous production weeks [1], which made it difficult for workers to maintain a social life.
I'm not saying that remote work should be totally banned. I think the flexibility offered by allowing people to do it occasionally is very humane, and perhaps it could help people who have some kind of condition that makes it hard for them to interact directly with others. However, it just doesn't seem wise to have remote work be the default.
I strongly prefer remote over in-person. There are pros and cons to either. One of the interesting things that comes up in remote is confronting the conflation people have between work and a job. Work and a job are not the same thing. A lot of people conflate the two and rely on external things to enforce a work ethic and self-discipline, but a lot of that structure is no longer there when working remote. If anything, your internal motivation and drive has to be strong. Related is that, when working on a distributed team as a remote worker, what feels like over-communicating to the point of harassment is probably the right amount of communication.
One interesting consequence though is when both partners in a marriage work from home. In a situation where one or both partners work outside of home, some of the stress that comes with intensely being together all the time is not there. When both partners work from home, though, that can get interesting. I know this because my wife also works from home. I don't think the general populace is quite ready for that yet (you won't see advice for this yet on the self-help section of the bookstore), though it is something that can still be worked out.
> Related is that, when working on a distributed team as a remote worker, what feels like over-communicating to the point of harassment is probably the right amount of communication.
Which gets at another problem of remote work: communication that feels effortless in-person becomes something that requires what feels like "harassment" (in your words) to be effective remotely. When I was working on a geographically split team, it felt like two gigabit LANs joined by a dial-up WAN link, since the in-person communication was so much more effective.
Humans have literally spent at least hundreds of thousands of years talking to each other in person. That software has probably had more effort and refinement put into it than Slack, Skype, and Outlook put together.
That's a perceptual bias. There's a tendency for humans to resist changes just because they don't feel normal.
Humans might have spent at least hundreds of thousands of years talking to each other in person, but only a fraction of that commuting by cars, or even having the notion of jobs, or even the notion of "productivity". Further, the same arguments you made are the same arguments made in any given era.
I do think it is mentally healthier to not be so addicted to technology, to have 1-on-1 personal communications. But generally-speaking, the sense of self-worth, validation, etc. for the vast majority of people at their jobs is suspect. The quality of 1-on-1, personal communication has more to do with what mindfulness meditators call "presence": how much your awareness is in the presence in the here-and-now, and less to do with whether you are intermediating that communication through technology. Much of the social communication tend to be on the superficial side, even without technology.
Being present is either the most difficult thing you will ever do, or the most effortless.
Tangent: Buckminster Fuller once characterized words and language as human's first technology. One that follows the ephemeralization pattern such that it disappeared (we are no longer generally conscious of language as a technology).
> Further, the same arguments you made are the same arguments made in any given era.
Communication is a mental process, transportation is not, so they're not really comparable areas of change. I'm not making some kind of Luddite argument for the way things were. The point I'm getting at is that remote work partisans often have a over-simplified model that misses the benefits of in-person presence. Human beings have a lot of support for communicating with each other in-person, verbally, non-verbally, unintentionally, etc. which often doesn't translate well to remote work scenarios. Many of the social aspects translate even more poorly.
I'm just going to skip the philosophical stuff about worth and meditation because it doesn't really have anything to do with what I was talking about.
>Communication is a mental process, transportation is not, so they're not really comparable areas of change.
Transportation changes the psychology of individuals and the social dynamics. It affects mental processes, so yes, they are comparable.
> The point I'm getting at is that remote work partisans often have a over-simplified model that misses the benefits of in-person presence. Human beings have a lot of support for communicating with each other in-person, verbally, non-verbally, unintentionally, etc. which often doesn't translate well to remote work scenarios.
Fair enough. I agree with that statement, though I still strongly prefer remote work for myself. Some other thoughts:
1. No technology is going to completely replace in-person presence. Rather than trying to work around it, one should be looking for what remote work enables that cannot be done with in-person presence.
2. Philosophical questions about worth has a lot to do with this topic, even if it does not seem like it to you. There is a bias towards in-person work because there is a conflation and confusion on what work is about, and what communication is about.
3. The same with meditation. The ground state in which one can see a lot of narratives and hangups clearly also reveals a lot of weird things underpinning a lot of people's motives for working onsite or working remotely. However, I don't expect this to be convincing to you or anyone else. It is something to be experienced rather than read about.
I would try purely emailing / chatting with someone and compare that against the relationship you build with someone who is right there. You probably are not going to be available on video, so there is a lot of transcoding happening between you and your email / IM etc. and that loses a bunch of info. Not to mention the lack of impromptu hallway conversations and general social bonding.
It is the same problem we face with remote offices - closer is considerably better unless we figure a way to be omni-visible in a better way. I don't think a good enough solution exists yet. It doesn't help that people associate working from home with laxer schedules / attire / locations etc. which also interferes with the omni-visible thing.
In my current remote job and in my previous ones, we use:
1. Zoom (or Hangouts, or etc., in other words, video)
2. Slack
3. Sometimes email
4. Sometimes phone
We use video and Slack quite a bit.
Both my current full-time job and in my last full-time job with a distributed team, every so often, people are flown in together to meet up, hang out, and build relationships.
So as I mentioned in one of my responses above, remote work is not intended to 100% replace in-person relationships. Video and Slack did not build the same kind of experience I had when I flew into San Francisco and spent some time strolling towards the Golden Gate Bridge park with two of the other team members while talking about life, rather than work. Not everything about building relationships with other people has to do with being productive.
I've found the idea "impromptu hallway conversations" come up so often, I suspect it is a kind of echo-chamber narrative that hasn't really been examined for what it is. Having said that, when I visited my team, the office was hosted in a co-living space. I had a lot of impromptu hallway conversations ... outside of the team with all sorts of people, perspectives, philosophies. But that is not the normal experience people have when working onsite, either.
"General social bonding" isn't always what it is cracked up to be. Most people do not allow themselves sufficient honesty or vulnerability to have real conversations. It's more the case, social interactions often has more to do with people's masks and social selves interacting.
By the same token, I have found that effective use of Slack following the Kanban principle of "Make Work Visible" allows me to communicate in a way that I can't easily do with an on-site presence.
That's weird. It's totally normal for couples to run mom and pop shops together. Most businesses historically (and maybe even up through today) have been run by families. It's human. It's natural.
I agree that it is normal for mom and pop shops. It is also normal for pre-modern dynamics: tribal (hunter-gatherer), family farms, etc, though the case can be made that there is some physical separation.
I've also seen co-living/co-working spaces where couples live and work with other family groups within the same building.
However, I also think that the Millennial generation did not generally grow up with this. Remote work also adds a different dimension too, if each partner of the couple are working with different teams remotely, rather than working together, and each partner does not have visibility into what the other partner is doing all day.
The reasoning behind our COO's no(low)-remote policy is that he cannot tell if someone is simply punching in and then watching TV. Meanwhile, he is oblivious to the dozens of in-house workers who are punching in and chatting, doing things on their phone, anything but their work, etc. I have one employee who was grandfathered in, since he's been working remotely since before the COO's random policy decision, and he's the most productive worker I have.
It's completely ridiculous, but you just can't get through to some people, no matter how logical your challenges are. The only reasoning I can see is that our COO is also the VP of Sales (small company), and he values "face time", and "body language", and "reading the room", and some such nonsense that only applies to sales and negotiations, but not production.
My organization requires personal presence because we work on prototype hardware that costs several hundreds of thousands/millions of dollars to make, so we can't just make one for each of us and bring it home. (And even if we could, these things require regular fixing, and if I'm in Japan and the girl who knows how to resolder a certain component in Chile, that's not very practical)
Sometimes I can work from home if I prepare work in advance to account for it (e.g. collect data from the hardware to enable offline testing), but it's extra overhead.
> If your organisation requires personal presence something in your organisation is broken
> > If your organisation requires personal presence something in your organisation is broken
> Please tell, what's broken in my org?
What I'm getting at with this is that if personal presence is mandatory you should have an actual reason for that. Your organisation obviously does.
The more usual reason for mandatory personal presence unfortunately is "Because it's always been done this way and we like to see butts in seats because we don't trust our employees nor do we know how to manage what they're working on or how to measure their results."
Every situation is obviously different, but I've been there. Our equipment had a build cost of just under $100k when were at the pre-production stages.
The problem isn't just working from home, it's "how do you give enough developers/testers" access to the equipment when each unit requires such a high upfront cost and ongoing maintenance and physical space, supplies, etc? So even if everyone is working in the lab, it's still a problem.
Our response was to create extremely detailed simulations of every aspect of the behavior. The code ran on our laptops exactly the same way it would on physical hardware. By simply flipping a switch in a config file, the software would either run on real hardware, or start up with simulated hardware.
Of course, we still needed to test on real hardware, but because we were forced to create the simulation to allow enough developers simultaneous access, it also made it easier for us to work from home :-)
You clearly don't have site to site mass materializers (ie star trek transporters) then you could just move it to your location when you need it. Get on the ball!
It's because the engineering manager thinks that in-person collaboration works better than a remote team.
I can't really argue with the results, the company is doing exceptionally well. Employees are generally happy (perhaps even excited) to work there, so I disagree that the organization is "broken". We're still a small-ish company, engineering is around 75 people and we all sit in the same area of the office. As we grow, then I imagine that this "in-person" effect (if it exists at all) will diminish
I'm in marketing and working remotely is kind of a pain in the ass, to be honest. I typically want to have in-person chats with product managers, developers, etc. about something or other on more or less on a daily basis.
I'm a huge fan of remote work, I've had a full-time remote position previously, I just think sometimes it doesn't work with the culture of a team or business. I don't think that means anything is broken.
> Can you tell what the reason behind that policy is?
there is no reasoning behind these policies. it's just someone's decision. you'd be surprised at how much business 'logic' is really just arbitrary choices.
the way to fix it is to quit and work for someone/some place that has a sane policy. these social shifts take decades to fully manifest because old rich people don't like changing their way. because they're old, and they're rich. why should they? they're old and rich, remember?
you do you, don't try to fight against what can't be changed.
I was with you until you turned it into some weird nonsense about class and age for no reason.
For thousands of years the majority of work occurred in collocation with other people doing the same work as you. Now we have technology that allows for remote work and there are a lot of companies taking advantage of it.
Over time the default will become remote if the specific job allows it. I imagine at some point beyond the default will become remote regardless of the task.
But you can't expect people to change the entire organizational structure of their business overnight "because Slack!"
The manager at my company that keeps this "no full-time telecommute" policy is in his mid-40's. And he's not rich. Well compensated, yes, but not 20 million dollar home in Atherton and a Tesla rich, more like "drives a BMW 4 series from his Peninsula Condo", but he's certainly not rich enough to not need to work.
So I don't think this is a problem with "old rich people".
He put the policy in place when he was hired (before then it was a more loose "come to the office if/when you want to", which worked for a 20 person company, but doesn't work so well with a 50 or 100 person company), along with more regular working hours (flex hours are fine but everyone is generally expected to be in the office between 10am - 3pm to allow meetings to be scheduled)
by old and rich i mean exactly what you described -- a person who works as a manager, is middle aged, and makes a healthy six figure salary. that's "rich" to most people. the ceo in a 20M mansion certainly qualifies also.
A 6 figure salary in the Bay Area is not what most people would call "rich", in some areas you can qualify for subsidized housing with a 6 figure salary and a family of 4.
And while I may be biased by being a decade older, "mid-forties" doesn't seem old for a senior manager.
In any case, unless someone is truly wealthy, you can't say "Oh well they don't care about their job because they are rich", because they need that job, and if they are a poor manager, they'll lose that job.
i'm from california and have lived in the bay. i'm not a podunk who doesn't know what a california salary looks like. we live in a wealth bubble, meaning even your 'lowly' six figure manager is still a rich guy to most people.
my point stands, and i'm doubling down on it. go check out the rest of america and the world, and you might see what i mean.
The really old thing is thinking that you have somehow escaped the human predicament when you really haven't. It's a time honored tradition repeated by fools in each generation.
> Don't you wonder why politicians hold town meetings in person?
Because town meetings are a performance. I prefer a live performance over a canned version, too (such as watching a well-crafted presentation instead of a YouTube recording). There's absolutely nothing against meeting people in person. Those meetings should count however. They should mean quality time (instead of a synonym for "Free doughnuts and countless person-hours wasted.").
I'm an IT contractor. My last contract was at a defence company, so I understand needing to be on their network and it was only 25 minutes away.
The current one is anything from 70 to 90 minutes each way and they have nothing on site, it's all in the cloud. But they insist we turn up in the office. It's utterly ridiculous. I would happily split the difference on travelling and work an extra hour per day (i'm on a day rate) but both parties lose for no reason at all.
FWIW my day is spent on Slack, Github and their cloud provider. I need to see if Gitlab are hiring for devops / sysadmins as they've got the right idea.
The problem is, that it's really time-consuming and expensive to get decent terms of service/privacy policy/other common legal document squeezed out of your local lawyer.
The initial version is basically a copy-paste of some template that just has your own company's name put in and does not anyhow describe the service you're building.
After a week or two with back-and-forward you'll get to settle for some English-like gibberish 15-page document that has been passed through the email and you're sure that after all the hours you've put in to try to make sense of the document your clients have no chance to understand even half of it so you're just putting it in since the whole service is already past the deadline and everyone's anyway blindly ticking the box without reading.
The reason why this hasn't changed is that lawyers get paid by the hour, so it's not wise for them to automate anything.
For personal projects I've used some of the 5$ templates from quick Google search, but the problem is that I have no-one who'd take the blame when the shit hits the fan.
In the perfect world this would be an automated computer program that'd ask me a few questions and produce a perfectly understandable and legally binding document that has some trustworthy corporation behind it making sure I won't get sued for trying to do simple business.
You can't really automate lawyers, unfortunately, anymore than you can automate accountants. Someone has to assume the liability for giving you legal advice / accounting advice. Computers can't yet assume such liability.
That's true. The computer cannot be liable for the advice.
I see two ways around this:
1. The company behind the computer takes full responsibility and charges for the risk. Stripe has made online payments a breeze, because they are the one taking responsibility for the legal things (securing payments, proofing physical access to servers holding the credit card data etc).
2. The tool is so understandable that I'm willing to take the legal risk. There are a few tools that make accounting so easy for a small business owner that I'm willing to take the legal risk myself about the accounting.
This isn't really what you were looking for so feel free to flag me as off topic since I'm kind of piggybacking on it. I feel like a lot of people at bigger companies know what needs to be done, how to do it, want to do it and sometimes have even purchased something to accomplish it but we have the hardest time getting traction.
I think one major issue is that manual processes often don't really "hurt" managers, they hurt the people doing them. To a developer or ops admin, "This $badthing caused by a typo won't happen again if we automate this" sounds very reasonable but sometimes managers just see it as a mistake that someone will need to be more careful about. Once they've factored the turnaround time into how they estimate they don't seem as interested in speeding things up. All that seems exacerbated by reactionary/feature driven mindsets which makes any kind of improvement that doesn't have an external event/person driving it very hard to get slotted. This seems to be made worse if you're working with a manager that's never really done the work that the people they're managing do or they did it so long ago they don't have an intuitive understanding of how it works today.
Another one is that a lot of people who perform a manual process for a long period of time become invested in it and defensive of it. No matter how much faster or better it is and no matter how involved they are if they end up feeling threatened it's probably dead in the water. Pretty typical human nature thing I think but at a big company with a lot of old established manual processes this can slow automation efforts down to a glacial crawl. Even if there's only one person that fully understands it I don't think managers appreciate the risk of having all of your eggs in one basket.
Eventually things do get automated but it seems like it's driven by a disaster or politics more than anything else. And sometimes not even disaster seems to be enough to drive real change if someone isn't pursuing it.
If anyone has tips on how to deal with any of this I'd love to hear them.
Automate your own tasks and do not tell anybody. Have a chilled out life!
It worked out for me until a got hospitalized for weeks and the college who took over my tasks figured it out. I did the same two more times and leard a lot about refactoring bad architectures. I jumped ship an sold myself as the guy who automates processes. Now I can refuse doing boring manual tasks. It makes me really satisfied.
This made me think of an old gig I had. It was a sort of so-easy-a-caveman-could-do-it tech support job. They actually had us printing out a report from an HTML document, cutting out portions that weren't supposed to be there with scissors, and then photocopying the cut up page to get a final report to mail out to the client. I'll let that sink in...
It didn't take me long to start editing the HTML document directly to skip the physical work (someone before me had figured this much out, but hadn't been able to teach anyone else well enough to pass it along when he left, just a vague rumor that it had happened). Then I went ahead and made a crude script to edit the documents automatically, ultimately turning an hour long job into a 2 minute one with cleaner looking results. Ended up spending a lot of time at that job just watching TV.
My next job after that was all about automating manual processes, but with less down time since I was automating other people's jobs, rather than my own. I think I preferred the former.
I used to work for a company basically copying and pasting data from one excel spreadsheet to the other. I didn't know how to program yet, but I knew there had to be a better way, so I learned macros. I spent ~20 minutes a day working. I worked part-time and when I left, my boss commented on how I got done more than all of the full-timers there.
I personally think the biggest benefit to every company would be to drill into people's heads how software should automate your day to day work. Software people think that way, but most employees don't.
>>Automate your own tasks and do not tell anybody. Have a chilled out life!
Many years ago there was a post on an obscure online forum about some guy who hired virtual assistants do to 100% of his work for him for a tiny, tiny fraction of his salary. I don't remember the details, but he would basically go to work and do nothing all day. After a while he started staying at home, and no one at his company even noticed.
No, I do not consult, I am a normal employee working as a data scientist in business intelligence. By jump ship I mean I went back to a small company I used to work for in the past. The VP of IT knows me (my unpleasant side too) and he needed someone impatient like me interested more in doing than in talking.
I do not know anybody doing consulting/contracting here in Germany, it seems to be an uncommon thing. I wish I would know how to get into it.
Nothing fancy. I was in the BI department of a big telco and I inherited a "next best offer" system. It was extracting data from the DWH, doing some scorecard based optimization, picking the right product for the right customer and sending the results to the call centers. The data extraction part was a PL/SQL framework and the optimization was done by a SAS tool. The system was really slow: after a change in the parameters it took 48 hours to recalculate the results. Unfortunately the product line managers loved to change the parameters on the day of the data delivery and my team lead couldn't say "no". So after a couple of month I ended up doing almost everything manually in order to keep the product line managers happy and to keep the deadlines. Practically I took the system step by step to pieces and I worked with standalone SQL scripts, like back in the 90's. After a lot of people were fired and my team lead resigned I was left alone for two months. There was practically nobody to require urgent changes so I used my time to rewrite almost everything from scratch, included the features the product line managers wanted and reduced my monthly workload from 25 days to 3. And I didn't tell about it.
I'd love to take the time to change the way our IT department functions. They don't automate anything. They don't virtualize. They don't believe in rack mounted servers. We have 30 tower servers sitting on a specially built shelf, taking up most of a room. It's absurd but I have so much other shit to do that I can't justify completely disrupting their entire workflow
Neccessity is the mother of invention. Do you have a need to distribute your job queues to multiple servers? Do you need multi-master db replication? Do you load balance? Do you need to instantiate db backups to recover/inspect data? Do you backup snapshots of every server? The more these things happen, the more likely is your IT to yield and buy rack servers
the way we solved it was getting the COO to approve us taking ownership of infrastructure and transitioning into AWS. That way we have a pretty flexible license where we can spin up servers and manage them ourselves. Certainly time overhead but at least now we don't have to email and pray. This also sends a strong message that if they don't try hard enough they can lose projects and therefore their worth at the company
I wonder how the organization puts limits to the AWS usage. For example, do you need approvals for increasing the AWS usage? Is there a limit for those approvals that require a new contract with Amazon?
we're not a huge company so don't need to worry about that too much. Also we're migrating our production servers from Sunguard to AWS which is 4x cheaper, so we're well ahead on expenses
I left a place a year ago where I ran the lab. I remember the satisfaction of my replacement converting all the VMs into "real computers", and then triplicating the VLAN network I had with layer 1 replacements.
I'm pretty sure if he could have unspooled cat5 to everyone's home, he would have gotten rid of the VPN server.
So what's the benefit of VMs? I mean, I understand the underlying benefits of isolation and such, but for things that easily fit on small servers (i.e. single/double core small procs with <4GB RAM), why is it better to virtualize instead of having a physical server for that task? Assuming said task isn't vital enough to have several redundant systems?
I've gone both ways before, but I seem to be on the other end of the spectrum and prefer small cheap hardware over VMs when possible.
Not trying to argue or anything, just curious for someone else's point of view.
Those small things are actually the ideal use case for VMs.
Imagine wanting to spin up a new server so you go and buy that small tower, bring it back, and hook it up.
Now imagine using a VM where you literally go onto a webpage and click a button to provision the same amount of resources.
Additionally, most hardware sits idle most of the time. When you're using tons of towers, it's likely that most of them will sit under 50% load 90+% of the time. With a VM setup, the hypervisor can balance that better so you can get better utilization of your hardware.
I work in pharma, and our biggest bottleneck is drafting and executing service agreements and statements of work with new vendors. A system to facilitate this workflow would be amazing (document templates, a queue for requests with weekly status updates, etc.)
Of course there is manual work done by Legal that can't be easily automated, but that is just one component of the bottleneck.
I work at a gov't organization and was going to say the same thing. It recently took me two months to get an $11/month pingdom account. There is some office somewhere that has to read the TOS and put the vendor on an "approved" list. They never use credit cards, and have to call the vendor (even for small webapps) to get bank routing numbers. Also, no recurring payments are allowed, they must be able to pay one lump sum. By the time I get an account the vendor already hates me.
hentrap - msg or email me. I've been itching to create a new project that also solves a huge/real pain. I'd really like to hear your workflow steps in detail. Here's a temp email I setup if you want to reach out: hn@robodale.33mail.com (removed public mailinator email per mbrookes advice)
I should also add that my wife is a clinical pharmacist who regularly creates infectious disease drug protocols for multiple 'big pharma' companies. Pretty sure she can help me round out any domain knowledge gaps I might have.
hentrep, my startup solves this exactly and we are now live at three Fortune 1,000 firms. Previously, I was a healthcare consultant with mckinsey so I understand the unique challenges in pharma. I would love to chat. Feel free to ping me at jl@thevetted.com.
90 day passwords, with multiple internal sites & servers each needing unique ones? I don't understand why we don't have automated client certificates and auto-generated ssh keys.
Rotation is a really interesting subject which has true security benefits. Unfortunately manual rotation is a PITA. What works better is to have an automated system rotating the credentials, and then you fetch the credentials as-needed by authenticating with an identity and access management system.
For example, in Conjur there is a suite of rotators (https://developer.conjur.net/reference/services/rotation) for rotating things like SSH keys, database passwords, and cloud credentials. In each case, the rotator changes the credential in the backend (e.g. changes the public key in the authorized_keys file), and then stores the new credential behind an access-controlled and audited API where only you (and other authorized roles) can fetch it.
A bit off topic, but the conjur.net domain seems to be a bit broken. https://conjur.net doesn't work properly and it threw an SSL/TLS certificate error the first time I visited. Also, it appears as if your main site doesn't redirect to HTTPS. As a security company my first thought is that if you can't handle these simple things I'm not sure I'm ready to talk to you about more complex matters.
We have actually developed such a service for internal usage (could not use any of these three because of compliance requirements), it works very well.
The 90 day password thing is pretty universal in my experience, but to be fair NIST has only very recently changed their recommendation on this so you can understand business' reticence to ease off on it.
As for the multiple internal sites and servers thing...well, from a security point of view I totally agree with the requirement for separate passwords but it sounds like you're in need of a proper identity management solution - which isn't really fair to blame security for - it's not usually the security function who are going to implement and own this sort of thing.
I'm SO glad NIST put out that new recommendation. I really hate the whole 90 day thing. Argued for days (friendly argument) with one of my co-workers who was partly responsible for our implementation of the 90 day rule on how it wasn't necessarily better, and often lead to stupid passwords with very dumb/simple patterns.
Even with the new NIST rec, I can't get him to back off on it, so sadly we'll be stuck on that for a while.
Maybe 8-10 years ago there was a solution (an AD add-on/schema) I was looking at which set a password change frequency dependent on the password complexity - so a shitty 8 char, lowercase password would be acceptable but might be forced to change every 5 days. Drop a number and something uppercase in there and you might get 15/20 days. Drop a proper password and you might get 90-180 days.
I really wish that had taken off (or, more accurately I guess, had a real business case).
As an industry we tout one set of rules/principles but then enforce a slightly different version.
My main passwords (the ones I have to remember, and not store) are all over 20 characters long and maximally complex and I change them very, very rarely.
Domestic freight, specifically rate quoting and booking.
I sell large equipment to the food & spirits industry. It often has to be shipped on pallets. Before a customer decides to order something from us they generally want to know the freight shipping cost. Rates vary daily, so our salesperson has to stop the sales process to get a freight quotation.
3PL companies already exist, and are supposed to exist to get a best-available rate from the sprawling mess of local, intrastate, and interstate freight carriers. Still, we've found that to REALLY get the best freight rates we have to send out a quote request to 3+ different 3PL companies, wait for all the quotes to come back in, figure out the cheapest quote from the most reliable carrier, then re-ask the same 3PL parties if they're willing to beat the best available rate. The sales process loses a ton of momentum, and it wastes our shipping manager's time.
A better version of this: http://cbsg.sourceforge.net/cgi-bin/live . The corporate bullshit generator. If it could also make powerpoints with nice graphs of merging product timelines, we could replace most of management.
The real problem with phone screens is that unless you (as a recruiter) trust an unbiased third party to do phone screens at the level of rigor that you would do them yourself (rather than being incentivized, as recruiting agencies often are, to try to maximize the number of candidates they give to you), you have to do phone screens yourself with every candidate, requiring NM conversations. If you do solve that problem of trust, then you just need K(N+M) conversations, where each recruiter and each candidate establishes a relationship with one of K third parties, wherein the recruiter is notified about the candidate iff the candidate passes the third party's screens. https://triplebyte.com/ is trying to be such a third party, establishing trust with YC alumni; there are likely others. From a friend going through the process as a candidate, it seems that they have a high level of rigor and are placing him in good later-stage interviews.
Hahahah! You just made me think of creating a chatbot to answer people's questions about me for phone screen interviews, since answering the same questions over and over and over again has gotten me to the point where I sometimes procrastinate getting back to recruiters because I don't want to go through the process for the fiftieth time.
"How much experience do you have with Unity?" <chatbot-version-of-me>: "I worked with Unity on projects blah and blah and....". "Tell me more about your leadership in project blah?" <chatbot-version-of-me>: "With project blah, I was in charge of X number of people. The project was completed over a period of X months and ...etc."
Pretty much! I'd also include narrative answers about challenges overcome, accomplishments, etc. and boilerplate about how great the company is, respectively.
It's critical to have the interviewer side fully automated as well, so the bots can all talk to one another and just ping us when things match up. Imagine the hyper conversations from the movie Her, but for jobs.
Shameless plug of a tool I built which might help you with this, especially if you're hiring developers.
It'll automatically research the applicants who apply to your open position and collect github profiles, repos, and do it's best to rate them appropriately.
By the time we'll have an AI that can do that well, the same AI will likely to be able to do both your and the recruiters job, so the phone screen won't be necessary.
The difficult part is that the areas that could be automated are usually the ones that would buy the automation software.
The person signing up for the automation would be reducing their total headcount, making them a perceived smaller player in the overall organization.
I've seen this in the purchasing part of big corporations. They automate with Ariba or similar, but then, don't shrink (even via attrition) to get the benefit.
Worse, because all these people still want something to do, they then inject more manual processes to feel like they are busy. Ugh.
As my company grows 50+ our DOO is failing at tracking who's working what and when. We use JIRA and have timekeeping but don't use either for resourcing. Also the company has 10 independent projects. I'd love to have some tool besides a spreadsheet or hearsay about upcoming work and who's doing it.
JIRA is terrible in my opinion but has evolved and many (most?) small, medium and big software houses use it.
There are more alternatives than I can count did you look elsewhere? For some reason people continue using JIRA and investing time and money on it. JIRA has an awful interface, is unnecessarily complicated, has a learning curve (when it shouldn't) and you actually need to know SQL in order to create helpful views for trivial things (e.g. have a proper view of hours/projects worked per week).
The only easy to use and reasonable tool is trello. You can keep a list of tasks but it's not very practical to see who's doing what.
---
A good practise is to request people (not just developers) to send a weekly email to manager(s). (Keep it concise AND bullet points MUST be understandable by anyone NOT familiar with their projects).
Major news: single line (if any)
Done: ...
Next week: ...
---
And then. Have each team make a google doc. Write down goals/targets for the next month(s) and who's responsible for executing it.
Teams update the document once a month and email it company wide, open to comments.
I think I can help with this. If you're interested in getting better visibility on what projects are in-flight and who's working on what, send me an email ray@ObjectiveIQ.com
I'd be happy to send you an invite for our private beta. Think of it as a blend between Slack and Jira.
I'd love to hear about various solutions for this as well. So many tools are so heavy weight, and others are too lightweight.. and everyone ends up with something JIRA/Bugzilla + spreadsheets and reports.
Don't be afraid to do the next least janky thing. Run with it. It's like David Allen with GTD:
If you can't do it with paper, you don't understand your process enough yet.
A manual process that is well understood can be well automated, an undefined process will struggle as automating something while also defining something always ends being a huge long project. If you can mentally model how to do it in trello, then do it, and come back to the automation step once you see it working (they have an API, you can get there).
Have a look at Odoo, it integrates all you need in a single software: project management, forecast/resource planning, timesheet, bug tracker, integration with github, communication tools, ... (as well as integration with sales and billing/accounting):
Are you talking about the process of assigning tasks for people to complete, having visibility into what is currently being worked on, or having visibility into what was done recently? Or some combination of the three?
I'm guessing you not talking strictly about organizing the tasks and projects themselves since there are a million tools for that.
More than anything the DOO probably just needs to learn how to do their job, communicate with people, and use the tools we already have. But yes -- not necessarily high fidelity within a project. More like "Because of funding on X you will be moving to work with Tanya on February 27. The program manager is Harvey and you will be allocating your time to account #777." And then based on that sort of information having a matrix or GANTT chart of which employees are charging where and which project. Perhaps the organization is just dysfunctional and no tool will solve the problem.
I recently started using WakaTime myself, with plans to integrate with Xero some weekend. I just need an intermediate interface to adjust invoice labels and review billable time. Something similar could work for internal projects - maybe try to get an on-prem WT instance.
I would like a tool that looks at what people are doing and fills out timesheets automatically. Stop asking your developers what they are working on directly and start looking at their artifacts. For example, if Dev A. just checked in a bunch of code for Project Alpha, there is a good chance they have been working on Project Alpha for the past X hours. If QA person Q just ran a bunch of tests for Project B and updated a spreadsheet, there is a good chance that they have been working on Project B for the past Y hours. Person W just updated a bunch of Wiki pages for Project C? And so on.
Sure, you can't capture everything everyone does, but most of the "timesheets" I've had to fill out in the past could have at least started with this information and allowed me to modify it. I hate filling out timesheets and keeping track of what I do. I'm doing work, something should keep track of that for me.
Ordering of stuff from central IT. I waited 3 months for my RSA token (which I need for working remotely). My boss waited 4 months for a dev server he desperately needs for a customer project. The request for the server was only processed when my boss talked to some other guy who knows someone from the central IT department. And the requested server wasn't even physical hardware but a virtual server!
I waited 3 months for my RSA token (which I need for working remotely). My boss waited 4 months for a dev server he desperately needs for a customer project.
Pardon my language: holy shit.
How large is your organization??? All I do at work is build dev environments, manage credential storage, and every now and then get roped into server upgrades kicking and screaming...four months for a freaking dev environment???
At Wells Fargo, I'd kill for a dev environment in general. We only do production-classified-as-dev. And 4 months? Slow down! We're six months...if you're lucky.
Our password policy is pretty terrible. We don't even have our own user profiles. Whenever I'm on a different desk than my own, I get to experience a completely different desktop. With completely different applications installed, settings, etc. I work part-time hence my desk isn't the same permanent spot, so this does occur regularly. So apart from a security hazard, this is also a productivity loss.
I'd also swap everything to Linux (my preference is macOS, but I can see how that'd increase cost). For the kind of development we do, Linux is just as good as the other two.
I honestly don't know how to solve the issue for me easily. Perhaps just install all applications and settings on a thumb drive?
A related question, for my own interests... how able do you feel to automate things at work? If you find a tool that can automate a severe pain point, can you bring a vendor in for a demo? Can you get a budget or get a manager to pay for automation tools?
As a founder about to hit the market with an automation tool, I'm very curious about the roadblocks and resistance that engineers perceive about bringing in tools that can save a lot of pain and money.
It's generic advice, but: Make sure you're solving the manager's pain point, not the low-level employee's (i.e. "this gets the information/service to you with a higher guarantee of quality and always at your fingertips" rather than "this saves your employee a lot of stress"), and make sure you're marketing to the manager, not just the low-level employee. And if you get lower-level employees as leads, make sure they have the ammunition (white papers, etc.) so they can escalate to their managers in terms of solving their managers' pain points.
I'm thinking of focusing on downtime and shortening recovery time from failures as a marketing angle. It's not the only problem I'm trying to solve, but it seems like a solid sell for management's pain points. Whether or not they care if their engineers are miserable, they care if they're losing a thousand bucks a minute on a down system.
Thanks. I've been thinking about that and how to present it. It should significantly reduce the duration of downtime incidents, which is a strong sell point if I can phrase it right, but I feel like my best sales force could be senior/lead engineers who want to make their lives easier.
Bringing our main app into various states (and also regular Selenium tests based on the same code, ideally in Clojure). It currently takes dozens of clicks and dozens of pages, all super repetitive to get to most places in the app (super long question / answer based interface). I should have done this years ago when I joined but the pain has finally become great enough that it can't be ignored anymore.
Interviewing and hiring interaction for seasonal workers.
We hire tons and tons of IC's two times per year. We run into bottlenecks due to time on the phone during interviews. If there way a consistent way to screen talent it would save us a ton of time.
onboarding new developers so they understand the essentials of our archeitecture and code base.
that includes writing up all the documentation. (what, you thought youd just create a sleek ui with the documentation provided by users? no! thats the hard part!)
Time tracking. Like, the physical act of figuring out how much time was spent on X task for Y client and then logging that in. And no, cheesy little desktop apps that provide a UI and timers for this are not the answer I'm looking for.
The challenge we faced and still face is more making it clear on how to classify time to the rank and file team (I work in a digital agency).
We are pretty much ~90% now.. ..some lessons learned:
1. Just have people track rough time per day (a couple hours here, a couple hours there), but make sure it is done daily. The resolution will hold up when you analyze it. What seems rough each day, ends up being quite accurate over weeks/months.
2. Don't be strict about budgets AND ask for perfect accuracy in time tracking. You are offloading the responsibility of good estimates to the team, and boxing them in.. screwing your long term job costing.
3. Build a dashboard that summarizes project / account status and is as useful and obvious for Project Managers & Leadership, and they will become advocates in promoting good time tracking hygiene. (I guess this is a basic truism in general.. build systems where the best way to use it is the easiest way.. )
I built my own SaaS tool to track my hours I worked when I used to do freelancing. I can create various tasks under the client's project and then log my hours.
I can then create reports to see how much time I spent on each task for each of my clients. Or even better, I can take those hours and create an invoice out of all my uninvoiced hours and email it right to my clients.
I don't have to get that specific with time, just hours worked, but I use IFTTT to track the hours I am physically at the office. Beyond that I'm pretty good about remembering work done offiste or at home.
Onboarding of new customers. I feel like we must do this different than most places because I've not been even able to find a good system to even track the steps and things I do to get them set up and started. I've tried just about every task and project manager out there, most of them were good enough, but nothing was ever perfect. Using Basecamp now, has proven to be "good enough" so far (support has been perfect though). I feel like a bunch of this should be able to be automated with something that already exists.
If nothing off-the-shelf works, then you may need either a customization of an existing product or an entirely new product. If there's nothing out there like it, then this is a competitive advantage for your company and you should consider investing significant resources into it. Hire a developer or consulting company that creates such software.
Just keep in mind that maybe 1 in 5 of those projects actually succeeds, so do a lot of due diligence up front. Don't go with "lowest bidder" and make sure your project manager has profound domain expertise and works very closely with the development team.
Paying twice as much to a proven implementor is worth it if the lowest bidder fails to pull off the project. In that case your rate of return is going to be rather bad.
I'm confused by what you mean. I'd argue that onboarding new customers should be your core competency, the focus of your main product. What am I missing?
We make an application that makes use of folder on a network share. One of the developers here types up instructions each time we install a new site. If the customer has trouble or opts to have our help, they will connect remotely to create a folder and some sub folders. This takes anywhere from a few minutes to over an hour if they have trouble connecting remotely.
I mentioned in a developer meeting that we should create an install script for the network folders. It would save the company hundreds of hours or work.
One developed asked how I would do it. A generally competent developer, who has worked with files and folders for many years, asked how we could deliver a program to create folders.
I nearly walked out (and we still dont have a 4 line script to create the folders we need)
>> I'd argue that onboarding new customers should be your core competency, the focus of your main product.
I suppose that's true, in a way. We host open source stuff for stuff, we support people, we do lots of stuff, some of it is automated, and some of it isn't. I was just saying a larger part of getting the new customers in production would be good to have more automated and I've not yet found an easy way to do that.
I do like the idea of that being a core competency, though not quite a focus of the main product.
Database changes. We can't use database projects just yet but I'd like to find a way to automate it much the same way that you can apt-get install things.
I'd make it event-driven. /usr/sbin/hire --ceo starts a setTimeout(function() {`/usr/sbin/fire --ceo`}, 'INTERVAL 60 DAY') (And that is a weird bit of pseudocode, indeed.)
I used to work in a big law firm working on startup-related corporate work. A substantial portion of my job looked like this:
* Find a form or template for a document. Sometimes the "template" wasn't really a template but "we worked on a deal that was pretty similar to this one three months ago -- use that". Sometimes the template was "use this form except for this one section you should use from that form".
* Tag form / template as "version 1" in our document management system.
* Fill in all the blanks, remove brackets, etc.
* Tag this as "version 2" in our document management system.
* Create a diff / redline with all my changes.
* Send diff to partner for review.
* Incorporate changes from partner into document.
* Replace (rather than append) "version 2" in our document management system with the new doc.
* Email document to opposing counsel for review.
* If we're sharing docs with opposing counsel via Dropbox, Box, etc., upload there too. But also email them, because they might not remember to check Dropbox.
* Bug opposing counsel every 24-48 hours until they respond with an edited copy of our document.
* Let partners and clients know that you are bugging opposing counsel so they know it's totally not your fault if this deal doesn't get done by Friday.
* Save opposing counsel's edited document as "version 3" in our document management system.
* Create a diff of the document they send and ask partner to review.
* Bug partner every 24 hours until they respond with more changes.
* Save this as "version 4" in our document management system.
* Send this, along with a diff, back to opposing counsel.
* Somewhere in this process we also pass along to our actual client for review.
* Repeat until no one has any more changes. Do this for many more documents that are part of the same deal.
* Send out the first set of documents for signature. Some people don't want to actually review the things they're signing (crazy!), so we create "signature packets" where it's just like four signature pages in a row. Also, everyone has a different set of documents to sign so different people get different sets of pages + documents -- and sometimes we need to make sure that person X doesn't see some document that only person Y can see because secrets.
* Or we use an e-signature service, in which case I spend some time creating little boxes over all the document so the service knows that this is a place where a signature-like image has to go.
* Discover some error in document. Fix. Redo all of my little boxes.
* Respond to people confused about how e-signatures work. Sometimes if there are four documents, the signatory gets four e-mails and then they're confused as to whether they should just sign the last one or all four or whatever (you should sign all four). Also, sometimes people refuse to use e-signatures, so we have to explain to people that because Docusign says the deal is done doesn't mean it's actually done.
* Sometimes this is where we file stuff with the state government.
* Send out a second set of documents of signature. We don't send these out with the first set (even if the same person is signing stuff in both the first and second set) because it's very important that the second set not be signed until after the first set is signed by all the parties (or after we get some sort of confirmation back from the government if there's a filing involved). Sometimes we have very important people that hate being interrupted to sign documents, so we let them sign everything in one go but hold some of those signatures "in escrow" so we can "release the signatures" in the right order.
* Track all of the outstanding signatures and filings via a spreadsheet and try to update this in as "real time" as possible.
* Respond to partner or client asking you about deal status by pointing to spreadsheet.
* Respond to partner or client unable to open spreadsheet for whatever reason by summarizing signature status in text form.
* Bug people periodically until everything is signed.
* If any of the parties to a deal refuses to e-sign stuff, this is where I have to create a "final" signed PDF copy of the documents, wherein I replace blank signature pages in a document with some faxed or scanned signature page.
* If signatures were being held "in escrow", bug the people who are holding the signatures in escrow for confirmation that the signatures are released.
* Sometimes these people need to bug other people for confirmation. These people then ask lots of questions like "has other person X signed yet?". Point to spreadsheet.
* Sometimes money gets wired here. Wait until we confirm the money came in.
* Signatures are released! The money came in! Tell everyone the deal is done!
This sounds painful, but it also sounds fairly typical. Except usually such work is split between several different people/positions.
No one thinks about it, but one of the main reasons this kind of stuff stays manual is because the typical tools people are using to do it have no (good) integration points. Automating the entire process would require writing a large and complicated system. Automating parts of the process one step at a time is extremely difficult, because implementing most of the individual "steps" will require creating tons of complex integrations, and not result in any immediate productivity gains. Such incremental changes disrupt what people are currently doing and possibly create more stuff for them to do in the short run.
For example:
"Fill in all the blanks, remove brackets, etc."
This is a perfect use case for machine learning or even a simple rule-based system. If you had all the data in one place, it probably would be trivial to automate. However, getting all the data from various systems, converting it to a standard representation, then converting fixed data to target formats and putting it into target systems is orders of magnitude more difficult than the actual corrections/changes.
Totally does seem like something that can be nicely automated to some level. Even document tracking and associated metadata (like a list of participants and status of signatures per page, approval of document, etc) would help.
Of course it can be automated. The problem is that everyone involved in the process is extremely resistant to automation because clients are billed by the hour and automation would result in fewer hours spent on the case, which means decreased revenue.
I'm a total outsider to this field, so forgive me if the answer to this is trivial/obvious, but why not sell a service like this directly to the client?
If you give outside counsel any significant role in a transaction, they'll find some way to create work and bump the bill up to whatever cap you set. So you don't really save cost-wise unless you're able to almost entirely remove the human element.
Now as to why we don't remove human lawyers from the process ... I think it's trust, mostly.
It's a bit like selling automated medical services. Your clients don't always have benchmarks for what's "good" legal work, much in the same they don't know if they're getting "good" medical advice, so it's hard to evaluate the quality of an automated service. And since there's always some chance the automation misses some edge case that a trained professional would have caught, if the stakes are high (medical -> life or death of a person, legal -> multi-million dollar lawsuit), clients opt to keep the lawyer (or doctor) in the loop.
For simpler or low-stake workflows though, there is direct selling to the client (see Clerky).
To answer your question about Software companies, the main process that will be automated is software development. AI is coming and engineers will be leaving.
Our company pumps out tons of long-document PDFs that are fairly complex in terms of text, charts, tables and whatnot. We then take the docs, excel files, and charts into InDesign to create a nicely designed PDF to upload online.
I need to find a way to automate this workflow. Anyone out there experience this in their organization and want to work together on something?
Check out pandoc. With it you could convert your documents into Markdown. Then use common *nix text-utils to merge the parts you want into a single file and then load it to InDesign. Check out this article (http://rhythmus.be/md2indd/) that inspired me to automate protocol specs extraction from Word documents (bluurgh).
Hi danraftis, I'm interested in a generic solution solution to automate (instead of manually cut+paste) assembly of PDF files. Contact me at ycco@fgrazi.33mail.com if you are interested in working together as pilot user.
InDesign itself is scriptable, but you may also want to look into automating it on the server using iText, which is available in Java and .NET flavours.
There are plenty of data cleansing and processing tools. Things like formatting errors can easily be fixed automatically. Things like "Human erroneously put a string in a date field in Excel and exported it to CSV."? Not so much. Errors like that often require bespoke solutions.
Yep. I'm more inclined to roll my own right now though, since I have some very specific ideas I want to implement and some other use cases to incorporate. The biggest problem lately has been time. I started down this path sometime last year, but have been letting it sit on the back-burner for a while, in favor of focusing on higher priority tasks. sigh
I wish a customer could go to our online order form and press "Price Quote" instead of "Order" and get a price quote (PDF) that they could give to their purchasing department. It would only take a few hours to pound out, but there is always higher priority work.
Delegating some rights to some managers in Active Directory. For example allow them to add or remove access to specific groups in a way that is intuitive to them.
It would allow us to focus on other stuff, and they would be able to quickly grant access without waiting after us at all.
I'd build a robot, tape a picture of my face onto it, and program it to tromp over to the conference room, zone out for fifteen minutes as everyone goes around the circle like it's kindergarten show-and-tell, then read my commit messages for the day before, the titles of the tickets I've picked out to work on today, and finish with "No roadblocks".
It'd save me an hour a day in interruptions and wasted time. Now I just need to build the robot...
Automate DEA state creation from CAD-Cell Descriptions, state-transfers and all-state-covered-automated-proofing- im so sick of all those forgotten states and the blame that usually gets shifted towards the moving actors aka robots.
Most of marketing at traditional compnaies can be automated by ML. This is already happening, but there are huge F500 companies where the employees have an incentive not to automate.
