
A Career Cold Start Algorithm - zdw
http://boz.com/articles/career-cold-start.html
======
ghotli
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. :)

~~~
hliyan
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.

~~~
eldavido
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.

~~~
aidenn0
You missed the step of "understand why each technology exists."

If you understand why a technology exists you are gaining an understanding of
problems, and after repeating a few times over a decade you may see patterns
in problems that are being solved.

It's easy to mock "AbstractSingletonProxyFactoryBean" but whoever created it
was not being wholly onanistic, and if you can't understand why it was
created, you are going to be in trouble if you ever create your own framework.

------
wccrawford
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.

~~~
arcticfox
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.

~~~
mercutio2
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.

~~~
JackFr
> 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.

I think there's a role for humility on both sides. In my current role, I was
an experienced hire. After a month on the job my manager and his manager
pulled me aside and said "What are we doing wrong?"

The interesting thing was that when I told them that I thought their module
system was seemed backwards, the response was "Yeah, we know. It's a quirk of
history that it ended up that way, and we've got a plan to fix it. Anything
else?"

They very much valued a fresh set of eyes to ensure that they weren't missing
something they had become house-blind to. At the same time, as a set of fresh
eyes your attitude should be one of questioning, "Why are we doing it that
way?" rather than "We're doing it wrong" or "This way is better".

~~~
kolpa
Remember Chesterton's Fence.

Here's the trick: Every weird architecture exists for a reason, good or bad.
If it looks wrong to a newbie, maybe the newbie misunderstands it, or maybe
the business can't afford to build something better (and it's good enough as
is), or maybe it really is wrong but the people who built it like it, so what
good will come of you you trying to change it? Your newbie ideas only help if
the veterans _want_ new ideas _and also_ your newbie ideas are better than
their veteran ideas. That's possible but rare.

------
hliyan
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.

~~~
degenerate
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.

~~~
hliyan
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...

~~~
throwaway080383
I'm sure the promotion committee had a tough time making that call...

------
stareatgoats
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.

~~~
malloci
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!

~~~
stareatgoats
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](https://en.oxforddictionaries.com/definition/jaded)

~~~
xkjkls
That's a pretty bad definition of jaded:

"made dull, apathetic, or cynical by experience or by having or seeing too
much of something" [1]

I would say that someone who feels that it's commonplace for managers to
refuse to allow new employees to schedule _30 minutes_ with other members of
their team while on-boarding would fit the definition of being overly cynical.

[1] [https://www.merriam-webster.com/dictionary/jaded](https://www.merriam-
webster.com/dictionary/jaded)

~~~
stareatgoats
Not to be nitpicking, but I said 'there are circumstances' which is not the
same as 'it's commonplace' (it's actually implying edge cases).

That said, thanks for a better definition of 'jaded' even if not applicable!
:-)

------
dsacco
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.

~~~
mercutio2
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.

~~~
aidenn0
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..."

------
bertil
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.

~~~
eldavido
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.

~~~
bertil
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.

------
mjevans
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)

~~~
masklinn
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

------
pbalau
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.

------
adbachman
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.

------
dagw
Starting a new job on Monday. Definitely going to be trying this.

------
mmikeff
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.

------
jobu
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.

------
tudorw
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 :)

------
mathattack
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....

------
freyfogle
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...](http://devblog.nestoria.com/post/96541221378/7-strategies-to-quickly-
become-productive-in-an)

------
Mikho
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.

------
foobiekr
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.

------
mjevans
(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.

~~~
gordon_freeman
you need another meeting to break up the tasks among focus-groups. This feels
like recursive ;)

~~~
AstralStorm
No you don't. Allow people to take on the tasks by themselves, (agile style)
distribute unwanted ones at random at a deadline.

~~~
Cthulhu_
But how do you determine what tasks to do and what the scope thereof is? When
they're done? That's what most our meetings are about, :p

~~~
mjevans
Ultimately there does have to be someone (or some small group) where 'the buck
stops'. That's who assigns the other tasks, or at least spawns them and sets
default ownership + deadline. (So that the tagged individual can either
produce a good alternative, or at least why they're not a good fit.)

------
inopinatus
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.

------
sytelus
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.

------
misthop
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

------
elthor89
Interesting post. I will start at a new job soon. I am going to try this piece
of advice.

------
erikb
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.

------
drelihan
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 ).

------
more-entropy
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.

------
juanmirocks
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.

------
djhaskin987
_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.

------
joslin01
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.

~~~
enjoylife
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.

~~~
joslin01
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.

------
untangle
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.

------
allenu
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?

------
pulsarpietro
Absolutely amazing advice! If you get to the point where you think that asking
as a good idea .. oh gosh.

------
borncrusader
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.

------
darkstar_16
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.

------
apabepa
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

------
aj_nikhil
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.

------
known
Depends on the company's culture and its formal KT rules

------
asyncanup
this is so great. absolutely amazing advice

------
lilfatbitch
This article is what would happen if Ulillillia suddenly joined tech

------
jenkstom
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.

