Kate Heddleston is freaking awesome, if you don't know. Her talk at Pycon 2015 about diversity in engineering environments is fantastic. Well explained in language free of activist rhetoric -- it was a pragmatic and thoughtful speech. Her blog expands on much of what she covers and should be read.
On the topic of on-boarding -- super important to get right! The idea of making your people the best they can be is lost, I think, on our generation. My grandfather-in-law was a mechanical engineer at Chrysler back in the day when they had a special school they ran to train their new recruits. When he started he had no idea of how cars worked but they picked him up from school and gave him the training he needed to become an important figure in their company.
Focusing on hiring the best because hiring someone mediocre will damage your business is negative thinking that can kill your on-boarding, and thus your culture and business. I've worked at places with terrible on-boarding and it was a fight just to get some direction and support for your work. Getting the attention of management was something you wanted to avoid which led to people becoming complacent about their work and its quality.
Great article. On-boarding is important to get right.
Regarding the negative thinking, this is a really important point. Consider these two alternative attitudes when on-boarding a new employee:
1. Let's evaluate to see whether the new developer is good enough, so we can fire fast if our expectations are not met.
2. Let's figure out how to help this developer achieve his/her maximum potential for adding value to the organization. If for some reason the developer is unwilling or unable to develop to a level that makes a positive contribution, then we consider separating.
I find the second approach much healthier for the employee and the organization.
False dichotomy in my world since I employ both 1 and 2 with a very, very lenient set of guidelines for 1. Some things do not manifest in an interview, and that's where during the first couple weeks I check for some basic professionalism. Things like:
1. Are you responsive to e-mails or IMs at all? I don't mean are you answering e-mails constantly and within 10 minutes each time, I mean "do you answer e-mails when you are asked for a response?"
2. Do you ask questions at all? If it's day 7 and you still don't have access to Github because you never asked "So where do I, you know... push code?" I have to wonder what you were doing from days 1 to 6.
3. Have you confirmed what your expectations are if they are not clear to you? I give a basic 1-day project fully expecting it to take a bit longer, but if it takes a whole week and you're silent, I have to ask why you think it's ok that you have no idea what's going on and that it's ok. If I suspect they're not pulling their weight, I'll give a project where they will immediately be blocked and require assistance if they spend more than 10 minutes investigating the issue. This also helps me determine if someone is simply really, really shy or if they're just not doing any work.
And lastly, reaffirm that you've done 1 to 3 and communicate clearly that those are the expectations before you fire the person for being pretty much dead weight.
You can't figure out how a lot of people will work until they actually start a job.
It's not that the idea of making your people the best they can be is lost. It's that our industry has accept job-hopping as normal, with the side-effect of limiting how much training a company is willing to invest in someone who stands a good chance of being gone in three years.
The notion has less been lost and more been re-evaluated in a new context.
Switching jobs has gotten me 30% pay increases twice in my life. I've never seen a yearly raise from a current employer for more than 4% though and significant promotions with pay increases from within are a rare event without moving into management roles. If you're young and your experience and capabilities multiply quickly, job hopping is the single most effective way to better your income.
Lots of employers seem to be OK with the churn of young developers. Pay the below market rates until they develop enough skills and confidence to demand something better, replace those people with new grads and retain the people willing to work for below average salary.
This is the truth. Nobody will increase your pay as much as someone willing to compete with another company for you.
The trick is to make companies where money isn't the only motivation for working there, because those kinds of companies will always lose in the talent wars anyway.
You left out a bigger factor, in my opinion: tracking compensation to inflation or the success of the business, not market rates.
If the market rate for an engineer is (making up numbers) 35% higher than it was in 2010, each engineer better be making at least 1.35 times what they were five years ago. Probably more, considering they're likely better at what they do than they were five years ago.
Market rate means nothing to employers. If they could give you 3% raise per year and get away with it, they would. The only way for non-union developers to protect their interest is to look out.
Market rate means something to employers - it's the rate they need to pay you more than, if they don't want you to have lots of better options for where to work. If you don't have lots of better options for where to work, you're more likely to stick around, and less distracted while you're doing so.
Show me a union worth five minute of talking to as a software engineer, and I'll talk to them. I've yet to see anything worth even a minimal effort, and I have looked. I've yet to see a single one that offers to actually improve my life.
I think I'd argue that not paying you the higher wage to prevent you from moving is an "anti-employee tactic." A side effect of this anti-employee tactic is you hopping jobs.
No it isn't. I have noticed that during my career I have had very few measly pay rises (and 1 decent one). Switch job and I usually get at least 10% more.
Its crazy, as on some systems that I have worked on it has taken me 6 months to get fully up to speed (not that I wasn't productive before then, just a lot slower). Rather than pay 10% more, they will let employees leave and pick up the tab for a new person learning the system.
Bloomberg does this for its software engineers. I know a few of their software developers (one was EE, one ME) who were both very sharp guys that they trained while paying them for six months while they sat in classes (at Bloomberg from a current Software Engineer) to develop for the Bloomberg terminal. Great way to introduce new talent to the company while also training them for the role.
The point you make about hiring ordinary people is an important one. The timeless, old essay "Why I Never Hire Brilliant Men"[1] makes a lot of great arguments to this end.
The meat of the essay comes down to this quote:
Business and life are built upon successful mediocrity; and victory comes to companies, not through the employment of brilliant men, but through knowing how to get the most out of ordinary folks.
Your grandfather-in-law is the perfect example of something I wish we'd see more of today.
I'd never read that before—thanks for sharing it. The author's examples of people that led him astray sound eerily familiar to the founder of a startup that I spent a few months at earlier this year... (which, thankfully, I was able to leave before things got too bad)
Kate's talk at PyCon Sweden was one of my favorites. It's called "The Ethics of Being a Programmer." Here's the video for anyone interested in watching:
Onboarding is a people/process/docs/technology problem. To the limited extent that it is a technology problem, you really can't go wrong with a) treating it like it is an actual shipping product of the company (implying a minimum standard of care like e.g. a repository, documentation about it, and a dedicated place to put issues) and b) actively maintaining something with the goal of getting someone up-and-running quickly.
None of my projects are at the point where you can just "vagrant up and go", but the next-best thing has been READMEs in the relevant repositories with exact lists of "Type this, type this, type this, type this. You now have a fully-working system running on localhost and you should be able to type this to get a full green test suite. If you can type this and it does not come out green, fixing that is more important than anything Patrick is doing right now."
Here's, for example, what we have for getting someone up and running on Appointment Reminder (in preparation for me soon no longer being the engineer who keeps all of that system in my head): https://gist.github.com/patio11/a0b1063c5d33b5748da6 Feel free to steal ideas in terms of level of detail or useful things to include. (A lot of the magic is in the rake commands like "setup_site", which take care of "All that crufty configuration stuff which you would otherwise need a senior engineer to do for you prior to actually seeing the page render correctly on localhost:3000.")
Quick hack which helped us on making sure this guide was actually accurate: we had two engineers coming into the project at the same time. I wrote down everything I thought they needed to know. Engineer #1 implemented to the document I had written, filled in the blank spots where he needed to ask questions, and then we committed the readme. Engineer #2 then had to do it off the readme without asking me any questions. Given that he was actually able to do this, we have high confidence that there is not at the moment anything rattling around in my head which is absolutely required to get up-and-running and documented nowhere else.
That's a great example of practical documentation. I just want to add that for a fair amount of developers they are not going to be successful unless they get an hour+ meeting a couple times a week for the first month for questions and a general birdseye tour of the architecture.
Things like "I know most people do this, but we are expecting to swap this feature out in two months so that's why it's put together like that so just roll with it and spend a few extra minutes manually testing before you ship it." or "Employee X is in the middle of refactoring all of this but is putting out a fire for the next couple weeks. If you need to do something here get in touch with him and what you want to do and he'll either walk you through it or apply the fix himself".
Unfortunately the personality type of a 10x developer is often not going to be like your 1-2x developer. Pointing them to some documentation and walking away often will lead to an unsuccessful onboarding. This may be preferable if you are actively testing out the new hire and really want fully independent developers, but if you are not knee deep in talent some verbal onboarding can work wonders.
Thanks a ton for this. I've been recently looking for examples to follow as no readme or style is perfect but this is a worthy goal for any software project to me, be it internal or external, closed or open source.
I think the key to make it successful is to have the feedback of someone actually working through it, finding the pitfalls or shortcomings, and correcting as they go. I know I tend to "just figure it" out but I've been in plenty of places with little to absolutely no documentation. It behooves me that if someone did take the time to document something, I should honestly take the time to "pay it forward" by keeping it current as I work through it. It's also far too easy to let this learned skill stagnate when you aren't required to document anything so absolutely no one does it.
Scripts like that need to be able to recover from a very wide range of error modes caused by subtle differences in how target machines are setup - or at least fail in a reasonably obvious way.
Writing such a script is significantly more time consuming than writing a README, and for it to be worth the effort, it should be expected to save a fairly high multiple of the time it takes to write, debug and support. For GitHub, that multiple is definitely very high, for Patrick, it might not even be greater than one. YMMV.
Very similar to this, I like to say that automation is documentation. Of course, actual documentation is better, but compared to no documentation, a script or automation or test is better than nothing. I used to do this just because i'd forget how to do something so I wanted a written down example of it, and then I make it into an actual program, and then I automatize it. You wouldn't believe how many people end up depending on these crap little examples. And of course READMEs in every directory in a tree that explains what everything in that directory is and what it does.
That quick hack is exactly the approach we've taken with new technical hires this summer. We are a "vagrant up and go" shop, but there are a bunch of steps between handing someone a laptop and running your app in vagrant. We took the time to document the process and used it in onboarding. We made it explicitly clear that if you notice issues, please fix them, which has the intended side effect of familiarizing the new hire with our development practices (pull requests, reviews, etc).
This sounds like a great approach; however, what is precluding you from making this into a script ? Maybe with a first step of "fill values in this properties file" for passwords etc ?
I worked for one company for a month. From the get go they had 100+ staff but no onboarding. Nobody knew how to set up the development environment or even get the application working on the company laptop. Nobody could show me how to VPN to client sites or show me how the software worked. I was meant to support it...
I was in my manager's office every day letting her know hey I really need assistance here, nobody seems to have time, nothing is working, I'm not learning anything and this needs to improve.
She'd tell staff to assist and they just wouldn't. And rinse wash repeat the next day.
A month in we are in a meeting and some difficult software issue comes up and it's assigned to me to fix. I mention that I don't have it running, don't know how to use it, have no method of finding who the customer contacts are to call them and will sound stupid not understanding anything, but also haven't been shown how to connect in. That I'm happy to shadow someone else and learn it.
It felt shameful but I knew it was the right thing, I had a year of extensive help desk experience under my belt including programming and other development, bug fixing, accounting, you name it, I was even team lead. I was used to dealing with multi million dollar clients and had no qualms about doing so... but this place was dysfunctional.
Anyway the boss stared me in the face in the meeting and called me a liar, to shut up and get to work. I was stunned. I repeated myself and she turned to my coworkers who claimed they had "showed me everything". I hadn't spent more than 5 minutes with them in the entire month and had been in her office every day. She told me to start pulling my weight and stop lying.
I walked very calmly to the office printed out a resignation and left my keys and walked out the door. I didn't get paid (a funny side effect of walking out of a job) and the move left me penniless and ALMOST homeless.
Luckily I got a job just in the nick of time shortly after, at twice the pay, and being treated like a human being. I removed that place off my resume and rarely discuss it because it's so humiliating.
I still remember the recruiter calling me screaming how unprofessional I was - he only cared about his lost bonus. I explained I was extremely professional but that after being humiliated and called a liar in a meeting and having none of the promised training, or anything remotely capable of making me a functional employee, there was no recovery.
I too had a similar experience. Senior dev at our open office rushed to my desk after I asked him to clarify about some email instructions he sent me. Told me to read the instructions out loud in front of the entire company. I laughed it off but he was really persistent. Just disconnected my laptop, and told him he can explain to the CEO why there's no longer a frontend department (I was lead frontend, and I got friends hired who I run a sideproject with, so we all just up and left, but we've been planning to for some time. This was the final straw.)
I'd be curious to know the state to double-check, but yes, that's my understanding too.
In California, at least, enforcement is vigorous. Once a client tried to stiff me on a couple months' wages on the grounds that they didn't have the money. I paid a lawyer to write them a short note, in which he explained the 7 kinds of hell that would rain down upon from the state government, and that by law wages come before pretty much any other claims on whatever assets they had. A check for the full amount was promptly overnighted to me and that was the end of it.
I'm sure a key to this is that unpaid W-2 income also means unpaid income taxes.
It's vigorous in Virginia as well: the state has a unit with totally humorless employees who've heard it all and are highly motivated and competent at helping you squeeze your back wages out of your deadbeat ex-employer. Or so was my experience in 1997 which I and 12 or so other employees of a startup resigned one day due to devil investors.
Just throwing it out there, it's remotely possible that state governments make this a priority because it is actually one of the moral underpinnings of a market economy and needs to be enforced. Litigating is very expensive, I doubt that the increased tax revenue on W2s from those cases pays off -- it's the overall effect on societal norms that matters, everyone on this thread immediately said "You should have gotten that money".
One possible exception to that is if you're a contractor (1099) instead of a "real" W-2 employee. In some states that means you're basically in a contract negotiation.
I found out the hard way that Colorado law doesn't protect you at all. Even better, if you sue to get your back pay you can't recover the legal costs even if you win.
Good point. I should have mentioned I was on a W2 there. Yes, contractors are treated like any other independent business, and enjoy much less in the way of legal protection.
I didn't find California's enforcement to be particularly vigorous at all, unfortunately (see my reply above). Probably because I didn't think of engaging a lawyer, though that wouldn't really have been cost-worthy.
I'm glad you did though! That's how it should be. :)
> I didn't find California's enforcement to be particularly vigorous at all, unfortunately (see my reply above). Probably because I didn't think of engaging a lawyer
State enforcement doesn't seem to be involved in your case -- you went self-service with a direct lawsuit in court.
If you want State enforcement, you file a wage claim with the Department of Industrial Relations, Division of Labor Standards Enforcement.
It's law in Australia. If you do not serve a notice period you owe the company wages for that period. 1 month wages minus 1 month notice = 0. Most people have no notice periods, serve their notice period, or get approval not to serve it at all.
In this case though (when I followed up with accounting) they confirmed they wanted to step on my neck.
Even now the entire situation seems utterly surreal. I've been through a few companies since then and never had any problem, I'm the likeable hard working quiet person. I guess they just really didn't like me!
Anyway I remember walking out of that office in tears and feeling that no matter what happened I could cling onto whatever self worth I still had. I didn't know how bad it was about to become. But I came out okay in the end :-)
> It's law in Australia. If you do not serve a notice period you owe the company wages for that period. 1 month wages minus 1 month notice = 0
You have misstated the law. If you sign an employment contract that requires two weeks notice from either party to terminate, then you work a week and quit without working the two week notice period your employer is not required to pay you for the notice period, they absolutely must pay you for the week you did work. Similarly if an employer tells you not to work the notice period they are still obliged to pay you for it.
I understand your confusion as the wording the clauses about withholding pay on notices is somewhat unclear and takes a pretty close reading to understand
It is and you can sue. I sued a company in small claims in SF for a week's pay because they refused to pay me because I took another offer after a week of being there. Mind you, this was at-will employment, though not the nicest thing to do, I know. I fought it in court and the judge awarded me the pay. On appeal, the appeal judge cut it to about half for no reason. I never actually collected as that would have required going to court yet again (for the third and possibly a fourth time) to discover their assets (since I didn't have a check from them I didn't know their bank) and then have the state put in an order for withdrawing money.
Anyway, I found out later by searching public records that this company had been sued in small claims a number of times and lost just that year. The moral of the story is to look up future potential employers' court records like you'd do a background check on a potential girl/boyfriend. Wait people don't do that to potential girl/boyfriends?
I think instantly walking out was a mistake, however. As sqldba said, it left them penniless, and they didn't appear to have any documentation of what was going on.
I, personally, would have taken the lower road and continued coasting there to pay my rent while I searched for a new job. If a company isn't invested in you, why should you be invested in the company?
It is a very positive, strong ethical position to take. I doubt that I would have had the fortitude to react in the same way as the GP.
Coasting with the company while finding a new job shows an ethical attitude which is similar to the company itself.
I don't think there's anything wrong with staying at a company while looking for a new job. Do you disagree, or is it specifically the mention of "coasting" that's objectionable?
I.e. it's possible to continue to do your job within normal parameters while still looking for the next thing. Defining this as ethically dubious gives too much power to employers, IMHO.
I'm in the midst of being onboarded at a very large healthcare organization. In addition to the complex SOA infrastructure, we deal with a multitude of databases, accessible through many different methods, from a number of vendors. There's a ton to take in—not to mention the business complexity inherent to the organization as a whole.
Heddleston's point about having less-senior people do the mentoring is especially apt. While I've received support from everyone in the team, the most helpful person has actually been an intern with only a few years of programming experience under his belt. While I have over a decade more general programming experience than he has, he knows a lot more about the specific domain, and has been an excellent teacher. I feel that this arrangement has been beneficial for both of us—as I've gained domain knowledge, he's gained confidence and depth in his own knowledge.
I think that a big part of this is not setting expectations too high—no matter how senior the new employee is. While I have a fair amount of experience, the expectation in my new position—both from me and from the team—is that it will take me a while to get up to speed,(especially given the complexity inherent to the role), even though I'm not coming in as a junior dev. Therefore, I don't feel the need to pretend that I'm an expert in something that I'm not, and there's no ego hit when I'm being mentored by someone who is technically my junior.
In my city, it seems like most everyone is looking for senior devs—to the point that they leave positions unfilled for months rather than hiring someone they don't consider senior enough. This is madness, and damaging to the industry as a whole. We need to focus more on efficiently developing talent, and Heddleston seems to have some great ideas for doing so.
I think outside of the day-to-day (you need to know Python, here's how to get Vagrant running, this is how you submit a code review) there can also be a gap in cultural onboarding. For example, someone moving from a large tech company to a startup has certain norms and expectations that they may slowly re-evaluate (if they actually do) over a number of weeks or months, potentially harming the product and even their own career -- for example, "that's not in my job description" doesn't fly at a startup but can be a protective reflex at a large company. (One may argue someone with this attitude may not be hired at a startup in the first place, but sometimes the attitudes and expectations aren't so upfront and clear-cut, and are hard to test for at interview!)
Would love to find some examples of great cultural onboarding where it's not just the "what" of the work that a new hire learns, but also the why and how, to avoid implicit assumptions and biases from day one...
I ran twitter's new engineer training for a long time, and much of this rings pretty true to me. I would only add 3 things:
-1 the skill of teaching is approximately orthogonal to domain knowledge, and the difference between a decent and very good teacher is huge, both in terms of student-reported happiness and in terms of retention of the material covered.
-2 history with the company tends to be very valuable, in that new hires are often curious about _why_ the company decided to build system X as it was. My goal was that teachers should be able to answer most such questions accurately, and truthfully say that they didn't know in the other cases. I found (anecdotally, because this data is hard to capture) that the student-reported quality of a class was generally proportional to the maximum length of question/answer/followup q/answer/... chains.
-3 the onboarding process is an extremely powerful propaganda platform. During twitter's long transition from ruby to scala, (before I ran it) there were a series of presentations that were forward looking to the point of inaccuracy: they described as existing in the present that which we hoped would one day exist. This confused a bunch of new engineers when the rainbow unicorn scala world promised them did not materialize. On the positive side, many of them were then motivated to help build a scala world.
Does anyone actually work as a QA for documentation? I've been in many projects where "just read the docs" or "go read this doc", and... nearly always it's out of date, or missing key information (like who wrote it, who to contact for access to systems in the document, etc) or so scantily written as to be useless.
Saying "I wrote docs" but having them be abysmal seems to be the norm. People now accept that having unit tests for code is a thing (not always done, but at least a thing) - is there an equivalent for documentation?
I'm surprised literate programming[0] never really caught on.
Rather than have separate documentation, the paradigm is completely different. Source code generation is interspersed with the abstract flow of thoughts that one usually has while developing.
This style of coding seems to be natural to me, as many algorithms are a set of discrete steps in an abstract sense. Implementing concrete steps and then describing their abstract counterparts seems sort of backwards to me.
great point about onboarding providing a high ROI, it's something I haven't thought enough about. this is a particularly useful part: "The best person to help someone set up their development environment is the last person who joined, regardless of seniority."
An inability to bring on new talent, junior or otherwise, is a symptom of lacking essential documentation. If I can't come into your office and have a copy of your software running or successfully compiling on my machine in less than an hour, something is very wrong with your documentation, tooling, or (lack of) build process.
"Here's Jim. He's our Widgitsoft guy. He's the only one who works on Widgitsoft. The system is entirely undocumented because Jim knows everything. Yeah, development has been slower than expected lately. Yeah, it would be nice if we could bring on a contractor when necessary, but getting to that point would be a lot of work, and we'll always have Jim."
If I can't come into your office and have a copy of your software running or successfully compiling on my machine in less than an hour, something is very wrong with your documentation, tooling, or (lack of) build process.
So that's why your first project here is going to be writing up some stuff so that it's easier to bring future people on board!
> So that's why your first project here is going to be writing up some stuff so that it's easier to bring future people on board!
Has "get started on a new project by first writing up the documentation" actually worked for anyone in either a company or an Open Source project? If so, I would really like to know how because I keep hearing this advice but I suspect it comes from people who've never done it.
I started a job a few months ago and pretty much the first thing I did was improve the getting-started documentation, and the next thing was to improve the build process so there was less documentation needed. Worked for me.
Putting yourself in the mind of a reader is really hard. And documentation, which is necessarily duplicative, can easily become out of date. So yeah, I think novices are often the best people to write novice-targeted documentation, because they understand the reader's needs quite well.
Personally, though, I'd be a little embarrassed to assign a new arrival that if there were absolutely nothing. I think the process is a lot easier if they have some starting point for the docs, even if it's just some headings and bullet points. I'd also sit nearby and give them strict instructions to stop me at any point they were confused so that I could get them back on track. But I think it's a pretty good task on arrival.
I did this, sort of, but had an interesting problem. Once i'd rewritten the onboarding documentation (because it was given to me as four or five different PDFs, which really isn't that useful, and doesn't tell you what you specifically will need to have set up), there was no place to put it; there were 3 wikis, none of which anyone really looked at other than for their own stuff. New hires wouldn't know where to look to find these onboarding docs and nobody else would know either.
So it just floated around and new hires basically started with the PDF all over again.
In our case, we just checked in the docs as part of the project. That's not always the best reader experience, but if they have the code, then they're sure to have the right version of the docs.
> I think the process is a lot easier if they have some starting point for the docs, even if it's just some headings and bullet points. I'd also sit nearby and give them strict instructions to stop me at any point they were confused so that I could get them back on track. But I think it's a pretty good task on arrival.
This is a good insight: the strategy does work if they have something to work through and a fallback if they are confused.
It also depends on the developer. I'd consider it an appropriate task for a mid-level or senior dev who's already familiar with our stack, but not for a junior person or someone transitioning from another stack.
Yes and, since I had a good manager, I was rewarded when "the next person" came along and the amount of time required to onboard dropped from one month to two weeks.
Everything in that situation came down to documentation and I spent my first couple of days just chasing down the "correct" IT person to setup all of my accounts (company network, version control, bug tracking software, customer network, remote access, email - each required a different person and I had to ask around to find out who they all were). I commented that having one IT person who can handle everything would be ideal; but I had to settle for creating a list of "who to contact for what". This still shaved days off the next person's lead time.
Simple stuff like having a development machine ready to go (installing Visual Studio, an Office suite, etc) when the new person arrives really makes a difference. There was a learning curve w/r/t the actual system but the new person didn't have to switch gears between hunting people down, installing a myriad of in-house software with which they have no familiarity, and other general "drinking from the firehose".
I took some stabs at making the firehose drinking not as overwhelming; but I didn't do as well as I wanted.
The organization's attitude mattered, in retrospect. Bringing on new people took a significant amount of time (still does but it's better) and everyone did what they could to help me document the process. I imagine if the organization had not been incentivized to help me, then I would have failed and "first write the documentation" would not have worked at all.
It worked really well for me. I started on a project that had no documentation, no setup scripts, and nobody I spoke to knew how to get it setup. Everyone kind of just got it working somehow.
I setup Vagrant, wrote provisioning scripts, wrote a README, and checked it in after I had figured everything out.
The next employee to join was setup in a day instead of 2 weeks. It worked out great for me.
Anecdotal, but my first job's first project was to take ownership of a codebase my team had just been given from another part of the company which nobody on the team really knew. Ensuring the documentation was up to date (it wasn't) and the other developers on the team were able to get, build, and deploy the codebase to their own VMs was literally the first thing I did--and it gave me a reasonably good basic understanding of the software to allow me to move forward with owning/working on it in the future.
To be honest, it was a kind of frustrating onboarding experience, but it definitely met the team's goals with a minimum of disruption to people who were shipping features.
What I've experienced as someone who has helped onboard new-hires is that we meet with the new-hire daily for a week or two, and throughout that process if we find documentation has gotten stale the mentor usually updates it (e.g., yeah, our baseline OS has changed to xyz, what is here is old, here's where you get the bits for the new stuff), because the new-hire probably has no idea how to fix it yet.
I've used this method before, and so long as you are transparent BEFORE they accept the job, and actually give them the support they need to successfully accomplish this, I've had it work really well.
Also there has to be very clear guidelines - Use the wikki to set up. if you get stuck ask us, but anything you ask needs to make it back in the wikki.
I have never seen a wikki stay 100% in sync with the real world. But make people edit the wikki as part of using it, and things change.
This is timely, as I’ve just gone through the worst onboarding I've ever experienced. It took two very long days to install an OS on a machine and get it to boot (I had to assembly my computer and then use the corporate installer, which failed multiple times with errors like “an unknown error occurred”). It then took me about a week to run the local project’s “hello world” (I was initially pointed to documentation that had been deprecated for months, and then when I found the right documentation it was incomplete and out of date). The actual process to get there was hilariously baroque; for example (if my email records are correct and I didn’t get duplicate emails from the system), I must have clicked through 18 EULAs to get a subset of the permissions I need. I promise, that’s worse than it sounds since the form to do so took more time to click through than you can imagine. It was a month before I could effectively do any work at all.
I originally thought that I was just unlucky, but when I asked around I found that I had an above average experience, at least among people near me who started recently. Unlike many other folks, I was actually able to get a username/alias, a computer, and an office. I don’t know what folks without a username do since they can’t even start clicking through the necessary EULAs to get permissions to do stuff, let alone do any actual work.
I’m not sure how it is in other parts of the company, but if you imagine that it’s similar and do some back of the envelope math on how many people get onboarded and how much losing a month (or more) of time costs, it comes out to N million dollars for a non-trivial N. And that’s just the direct cost of the really trivial stuff. It’s hard to calculate the cost of the higher level stuff that’s mentioned in the article, but I suspect that’s even more expensive.
I'm curious, what subset of the software development world are you working in? "Developing locally on your machine" is and has always been standard practice in every part of the industry I have encountered.
Every project I worked on at BT (15 years) and all the webdev work it makes no sense to have 20 different pcs all developing and trying to merge the code at the end.
You remove the risk of subtle differences between developers pc's
if your only developing standalone apps I could see it but Microsoft doesn't develop windows or office that way.
Perhaps I just don't understand what you're describing, because in my experience it is completely normal to have developers working on 20 different PCs and all merging code as they go - that's what version control systems are for! I can't really imagine how else you would do it. Do all the devs really mount a shared filesystem with a single copy of the code!?
Or do you mean that the devs all still have individual copies of the source tree, but they do all their work by remoting in to some big monster server and building/testing there? That sounds.... um.... ungodly slow. Though I suppose if you are talking about webdev, perhaps there is no build step, so it might not suck quite as much...?
It sounds like a very different world, and I'm struggling to understand what you mean.
I never worked on Windows or Office, but I did work in devdiv for a while, and at that time Microsoft certainly did develop Visual Studio in the traditional way. There were build farms, to be sure, but they were used for occasional checkpoint builds and for testing. For daily work, we ran the ol' edit/compile/link/run/crash cycle locally, on our own dev machines.
You can have your own source control at the server level and every one logs into that server just run an X Server on your PC. And yes you should be developing on exactly the same hardware its going to run on.
All you need to set up a new user is a bog standard pc and a new account set up on the server.
Its a lot easier to keep dev test and live identical than 20 or so developers pc's
And even when we did local development (oracle forms) all the code was checked in to a central server which was used to produce a daily build.
How do you think IBM mainframe development is done?
Thanks for explaining. That's certainly a very different way of working from anything I've ever encountered. I don't know enough about mainframes to even wonder how things are done, it simply isn't part of my world at all.
I come from a personal computing background, where it really doesn't make sense to talk about "developing on exactly the same hardware it's going to run on" because you cannot know in advance what that is going to be. The kind of thing you are talking about makes even less sense in the embedded world, where cross-compilation is the rule and the target machines are likely not capable of self-hosting a toolchain at all.
I actually think those subtle differences are more likely to bring problems to the front earlier. If you have code that works on 20 slightly different setups, then it is likely to be more robust than code that has only ever seen one setup.
Obviously this is quite subjective, and depends a lot on what type of development you are doing.
What do you mean when you say develop on a server?
Do you actually remote in and do development via commandline?
Do you edit the files locally and upload it back?
Do you run a remote desktop with gui?
If one person accidentally saves a file that has a syntax error or something, does it crash the server for everyone?
Standout quote: "People think that confidence follows skills, but it’s usually the other way around where skills follow confidence." This is a fact that really needs to be more widely acknowledged. (It also casts the microagressions that have the effect of chipping away at the confidence of women and minorities in a rather uncomfortable light.)
I've been learning to interviewing potential hires. One of the questions I ask is, "Do you have any questions for us?" The questions can tell a lot about the prospective hire.
Turn this around: "What is your onboarding process?" is a great question from prospective hires.
This past year, having taken a number of short-term contracts at small teams, I've learned the hard way how to survive getting thrown into the deep end. You have to get really aggressive about communication, especially on a remote team. A lot of expectations can get lost. It's possible to survive and thrive without a good on-boarding process, but you have to step up and assume that responsibility yourself.
This isn't everyone's thing, and often feels like straying into rude, invasive behavior -- and from the startup's perspective, you lose a lot of great people too -- so asking this question will give the prospective hire an idea of whether they are getting set up for failure. Even an honest answer from the potential employer, "We don't have one, we are very busy and everything is really chaotic here" will tell you a lot about expectations (for both parties) within the first couple weeks of starting work.
And obviously, if the potential employer gives some BS in lieu of a straight answer, why waste time joining?
I think lack of onboarding is probably one of the biggest problems with open source projects as well. You can't expect to get new contributors, if you have no documentation on how to setup a development environment, which tools you use and how the project is structured.
I'd ballpark it as "several hundred." (Edit to add: this was a guesstimate based on "having a sense for this sort of thing is a key job skill for me." I then went looking to firm up the guesstimate. Data points in favor: 400 people match a search for "Airbnb engineer" on LinkedIn. A recent post shows a photo of their data science team with ~30 people on it; on previous experience with software companies, I'd have difficulty thinking there aren't at least 5+ much larger teams.)
More broadly, I think people consistently underestimate how much you can get done with a very small team at a startup and, simultaneously, underestimate how many engineers it is possible to throw at a single product.
Hmm, lets see I would guess they at the very minimum have a:
-Web team
-Mobile team
-Data team
-Infrastructure team
-Tools team
So assuming at least 5 people per team thats already 25 people ... why is it so hard to understand that building anything at scale involves lots of man power?
The form of the interview was a bit weird: All the questions seemed to be entirely predetermined, with no follow-up questions and no opportunity for the answers to guide the direction of the interview. But on the other hand they were open-ended enough that it was more like a talk where the interview questions were hardly needed – essentially:
So I heard you like x.
How did you get started with x?
Tell us a few things about x.
In addition to those things, could you tell us something more about x?
Is there anything else you want to say about x?
I really enjoyed this video as I am currently looking for programmers and coders. I am leaning towards female engineers as I am a proponent of diversity and that I want to produce gender neutral software for my market. My goal is to hire the "right" people who can objectively work together while also producing software that takes multiple points of view into its development.
I don't agree with all the advice, but I do think it's a good message. My favorite part is actually on pre-onboarding: "If everyone has to come in and manually set up everything, what you have is this super painful onboarding process that’s just going to bottleneck your company."
My Induction at my first job after being issued with my labcoat was an hours instruction on how to boot the PDP11/40 and I was told ah the company library has a book on FORTRAN go and learn it :-)
On the topic of on-boarding -- super important to get right! The idea of making your people the best they can be is lost, I think, on our generation. My grandfather-in-law was a mechanical engineer at Chrysler back in the day when they had a special school they ran to train their new recruits. When he started he had no idea of how cars worked but they picked him up from school and gave him the training he needed to become an important figure in their company.
Focusing on hiring the best because hiring someone mediocre will damage your business is negative thinking that can kill your on-boarding, and thus your culture and business. I've worked at places with terrible on-boarding and it was a fight just to get some direction and support for your work. Getting the attention of management was something you wanted to avoid which led to people becoming complacent about their work and its quality.
Great article. On-boarding is important to get right.