Here's my programmer cold start algorithm for those interested:
1. Go to indeed.com
2. Type in 'software engineer' or 'data scientist' or something like that.
3. Don't put in a city.
4. Put the money slider all the way to the top.
5. Open a few pages of job postings in tabs.
6. Write down every word you don't know.
7. Repeat the process by searching for each one of those words you don't know and then write down additional words you don't know.
Now you have a list of what technologies are valuable in the zeitgeist and your mission is to determine why each technology exists and what it's use case is. You'll then be armed with a larger and more modern toolbox full of tools to reach for when the time comes to solve that kind of problem.
A very effective, but somewhat utilitarian (dare I say, mercenary) approach. It will get you the job, but I don't know how well it will help you keep it (sometimes you might even end up with a mixed bag of buzzwords and hype). I would prefer that candidates try to deeply understand the problems facing the industry and try to develop the skills that solve them.
I know this was half in jest but it speaks to a larger point, that of the "implementation ghetto".
I'm going to get a lot of pushback for saying this, but there are basically three roles in any company: (a) people who do the work, (b) people who make sure the work gets done, and (c) people who decide what work to do.
If you follow the strategy outlined above, you will never rise beyond a pure implementer of someone else's vision.
Empirically, understanding more about the business domain and industry seem to be important if you want to do (b) or (c). If anyone has more tips, I'd love to hear them.
EDIT: When I say "above", I'm talking about in the comment two levels up, not the article.
thanks this is a great way to learn about new terms. Adding onto this, I usually find the github repo of that keyword term (if its open source) and star it. If its a close source platform, I usually bookmark it on alternativeto.net and check up its competing cases. If its a youtube video, I usually put a like on it. this way I can just thumb through my favorites / likes / stars and get a complete picture of a modern toolset
Another good term is to do "Term VS ______" in google to learn about competing technology use cases as well
At the end of the day some of these terms are possibly all buzzwords but its nice to see what actual companies are using, what that business does, and why they might be using it. Sometimes you get some really nice insights when you dig down deeper (look at their forum posts, etc). This is especially true for things like ecommerce carts (run wappylzer → inspect what the site is running on), sometimes you can actually physically see the decisions they made at a company publically.
Can't see any such slider. Do I need to get a user ID at the site, or is it just that there is no such thing at indeed.com for Europe? (It only returned jobs near Helsinki [Finland] when I left the City field empty, so I also tried Berlin [Germany], which returned a link to de.indeed.com.)
I honestly thought about this last night. Current role is a lot of React/Redux/Typescript, which appears to be hot new thing, but is not particularly well paid here in the Southeast. Plus I miss being immersed in dealing with data so I need to lean to a full stack role again
We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
On the other hand, all my best newbie programmers came in, buried themselves in their tickets until they understood them, fixed them, and went on to the next ticket. There was very little attempt to change the system in their first year.
I'm much happier with people who focus on doing their job instead of focusing on trying to impress people.
The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that.
It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that.
The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets.
Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.
It sometimes seems like we software developers travel in really distinct worlds.
People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better.
I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job.
As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done.
Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.
> don't expect them to make suggestions for a year
That's not the problem.
The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector.
For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement.
A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore.
There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.
Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.)
Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
The article is clearly targeted at managers and leaders, not your average individual contributor.
Often new leaders & managers start in an established team and want to change something to "make their mark" or have an impact as soon as possible, often with disastrous results (because they don't yet have the context to make informed decisions).
The advice is to spend time with your team to learn the ropes, figure out the internal politics, hear the common pain points and _then_ start addressing things, hopefully with some quick wins (like canceling a wasteful meeting or appropriating a larger conference room) that due to organizational inertia, went unaddressed.
That isn’t clear to me at all, but then I don’t know the author.
This seems like excellent advice for individual contributors, of whatever seniority, if you can already kick ass at the work you’re assigned, maybe after the first month or two. Provided you have the diplomatic skills to broach process change ideas in a way that doesn’t leave you looking like an entitled asshole, of course. But then, maybe that’s what you meant by “leader”!
How does what you say contradict the OP in any way, shape or form?
He says ask to meet people to understand how everything works. It's not about impressing them, even if it shows proper respect as a side effect (and showing respect by listening is quite the opposing of suggesting new things nilly willy).
I think the original article was written for someone who's going to _manage_ a new team, although it doesn't say that as explicitly as it should. But that's what I'm reading between the lines.
I think the "listening tour" is a pretty good idea even if you aren't a manager. But what to _do_ with it, needs somewhat different advice.
I also suspect the programmer in the comment I'm replying to did _not_ in fact do the "listening tour" that is the main recommendation of the original article. It's not advocating for suggesting changes based on your personal opinion, but only after learning what the team thinks and based on what they think. So the programmer in the comment I'm replying to didn't follow the advice at all.
I think implicit in the author's text is the implication that you have a high standard for ownership, so that you can handle your responsibilitites well.
I agree though that this should not be advice for novice programmers, as in this moment of the career you are not sure of the most common pitfalls a team/project gets into and should be mostly concerned about learning the technical knowledge. Trying to do anything else will be a distraction from your current goals.
Very helpful advice for consultants or team members who really care about the project and your career.
But again, as said by a sibling comment, you should always pay attention to disfunctional environments and avoid getting too much attention from sociopathic managers/technical leads. Get some advice from the peers at the same hierarchical level first to know if things are handled smoothly, before iterating.
I am dealing with this at the moment. We have a new contractor and he always wants to make big changes whenever he does something. Sometimes he may be right but I am getting tired explaining that maybe there is a reason why we are doing things a certain way and that the changes he is proposing often are just changes but don't really improve anything.
This is one of the most valuable lessons of contracting: only try to help people who want to be helped. Sometimes you can influence them to want help with something (e.g. an architectural change that will make things better), but if they don't believe there's anything wrong, it's just going to be a pointless battle.
It gets more awkward when you're brought in by one person, but quickly realize that the people you're working with don't want you to do what you were brought in to do. Or when people tangential to the project see it as a threat to the status quo and actively try to prevent you from doing what you're trying to do.
You're probably correct in your analysis, but in general I'm very wary of people who use self-help readings or techniques to analyze what everyone around them should be doing differently. I often run into people who seem to use these kinds of things as excuses to blame others and not take reasonable action on their own.
> We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
If you had people like that, and you weren't able to utilize their talent, then your workplace sucks.
The right way to go when someone says "We should do $X!" and you don't believe it is to say "Prove it!"
Depends on how disruptive their proving it is going to be. If it's not going to be worth the code turmoil, even if they're right, then no, that's not "the right way to go".
Improvements aren't free. They cost, usually more than just the opportunity cost of the implementer's time. There are lots of ideas for improvement that will cost more than they deliver. If I have someone consistently suggesting them, no, I have no place for utilizing their "talent", and no, it's not because my workplace sucks.
The best way become more familiar with an unknown team and code base is to work in the code daily. Spending your entire day in 30-minute one-on-ones with people will not help either of those. The exception of course is when you're brought in as a senior-level person in order to change something. But then you need to ask yourself why the senior folks on that team aren't in charge of that.
Spending your entire day in 30-minute one-on-ones with people will not help either of those
I assumed it would be around 5-10 meetings over a few weeks. Half of which can probably be done on lunch breaks. So it shouldn't take too much time away from real work. Obviously you should be working in the code base daily, but in the beginning working 8 hours a day is probably less efficient than working 7.5 hours and spending 30 minutes actually asking someone to explain parts of the code base to you.
> Spending your entire day in 30-minute one-on-ones with people will not help either of those.
How many of these meetings do you think the author is suggesting?? Even one day of that is 16 meetings, roughly the number of people I worked with on a regular basis at Microsoft.
Clearly the author is suggesting to mix them with regular work. One hour of effective meetings per day, plus seven hours in the code, is going to be vastly more effective than just wallowing through code for the entire day.
This confuses me. Coding is more of a tactical operation, and with it you're still going to want a grand strategic vision of what to implement. I think it's foolish to think that you can see the big picture just by trying to make a lot of commits.
You are rather elaborately saying that you want people who do what they're told and don't make waves. Got it--every manager wants that 100 percent. No kidding.
Style tip: When talking about a particular person, don't refer to him or her as "they".
I have a different algorithm, which I have successfully used twice: assume the duties of someone one level lower than your designation for at least a month. If you're a tech lead, drop into the shoes of an engineer; if you're a director/VP, drop into the shoes of an architect (provided you're in the technical track). Get down to the weeds. You will not only build a better mental picture of goings-on from first hand experience, the team will more readily accept you as one of their own.
I wish this is how all managers thought. Most love to stay on their level, and know nothing of what is actually going on a step below them. They take pride in pushing information up or down the chain without an inkling of how anything actually runs/works.
I forgot to mention how I learned to do this: apparently when Walter Chrysler Jr. joined Chrysler, his father did not put him straight away in an executive position like the other car company founders did. Instead, his first job was to clean out the basement of the Chrysler building. From there, he had to work his way up. It is said Chrysler Jr. became a proper manager as a result. I heard this story while I was a teenager and never forgot it...
Then you very often won't be doing much (hopefully nothing) that is critical and it's your superiors' and your seniors' job to get you to the point where you can.
Great advice, but be aware that there are circumstances where it might not work too well:
- disorganized workplaces run by a paranoid manager (all too common): The tactic would probably be conceived as taking too much own initiative, and 'stealing' 30 minutes from an arbitrary number of employees would not go down well (even if it was in your free time). You could try and get managerial sign-off, but don't count on it. If you really need that job in the first place (it's going to be a rough ride) better do over a beer or similar. It is why 'after work' was invented in the first place after all.
- as a very junior or entry-level employee it would seem like overkill in most teams, and probably not work to your advantage. In that case, and if you're ambitious and want to move quickly, try to get the same information but in a less overt way.
This is an incredibly jaded view. Both cases should be encouraging to anyone in a management position. Spending time to understand the lay of the land shows that the new hire is motivated to learn the system they are working on through the other experts on the team. It shows they care, which is a huge win for any project. If a manager truly took issue with this they shouldn’t be managing. It’s also a clear sign to find something else quickly!
jaded : Bored or lacking enthusiasm, typically after having had too much of something. [0] - hm?
Lacking in enthusiasm, perhaps. There is something to be said for people who venture into every new setting with an optimistic mindset, and not caring if they should tiptoe round, so agree inasmuch.
On the other hand (based on 40 years+ of professional experience), workplaces are in reality on a spectrum regarding these things (not binary good or bad), and peoples seniority as well as their need to take any job in the lower end are on a spectrum as well (some need to take what is provided because of location or other factors). In certain intersections of these factors I'd still say be careful to follow the advice in the linked article very literally.
In the appropriate cases I'd say it was excellent advice though, perhaps that wasn't clear enough.
as a very junior or entry-level employee it would seem like overkill in most teams
You don't have to start with the senior project manager. Try to find someone who's equally entry-level and been there less than year and talk to them. They'll no doubt be happy to talk and teach you the important things that you actually need to know in your position.
I read this comment before reading the article (something I often do) and it intrigued me enough to read the actual article. Then I realized that the article is just saying “talk to people when you start a new job”. If that’s an issue for any manager, regardless of my seniority level, I’ll know I’ve made a wrong decision to join that team.
I think the advice in the article was excellent - to the point that your summary quote does it some injustice. But my comment regarded some edge cases, among which the case when a new leader would be compelled to take a job even if workplace was in some disarray. Obviously, if one can pick and choose then it doesn't apply.
>disorganized workplaces run by a paranoid manager (all too common)
You basically can't win in a place like this. It's better to keep your head down and leave as soon as you can and try to see the warning signs before taking the job in future.
Could we maybe adjust the title to say something like, “A Career Cold Start Algorithm For Managers”?
It’s somewhat applicable to individual contributors, but it’s intended more for managers, which I didn’t realize until halfway through it. Might just add some clarity for folks opening it up without any context.
You’re not alone in thinking this was advice for managers, many people have said this. But the word manager doesn’t appear in the piece a single time, and I think it’s great advice for individual contributors, so I hope no one editorializes the title this way!
It’s not like only managers can propose slight shifts (desired by the existing team, explicitly in this construction) in process. Unless you’ve got a real jerk of a manager or aren’t doing your base line job well yet, such suggestions, if broached carefully, ought to be welcome.
The higher up you get in engineering the IC/management distinctions normally start to blur. I think this is equally good advice for many senior engineers.
Boz has mainly changed position within Facebook where a lot of things go right: people know what they are going and why; they get challenged over it often enough to be able to explain themselves succinctly; power is held by people who make things happen and can explain what is necessary.
I have applied the same method to several companies, and that didn’t lead to a lot of goodwill in highly dysfunctional places. The crux of the issue is that in many places, people can’t offer a consistent and exhaustive view of their work in 25 minutes. Being about to do that well enough that no other meeting is necessary it’s actually quite typical of Facebook where the pressure for people’s time and meeting rooms is so high that most meetings are 30-minute long; most people are smart and curious enough to be able to structure their entire role and its context, and fit that in a cogent 25 minutes, including questions. Elsewhere, you might get into trouble for trying to make sense of a lot of frustration, under-optimal decisions and misunderstandings.
You're right and I'd like to add, from firsthand accounts of friends who workthere, facebook seems like an incredibly well-managed company. They have good process, measure what matters, focus on impact, and seem to keep their employees happy.
Most places aren't at their level of alignment or clarity; it's a huge jumble of poorly-prioritized tasks and dysfunction.
I can directly confirm, and it comes down two three simple things:
- a constance focus on finding solutions: if you don’t know something, that’s not your problem, you managers pivots that into why it wasn’t taught in Bootcamp, why it wasn’t checked; you are never stuck or blamed: it’s always about establishing a long list of things to do, many personal improvements, and having the most important on top; “How can we fix this?” is the default response and it works really well;
- no hesitation to replace managers: I did work with people who were not… great at sharing their vision, and their responsibilities changed, often and fast; there is a quarterly detailed review leveraging a very detailed poll of all employees — outcomes are shared, decisions are public and debated at every level; authority is never something you own, and nowhere else have I seen so many senior people go back to the trenches because they though that would be best; little surprise though: their ability to take and act on criticism meant they generally get promoted very fast again;
- no hesitation in promoting unconventional people for management role and allowing them to be themselves, because that role is not about being the best, but the most able to give a team a direction. No where more than there have I reacted “Your manager did WHAT?! No, that’s awesome, and brutally honest but… Wow.” Sharing graphic details of pregnancy (to ask for specific team support around length of meetings), alternative hobby (like, really — to explain an issue with one use-case). No shame, just constructive direction.
The only thing at all that's wrong about this is the title...
'Onboarding jumpstart' seems like a better title, maybe 'newhire jumpstart' as an alternate.
This is really good advice that can probably actually be generalized, though it doesn't really tell you how to do the actual hard things (like how to take care of that meeting stuff).
(I'll make a different post about my own meetings rant)
Yes this seems to be interesting advice about integrating into any non-trivial project, whether at a new job, at an existing job (e.g. changing team or starting on a client project) or starting to contribute to OSS stuff
This was also posted internally and somebody else had a better way imho: after every weekly sync, he would take the bullet point list of things everybody in the team worked on/will work on and see if he can explain to an outsider what every item means. If yes, then check that out. Take all the remaining items, grouped by person and have 1:1 with said person to explain you the things you don't understand. Then you can set up a goal, like after 6 months I want to be able to strike out 70% of the items etc.
I’ve been 100% remote for two years with a trip to the office every 5 months or so and this is roughly the same strategy I use to stay connected during those visits.
“What are you working on? What’s next? What do we need most?" 1-on-1, less than 30 minutes, we're a pretty loosely structured org so it’s all self-initiated. Works well, I’m more comfortable with my colleagues and they’re more comfortable with me, we know roughly what each other are working on, and bandwidth is so much higher in person than on video or text chat.
This advice applies to managers hiring new positions as well, make your new hires do this!
The position in my career where I had the most success started with my manager on my first day pretty much setting this exact exercise as my objective for the first week. He gave me a list of 3 people to talk to and told me to find out who the other people were for myself.
This is really interesting, my self-onboarding process is completely different, but seems to serve the same purpose.
1) Look at the bug backlog and pick one that's obvious and reproducible
2) Set up the environment(s) and start to debug (It's surprising how painful this step can be in some organizations, but for any team it will showcase a number of pain points for the developers and testers.)
3) Skim the related code history and make a list of people to talk to from the commits.
4) Informal meetings with those people to ask questions about the product, codebase, and what they see as major problems or bottlenecks.
Step three from the article ("ask who else you should talk to") is something I hadn't thought of before:
The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.
In large organizations there are often a number of lynchpin-type people (often in non-senior roles) scattered across teams that everyone respects and goes to for information and advice. Finding these people early saves a lot of time and frustration.
It also taps into a bias that we are more likely to help people in the future if we've helped them already, so asking for help from the start as long as it's appropriate and respectful is win win :)
Great advice from a very effective guy at Facebook. I do notice that he falls for the Harvard/Goldman conceit in his about screen. They just have to let you know in the first two minutes....
In every situation in a new environment, the best way is to just listen more and talk less -- pretty fast you'd get the social dynamic without pretending to be someone you are not or trying to wrongly impress people. And -- important -- keeping to yourself your weak spots during the timeframe when people form their opinion about you.
Soon you will see what the main struggles are in the company, who opinion leader is, and what the product development dynamic is. Only then, when you figured out the playing field and all mines you may start talking more if you really have something to say.
Quite a few comments here are saying this is for managers.
I don't agree.
This is a perfectly sensible guide for engineers in the second half of their career.
When you are young and fresh, it is the company's job to make use of you and make you productive. Effectively, the first thing they should do is intro you, give you a few learning projects, and help course correct to get you productive. Managers invest time in this so that the manager effectiveness amplification occurs.
When you get old, senior and soulless, once you start getting hired as a lead, this algorithm is basically exactly what you should be doing in your first 30 days. At that point you're almost always being hired to fix something that's broken and it's your job to make yourself productive for the company instead of the other way around and then help make other people productive (or, more often, make other people less unproductive). Putting aside the very rare exception where you are your own brand name and can get vanity projects and total control, the only real exceptions are when you start a fresh company or project and have total control, but those opportunities are comparatively rare. Most senior engineers hired into a new org who are in a leadership position will find these steps quite sensible.
The big issue I tend to have with normal corporate meetings is that everyone seems to be a complete cargo cult amateur at it; even when they try.
I think I'd much prefer a "remote first" style of meeting, where everything is designed as an asynchronous, clear deadlines for contribution, process. The actual meetings should be broken up in to focus-groups tackling a specific task, such as brain-storming the definition of a problem, or that problem's solution.
I have applied this approach throughout my career. The recommendation with the greatest long-term utility has turned out to be the last one (the network building) since this provides an organizational map - and knowing where leverage can be applied is powerful knowledge indeed. However the prior two steps suggested are useful for building both rapport and context.
These are the questions we call it the enumeration types. This means the answer to these questions requires scanning large number of options, sort them effectively and return top few choices. Ask someone what are your most favorite 10 movies and you will know how hard it is to answer these effectively and accurately.
Another thing is that much of the organizational memory these days is available electronically. When I join new team, I go through recent documents, slides, meeting notes, emails in internal discussions etc in first two days that is available to everyone in the team. I also learn building source code, looking at architecture/design docs, their evolution over time, release plans etc. After doing all these for first few days, it makes sense to ask specific questions as opposed to let me Google it for you questions and you would look prepared and worth spending time to talk details beyond giving elementary pointers.
I am in the process of interviewing for Engineering Manager/VP/CTO type roles. This will require a new skill set of me beyond the tech lead work that I have been doing. This article neatly sums up a good answer to my internal question of how do I start?
For me this kind of micro optimization never worked but in the most advanced skill areas I have (e.g. vim hotkeys).
For everything people related for me the very simple approach worked best:
- find a topic where you can see the other person getting a profit for their problems/career as well
- start discussing that topic with them
- if you hit it off, stay in contact
- if you don't hit it off, try to reduce contact as much as possible
And then work hard and try not to be a dick, but be a dick to people who want to exploit you. If someone worthy gets a bad impression because you self-defence he will come around when he sees you in action more.
Most of the comments seem to read a lot more into this that what the author of the article was proposing. The algorithm is sound. Talk to one person, get some knowledge/opinions and a list of other people to talk to. Repeat until no one is suggesting anyone new. The goal of the algorithm is to get a base sample of the project or organization so you can figure out where to start contributing and/or learning more. I have seen ( similar approach ) work in both individual contributor, manager, and investor role.
What the interviewer does with that information is another story ( likely multiple other stories ).
From my point of ignorance, the best thing is just start working. Seriously! Get a task and start solving it by your own. Even a simple task in a big project gives you a bigger picture that tons of useless meetings.
Excellent approach! Moreover, this approach helps you quickly build a relationship with each individual person in the team and immediately gain their respect. Everybody likes to be consulted as an expert.
The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.
This hits me hard. I always go into a company and ask to see its org chart so I can get a feel for where I'm at in the company. I have been frustrated before because some companies don't have org charts or they are inaccurate. I will be using this trick in the future.
A career cold start algorithm from a guy who has changed companies twice in his career (Facebook for the last 12 years and Microsoft for 1.5 years before that). Ok.
I would agree if the person was only working on the exact same project each time. However I would also find that hard to believe. I bet if we replaced career with team, we could then all agree its relevant.
I would agree that's relevant, it's true. Cold starting a career sounded like "I never coded before, let me try to jump in" or at the very least, "I never coded in X company before, let me try to jump in." His advice isn't bad, but for him personally, it's all been sheltered at Facebook, a well managed company, for more than a decade. Not exactly daring jumps into strange, new lands.
I advise new team members to begin their tenure by improving one or two key existing processes. Ideally, make life easier for a couple teammates. Right an age-old wrong within the system.
This provides an efficient way to learn the team, garner respect, and create a platform to do bigger things down the line.
I have seen far more accomplishment using this formula than the blunderbuss "we have to make changes now" approach.
This is interesting advice, but the real world is messy and 30 minutes to boil down everything you should know is not going to happen with most people. (And 3 minutes to talk about the biggest challenges to the team?) Have you ever tried to meet with people to discuss anything?
This is such valuable advice. I've tried cold starts in the past only to not really progress as much as I had hoped to. I'm looking at another cold start in the near future and I hope to use this.
This is really great advice. As someone who has recently joined a new team, I can put this to use immediately. Although the advice might differ a bit from an engineer's point of view.
This is weird... I just received a BOZ Cold Brew Coffee Maker, which I ordered from Amazon. I had to read this several times to make sure it wasn't some sort of pun.
Here's my programmer cold start algorithm for those interested:
1. Go to indeed.com
2. Type in 'software engineer' or 'data scientist' or something like that.
3. Don't put in a city.
4. Put the money slider all the way to the top.
5. Open a few pages of job postings in tabs.
6. Write down every word you don't know.
7. Repeat the process by searching for each one of those words you don't know and then write down additional words you don't know.
Now you have a list of what technologies are valuable in the zeitgeist and your mission is to determine why each technology exists and what it's use case is. You'll then be armed with a larger and more modern toolbox full of tools to reach for when the time comes to solve that kind of problem.
Rinse, repeat every few years.
Hope that helps someone. :)
A very effective, but somewhat utilitarian (dare I say, mercenary) approach. It will get you the job, but I don't know how well it will help you keep it (sometimes you might even end up with a mixed bag of buzzwords and hype). I would prefer that candidates try to deeply understand the problems facing the industry and try to develop the skills that solve them.
I know this was half in jest but it speaks to a larger point, that of the "implementation ghetto".
I'm going to get a lot of pushback for saying this, but there are basically three roles in any company: (a) people who do the work, (b) people who make sure the work gets done, and (c) people who decide what work to do.
If you follow the strategy outlined above, you will never rise beyond a pure implementer of someone else's vision.
Empirically, understanding more about the business domain and industry seem to be important if you want to do (b) or (c). If anyone has more tips, I'd love to hear them.
EDIT: When I say "above", I'm talking about in the comment two levels up, not the article.
2 replies →
"...and your mission is to determine why each technology exists and what it's use case is."
ghotli did address that, obliquely.
thanks this is a great way to learn about new terms. Adding onto this, I usually find the github repo of that keyword term (if its open source) and star it. If its a close source platform, I usually bookmark it on alternativeto.net and check up its competing cases. If its a youtube video, I usually put a like on it. this way I can just thumb through my favorites / likes / stars and get a complete picture of a modern toolset
Another good term is to do "Term VS ______" in google to learn about competing technology use cases as well
At the end of the day some of these terms are possibly all buzzwords but its nice to see what actual companies are using, what that business does, and why they might be using it. Sometimes you get some really nice insights when you dig down deeper (look at their forum posts, etc). This is especially true for things like ecommerce carts (run wappylzer → inspect what the site is running on), sometimes you can actually physically see the decisions they made at a company publically.
Omg. Could somebody just go and do this and post the results in a cliffs notes summary? That would be the worlds greatest article.
Be the change you want to see in the world ;)
"Put the money slider all the way to the top" ?
Can't see any such slider. Do I need to get a user ID at the site, or is it just that there is no such thing at indeed.com for Europe? (It only returned jobs near Helsinki [Finland] when I left the City field empty, so I also tried Berlin [Germany], which returned a link to de.indeed.com.)
I honestly thought about this last night. Current role is a lot of React/Redux/Typescript, which appears to be hot new thing, but is not particularly well paid here in the Southeast. Plus I miss being immersed in dealing with data so I need to lean to a full stack role again
>4. Put the money slider all the way to the top.
I dont see a slider on indeed. What are you talking about?
How helpful would this be for someone self taught looking for a job?
Use the advanced job search and put in a salary range.
1 reply →
This is genius.
I don't think I agree with this.
We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
On the other hand, all my best newbie programmers came in, buried themselves in their tickets until they understood them, fixed them, and went on to the next ticket. There was very little attempt to change the system in their first year.
I'm much happier with people who focus on doing their job instead of focusing on trying to impress people.
The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that.
It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that.
The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets.
Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.
It sometimes seems like we software developers travel in really distinct worlds.
People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better.
I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job.
As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done.
Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.
31 replies →
> don't expect them to make suggestions for a year
That's not the problem.
The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector.
For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
2 replies →
Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement.
A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
8 replies →
I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore.
There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.
Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.)
Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
The article is clearly targeted at managers and leaders, not your average individual contributor.
Often new leaders & managers start in an established team and want to change something to "make their mark" or have an impact as soon as possible, often with disastrous results (because they don't yet have the context to make informed decisions).
The advice is to spend time with your team to learn the ropes, figure out the internal politics, hear the common pain points and _then_ start addressing things, hopefully with some quick wins (like canceling a wasteful meeting or appropriating a larger conference room) that due to organizational inertia, went unaddressed.
Yes. And I think the article is also good advice for coaches / consultants.
When I come to a new team, I always try to find out a lot of things during the coffee breaks. But the approach from the article is more structured.
So, I guess I will try a mix of the two approaches next time ;)
1 reply →
That isn’t clear to me at all, but then I don’t know the author.
This seems like excellent advice for individual contributors, of whatever seniority, if you can already kick ass at the work you’re assigned, maybe after the first month or two. Provided you have the diplomatic skills to broach process change ideas in a way that doesn’t leave you looking like an entitled asshole, of course. But then, maybe that’s what you meant by “leader”!
1 reply →
How does what you say contradict the OP in any way, shape or form?
He says ask to meet people to understand how everything works. It's not about impressing them, even if it shows proper respect as a side effect (and showing respect by listening is quite the opposing of suggesting new things nilly willy).
I think the original article was written for someone who's going to _manage_ a new team, although it doesn't say that as explicitly as it should. But that's what I'm reading between the lines.
I think the "listening tour" is a pretty good idea even if you aren't a manager. But what to _do_ with it, needs somewhat different advice.
I also suspect the programmer in the comment I'm replying to did _not_ in fact do the "listening tour" that is the main recommendation of the original article. It's not advocating for suggesting changes based on your personal opinion, but only after learning what the team thinks and based on what they think. So the programmer in the comment I'm replying to didn't follow the advice at all.
I think implicit in the author's text is the implication that you have a high standard for ownership, so that you can handle your responsibilitites well.
I agree though that this should not be advice for novice programmers, as in this moment of the career you are not sure of the most common pitfalls a team/project gets into and should be mostly concerned about learning the technical knowledge. Trying to do anything else will be a distraction from your current goals.
Very helpful advice for consultants or team members who really care about the project and your career.
But again, as said by a sibling comment, you should always pay attention to disfunctional environments and avoid getting too much attention from sociopathic managers/technical leads. Get some advice from the peers at the same hierarchical level first to know if things are handled smoothly, before iterating.
I am dealing with this at the moment. We have a new contractor and he always wants to make big changes whenever he does something. Sometimes he may be right but I am getting tired explaining that maybe there is a reason why we are doing things a certain way and that the changes he is proposing often are just changes but don't really improve anything.
To quote the seven habits of effective people:
"Seek first to understand, then to be understood"
This is one of the most valuable lessons of contracting: only try to help people who want to be helped. Sometimes you can influence them to want help with something (e.g. an architectural change that will make things better), but if they don't believe there's anything wrong, it's just going to be a pointless battle.
It gets more awkward when you're brought in by one person, but quickly realize that the people you're working with don't want you to do what you were brought in to do. Or when people tangential to the project see it as a threat to the status quo and actively try to prevent you from doing what you're trying to do.
2 replies →
You're probably correct in your analysis, but in general I'm very wary of people who use self-help readings or techniques to analyze what everyone around them should be doing differently. I often run into people who seem to use these kinds of things as excuses to blame others and not take reasonable action on their own.
1 reply →
Of course, for a contractor, there's good money in making the problem bigger...
> I don't think I agree with this.
> We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
If you had people like that, and you weren't able to utilize their talent, then your workplace sucks.
The right way to go when someone says "We should do $X!" and you don't believe it is to say "Prove it!"
Depends on how disruptive their proving it is going to be. If it's not going to be worth the code turmoil, even if they're right, then no, that's not "the right way to go".
Improvements aren't free. They cost, usually more than just the opportunity cost of the implementer's time. There are lots of ideas for improvement that will cost more than they deliver. If I have someone consistently suggesting them, no, I have no place for utilizing their "talent", and no, it's not because my workplace sucks.
1 reply →
> What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
I'm not sure I would call that "talent", and based on that performance, I certainly wouldn't want their "improvements" on our systems.
The best way become more familiar with an unknown team and code base is to work in the code daily. Spending your entire day in 30-minute one-on-ones with people will not help either of those. The exception of course is when you're brought in as a senior-level person in order to change something. But then you need to ask yourself why the senior folks on that team aren't in charge of that.
Spending your entire day in 30-minute one-on-ones with people will not help either of those
I assumed it would be around 5-10 meetings over a few weeks. Half of which can probably be done on lunch breaks. So it shouldn't take too much time away from real work. Obviously you should be working in the code base daily, but in the beginning working 8 hours a day is probably less efficient than working 7.5 hours and spending 30 minutes actually asking someone to explain parts of the code base to you.
4 replies →
> Spending your entire day in 30-minute one-on-ones with people will not help either of those.
How many of these meetings do you think the author is suggesting?? Even one day of that is 16 meetings, roughly the number of people I worked with on a regular basis at Microsoft.
Clearly the author is suggesting to mix them with regular work. One hour of effective meetings per day, plus seven hours in the code, is going to be vastly more effective than just wallowing through code for the entire day.
This confuses me. Coding is more of a tactical operation, and with it you're still going to want a grand strategic vision of what to implement. I think it's foolish to think that you can see the big picture just by trying to make a lot of commits.
A common one is that they are bogged down in work. Then, figure out why that has been allowed to happen and tread carefully.
I think you missed the point - it's not being over eager. It's a methodical approach to quickly learning about your new organization.
I read it as the more neutral impress, as in draw attention or make a lasting mark, versus "make yourself look good".
You are rather elaborately saying that you want people who do what they're told and don't make waves. Got it--every manager wants that 100 percent. No kidding.
Style tip: When talking about a particular person, don't refer to him or her as "they".
> Style tip: When talking about a particular person, don't refer to him or her as "they".
Can you explain why, please?
3 replies →
I have a different algorithm, which I have successfully used twice: assume the duties of someone one level lower than your designation for at least a month. If you're a tech lead, drop into the shoes of an engineer; if you're a director/VP, drop into the shoes of an architect (provided you're in the technical track). Get down to the weeds. You will not only build a better mental picture of goings-on from first hand experience, the team will more readily accept you as one of their own.
I wish this is how all managers thought. Most love to stay on their level, and know nothing of what is actually going on a step below them. They take pride in pushing information up or down the chain without an inkling of how anything actually runs/works.
I forgot to mention how I learned to do this: apparently when Walter Chrysler Jr. joined Chrysler, his father did not put him straight away in an executive position like the other car company founders did. Instead, his first job was to clean out the basement of the Chrysler building. From there, he had to work his way up. It is said Chrysler Jr. became a proper manager as a result. I heard this story while I was a teenager and never forgot it...
1 reply →
What if you’re starting at an entry level position?
Then you very often won't be doing much (hopefully nothing) that is critical and it's your superiors' and your seniors' job to get you to the point where you can.
Great advice, but be aware that there are circumstances where it might not work too well:
- disorganized workplaces run by a paranoid manager (all too common): The tactic would probably be conceived as taking too much own initiative, and 'stealing' 30 minutes from an arbitrary number of employees would not go down well (even if it was in your free time). You could try and get managerial sign-off, but don't count on it. If you really need that job in the first place (it's going to be a rough ride) better do over a beer or similar. It is why 'after work' was invented in the first place after all.
- as a very junior or entry-level employee it would seem like overkill in most teams, and probably not work to your advantage. In that case, and if you're ambitious and want to move quickly, try to get the same information but in a less overt way.
This is an incredibly jaded view. Both cases should be encouraging to anyone in a management position. Spending time to understand the lay of the land shows that the new hire is motivated to learn the system they are working on through the other experts on the team. It shows they care, which is a huge win for any project. If a manager truly took issue with this they shouldn’t be managing. It’s also a clear sign to find something else quickly!
And jaded is not good now? Wow I must be really jaded.
1 reply →
jaded : Bored or lacking enthusiasm, typically after having had too much of something. [0] - hm?
Lacking in enthusiasm, perhaps. There is something to be said for people who venture into every new setting with an optimistic mindset, and not caring if they should tiptoe round, so agree inasmuch.
On the other hand (based on 40 years+ of professional experience), workplaces are in reality on a spectrum regarding these things (not binary good or bad), and peoples seniority as well as their need to take any job in the lower end are on a spectrum as well (some need to take what is provided because of location or other factors). In certain intersections of these factors I'd still say be careful to follow the advice in the linked article very literally.
In the appropriate cases I'd say it was excellent advice though, perhaps that wasn't clear enough.
[0] https://en.oxforddictionaries.com/definition/jaded
3 replies →
as a very junior or entry-level employee it would seem like overkill in most teams
You don't have to start with the senior project manager. Try to find someone who's equally entry-level and been there less than year and talk to them. They'll no doubt be happy to talk and teach you the important things that you actually need to know in your position.
>> They'll no doubt be happy to talk and teach you the important things that you actually need to know in your position
Unless they are jaded from being underpaid or stuck at a position they dislike, which is a very common theme in Eastern Europe and middle East.
1 reply →
The article is aimed at a manager or team leader that is joining a new team.
> things you can easily help with, like “we waste a bunch of time in meetings every week” or “we need a dedicated conference room.”
But agreed, a junior could do the same thing in a less overt way.
For the former case, just leave - if they don't want your help then they don't deserve it. In IT there's plenty of work.
I read this comment before reading the article (something I often do) and it intrigued me enough to read the actual article. Then I realized that the article is just saying “talk to people when you start a new job”. If that’s an issue for any manager, regardless of my seniority level, I’ll know I’ve made a wrong decision to join that team.
Cool, happy to inspire!:)
I think the advice in the article was excellent - to the point that your summary quote does it some injustice. But my comment regarded some edge cases, among which the case when a new leader would be compelled to take a job even if workplace was in some disarray. Obviously, if one can pick and choose then it doesn't apply.
>disorganized workplaces run by a paranoid manager (all too common)
You basically can't win in a place like this. It's better to keep your head down and leave as soon as you can and try to see the warning signs before taking the job in future.
If it causes problems... run and never look back.
Could we maybe adjust the title to say something like, “A Career Cold Start Algorithm For Managers”?
It’s somewhat applicable to individual contributors, but it’s intended more for managers, which I didn’t realize until halfway through it. Might just add some clarity for folks opening it up without any context.
You’re not alone in thinking this was advice for managers, many people have said this. But the word manager doesn’t appear in the piece a single time, and I think it’s great advice for individual contributors, so I hope no one editorializes the title this way!
It’s not like only managers can propose slight shifts (desired by the existing team, explicitly in this construction) in process. Unless you’ve got a real jerk of a manager or aren’t doing your base line job well yet, such suggestions, if broached carefully, ought to be welcome.
The world "leader" is used though. While there are certainly non-manager leaders, most members on any given team are not leaders.
"...the natural instinct to push for early impact leads many incoming leaders into challenging relationships..."
The higher up you get in engineering the IC/management distinctions normally start to blur. I think this is equally good advice for many senior engineers.
I'm an IC and I read it as very relevant for ICs.
Boz has mainly changed position within Facebook where a lot of things go right: people know what they are going and why; they get challenged over it often enough to be able to explain themselves succinctly; power is held by people who make things happen and can explain what is necessary.
I have applied the same method to several companies, and that didn’t lead to a lot of goodwill in highly dysfunctional places. The crux of the issue is that in many places, people can’t offer a consistent and exhaustive view of their work in 25 minutes. Being about to do that well enough that no other meeting is necessary it’s actually quite typical of Facebook where the pressure for people’s time and meeting rooms is so high that most meetings are 30-minute long; most people are smart and curious enough to be able to structure their entire role and its context, and fit that in a cogent 25 minutes, including questions. Elsewhere, you might get into trouble for trying to make sense of a lot of frustration, under-optimal decisions and misunderstandings.
You're right and I'd like to add, from firsthand accounts of friends who workthere, facebook seems like an incredibly well-managed company. They have good process, measure what matters, focus on impact, and seem to keep their employees happy.
Most places aren't at their level of alignment or clarity; it's a huge jumble of poorly-prioritized tasks and dysfunction.
I can directly confirm, and it comes down two three simple things:
- a constance focus on finding solutions: if you don’t know something, that’s not your problem, you managers pivots that into why it wasn’t taught in Bootcamp, why it wasn’t checked; you are never stuck or blamed: it’s always about establishing a long list of things to do, many personal improvements, and having the most important on top; “How can we fix this?” is the default response and it works really well;
- no hesitation to replace managers: I did work with people who were not… great at sharing their vision, and their responsibilities changed, often and fast; there is a quarterly detailed review leveraging a very detailed poll of all employees — outcomes are shared, decisions are public and debated at every level; authority is never something you own, and nowhere else have I seen so many senior people go back to the trenches because they though that would be best; little surprise though: their ability to take and act on criticism meant they generally get promoted very fast again;
- no hesitation in promoting unconventional people for management role and allowing them to be themselves, because that role is not about being the best, but the most able to give a team a direction. No where more than there have I reacted “Your manager did WHAT?! No, that’s awesome, and brutally honest but… Wow.” Sharing graphic details of pregnancy (to ask for specific team support around length of meetings), alternative hobby (like, really — to explain an issue with one use-case). No shame, just constructive direction.
The only thing at all that's wrong about this is the title...
'Onboarding jumpstart' seems like a better title, maybe 'newhire jumpstart' as an alternate.
This is really good advice that can probably actually be generalized, though it doesn't really tell you how to do the actual hard things (like how to take care of that meeting stuff).
(I'll make a different post about my own meetings rant)
Yes this seems to be interesting advice about integrating into any non-trivial project, whether at a new job, at an existing job (e.g. changing team or starting on a client project) or starting to contribute to OSS stuff
Same here, I was fooled the article would be about some career switch idea.
This was also posted internally and somebody else had a better way imho: after every weekly sync, he would take the bullet point list of things everybody in the team worked on/will work on and see if he can explain to an outsider what every item means. If yes, then check that out. Take all the remaining items, grouped by person and have 1:1 with said person to explain you the things you don't understand. Then you can set up a goal, like after 6 months I want to be able to strike out 70% of the items etc.
I’ve been 100% remote for two years with a trip to the office every 5 months or so and this is roughly the same strategy I use to stay connected during those visits.
“What are you working on? What’s next? What do we need most?" 1-on-1, less than 30 minutes, we're a pretty loosely structured org so it’s all self-initiated. Works well, I’m more comfortable with my colleagues and they’re more comfortable with me, we know roughly what each other are working on, and bandwidth is so much higher in person than on video or text chat.
Starting a new job on Monday. Definitely going to be trying this.
Excellent advice.
This advice applies to managers hiring new positions as well, make your new hires do this!
The position in my career where I had the most success started with my manager on my first day pretty much setting this exact exercise as my objective for the first week. He gave me a list of 3 people to talk to and told me to find out who the other people were for myself.
This is really interesting, my self-onboarding process is completely different, but seems to serve the same purpose.
1) Look at the bug backlog and pick one that's obvious and reproducible
2) Set up the environment(s) and start to debug (It's surprising how painful this step can be in some organizations, but for any team it will showcase a number of pain points for the developers and testers.)
3) Skim the related code history and make a list of people to talk to from the commits.
4) Informal meetings with those people to ask questions about the product, codebase, and what they see as major problems or bottlenecks.
Step three from the article ("ask who else you should talk to") is something I hadn't thought of before:
The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.
In large organizations there are often a number of lynchpin-type people (often in non-senior roles) scattered across teams that everyone respects and goes to for information and advice. Finding these people early saves a lot of time and frustration.
It also taps into a bias that we are more likely to help people in the future if we've helped them already, so asking for help from the start as long as it's appropriate and respectful is win win :)
Great advice from a very effective guy at Facebook. I do notice that he falls for the Harvard/Goldman conceit in his about screen. They just have to let you know in the first two minutes....
Related, here's a good post on strategies for quickly becoming familiar with a new code base: http://devblog.nestoria.com/post/96541221378/7-strategies-to...
In every situation in a new environment, the best way is to just listen more and talk less -- pretty fast you'd get the social dynamic without pretending to be someone you are not or trying to wrongly impress people. And -- important -- keeping to yourself your weak spots during the timeframe when people form their opinion about you.
Soon you will see what the main struggles are in the company, who opinion leader is, and what the product development dynamic is. Only then, when you figured out the playing field and all mines you may start talking more if you really have something to say.
Quite a few comments here are saying this is for managers. I don't agree.
This is a perfectly sensible guide for engineers in the second half of their career.
When you are young and fresh, it is the company's job to make use of you and make you productive. Effectively, the first thing they should do is intro you, give you a few learning projects, and help course correct to get you productive. Managers invest time in this so that the manager effectiveness amplification occurs.
When you get old, senior and soulless, once you start getting hired as a lead, this algorithm is basically exactly what you should be doing in your first 30 days. At that point you're almost always being hired to fix something that's broken and it's your job to make yourself productive for the company instead of the other way around and then help make other people productive (or, more often, make other people less unproductive). Putting aside the very rare exception where you are your own brand name and can get vanity projects and total control, the only real exceptions are when you start a fresh company or project and have total control, but those opportunities are comparatively rare. Most senior engineers hired into a new org who are in a leadership position will find these steps quite sensible.
(The meetings sub-rant)
The big issue I tend to have with normal corporate meetings is that everyone seems to be a complete cargo cult amateur at it; even when they try.
I think I'd much prefer a "remote first" style of meeting, where everything is designed as an asynchronous, clear deadlines for contribution, process. The actual meetings should be broken up in to focus-groups tackling a specific task, such as brain-storming the definition of a problem, or that problem's solution.
you need another meeting to break up the tasks among focus-groups. This feels like recursive ;)
No you don't. Allow people to take on the tasks by themselves, (agile style) distribute unwanted ones at random at a deadline.
2 replies →
I have applied this approach throughout my career. The recommendation with the greatest long-term utility has turned out to be the last one (the network building) since this provides an organizational map - and knowing where leverage can be applied is powerful knowledge indeed. However the prior two steps suggested are useful for building both rapport and context.
These are the questions we call it the enumeration types. This means the answer to these questions requires scanning large number of options, sort them effectively and return top few choices. Ask someone what are your most favorite 10 movies and you will know how hard it is to answer these effectively and accurately.
Another thing is that much of the organizational memory these days is available electronically. When I join new team, I go through recent documents, slides, meeting notes, emails in internal discussions etc in first two days that is available to everyone in the team. I also learn building source code, looking at architecture/design docs, their evolution over time, release plans etc. After doing all these for first few days, it makes sense to ask specific questions as opposed to let me Google it for you questions and you would look prepared and worth spending time to talk details beyond giving elementary pointers.
I am in the process of interviewing for Engineering Manager/VP/CTO type roles. This will require a new skill set of me beyond the tech lead work that I have been doing. This article neatly sums up a good answer to my internal question of how do I start?
Thank you for it
Interesting post. I will start at a new job soon. I am going to try this piece of advice.
For me this kind of micro optimization never worked but in the most advanced skill areas I have (e.g. vim hotkeys).
For everything people related for me the very simple approach worked best: - find a topic where you can see the other person getting a profit for their problems/career as well - start discussing that topic with them - if you hit it off, stay in contact - if you don't hit it off, try to reduce contact as much as possible
And then work hard and try not to be a dick, but be a dick to people who want to exploit you. If someone worthy gets a bad impression because you self-defence he will come around when he sees you in action more.
Most of the comments seem to read a lot more into this that what the author of the article was proposing. The algorithm is sound. Talk to one person, get some knowledge/opinions and a list of other people to talk to. Repeat until no one is suggesting anyone new. The goal of the algorithm is to get a base sample of the project or organization so you can figure out where to start contributing and/or learning more. I have seen ( similar approach ) work in both individual contributor, manager, and investor role.
What the interviewer does with that information is another story ( likely multiple other stories ).
From my point of ignorance, the best thing is just start working. Seriously! Get a task and start solving it by your own. Even a simple task in a big project gives you a bigger picture that tons of useless meetings.
Excellent approach! Moreover, this approach helps you quickly build a relationship with each individual person in the team and immediately gain their respect. Everybody likes to be consulted as an expert.
The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.
This hits me hard. I always go into a company and ask to see its org chart so I can get a feel for where I'm at in the company. I have been frustrated before because some companies don't have org charts or they are inaccurate. I will be using this trick in the future.
A career cold start algorithm from a guy who has changed companies twice in his career (Facebook for the last 12 years and Microsoft for 1.5 years before that). Ok.
I would agree if the person was only working on the exact same project each time. However I would also find that hard to believe. I bet if we replaced career with team, we could then all agree its relevant.
I would agree that's relevant, it's true. Cold starting a career sounded like "I never coded before, let me try to jump in" or at the very least, "I never coded in X company before, let me try to jump in." His advice isn't bad, but for him personally, it's all been sheltered at Facebook, a well managed company, for more than a decade. Not exactly daring jumps into strange, new lands.
I advise new team members to begin their tenure by improving one or two key existing processes. Ideally, make life easier for a couple teammates. Right an age-old wrong within the system.
This provides an efficient way to learn the team, garner respect, and create a platform to do bigger things down the line.
I have seen far more accomplishment using this formula than the blunderbuss "we have to make changes now" approach.
This is interesting advice, but the real world is messy and 30 minutes to boil down everything you should know is not going to happen with most people. (And 3 minutes to talk about the biggest challenges to the team?) Have you ever tried to meet with people to discuss anything?
Absolutely amazing advice! If you get to the point where you think that asking as a good idea .. oh gosh.
This is such valuable advice. I've tried cold starts in the past only to not really progress as much as I had hoped to. I'm looking at another cold start in the near future and I hope to use this.
This is really great advice. As someone who has recently joined a new team, I can put this to use immediately. Although the advice might differ a bit from an engineer's point of view.
Its good advice but I wouldn't spill my guts to someone taking notes. I would try a more casual approach, talk with people over a coffee or similar
In India people don't explain much to team mates because their importance will decrease. It's not so easy here, Politics is over the head.
Depends on the company's culture and its formal KT rules
this is so great. absolutely amazing advice
This article is what would happen if Ulillillia suddenly joined tech
This is weird... I just received a BOZ Cold Brew Coffee Maker, which I ordered from Amazon. I had to read this several times to make sure it wasn't some sort of pun.