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.
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.
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.
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.
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
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
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 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.
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.
"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.
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.
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.
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).
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.
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).
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.
Mac: https://qotoqot.com/qbserve/ (our app, the site lacks info but it has export now)
Linux: https://github.com/gurgeh/selfspy
Windows: http://www.manictime.com/
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?
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?
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!
Actually, automating "dealing with regulation in general" would be the most amazing thing ever.
http://interestingengineering.com/programmer-automates-job-6...
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.
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!)
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 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.
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 it works we could apply it to the US presidency ;).
Edit: What? This is a great idea. Does anyone know a good encoding scheme for the 10 key?
* 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!
* Curl into fetal position.
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.
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).
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.
Model that process on the engine, the engine takes care of everything else; notification, queueing, etc.
Many bots are admittedly experimental, but individuals are empowered to optimize or unsubscribe from a channel.
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?
I’ve done this for 13 years (Mostly Quark instead of InDesign, but the same tools and tricks).
Let me know if you want to work together.
rusty
[you can email, feepish @ google’s free email]
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.
It would allow us to focus on other stuff, and they would be able to quickly grant access without waiting after us at all.
http://www.businessinsider.com/programmer-automates-his-job-...
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...
/remind Time for the daily standup! Say what matters and where you need help. everyday at 10 AM
(Before, the meeting was in voice chat, not a physical standup since we're at multiple locations.)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.