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'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.)
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.
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.
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.
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
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
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
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.
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.
My name is Kaitlyn and I am with LogicGate. We will be able to help you streamline your process.
LogicGate is a flexible software solution, which empowers you to create highly controlled processes to automate and track your activities with new or existing vendors.
If you are currently using excel, emails and share drives to manage these activities, LogicGate can help automate, centralize and streamline your process.
Rather than shoehorning your process into expensive out-of-the-box software solution, or relying on Corporate IT, LogicGate enables you to take control of your risk thru a drag and drop interface.
I would love to show you a demo of our product. What is your direct contact information?
I look forward to connecting!
Kaitlyn Martin
414-517-9409
kaitlyn.martin@logicgate.com
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.
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.
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.
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.
> 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.
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
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!
> > 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 :-)
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
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.
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.
> 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.").
> 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.
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.
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.
> 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.
>"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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 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.
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):
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.
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.
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).
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.
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.
>>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.
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.
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.
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.
257 comments
[ 14.7 ms ] story [ 5319 ms ] threadhttps://dlvrit.com/
https://ifttt.com/connect/feed/twitter
If it works we could apply it to the US presidency ;).
[1]: http://www.ledger-cli.org/
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.
https://github.com/Netflix/bless
http://gravitational.com/teleport
https://www.scaleft.com
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.
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.
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.
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.
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.
Disclosure: I am CTO of Conjur.
I'm pretty sure if he could have unspooled cat5 to everyone's home, he would have gotten rid of the VPN server.
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.
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.
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 highly recommend 33mail.com instead - it has a pretty generous free tier: http://33mail.com/rj37w3.
(Not associated, just a long-time user and happy paying customer.)
hn@robodale.33mail.com
My name is Kaitlyn and I am with LogicGate. We will be able to help you streamline your process.
LogicGate is a flexible software solution, which empowers you to create highly controlled processes to automate and track your activities with new or existing vendors.
If you are currently using excel, emails and share drives to manage these activities, LogicGate can help automate, centralize and streamline your process.
Rather than shoehorning your process into expensive out-of-the-box software solution, or relying on Corporate IT, LogicGate enables you to take control of your risk thru a drag and drop interface.
I would love to show you a demo of our product. What is your direct contact information?
I look forward to connecting!
Kaitlyn Martin 414-517-9409 kaitlyn.martin@logicgate.com
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.
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.
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!"
So I don't think this is a problem with "old rich people".
but that's just like, my opinion, man.
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.
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.
A small to mid sized startup manager is not (usually) rich enough to not need his job or care about job performance.
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
Please tell, what's broken in my org?
> 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."
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 :-)
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
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.
There are loads of people who watch Netflix all day at my company, but full time remote isn't offered to everyone.
Why do you categorically say that something is broken if it requires personal presence?
If personal presence is mandatory you'd have a very good reason for it (as in GuiA's case above).
If your main field is hardware related, it's probably necessary.
But a software developer, a sales person, a marketer?
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.
Don't you wonder why politicians hold town meetings in person?
Edit: Also, if your org doesn't require personal presence it is vulnerable to some attacks.
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.").
> 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.
[1] http://calendars.wikia.com/wiki/Soviet_revolutionary_calenda...
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.
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.
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).
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.
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.
Thanks for engaging, it's been fun chatting.
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.
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.
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.
Pretty hard to run a repair center for physical items without people physically present to do the work.
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.
Gitlab just posted in the who's hiring thread, so I guess that's a yes :D
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.
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.
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.
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).
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.
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.
Hmm. No one responded self-driving cars as a solution. Maybe with internet connectivity built-in so people can work en route.
http://www.businessinsider.com/programmer-automates-his-job-...
http://interestingengineering.com/programmer-automates-job-6...
https://github.com/NARKOZ/hacker-scripts
Actually, automating "dealing with regulation in general" would be the most amazing thing ever.
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.
Basically I want both sides to be faithfully represented by conversational AI, inclusive of demeanor, domain knowlege, and general aptitude.
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.
https://www.hireloop.io
"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."
That's what you're suggesting, isn't it?
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.
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.
White papers are a fine idea!
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.
The human element.
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 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.
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.
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).
Good luck!
I'm guessing you not talking strictly about organizing the tasks and projects themselves since there are a million tools for that.
I'd be happy to send you an invite for our private beta. Think of it as a blend between Slack and Jira.
https://www.odoo.com
Disclaimer: I am the founder of Odoo
---
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).
---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.
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).
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.
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.
As someone who's interested in this kind of work, do you have any advice?
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.
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.
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 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.
What is the ROI?
What is the cost of the current process (time, money, resources, FTEs, etc)?
What is the cost to implement (time, money, resources, FTEs, etc)?
What will be the maintenance cost?
What is the risk of implementing this?
What is the risk of not implementing this?
Once you have all this take it to your manager or your manager's manager or the business manager this affects.
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???
FOUR? How does this happen?
Are you even trying?
There's no real excuse for delivering a dev server in 4 vm in months. You sure he ordered one server and not say a dedicated cluster of 4.000 servers?