
Micro-promotions and mentorship: impact of small actions in engineering culture - Bary0n1cMatt3r
https://circleci.com/blog/micro-promotions-and-mentorship-the-big-impact-of-small-actions-in-an-engineering-culture/
======
phsource
> Significantly, they also acknowledged the contributions I made.
> Acknowledgment doesn’t require a parade. These are small gestures that folks
> made that were meaningful to me:

> Using the :clap: emoji in a pull request comment to highlight a clever bit
> of my code.

> Sending a direct message of thanks upon realizing they were actively
> benefiting from a refactor I’d made to a previously gnarly bit of code.

> Posting a note to our #gratitude channel on Slack recognizing how helpful
> some documentation I’d written had been to them, and encouraging others to
> use it.

I remember reading a study about how for a romantic relationship to succeed,
the ratio of positive to negative interactions has to be 5 to 1. [1]

Work relationships might only need a ratio of 1:1, but especially as an
engineer, where the default's to critique and only pick out the bad parts in
code reviews, these really help! Even at Stripe, I remember how far a "Nice!
I've been meaning to do this for a while" as a part of a code review would go
in just making all the other suggestions go down better. Definitely kudos to
CircleCI for making this a part of the culture.

[1] [https://www.gottman.com/blog/the-magic-relationship-ratio-
ac...](https://www.gottman.com/blog/the-magic-relationship-ratio-according-
science/)

~~~
enjo
"Work relationships might only need a ratio of 1:1, but especially as an
engineer, where the default's to critique and only pick out the bad parts in
code reviews, these really help!"

I'm on mobile so I can't pull a source, but research for work relationships
generally agrees on a ratio of around 6:1 positive to negative ratio for
negative feedback to be taken in a positive way.

You're correct that engineering culture falls FAR short of this, and leads to
some really bad outcomes as a result.

~~~
whatshisface
I'm not exactly a software engineer, but I have a really hard time imagining
how 6 in 1 statements about anything could be complements. In my area, most
work is average (by definition) and the main reason you show your work to
people sitting in the chair next to you is so that they can catch your trivial
mistakes. (Kind of like code review.) I do know that in the average program
there are far more bugs than clever inventions.

