A lot of what is in this thread is excellent. I'm actually working on a fairly detailed HOWTO for creating a custom-fit onboarding program (send me an email and I'll send you a draft; I'll update here when it's ready for public consumption). Here are the key principles:
1. Know what you want the employee to do, and equip them to do it. (This covers things like shipping the laptop ahead of time, getting accounts set up, planning tasks for them when they start...)
2. Help the new employee feel supported. (Item #1 relates to this, but it's also things like welcoming them on their first day, assigning a buddy, giving them a tour of your company / application / industry, making their initial responsibilities clear...)
3. Have a plan for bringing them up to speed. They need to get to know the job itself, the company, the people, and that all takes time. Work sequencing is important in building a product. It's even more important when it comes to integrating a person into a complex network of activities and other people.
In all those items, the ability to put yourself in the new hire's shoes is essential. It's easy to forget how much you know about the job, the company, etc., that you end up giving them tasks that feel small, but that are daunting to them. That said, taking time with the new hire regularly over their first couple of weeks and building a good working relationship can help calibrate, and help smooth over any potential issues that come up from being miscalibrated.
Also, a couple posts I've written about onboarding might be helpful:
Seconding Manager Tools podcasts. Use their "Map of the Universe". Professional Success -> Professional Skills -> Meetings gets to most of the meeting casts.
Having an agenda and sticking to it plus setting ground rules helps a lot, whether it's remote meetings or in-person.
Agreed, especially starting with Working Effectively with Legacy Code.
One of the hard things about what we're assuming is OP's tech lead role is that they're having to influence changes up (with management) and down/laterally (with the team). Things that might convince the team are going to be generally different than the things that might convince management. Management will probably be more convinced by things like improved lead time for changes, eliminating risk of failure, improving confidence in correctness of feature roll-out (though some of this depends a lot on the industry / domain and the incentives of management). Meanwhile the team will be more convinced by things like making their job easier or setting themselves up with more and better skills to take a "better" job down the road.
The rub with all this is that if the team doesn't like OP's changes (e.g., using source control), they'll have management cover right now. At each step it's important to show why it's better.
A way to do that—hard to tell if it's the right way without knowing more about the team's dynamics—is to make a lot of the changes for your own work. For example, set up your own test environment, develop there, then using this mystical "source control" magic apply the safely-tested changes to prod. Eventually someone will notice that you're not breaking prod as much as everyone else. ("You" here being either OP, or someone else in the same situation.)
All of this is just nuance, politics, and team dynamics layered on top of the excellent recommendation I'm replying to.
Are you talking about from the employee's point of view, or the HR process? I'll answer from the employee/team's point of view, because that's more interesting. If you're looking for the HR tools, disregard this answer!
My current company uses a Miro board for onboarding (with links to Confluence pages, Google docs, Slack channels, and other things we need).
A previous company I worked for used random links people threw at each other in Slack. Before I left, I'd put together a Google sheet (or the Microsoft cloud equivalent, now that I think about it I don't remember which platform we used there) that included set-up tasks, people to meet, things to read/understand—pretty much everything someone would need to get up to speed. The big advantage of that over Miro (or Trello/Jira/etc) is that everything was visible in one place, with due dates easy to see and to calculate based on start date, and owners easy to identify.
I'm not sure if this will be useful, but https://www.cybadger.com/2022/07/02/a-tale-of-two-onboarding... gives some details about other onboarding experiences I've had. Apologies for the shameless (well, some shame involved) self-promotion; feel free to ask for more info if it'd help!
There are a lot of different levels of rigor you can aim for when writing a spec. But at its most simple, a spec simply captures what you want the product to do in enough detail that you can later focus on implementing. The "big decisions" are already made. It can be as simple as the classic napkin sketch, a few notes on a whiteboard, or hundreds of pages of extensively-reviewed "shall" statements in binders.
But start with Joel Spolsky's classic "Painless Functional Specifications" (read the whole series) and you'll be starting in a good place.
Hey! I know this is a bit late, but Part 1 of Basecamp's book "Shape Up" might be helpful too. It's not explicitly about specs, which is probably why I didn't think of it before, but it's worth a skim.
I'm close to your age, male, been married for quite a while, kids. So take what I write with appropriate amounts of salt, because things definitely look different at 41 than 21.
I've had some guy friends who have been similarly focused on getting married. Great guys, who for the record, are now married to lovely women. But it definitely didn't happen on their timelines or on the paths they intended.
By now you've almost certainly got your list of must-haves and dealbreakers set. But it's interesting that you've been pretty vague about the reasons that most of your relationships haven't worked out. I don't think you're being evasive. But I do think maybe you just don't know. For any given guy, you can give a yes/no answer, but maybe you can't say why.
So let me ask you about your dreams of falling in love and having a family, because there might be some clues in there. What _are_ your dreams? Are they dreams of tying a bow in the hair of your 4-year-old daughter in a princess dress? Watching your 10-year-old head off to summer science camp? Wedding day? Baby shower? Bringing the new baby home from the hospital? Volunteering at the kid's school? Arranging the perfect birthday party?
Or are they dreams about long walks on the beach with your husband? Walking down the aisle on your wedding day? Going line dancing? The two of you making dinner together and snuggling up on the couch to watch a pretentious artsy film and MST3K it? Or family camping trips? Cross-country drives to see the national parks? (Side note: if, in the previous paragraph, you didn't quite notice that none of those items involved a husband, that's worth reflecting on. Not worth getting worked up about, but worth reflecting on.)
The dreams you've had all your life might help you understand what it is that's keeping your dates from turning into more. For example, if you pictured an adventurous husband who'd teach your kids to ride horses and you realize you're dating super-placid, risk-averse dudes, that might be a light-bulb moment.
Two pieces of advice, then a bit of encouragement.
First, it seems like you're hyper-focused on getting married. Relax. Observe. Enjoy. Meet some guys with the express purpose of getting honest feedback on how you come across. In your own mind, take marriage off the table for six months to a year. Just plain not allowed. Maaaaaaybe you can date. If you've a trusted friend, she can give you permission to go on a second date if there's a guy that's just perfect.
Second, there's a surprisingly deep piece of advice hidden in the trite-sounding "become the person the person you're looking for is looking for". You need to know who/what you're looking for. To do that, you need to know yourself well enough to know who/what you're looking for, and that you're not adding extra criteria on top of that. ("He has to be kind...oh, and handsome! and rich! and famous!") It sounds like you've been working on yourself, but maybe a little bit more focused on making yourself a better catch, rather than on figuring out what you're going after and choosing the right bait (to stretch the fishing analogy too far!).
So that advice really all kind of fits together.
But now, the encouragement.
If your guy friends are telling you you're smart, beautiful, fit, kind, emotionally mature, well, I've never met you. I'll trust what they're saying. Ms. Actfrench, I agree with them. You are smart and beautiful and kind. You're working to make the world a better place. That's remarkable. If one of my daughters turned 41 and wasn't married, but was smart and beautiful and kind and working to make the world a better place, I'd tell her I was proud of her and it'd be the truth. And I'd tell her this, too, if she were anxious to get married: It's discouraging when things don't work out the way you want them to. So keep on making the world a better place. And as you're doing that, there will come a time when you'll look to your right or your left and see a guy who's also working to make the world a better place and you think he might be something special, give him a chance. Maybe he'll be the one you get to make the world a better place with, together.
So keep on making the world a better place. And as you're doing that, there will come a time when you'll look to your right or your left and see a guy who's also working to make the world a better place and you think he might be something special, give him a chance. Maybe he'll be the one you get to make the world a better place with, together.
This sounds about right.
I worked with a guy who never gave an estimate more than "an hour" or "I can bang this out in a weekend".
Of course quite often he'd end up working on the feature for 3 months...
My time in rail was all related to positive train control (PTC), which is a safety overlay that stops the train before anything bad happens, at least in theory. The railroads generally despised the idea because it would slow down overall network velocity. It was only when it was mandated that they really got started with it beyond science projects.
I'm pretty far from rail these days, so I know I'm out of date. But as I recall, the prediction algorithms didn't work as well with distributed power (locomotive in the middle of the train, almost required for trains this long). So it's entirely possible that these super-long trains aren't able to predict unsafe conditions. I also vaguely recall they didn't predict anything to do with buff and draft forces (or other in-train forces) that could lead to the kind of derailments the article discussed.
This seems odd given the safety culture of railroads (every meeting I attended as a vendor, even if it was just a handful of people who had known each other for years, started with a safety briefing that included evacuation instructions and who was CPR qualified, along with tripping hazards and such). But around the time I was leaving the industry, CSX was spending lots of millions of dollars to bring the (now-late) Hunter Harrison in to implement Precision Scheduled Railroading. That led to a rush for other roads to implement it, to the point where I believe BNSF is the only Class I that does not do PSR. And PSR is all about reducing costs, cutting manpower, mothballing locomotives—which absolutely could lead to the sort of stuff this article is about. And, because it is (at least was) so fashionable in the industry, a road moving away from PSR (whether announced or just in practice) would likely see a stock price plunge and a CEO change.
Makes me wonder if, stuck between a rock and a hard place (ballast and the rail?), the roads are hoping the STB steps in and makes a rule to stop their game of chicken.
I agree 100%, based on my own experience both as having been a kid and being a parent.
Like a lot of other folks have already posted, I was also the weird sort of kid that spent time "playing on the computer" and talking about what I'd learned and asking about "modems" and "BBSs" or "the Internet". My parents would listen, supported getting an extra phone line to run my own BBS, would drive me places to support my hardware and books habits--and that all was important to continuing to explore this niche.
As a parent, well, I have an interesting mirror experience. My oldest daughter got really into basketball. This is absolutely inexplicable to me, because neither I nor my wife ever played, nor did we ever watch a basketball game at home before her interest developed. (Schools these days, exposing children to strange new ideas!) I knew the basics (orange sphere through orange ring = points; double dribbling and traveling are bad; no tackling) but really had no interest. But we've enabled her interest: let her join the school team, signed her up for summer camps or 3-on-3 leagues, encouraged her to practice in the driveway (oh, yeah, bought a hoop for the driveway), have watched or taken her to college women's games.
She still knows more about the game than I do. Even with years of watching, "volunteering" for scorebook duty at some of her home games, talking with coaches and refs, there are still a lot of subtleties of the game that escape me. But it's okay. She plays, she enjoys it, and she knows her parents support her strange, strange interest.
Even if you don't really, completely "get it" as a parent, supporting and enabling ("enabler" is such a good word here) is worth a lot.
I used to ride my bicycle to work most days. I like to ride. I am all for "a bicycle is a vehicle", but I still think this adjustment makes sense.
Being able to treat a stoplight like a stop sign is great. It's pretty common for stoplight sensors to not detect bicycles. It's also common for polite folks in cars to stop far enough behind a bicycle that their cars don't get sensed. It's not a good feeling to sit on the sensor loop, watching the walk lights cycle and reset, knowing that if you don't run a red or walk out of the intersection, you'll be stuck.
As for treating a stop sign like a yield sign, I agree with a lot of other posters who come citing sources: bicycles move slower and are at a lot of risk from cars coming up from behind. It's not about the extra effort to get started (though in a hilly place, I could see that being a problem for some riders).
As a cyclist, bike safety is hard. You're squishable and very aware of it, surrounded by big, fast, solid cars whose drivers often aren't paying close attention.
As a driver, bike safety is hard. A lot of drivers get weird around bikes (e.g., they yield the right-of-way when they shouldn't). Cyclists often aren't well-trained in the rules of the road. And the rules of the road often force bikes and cars to intersect in ways that aren't ideal.
So I think making it clear that yes, bikes are vehicles, but making a few exceptions to improve safety by reducing the chance of bicycles getting unintentionally hit from behind--seems like a win to me!
1. Know what you want the employee to do, and equip them to do it. (This covers things like shipping the laptop ahead of time, getting accounts set up, planning tasks for them when they start...)
2. Help the new employee feel supported. (Item #1 relates to this, but it's also things like welcoming them on their first day, assigning a buddy, giving them a tour of your company / application / industry, making their initial responsibilities clear...)
3. Have a plan for bringing them up to speed. They need to get to know the job itself, the company, the people, and that all takes time. Work sequencing is important in building a product. It's even more important when it comes to integrating a person into a complex network of activities and other people.
In all those items, the ability to put yourself in the new hire's shoes is essential. It's easy to forget how much you know about the job, the company, etc., that you end up giving them tasks that feel small, but that are daunting to them. That said, taking time with the new hire regularly over their first couple of weeks and building a good working relationship can help calibrate, and help smooth over any potential issues that come up from being miscalibrated.
Also, a couple posts I've written about onboarding might be helpful:
- https://www.cybadger.com/2022/07/02/a-tale-of-two-onboarding... is a reflection on two onboarding experiences I've personally had
- https://www.cybadger.com/2022/10/11/onboarding-gis-technicia... is creating a better onboarding experience for a non-developer role, but the principles are the same.