~~~
MaulingMonkey
In between those trivial mistakes is a lot of functional code I didn't have to
write myself. Very often, that's code that _I personally_ no longer have to
write (if I'm reviewing it, there's a good chance it would've ended up on my
place if they didn't take care of it for me), or that I get to leverage in my
own code. That's stuff I can thank them for.

Phrasing is important. "Here's 3 things you fucked up, fix it" is negative.
"Here's 3 minor nitpicks. Otherwise, LGTM, thanks for tackling this!
:thumsup:" is overall positive. Both could be describing the same code review.
"While you're in there, could you add unit tests for X and Y?" is asking for a
favor you can then thank them for doing, "X is missing unit tests, why?" is
demanding answers for a mistake.

You can still help set the tone on the receiving end of code reviews as well.
"Good catch!" when people spot significant bugs in my code, reacting with
thumbs up emojis when people voice their concerns. Elicit feedback,
suggestions for improvements - instead of "what is everything this code does
wrong", it's "okay, here's a first draft - how can we make it better?".

The goal is not to deliver perfect code. That's impossible - we're human.
Trying to do so anyways is counterproductive - static analysis, and a second
set of fresh set of eyes will find some bugs faster. Seperating onself from
one's work like that can be difficult - but between setting an example
yourself, and showing geniue appreciation for the person's work even as you're
finding issues in the code can help.

~~~
ambicapter
I hate when people says LGTM but still have nits to pick. Either its ready to
ship or its not.

~~~
MaulingMonkey
It's ready to ship.

Because nothing ever ships without issues. When talking about end products,
we're often - if not usually - talking straight up known bugs, not mere
nitpicks. Hell, I'm willing to OK _known bugs in changelists_ under some
circumstances - like being less buggy than what's currently checked in!

Serious bugs can be a good reason to hold off on something. But nitpicks -
say, a minor quibble about function naming is a subjective personal preference
that should never devolve into a lengthy debate holding up an important
improvement that otherwise checkin. We both have bigger, more important
dragons we could use our time to slay. It's worth discussing briefly - maybe
we can achieve consensus and find a better option - but if you want to check
in your code as is, right now, for pretty much any reason whatsoever? Go for
it. We can always make a followup changelist. Hell, please do - those are
easier to diff! Even if we're working in "commit straight to shared master
branch in perforce" style. If you're using git, but are worried other people
about to start refactoring and want to merge into the main work branch ASAP?
Go for it. Naming debates can wait. Typos can wait. There's always the next
changelist. Just have a general dread of having lots of files checked out? Go
for it. Make your commit. The issues are nitpicks, not blockers.

I've seen plenty of good work - changelists that are objectively improvements
- die in analysis paralysis and never get checked in because of quibbles over
less important details. It sucks. Minor naming quibbles should not be a cause
of this. Significant design problems - maybe - but not minor easily fixed
after the fact naming quibbles.

"LGTM otherwise!" is also a good finisher to signal "Okay, I've gone through
everything, I think I won't find anything else." In more relaxed review
environments, it's a signal that I don't feel the need to re-review your
change - maybe with minor fixes for outright bugs - before you commit. It is
carte blanche to move forwards.

------
jabloczko
I am struggling to phrase this comment in a non-abrasive way. Please read on
charitably.

I, similarly to the author, was hired into a position without necessarily
having a huge amount of skills. The reason I was hired was due to me showing
an aptitude for being able to be dropped into a new situation and find my own
way out of it. My hiring experience was baptism by fire. There was no
onboarding, just JIRA tickets and some architecture diagrams.

My team races at a million miles per hour, and frankly doesn't have the time
to hand-hold a juniour as they learn the ropes. I was put on pagerduty and
started putting out production fires within 3 weeks of being hired. With no
prior experience.

That is not to say that my team didn't help _at all_. However, I distinctly
recall trying to limit my questioning to daily stand-up, and only asking
further questions if I was very stuck on some proprietary technology (because
Google searches can't help you with in-house tech.) My manager during
performance reviews would heap praise on me for being so green and yet so low-
maintenance.

Now at this point I'm programming, doing "infrastructure as code" in the
cloud, and working on baremetal hardware. Coming from basically nothing. Allow
me to brag a little bit. I'm proud of myself.

It is stressful, there are long hours involved, but the experience hardens one
for sure.

Maybe I'm just experiencing a sort of Stockholm syndrome. Maybe I was put into
a terrible situation and just accepted it as normal, even good. Experience is
subjective like that.

~~~
humbleMouse
If your organization has a junior putting out "fires" in production after 3
weeks, a few major things are wrong. First of all, code shouldn't be "on fire"
frequently in production. Especially a domain of functionality that is simple
enough for a 3 week old junior.

Honestly I can't think of as valid reason why there would be something
breaking in production that a junior with 3 weeks of experience on a team
could fix. Where are the dev ops people? Why is the production code so
fragile? If the "fire" is easy enough for a junior with 3 weeks experience on
the codebase to put out, why is it even a problem in the first place? Many
questions here.

~~~
opportune
Yeah, this. It's great that the poster leveraged it as a learning opportunity
and could handle things, but it speaks to the poor quality of the
organization/team that this would be an issue to begin with. But of course we
have limited details.

Also, when you're a green software engineer it can be hard to know when to ask
questions. You definitely don't want to ask too many questions which are
trivial and easily googleable. But you also don't want to spend 4 hours
figuring something out that a teammate could explain in 10 minutes, unless
their time really is 16x more valuable than yours.

------
ralusek
This is the first time I've heard the term "micro-promotion," and I would very
much like to never hear it again.

~~~
ebiester
I think it is in terms of promoting in terms of publicity rather than
advancement. I'd like a better word, but it seems to be in contrast to micro-
aggressions.

I like the concept but the homophone makes it confusing. (Giving positive
feedback in public regularly and in front of peers and management seems to be
a good thing.)

~~~
josteink
Given that micro-aggression are arguably mostly created by the mentality of
the receiver, and not the acts of the sender, I don’t think the comparison is
entirely right.

How about just calling it casual encouragement?

~~~
zachr
We can pretty easily call micro aggressions casual [race/sex/class/etc]ism.

Sound good?

~~~
stupidthrottle
No, because those are real things, based on actual classifiable actions and
behaviour.

Micro-aggressions are just made up offenses in the mind of the receiver.

~~~
zjaffee
The person above you was correct and they are real things that are called
microaggressions. A micro aggression is defined as "A statement, action, or
incident regarded as an instance of indirect, subtle, or unintentional
discrimination against members of a marginalized group such as a racial or
ethnic minority."

------
munificent
I really like this article. It's very concrete in terms of what the author
experienced, how it felt, and the actions the people around her took to make
her experience go well.

In a lot of the discussions around gender, I end up thinking. "OK, I care. Now
what should I _do_?" This post actually has some answers.

Also, even though I've got basically all of the privilege merit badges, I can
empathize with her about what it feels like to be intimidated and how a little
caring support goes a _very_ long way in that time.

~~~
alexeldeib
I recently started reading about non violent communication, and this is a big
tenet from what I gather. Affirmatively communicate your feelings and your
needs.

I found there are two difficult aspects to this: clearly defining the
relationship from feelings -> needs (many examples in the book of this, and
how people twist words when asked to describe what other people do that they
don’t like), and avoiding specific language mannerisms I’ve grown used to but
recognize as following negative patterns.

I found the approach helpful when I tried using it during some emotionally
tense situations.

------
daenz
>For the last decade, I have worked in male-dominated environments. While
during this time I’ve encountered many nitwits and detractors...

What a way to start an article that will presumably be read by your current
peers, subordinates, and superiors.

~~~
xsmasher
That's only part of the sentence.

> For the last decade, I have worked in male-dominated environments. While
> during this time I’ve encountered many nitwits and detractors, I’ve also
> been fortunate to encounter many proponents and advocates.

That doesn't seem like a blanket denunciation of their peers, subordinates,
and superiors.

~~~
daenz
I expect more from someone in a team leadership position (Engineering Team
Lead) than to have public, petty and negative opinions about a vague "many"
number of their coworkers. This is a red flag when it comes to leadership, and
if they're serious about attracting and keeping experienced software
developers, they'll keep those kinds of opinions out of the workplace's
acceptable discourse.

~~~
ketzo
Personally, I value honesty and a critical eye in my leaders. If those two
things happen to reveal something negative about a workforce or a talent pool,
is that a negative?

~~~
AlphaSite
There are many ways to say the same thing.

------
jpmoyn
It feels good, and is a good motivator, when your code is received positively.
Especially early on when you aren't necessarily confident that you are a
"coder" yet. I think that is a great nugget of truth for anyone working on an
engineering team.

That said, this person graduated a coding bootcamp + joined their first team
less than 3 years ago. I'm not sold that they have much to teach about
managing an engineering team (not that I do either).

~~~
jniedrauer
> Especially early on when you aren't necessarily confident that you are a
> "coder" yet.

When I was lacking experience, I actually really just wanted negative
feedback. The absence of feedback, to me, was synonymous with "your work is
correct." But no one would ever tell me what I was doing _wrong_. Even now,
half a decade later, I have yet to get that negative feedback. I hope that
means I'm just a good coder, but I always have this nagging feeling that it's
because no one has actually reviewed my code before.

~~~
ketzo
I’m actually in your position, and I agree, sometimes what you really want is
to know what you did wrong.

That said, imposter syndrome is a very real thing, and it’s felt
disproportionately by women and minorities in tech — I think we should be
cognizant that a lot of our colleagues have been told throughout their lives,
implicitly or explicitly, that their work isn’t good enough, and so that
positive affirmation can do a huge amount of good.

------
siliconc0w
The problem with adhoc public praise is that it invariably gets unevenly
applied which makes people feel unvalued if they work on a less visible or
more esoteric part of a system. It may actually result in them being
undervalued because some manager who has twenty reports, never sees Bob get
any :claps: and so begins to assume bob isn't generating value.

Ultimately this about measuring and rewarding value generated which I prefer
be evenly applied, objective as possible, transparent, and continuous. I
prefer a culture of professionalism - a premise that we're all good at what we
do and we all have agreed on some process to determine what is valuable to
work on so we don't need continual praise - if the work wasn't valuable we
wouldn't be working on it.

------
diNgUrAndI
I found it tricky when working with junior devs. I remember when I was junior
several years ago, I wasn't given the permission to update some shared google
docs, not even correcting some obvious typos. Only senior engineers who "own"
them have the write permissions. When I raised the question in the team
meeting, the management simply said that's an established process and showed
no willingness to change that.

Part of me interpreted it as they don't trust me and tried to defend from my
stupid mistakes. But I told myself to be patient and shook off the negative
thoughts.

Recently I updated my view. Since I became a component lead, I wanted to be a
bit more open-minded and let a junior dev to help edit a document. He messed
up a few times (fat finger typos, pasted letters without accents, unsorted
columns, etc.)

I researched together with him into why he inadvertently made those mistakes
and it turned out he's very new to the IDE and not familiar with some editing
tricks. He was a bit ashamed about that and tried to learn. But mistakes still
happened sometimes.

One day, faced with deadlines and no time for re-doing edits, I turned off
junior dev's write permissions.

I knew that this would cause negative emotions and explained to him. He
understood it too. Things went smoothly for that deadline.

What I wanted to say is, some micro-act of taking away permissions is good for
team efficiency, but may also show distrust, especially for sensitive team
members.

My current take is: Trust by default. If breached more than twice, build it
into the process and explain carefully.

What do you think?

~~~
ravenstine
You are right because, while I tend to be easy going, if I were that junior
dev I would see having my write permissions taken away as a big F-U. I'd be
polite about it, and begin looking for a new position elsewhere.

------
esturk
I'm more curious how she went from no experience SWE to Senior SWE and a team
lead in 2 years.

I'm not saying its not warranted but I've seen people working at Google for
several years and not get the Senior title.

~~~
chewbacha
In some places, "Senior" is the second tier with other titles coming after. I
once worked some place that was:

* SWE

* Senior SWE

* Staff SWE

* Principle SWE

I think it depends a lot on the company and what terminology they use. Even at
my current company, "senior" is not the highest level.

~~~
Zaheer
Yes these titles vary widely at different companies. In fact, that's exactly
why we build [https://www.levels.fyi](https://www.levels.fyi) \- We don't have
CircleCI on there yet but hope it helps.

------
purplezooey
The actions in here are excellent. At most workplaces you have to ignore
everything that does not please management and only do the things that do.
Even if it means ignoring a lot of little things that customers will view as
quality.

------
kureikain
One of the thing about code review I found sad is that many engineers have big
ego.

Time to time, I see review like: "This is confused to me" and the person who
write that code explains a lot but refuse to make chances...I think those
don't assume good intention in code review.

We aren't in school anymore. We are all get paid to work on something and to
help the companies success, or the next engineer to success. When people spend
time review your code, read your code, being thankful for these free advice.

I learned so much and thank deeply to people who review my code literally line
by line.

The extra emoji, tactic, micro-promotions etc add no value to my learning
experience.

~~~
BeetleB
>Time to time, I see review like: "This is confused to me" and the person who
write that code explains a lot but refuse to make chances...I think those
don't assume good intention in code review.

The flip side to the coin is that "This is confusing to me" is not
particularly useful feedback. It reminds me of my days in academia, where
professors told students they can't help them if they come to them and merely
say "I don't understand this." You have to give more details.

------
skizm
As a low level individual contributor, unless the micro-promotion comes with a
pay raise, the title changes are just patronizing IMO.

~~~
lkbm
Title changes can be very valuable. The thing is, they're only valuable
because they help you get a better job elsewhere. "Here's something that is
only useful if you leave". Cool, I appreciate it, but do you expect me not to
use it?

If you want to help your employees, give them title changes. If you want to
help _and retain_ your employees, give them title changes _and_ pay raises.

------
JustSomeNobody
Along these lines, I think some people need to do some introspection and ask
themselves why isn't it their default to give praise. If someone does a good
job, say it. I mean seriously, how freaking hard is that?

------
strogonoff
Sometimes remote calls with multiple participants feel awkward, and there’s
this mild detachment and lowered engagement (not sure about the cause and
effect relationship there). Laugh track, used sparingly with good timing,
sounds like a golden idea or at least something hilarious to try.

~~~
swiley
>Laugh track, used sparingly with good timing, sounds like a golden idea or at
least something hilarious to try.

Oh gosh no, voice calls are bad enough already. I'm sure we'll see something
like a soundboard in slack or discord at some point specifically for this
though. :|

------
sigillum
Abstracting from the poetry, what could be the factor when the time spent by
senior developers coaching bootcamp's product and not working on actual
company's product could cause recent circle ci production issues?

------
omot
First of all, this is an important article that reminds that cultivating an
inclusive environment means culmination of small and subtle gestures as
opposed to simply declaring that diversity is important. It's a great article
but... I just couldn't forgive this line:

> He also uses Emacs, which is terrible, but nobody’s perfect.

This is triggering me hard. I guess I know it's a joke, but most legendary
programmers use emacs and for good reasons, it's a huge productivity booster.
There's a high learning curve, but if you're going to tackle one of the more
intelligently sophisticated industries with a semi-high learning curve let's
not shy away from tools that that are also hard to learn.

Sorry for the rant: you all have a nice weekend. Maybe practice how to use
emacs for a couple hours!

~~~
noddingham
But vim is better?

------
sorinn
I love reading blog posts like that. But wouldn't it be better to spend that
time on ... you know ... keeping the service functional to paying customers?
[https://status.circleci.com/](https://status.circleci.com/)

~~~
sinsterizme
Ah yes, people must be working at all hours of the day. How dare they spend
time doing other things!

------
dominotw
I have a theory that if you want to be promoted for your skills, work ethic
ect you have to work at company that's facing the pressures of capitalism.
Wants to succeed.

If you work a major bank or something, there is nothing stopping your managers
from covering their asses ( all along the hierachy) an simply transferring the
blame onto the lowest level employees.

~~~
munificent
That theory assumes that skills and work ethic directly translate to
capitalistic success.

My impression is that many ways to win in business don't involve working smart
and hard, but instead involve reducing competition, influencing regulation,
restricting consumer access to accurate product information, etc.

In other words, you can win the market by being the best, or you can just
change the market itself. Your bank example is a good one — look at what a
financial successful strategy it has been for banks to capitalize on their
gains and then distribute their losses onto us by getting bailed out.

~~~
dominotw
Yea that makes sense.

I am not sure then how low level employees can protect themselves from
becoming a scapegoat for failures and theft of success . Its hard to asses
management before you join a team and harder to change teams.

~~~
djakjxnanjak
The only way is networking. You have to find good people and stick with those
people. Only work somewhere if you know someone good who works on that team
and likes it.

------
anbop
This is a great example of how to foster an inclusive culture that isn’t at
all limited to women and minorities. The things described here will make
everyone feel good about the work they do and the people they do it with.

------
sonnyblarney
These are some fine ideas, but I'd argue they should be separated from the
very ideological elements in the reference 'micro promotions' document here:
[1]

It may very well have policies that are in fact illegal in terms of their
application.

I would never work at a company that promoted these specific ideals in an
official manner, not because I don't believe in the general impetus of the
notion that 'we should be helpful to those who are minorities in tech' (of
course we should), rather, that one would be subjected to wicked well-
intentioned-but-ultimately-maligned discriminatory policies.

\+ For example, boycotting / refusing to attend 'speaking engagements that
require 50/50 female/male representation in micro cultures that are in fact
heavily skewed in one direction - this is in fact discriminatory. I'm not
going to boycott a conference because it's mostly dudes, or women, or whatever
group may constitute the majority of speakers/attendees.

\+ "Discipline or fire employees who abuse privilege". This is definitely a
dealbreaker, as in, 'run away from this company as fast as you can'. Consider
for a moment who is defining privilege, on what basis, and what might
constitute 'abuse' of such privilege?

Besides the fact that this is probably illegal, and surely immoral - it means
that you will be subject to disciplining and firing on the basis of your
perceived status as defined by race, gender, background, nationality,
immigration status? What else?

And who is making such assertions? By what standards? Are they clear? I'd dare
the author to articulate one instance of admonishing someone for 'abuse of
privilege' which is not in fact illegal.

This policy essentially promotes cult-like authoritarian behaviour on the part
of senior management, whereby they'll be empowered to promote, fire, denigrate
or support individuals on some arbitrary social basis that basically has
nothing to do with one's level of general professionalism, or work ethic.

A much simpler, more pragmatic, less ideological framework would actually help
the framers of this policy achieve basic goals.

And again, some 'micro cultural' issues in the article I think have merit,
outside the context of the aforementioned document.

Finally, I will say, that a lot of this 'decent management' is normalized in
other professions. I think perhaps what we might be talking a lot about
companies which are really just 'a bunch of guys who just finished school' \-
who may not even have had a lot of mentorship or professional experience
themselves. Combined with the longer hours, stress ... maybe it makes for a
more toxic work environment wherein 'high five' behaviours are not common?

[1] [https://maleallies.com/wp-content/uploads/2015/01/Male-
Allie...](https://maleallies.com/wp-content/uploads/2015/01/Male-Allies-Bingo-
JAN-15-2015.pdf)

~~~
kristianc
> This policy essentially promotes cult-like authoritarian behaviour on the
> part of senior management, whereby they'll be empowered to promote, fire,
> denigrate or support individuals on some arbitrary social basis that
> basically has nothing to do with one's level of general professionalism, or
> work ethic.

Uh, I'd say this predates current practices by a good 50 years. Companies have
always done this.

~~~
sonnyblarney
Yes, having worked in 'cult like companies' I'm inclined to agree, though
maybe not so much 50 years, but 'since the dawn of time'.

But to codify one's arbitrary ideological assumptions, which are probably
illegal, is beyond pale.

They are asking for a major lawsuit.

------
externalreality
> Although no company is perfect, at CircleCI I’ve had opportunities to grow
> my career in an environment I enjoy.

Small gripe. Its funny how software developers think they have a career. Once
you leave a job you are basically an entry level programmer again. What I mean
is if you stay somewhere 5 years using one set of technologies, you'll find
that you are not qualified for the vast amount of open positions that use
other new (just came about in the last 5 years) technologies. You basically
have to start all over again or somehow find a team that is using the same set
of technologies (which is rare). You know (React now) wait until 5 years from
now when you try for a new job, there will be something else and your
experience won't count only your knowledge of the hot new thing.

At the new job, the culture will be white make dominated, if not age < 32
white male dominated. So a career in software == a job in software that gets
reset every time you change jobs, and there is no escaping white male
domination because software is based is often blind trust and the ones with
the highest probability of getting that are white males (It may be hard to
swallow but it is true).

As for mentor ship, the culture of most places dictate that the most
experienced mentor who that like. Females are usually excluded from this group
and made to handle the bug list and given minor tasks. After 15 years they may
be put in a position of leadership so that the company can save face (if the
female employee sticks around for that long).

~~~
aiisjustanif
No offense but you sound like someone who got burned.

> Once you leave a job you are basically an entry level programmer again. What
> I mean is if you stay somewhere 5 years using on set of technologies, you'll
> find that you are not qualified for the vast amount of open positions that
> use other technologies.

I doubt this is true for your average Java/Python/C# developer or even a
powershell person.

> At the new job, the culture will be white make dominated, if not age < 32
> white male dominated.

What does this have to do with anything related to the first point?

> As for mentor ship, the culture of most places dictate that the most
> experienced mentor who that like. Females are usually excluded from this
> group and made to handle the bug list and given minor tasks.

This is still true at some companies, but I think it is changing far and wide
in the US. I've met some amazingly gifted female developers, some terrible.
I've met amazing male devs and terrible ones too. When we become blind to that
bias and we have a good diversity on a team, I find teams become pretty cool
to be apart of, especially when we have a mindset of mentoring.

~~~
externalreality
>No offense but you sound like someone who got burned.

No offense taken. If I didn't get burned (I guessed "burned" means to have
observed this first hand countless times over 15 years in the industry), then
how would I know it to be true?

> I doubt this is true for your average Java/Python/C# developer or even a
> powershell person.

You can know Java, but if the team is using mongo and you don't know mongo,
then there is a problem - if you know java and mongo - but there is a react
front-end, then there is a problem... get my drift. The industry is going with
a "experience doesn't count - you have to know what I know or be good at
faking it" kind of theme. It very prevalent.

> What does this have to do with anything related to the first point?

I has to do with the article. Did you read it?

> This is still true at some companies, but I think it is changing...

"Changing" isn't good enough. Think about something horrible , anything, would
you want it to be "changing", or would you want it changed?

~~~
aiisjustanif
As a minority, I guess I'll just have to agree to disagree.

