Ochronus online

Staying motivated while growing

2017-02-24T00:00:00Z

For those unfamiliar with classic fairy tales, in Goldilocks, a little girl visited the home of a family of three bears, and tried each of their meals, chairs and beds. She choose the options most comfortable for her, in terms of taste, size and softness.

In cognitive science and developmental psychology, the Goldilocks effect or principle refers to an infant’s preference to attend to events which are neither too simple nor too complex according to their current representation of the world.

Human beings both love and need challenges, but there’s an optimal level of difficulty in them for us to be able to be both motivated and be growing at the same time.

Imagine you’re playing chess. If your opponent is a five-year-old kid you’ll quickly become bored as the match is way too easy, you’re not learning anything from it. On the other end of the spectrum if you play against Garry Kasparov you’ll be demotivated for another reason: there’s simply no way you can win and probably again won’t learn anything as the match will be over before you even begin to comprehend your opponent’s moves.

Compare the above with the experience you have when you’re playing against someone who’s closer to your current level — now you have a chance to win but you need to work really hard. Your focus is at the right place, all distractions fade and you’re soon in the flow. You are making progress and you’re most probably learning along the way. The challenge is optimal — ‘just manageable’. Sometimes you lose, sometimes you win but that’s not the point. Tasks like these — according to scientific research — are the ones most likely to keep us motivated and growing for the long term.

The key to progress is the temptation of constant challenge, with tasks that remain both achievable and interesting, broken up into pieces of work that are just right. As Orville Gilbert Brim, a social psychologist put it:

One of the important sources of human happiness is working on tasks at a suitable level of difficulty, neither too hard nor too easy.

It’s our task as managers to ensure our engineers are getting such tasks. We both need to help define them and grow our engineers to be more self-aware and conscious in defining such tasks themselves and also learn and teach how to break down seemingly impossible projects into smaller, achievable pieces. This differs from person to person and it’s one of the beauties and challenges of personal coaching. One guide could be setting S.M.A.R.T. goals but we don’t need to stick to a single framework.

The other very important aspect is constant measurement and feedback on your progress. Being in the moment of making progress is incredibly motivating but for this you need instant/quick feedback. In chess you get this by winning/losing the match or even by seeing the expression of concern on your opponent’s face when you make a critical move. In software development this measurement and feedback can be manifold, ranging from a few good words from colleagues through a nice bump in a graph on a dashboard to a green build. The important part is to have relevant measurement and feedback loop set up.

Long story short, one of the keys for staying motivated and growing is this two-factor strategy:

Follow the Goldilocks principle and set goals/tasks which are both stretching and achievable
Have measurement and if possible instant, frequent feedback on your progress

Engineering managers, stop coding!

2017-02-24T08:39:54Z

So you became an engineering manager from a senior engineer. Congratulations and welcome to possibly the hardest change in your career. Everything is going to change — the way you defined yourself so far, your evaluation, your goals, the length of your work’s feedback loop. Now you start learning again, this time not the next tech stack or framework but something completely different. You’ll learn about people, their motivations, their pains, their unique perception of the world. You’ll learn some politics for sure, whether you like it or not. You’ll learn how to be there for others, how to be a servant leader. From time to time, you will fail. You’ll get tired in ways you never imagined before. You’ll get frustrated about the long feedback loops your work has. There will be days when you’ll want to get back to coding, you’ll want it bad.

Let me restate all the above: engineering management is not the natural advancement of an engineer’s career path: it’s an alternative track. It does help (a lot) to become senior engineers first, mostly due to the experience you gain during that journey about meta-topics in engineering and it also helps your communication as a manager with your engineers, but engineering management is something entirely different.

From the fact that you became an EM, I assume the following:

you love to teach others
you get more excited about the fact that you can help someone else to grow in ways they couldn’t even imagine than from the next new shiny technology
you care a lot about the place you work at and you want to make it better and/or help it adapt to changes on the organization level
you have no problem staying in the background, not taking praise but giving praise and taking blame for your team
most importantly you have deep empathy towards others’ and you care about the people you’re working with

Now, you will get tempted from time to time to keep on coding in your team. This can spring from any combination of the following (or others):

This is how you define yourself. You code.
You get frustrated with your role and you want to go back to your comfort zone even if only for a little while
You are afraid that if you don’t do it your knowledge will fade away and maybe your engineers won’t respect you anymore
You’re concerned about your team’s velocity
You’re an awesome coder, you not writing code would be a waste of talent

Let me give you a few reasons why you should stop right now.

It will kill/stall your growth as a manager. You should focus all of your free energy on learning how to be an awesome people manager or organizational developer.
You helping out the team gives false support and a false sense of security / velocity. This is not sustainable, you will need to work on organization level projects as well and maybe you’ll need to scale yourself up to managing multiple teams. If the team is thin without you, hire that new engineer.
You’ll have a sub-par performance in both roles because of the context switches.

Try this instead: every time you feel the urge to write code, instead spend the time reading or learning something related to management. Everyone who manages people will have favorite books, blogs, or speakers so just ask a peer or two for some material to get started. Heck, I’ll even recommend an awesome book right now — The three levels of leadership

Kill your heroes

2019-06-04T00:00:00Z

The project is 3 months late, you can feel the pressure from upper management building up on you and your team. What to do? Well, work harder, right? Sounds reasonable, hm? Would it work though?
Probably not. Unless the problem actually IS that people aren't working as expected, working harder will most likely result in two things: you and your team failing to understand how you work (especially planning and estimation) and the birth of a deadly caste: the Hero Engineer. Later, as your heroes slowly bleed themselves out you'll be left with three hard problems:

You've created a caste of burnt-out heroes
You and your heroes have alienated most of your other engineers on the team and possibly stalled their growth
The project is most probably still screwed

premature clarification / intent

This post might look like some kind of propaganda against hero engineers. It is not. It is against the concept, but it's not the engineers' fault if they get into this situation - it's yours, dear manager. You create them and you have all the means and tools to prevent such situations from happening.

wait but why?

Let's see things from the soon-to-be-hero's point of view.
You walk in the office on a Monday and your manager suddenly invites you to a quick meeting. He really needs you to finish your current project but he also wants you to finish your colleague's project. Well, help, at least. But do it in a way that the colleague is not hurt. He owns the project, after all. You'll be just doing it. Come on, be a good teammate, we need to be delivering, you understand that, right? You're a good guy, you also have expertise with the other project, so sure, why not.
A few weeks later your manager catches you at the water cooler and asks you if you've seen the user bug reports about the heisenbug in the login page. He expresses deep trust in your abilities and asks you to look into the bug. But of course the original two projects are priority. But please fix the bug because it's important. Sounds like a good challenge, you also understand how bad the bug can be to users, so you agree.

Congrats, you're a hero engineer. It's been nice knowing you.

Most other engineers are actually happy that you're taking a lead on these projects and bugs, some might have been too hard to tackle for them, or they are simply swamped with their current projects. At least someone is doing it, right? Well, all is not well. Some other engineers are quietly getting more and more bitter because they are not sure anymore how to contribute or are they doing enough - are 10 hour workdays the new standard? Do others view them as slackers when they leave at 5 in the afternoon to pick up their kids? They are also feeling left out, now many critical system changes are being driven an approved by you and your hero friends off office hours and they feel they can't really contribute. You seem to be getting all the fame, too. Honestly, you start to feel that other engineers are not really pulling their weight. You're also not getting the recognition you think you deserve. How did it come to this?!

The camera moves back to the manager. He kind of likes the hero engineer, he feels he can rely on her, after all she just saved the day - again. See the vicious cycle forming?

You've created a monster, we could call them 'dividers' along the edges of calling certain engineers 'multipliers' - as they are negatively affecting their team, especially other engineers around them in the mid- and long run.

Something else is cooking, though, something similarly sinister. Since the hero saved the day it seems that planning and estimation were right after all, the team CAN deliver. The mere existence of a hero can overshadow planning mistakes thus hindering the team's capacity to learn.

umm, you surely aren't suggesting we should keep being late with the project, right?

Well, maybe that's how it's going to be in the end.
You can try other ways, such as reducing scope or asking for help from other teams (NOT overtime, but conscious, planned help), or if all else fails and the business' life does depend on this single project (quite unlikely) you can get the team in a room and ask them to a crunch - but if you choose this last resort be sure that you:

highlight that this is NOT the preferred way to work
make it a conscious team effort, not a deal in the shadows with a single engineer
compensate the team accordingly / make sure the team has a chance to rest (yes, I do mean extra days off)
do a retro/post mortem about the project and use the learning to get the next project right

what should you do if you already have a few heroes?

Some of them can still be converted back to regular engineers, but it's going to take lots of hand-holding.
Heroes usually either burn out and leave or will feel being put in a corner by you while regretting what they've suddenly lost compared to their hero lives.

You can try rehabilitating them, though. Be prepared that they might hate you for a while, but that's OK, it's your punishment for creating them in the first place :P

Excuse no. 13 - this is how I am

2019-10-06T00:00:00Z

“I know sometimes I'm not easy to deal with. It’s just the way I am.”

How often have you heard sentences like that? Or maybe in some other forms, like:
"You know I'm just a passionate person and I get carried away" or "You know I'm just an honest guy so I'll be blunt with you", etc.?

Well, it's just excuses. Even when wrapped in a sad story that helps you sympathize with the other person, like the result of a rough upbringing, it's just excuses. Ultimately we should own who we are.

"It's just the way I am" is self-limiting. Let me tell you why.

Limiting beliefs have more of a negative impact on your life than any other factor. They come from a variety of sources such as our own interpretation of the world around us, our culture and upbringing and past experiences (especially negative experiences). Our brain is built to learn and find patterns, but sometimes we learn things or find patterns that are inaccurate or are only true in a certain context but we keep applying them in different contexts. Many of these beliefs start like this:

I am / I am not. For example: I am an engineer (so I won't ever be good at arts)
I can't / I must / I mustn't. "I cannot dance". "I mustn't let others see me vulnerable".
Others are / this world is. "This world is a cruel place (so I need to be tough)". "Others only care about themselves (so why should I care about them)"

The way most of these beliefs work is that they prune our perceived set of options in certain situations. Since I'm a bad dancer I won't even try to get into situations in which I could improve that skill. While I might not consciously avoid dancing I'll just naturally look for other ways to spend my time.

Our society is not set up to encourage or even support change in people after we grow up.

For one there's this general understanding in people's minds that (after a certain age) we can't change. From experience, I can tell you this is far from the truth. While change is not easy, especially changes to our self-image but it's still all very possible. It depends on our willingness to change which is why statements like above are quite dangerous as they can engrave this false idea of change being impossible and undermine our openness while being a kind of a comforting 'fallback' when facing criticism or feedback.

There's also this 'romantic' notion of "just accept me the way I am" in our society. It shows up in how we picture friendship, relationships and even work situations. You can be seen as a bad friend or lover if you don't accept your peers just as they are. I think the key lies in the term 'accepting'. Accepting should not mean being 100% happy with something! I can accept the fact that there are still wars in the world and still dislike it. I can accept that I'm not easy to deal with and I get emotional fast in heated debates and still work on changing it for the better.

So next time if your gut reaction to someone telling you to chill is "well you know I'm like this" - stop, think and evaluate if their claim is valid or not regardless of what beliefs you hold about yourself. Then you can think about figuring out the kind of person you want to be and work your way there. Thinking we're static and that our personalities an habits are set in stone is a limiting belief itself.

Read more about this topic in my other post called the stories we tell ourselves

The basics of one-on-ones

2020-02-07T00:00:00Z

Conducting good 1:1 sessions is one of the most frustrating skills new engineering leads need to learn. It’s frustrating for many because this is one of the leadership areas where you don’t have a step-by-step guide, it takes a fairly long time to form a good 1:1 structure with each peer and by nature it’s dynamic – very different conversations will be necessary in different scenarios. My goal with this post is to write about my experience and my personal best practices that worked for me on both sides of this relationship – as an engineer and as an engineering manager. I’ll also mention some common pitfalls to avoid.

The purpose of one-on-one sessions

1:1s have many purposes, such as:

Building trust and rapport between you and your direct report
Depending on the efficiency of communication in the company, it’s a great time to discuss important changes, news, events AND get feedback on them. While you’ll do it with the whole team, 1:1s can have a different setting and your direct reports might be more open than in a group setting
Your direct reports getting feedback from you (e.g. it’s a bad idea in general (except for some rare cases) to give constructive criticism in a group setting). While hopefully you’re praising your peers in front of others, 1:1s are a great opportunity to repeat that praise, making it feel more personal
You getting feedback from your direct reports
Discussing your direct reports’ growth, setting goals and checkin in on them – while this might feel like reporting, 1:1s are actually a great fit for discussing personal goals
Showing that you care for your peers. Do ask them about their wellbeing in general. Show them you’re here to support them
Get aligned on topics such as (random examples, there are way more)
- Company / team goals, mission, vision
- Future of the team (hiring, etc.)
- Engineers’ role in the hiring loop
Onboarding check-in for new hires
Share your mindset, way of thinking and let your peers challenge it

What to avoid:

Status report 1:1s – it’s very easy to fall into this habit because it’s natural due to the relationship between you and it’s a great time filler. It won’t serve the purposes of the 1:1s and most status updates are topics for the whole team anyway, not two people behind closed doors.
Mostly you driving the session – try to get your direct reports into the habit of ‘owning’ the 1:1s. It’s not easy but you can get there, e.g. nudge them to come with topics prepared. You can remind them 1-2 days before the session.

Who ‘owns’ one-on-ones?

This is a tricky part – while the 1:1s are mainly for your direct reports you’re still accountable for making sure they get what they want (and need!) from it. What that means is that you’re not doing a great job here unless they feel it’s beneficial for them, that they can open up to you, ask help, give feedback, bring up sensitive problems. What makes the assessment really hard is that every person and situation is different (and chages over time!) – some peers will be naturally more open because of their nature and past experiences, others might need a lot of time to feel comfortable and trust you. The thing is, in all cases it’s your responsibility to do everything you can to make 1:1s a good experience for your direct reports. I admit it’s really hard or even impossible in some cases. Be prepared to fail a lot. Ask for feedback. Talk to other managers about it. Ask for advice. Use your own experience from ‘the other side of the table’.

What to avoid:

Blaming it on your direct reports – it might be nobody’s fault if someone won’t open up – or it might be yours. Don’t blame it on the other person who “didn’t even want to be there”. Remember, it’s primarily your job to make it work.
Skipping “cringy” 1:1s – from time to time these sessions can get “weird”, you won’t feel much progress but keep having them, keep trying different approaches, different topics, different formats (meeting room vs. cafe vs. walking 1:1s vs lunch together, etc.)
Skipping the rapport building part of 1:1s – it’s easy to fall into the routine of a rigid, quick check-in with no real content and no trust-building, especially with peers you have a hard time getting close to. This is almost as if you’re not having the 1:1 in the first place. Prepare, bring different topics to the table, try, try, try.

Timing of one-on-ones

I’ve seen and tried different varieties of length and cadence of 1:1s, the common thing in all is predictable regularity. Currently I’m blocking a 1 hour session with all my engineers each week – same time & place for each. Your schedule might not allow such a setup, my advice is to prefer frequency over length (but of course a 1 minute checkin is not a 1:1), mainly because it supports building rapport and it gives you more flexibility – it’s better to skip a weekly 1:1 and still meet after 2 weeks than skipping a biweekly one and meeting after a month. Treat the blocked time as dynamic – it’s fine to finish earlier (sometimes much earlier) if you have nothing more to talk about.

What to avoid:

Regularly missing your 1:1s – it’s OK to skip or move around a few of these sessions but make sure you do your best to make it predictable and regular for your direct reports. If you don’t, you risk being seen as reliable and people might feel you’re not there when they need you.
Filling out the time just for the sake of keeping the length of the 1:1 – it’s perfectly fine to finish after 15 minutes. If you don’t have more topics (be sure to double-check though!) just let it go. It is to be expected anyway if you’re meeting frequently.

A list of random example topics for the one-on-one sessions

in no particular order

Feedback for the manager
Feedback for the direct report
Setting personal developmental goals
Checking in on progress towards goals and the validity/priority of the goals (do they still make sense?)
Highlighting opportunities to progress towards goals (e.g. “someone needs to figure out whether we should go with PostgreSQL or MySQL – does it sound interesting to you?”)
News from upper management (even if only reiterating on them)
Feedback/opinion on the news/changes from the previous topic
“Are you happy here? What could we do to make you happier?”
“What are the biggest roadblocks for you / for the team?”
“Does the company’s vision make sense to you?”
“What would you like to change in our 1:1s?”
“Is the company / your team / your role supporting you in reaching your goals?”
Hiring plans for the team / for the company / for the stack
“What do you think of how person X acted in that certain situation? Do you understand their reasons? If you didn’t like that, have you given them feedback?”
“How can I help you?”
“How do you think we are in terms of tech debt? Do you feel you are getting enough time / support to deal with it?
“You’ve been paged a lot lately, are you getting enough rest? Feel free to stay home tomorrow. Do we need to change anything in our on-call structure?”
“We’ll be starting a new project in about a month – I think you’d do a great job leading it, what do you think?”

Well, that’s it for an introduction to the topic, stay tuned to more specific tips and tricks in follow-up articles.

Questions vs. directions

2020-04-22T00:00:00Z

Asking questions is a basic coaching technique but doing it properly is a matter of practice, finding a good balance and avoiding some common pitfalls. As with most of the things in life.

Why not just give directions?

During coaching discussions such as 1:1s managers are many times tempted to just tell their engineers the One True Way of doing things. I invite you to ask guiding and challenging questions instead, for the following reasons:

well, you might be just plain wrong about your solution idea ;)
giving the answer is not coaching, it's optimizing for resolution time instead of the growth of your engineer
giving the answer can many times feel like giving direction, which is not the style usually preferred by engineers
good questions demonstrate care for the other party's opinion
good questions can clarify the situation thus showing a path forward
good questions nurture a relationship based on ownership, autonomy and respect

You mentioned balance

Yup. As with most of the things in life, balance is the key. One common pitfall of this technique is overusing it - sometimes people actually do need directions. How do you know if that's the case? Well, have you tried asking them? ;) I'm not kidding. Sometimes you can feel that the other person needs answers, directions, but many times you won't - asking them about the best way you can help is usually the right course of action.

Ask the question and then shut up!

Another common pitfall is asking questions and not giving space for the other person to actually answer them. This can happen for multiple reasons:

Silence can grow awkward

Silence makes us uncomfortable, so we try to fill it with chatter. Instead, after asking the question take a deep breath and/or explicitly say you'll give them a moment to think about the answer.

You fear they don't know the answer

You might be right, but it's good to surface that - after all this is a coaching session, not an interview! If this is the case depending on the situation and your goals you might want to try more guided questions or even giving some directions. Be super clear that it's completely OK not to have an answer!

Am I performing well?

It's quite usual for managers to feel less confident about their execution of this technique when they face some silence. This often results in a quick reiteration of the question, some monologue about context, effectively taking away the space from the other person to answer. Instead, if the silence grows really long, ask them to paraphrase what they've heard you asking them.

Open and closed questions

There are two kinds of questions: open and closed ones. Closed questions require a binary or a very short, usually factual answer. "Are you hungry?" yes or no. "Do you feel the board's decision to cut back on hiring was justified?" Yes or no. Open questsions spark thinking and conversations. "How do you feel about the board's decision to cut back on hiring?". Open questions usually begin with why, what, how, or describe, tell me.

As a rule of thumb in coaching you should use open questions. The reason is that they inspire actual thinking instead of gut reactions, they don't limit the coachee's answer range and they show way more that you actually care about their thoughts, ideas and opinions. They also spark conversations which lead to smooth discussion flows instead of a question-answer back and forth.

Leading or loaded questions

There's a sneaky type of questions - when a limiting assumption is already loaded in the question, either because you unconsciously believe that assumption to be true or because you deliberately want to guide the coachee in a certain direction. "How late do you think the project will be?" vs. "How is the project doing in terms of timeline?". While it's still valid to answer "It won't be late at all" to the first question, many coachees will feel that they need to treat the assumption of the project being late as a fact. Use this type of questions very sparingly - sometimes you do need them to strike a good balance of coaching and effectiveness, but be aware that it can limit your coachee and can come across as hidden directions.

By now I hope you got the basic idea about this coaching technique - please share your experience in comments!

Learning at work is work

2020-05-07T00:00:00Z

Nowadays there are hardly any companies who aren't trying to assess candidates' willingness and ability to learn. Nearly everyone agrees that constant learning and having a growth mindset are fundamental to success in software engineering. Albert Einstein is reported to have stated, “Once you stop learning, you start dying” and this definitely seems true in our trade, there's so much change on multiple levels: new programming languages, frameworks and tools pop up like mushrooms after rain.

Yet once you're done with onboarding at your new job as a software engineer the rat race seems to begin, leaving no dedicated time for learning. True, in many cases the best way to learn is by doing, but that usually lacks structure and strategy and a sense of progress.

Why isn't learning happening?

First of all learning is complicated. Doing it right highly depends on your personality and requires a topic-specific setup and structure. Some things are best learnt by just doing it repeatedly, some things need a top-down, hierarchically built set of materials, some require a constant back and forth between these two modes. Some people learn best alone, some progress best with a mentor who stays close. Certain topics need longer chunks of focused time, some can be mastered in a series of 10 minute breaks between two work sessions.

Most importantly in the majority of cases learning requires a commitment from both parties which means support from the company (plus your team and your manager). Moral support is hardly enough. It's not enough to say 'we trust you can learn this, do your best'.

For most of the engineers immediate success is defined by team goals (sprint goals / project goals) and personal goals. This means that if you only talk about learning the next card on the board will be more appealing to your engineers. They might even feel they're cheating on their team and they are being selfish if they use work hours for learning. When annual reviews happen they aren't talking about the books they read but the projects that they contributed to (and even though learning might support the next project, the immediate need feels to be the current one).

What can we do then?

As a manager supporting your engineers is a huge part of your job. In this particular topic support has many forms and aspects:

Encouragement and empowering - clearly communicate that learning in topic X, Y and Z are officially supported (or even expected!)
Create space and time. One thing can work particularly well: if you're using some kind of work-tracking tool (JIRA, etc.) make sure that learning tasks/cards are represented there. This does two important things: it makes it official and it can inspire others in the team to do the same. Make learning a goal. Think of having dedicated learning days even (which has the nice opportunity to turn into a team event such as a mini hackathon from time to time).
Create structure for that specific learning area or topic. Work with your engineer to figure out what clicks, what works best for them AND the topic at hand. Is it reading a book about it? Is it creating a pet project? Is it fixing a handful of cherry-picked bugs from the team backlog? Is it an online course? Any combination of the above? This relies on your experience, the engineer's experience and some trial-and error.
Think about mentorship as a potential setup here - which is a mutually beneficial relationship: it can tremendously boost learning and can grow the impact scope of the mentor. There are additional benefits such as creating connections across team boundaries and helping with knowledge distribution within engineering.
Regularly follow up with your engineers - do they feel their learning is going well? How is their progress? How can you (or others) help them?
Think meta - learning hard skills is usually trivial and is the low hanging fruit. Picking up a new language or framework? Easy. We kind of know how to learn that, we've seen tons of examples. Well then, how to learn debugging the best? How about incident response? How about leading meetings? How about architectural planning? These are not so trivial but depending on the level and interest of your engineers can be the biggest blockers in the growth and career. Think ahead of time and set them up for success.
Make sure that checking in on learning goals (called development goals officially) are part of your review cycles.

Celebrate learning. You don't need to overhype it, of course, but some public praise is always a moral booster and a good feedback.
Reduce pressure on your team - get realistic with estimation and deadlines (this is a longer topic in itself) to make sure you have time for learning and it doesn't feel like 'learning vs. delivering'.
This might sound trivial - make sure you have a budget to spend on learning. Books, courses, conferences cost money, don't expect your engineers to pay for those - at least chip in. Put your money where your mouth is.
Help form communities around learning some longer topics within your company. Think book clubs extended.

As a closing remark I'd like to emphasize that making sure learning happens is your responsibility, too, dear manager. It's not enough to say you encourage it, demonstrate it with relevant actions. Don't expect people to magically grow without proper support. The amount and kind of support heavily depends on the situation, but it's always required.

Thoughts on giving feedback

2020-05-19T00:00:00Z

A good, blameless feedback culture is essential for working together efficiently as it forms healthy relationships, fuels personal and professional growth and aligns us with common norms. Feedback is one of the cornerstones of company culture.

All that said I've found that giving good feedback is quite problematic for most of the people (me included!). There's a social stigma to giving so-called constructive feedback (see, even the name is somewhat of a euphemism), we feel we're expected to be nice to each other and surely telling someone they were wrong is not nice. We also tend to be way too simple and not specific when giving praise - no, a simple 'well done' is usually not considered as useful feedback.

Let me share with you a few key points about giving useful feedback. I promise it's all easy and trivial, you just need to consciously practice it.

The how

One of the most important things is getting buy-in for providing feedback. That gives back some of the control to the recipient and helps in having a more open mindset compared to unsolicited feedback. Simply ask if the other party is open to talk about the certain topics. Give some context so they can decide. E.g. "May I share some thoughts about the daily standup we had today?"
Be objective and be specific. These support each other, generalization tends to lead to giving feedback on perceived character traits which is a huge anti-pattern ("You always commit bad code.").
There are a few feedback models out there, what worked the best for me is the SBI (Situation - Behavior - Impact) model. This helps in giving enough context and specificity and being objective. An example: "During the standup today you didn't mention you were blocked in your work and by this we missed our chance to deploy today, resulting in a delay in delivery."

Don't use the feedback sandwich technique (starting with a compliment, then negative feedback, then an optional compliment again). Unfortunately it's still something certain coaches suggest - my advice is that it's not OK. There's a reason some call it sh*t sandwich. It shows that you're not confident in your communication and gives mixed signals, practically killing the actionability of your feedback.
Don't include suggestions in your feedback! That's the next step, but it's not part of the feedback. It's very easy to slip into this anti-pattern: "Why didn't you just use library X? That would make so much sense". First, this is not feedback, this is question, second it's not objective but you're talking about your opinion, not the other person's behavior and its effect.
Follow the SBI model even for praises! We tend to oversimplify positive feedback. A pat on the shoulder, a thumbs-up or a 'nice job!' has its place and value but the point of positive feedback is more than just recognition: it's also to make the other person understand what exactly went well in what context and how to repeat that in the future. It's much nicer to hear "By helping me out with data about the costs during my presentation yesterday we successfully convinced the board to fund our roadmap, thank you for that!" vs. "Thx for the help!"
It's even better to focus on data than behavior (if you can).
Always leave room for the other party to express their thoughts on the matter and even disagree. You can facilitate this by asking how they feel about the issue.
Make sure to agree on a course of actions together. It's not enough to drop your feedback and leave. You can help guide this process but the ownership lies with the recipient of the feedback (and yes, they can choose not to take action but they should be clear about that and their reasons). Ask guiding questions like "What are our action items here?" or "How can we make sure next time you feel safe to talk about your blockers during standup?".
Remember I said don't generalize? Well if it's a positive feedback it can actually help and encourage if you talk about patterns in the recipient's behavior. "I've noticed that you give awesome presentations lately, for example this last time about Kubernetes...."
It's completely OK to talk about your feelings in the situation you're describing, just make sure you're explicit about them being feelings and not facts. "When you interrupted me during my presentation last Tuesday I felt really disrespected and undervalued" (v.s. "You don't respect me").

The when

Timely feedback is key. Give feedback as soon as you can - hopefully the same day the event that you're giving feedback about happened. Why? First, both of you still have the context fresh in your minds, second, this way a mental connection is formed between action and reaction.
Unless you have good experience in it don't give instant feedback. Make sure you give yourself some breathing space and time to consider how you want to deliver your message. This is especially true for emotionally loaded situations.
As a rule of thumb praise publicly and criticize privately. Of course it's completely OK to repeat praise in a private setting and rephrase/clarify it.

Finally, giving good feedback is as much about forming the habit as skills. Make sure you practice it, I guarantee you can find good occasions almost each day if you look closely.

The 101 of effective goal setting

2020-07-02T09:39:54Z

I'd like to talk a bit about goals, their importance, some concepts and techniques for individuals (Team/group goals are a different topic).

Performance vs. developmental goals

There are basically two kinds of goals in a work setting - performance goals and developmental, a.k.a. growth goals. The key difference in theory is that performance goals focus on end results while developmental goals are learning & growth oriented. In reality most companies use performance goals in a very narrow way, e.g. to incentivize the sales team. This created a bad rap for performance goals and a shift in terminology.

I am strongly biased in favor of developmental goals for software engineers. The reason is that I find that most engineers are highly motivated to grow and are also intrinsically motivated to perform in their roles and are just fine without "the boss" telling them how to perform. In fact, after working with cca. 200 engineers I'm yet to find a single one who doesn't want to perform well in their job.

Helping your engineers with good growth goals and coaching / mentorship can add a lot of value for them, though. It helps them focus, since there's always just too many things to learn next, it helps them feel they're progressing, it helps with the alignment with the company's expectations of their career - which is ideally what the market wants already - and last but not least it makes them feel they're at the right company. I find that growth opportunities are just as important to engineers as an exciting product to work on, great colleagues, good company culture and of course, fair compensation. I had engineers leave solely because they felt they're not growing anymore.

There are some rate situations in which performance goals do make sense. One I can think of is when there's already a gap between your expectations and the engineer's performance. Closing that gap might require very narrow, outcome-focused goals, but note that this should only be temporary (until closing the gap or deciding to part ways). An example for a place for performance goals is a PiP (Personal Improvement Plan).

I'd also like to have an argument against 'by default' performance goals. Setting performance goals will feel like micromanagement and mistrust for your engineers. General expectations should be set by the leveling system you hopefully have in place, your company and team culture and your shared values. If none of these inspire and define good performance, then you have a problem there. Setting individual or team performance goals is a band-aid solution.

Your HR department might try to push you towards setting performance goals for your engineers for multiple reasons:

They don't deeply understand each department's field
They want a uniform process and set of training materials across the company
They want an easy way to decide on promotions and compensation

My advice is to be proactive about this, reach out to them and make sure you give context about why you believe performance goals don't fit your department.

OKRs, KPIs and SMART goals, oh my

OKRs (Objectives and Key Results) and KPIs (Key Performance Indicators) are two frameworks and concepts for goal setting

There are a plenty of articles about this topic, some very confusing. There's also a false dichotomy floating around. No, it's not an either-or situation.

OKRs

The best way to describe this framework is with this 'formula':

I will (Objective) as measured by (this set of Key Results).

You start out with high level Objectives which might be hard or impossible to measure by themselves then you come up with multiple Key Results. Key Results are like milestones but they don't align on a linear timeline necessarily. They might or might not build/depend on each other.

Objectives are memorable qualitative descriptions of what you want to achieve. Objectives should be short, inspirational and engaging. An Objective should motivate and challenge the individual.

Key Results are a set of metrics/milestones that measure your progress towards the Objective. By definition the success of each key result needs to be easy do decide. It's also OK not to achieve all of the key results! There's usually not a 1-1 mapping between objectives and a set of key results.

Let's see an example: you want to get better at programming in Go. An idea for an objective would be "I want to get confident at Go programming". A set of potential Key Results could be:

Write a CLI tool for updating our JIRA board
Write a REST API service for X
Convert my old Go project to use go modules
Study and deeply understand the following pieces of the standard library: [...]

You can get a sense. I find this framework really helpful for breaking down vague high level "things I want" to actionable and measurable smaller pieces.

You might have seen company/department level OKRs which probably looked different, the reason for that is those usually have numbers as targets in their key results. Some of them are KPIs!

KPIs

This is not a goal setting method! This is just a way to structure measuring things, usually performance, usually on the company/departmental level. E.g. for engineering you could have some of these KPI candidates: number of deployments per day, MTTR (Mean Time To Recovery), Cycle time. On a company level some examples are burn rate, profit margin, NPS (Net Promoter Score).

The most important thing about KPIs is which differentiates them from any other metric/indicator is that they measure the most important aspects of performance. You can have many supporting metrics but KPIs should be few and represent the performance

In a developmental goal scenario KPIs sometimes come in handy, mostly for making sure we focus on the real important things and not some vanity metrics. KPI targets are nice Key Result candidates sometimes. Such an example would be an engineer who wants to improve in code quality identifying e.g. mean pull request back-and-forth cycles as a KPI and then setting a target for it as a Key Result.

SMART goals

This is another framework that can be combined with others. This talks about how an ideal goal should look like:

Specific (simple, sensible, significant).
Measurable (meaningful, motivating).
Achievable (agreed, attainable).
Relevant (reasonable, realistic and resourced, results-based).
Time bound (time-based, time limited, time/cost limited, timely, time-sensitive).

The OKR framework guarantees some of these but this is still good guidance.

Consider the previous example: "I want to get confident at Go programming". Is this a SMART goal? Well... it's not specific, it's vaguely measurable (very subjective), probably Achievable, probably Relevant and not time bound.

You could wrangle a bit with making it a SMART goal but I found that some things (the personal and motivating aspect especially) can get lost in that effort. I grew to prefer OKRs over religiously SMART goals.

Again, this is another aspect to take into account and good guidance in general.

Not clinging to goals

Now we got to the most important discussion about goals.

Your engineers set the most amazing developmental goals, so full of energy, motivation, ready to take on the world - then life happened. Should they feel bad? Should you be disappointed as their manager?

Hell no. Of course it's not nice when someone constantly ditches their goals but goals reflect an intent AND a life situation. Both can change. People might find out that Go is not their thing after all and jump to Rust instead. Did they fail their goal? Of course not. Hell, COVID might happen and people end up cramped together with flatmates or family, not really feeling energetic enough to keep learning. They might not be doing super well in work/life balance.

I might do a separate posts about the buddhist concept of non-attachment and stoicism to give some more perspective here. The bottom line is that goals in general work best if you don't cling to them but use them as north stars and proxies.

How can you support your engineers in setting and achieving goals?

First and foremost by being supportive, not demanding (see the previous section).

Depending on the level and experience of the individuals you might need to be more suggestive, using your own past experience to come up with good goal ideas.

Make sure they understand it's for them and you're not there to dictate goals, merely to support them.

Understand that you're not always the best person to help them in reaching their goals! There's a difference between coaching and mentoring and maybe already coaching is better done by someone else in specific areas. Remember, you're there to support, not to dictate! If you feel someone else is better suited to help in a specific area, connect them!

Make sure they have enough actual support for achieving their goals, such as time and mentorship during working hours! I actually have a post about it: Learning at work is work

I hope this article was useful for some of you out there, most things are trivial here, no great revelations but I sure could have used it a few years back :)

On COVID, burnout, teams and self-care

2020-08-19T00:00:00Z

Burnout

Burnout is simply much more likely to happen in the current situation. Most believe that the primary cause of burnout is workload, but that's not always the case. For most, burnout is caused by a lack of connection to their work. These times are challenging our connection and sense of impact. Communication became non-trivial and sometimes flaky and this underlies many things. We lost much of the default micro-feedback we get when working in the same room. This manifests as disengagement, feeling undervalued or that you're not working on something meaningful. Broken communication can also result in feeling you can't be open with colleagues and managers and must bottle everything up. We sometimes lose our sense of identity and become reactive.

Burnout impacts self-awareness. When you are burnt out it becomes quite hard to tell if you are burnt out. No one is immune to this: CEOs, VPs, managers, individual contributors are prone to it.

What worked so far may not work now. We all have varying approaches to self-care with varying degrees of efficacy. The person who "just barely held it together" pre-covid may be pushed over their limit.

Some are experiencing a deep sense of guilt, especially in tech. They have a job while others do not any more. It feels trivial to complain when others are suffering so much. Grin and bear. This is a recipe for burnout.

Coping with all this as a people manager

You need to talk about it - out in the open.

People will interpret company goals and situations in very different ways. Some engineers will fear really adverse impacts if a goal is missed. Others will assume their manager and their organization will obviously understand, it is a pandemic, right? You need to be open about expectations and your (and the organization's) support in this situation. Don't assume people would know.

This situation is highly complex. Don't assume you can consider everything.

COVID already has massive impacts on job and housing markets, childcare, vacation habits and how people socialize. It is impossible to piece this all together in the middle of this whirlwind. Your colleagues (and you!) are caught in this swirl of "what ifs". You will be surprised and shocked. Keep the dialog and your mind open. It's OK if you didn't think of something. You never know what is going on at someone's home. The colleague with a great salary may be paying their whole family’s bills now. The whole family may be out of work. As always it is easy and dangerous to jump to conclusions. There are all kinds of potential "cascades" that can spring up. Stressing on how great it was to hit a recent goal may set in motion a cascade of additional guilt, burnout and attrition.

People will have different views on this

Don't expect that everyone has the same view on the situation. You’ll have colleagues who see this as a "ruined summer". Others will see the unraveling of democracy, or other kinds of life-defining, tragic moments. Some interpret distancing and lockdown a life-as-normal but with a mask, some others as "I haven’t left the house in 150 days". People had and have varied experiences, from "I don’t know what to do with all this time suddenly" to parents feeling "I had five minutes to take a shower two days ago". You have to listen and respect. Your view is only one view.

Showing vulnerability goes a long way!

We as leaders want to set a good example and be "strong and supportive". Thus we don’t necessarily share just how messed up things are at home (or at work, for that matter). This can have adverse effects. Your colleagues will wonder... "is it just me?" - "How come they are holding it together so well?". You obviously don't need to turn your 1:1s into therapy sessions but try showing that you're in this together and it's OK to be affected by the situation. This is one of the foundations of building trust and not specific to COVID but is exponentially important now.

Care and self-care are extremely important now

Some people respond to this current situation like: "I am going to grin and bear it for now, work my ass off and when this clears I’ll take a well deserved break." A tempting recipe for burnout. It may not clear up. This is true for you, too! It's your job to make sure your team is OK. Your usual management feedback loops can break down. Burnout is tricky. It suddenly creeps up on people and once it hits can take weeks or months to unwind. This challenges normal "sense and respond" techniques or efforts to "balance the energy". Don't put off self-care or things that give you strength. People are delaying important life decisions until "when this clears up." which contributes to a sense of suspended reality and time. This impacts "present thinking" by putting the "brighter things" in the future.

The stories we tell ourselves

2020-09-17T00:00:00Z

We have a mechanism that can conceive unhappiness, difficulty changing habits, relationship problems, frustration, anger, and disappointment. We are usually not aware, but it's happening continuously and in all of us.

It’s us unconsciously telling stories to ourselves.

“We tell ourselves stories in order to live...We look for the sermon in the suicide, for the social or moral lesson in the murder of five. We interpret what we see, select the most workable of the multiple choices. We live entirely, especially if we are writers, by the imposition of a narrative line upon disparate images, by the "ideas" with which we have learned to freeze the shifting phantasmagoria which is our actual experience.”
-- Joan Didion, The White Album

A good story can entertain, motivate, teach valuable lessons, and solidify good habits.

A bad story can demotivate, cause frustration and anger, and curb our capability to be fully ourselves.

These stories are not necessarily false but usually, they don't tell the entire truth — just one perspective. Another person could look at the same situation and tell a very different story. Telling ourselves stories is natural — we all do it, all the time. There’s nothing inherently wrong with it. That said if we aren't aware of this happening, we won’t understand how they shape our mood, actions, happiness, and relationships.

An example of such a story:

The event: You submitted a pull request for review after half a day of work. Another engineer asked you to change half of your code and to increase your test coverage.

Your story: A nitpicking a**hole commented on every single thing I did in that pull request; I guess he has nothing better to do. I wish people stopped blocking me from making progress. Why are they always making game of me?!

The other engineer's story: Some terrible code almost went live today; thank god I checked that pull request! Why does it always have to be me to watch quality? It's so sad it's only important to me in this whole company...

A bystander's story: Whoa, that was some tense back-and-forth in the comments of that pull request. I wish people were just nicer to each other; we all want to do a good job at the end of the day, right?

Roots of these stories

The most common origins of these stories are cognitive biases, our self-image made by / combined with our limiting beliefs, and our fears.

Our self-image and limiting beliefs

Ultimately we all have an idea about what kind of a person we are. This idea subconsciously influences how we think, react, and make decisions. The image is usually closely tied to our fundamental values and worldview. Most of us want to be good persons in the end. What 'right' is is defined by these very values and core beliefs.
Our self-image influences the stories we tell ourselves because we're looking for ways to find justification in our day-to-day experience.

Thus this image can limit our perceived set of options and understanding of the world around us.

Related to the personas in the previous example:

I'm the guy who gets things done (might imply that I think others are slowpokes)
As a professional software engineer I am the sole guardian of quality in the company (might imply that I think others are careless or unprofessional)
I'm the kind of person who cares for others' feelings (might imply that I think others have lower EQ)

Of course these are simply bits and pieces of the whole image.

In all of the narratives above there are (hopefully unfounded) assumptions, lots of jumping to conclusions and unproductive, limiting language. In this particular situation, this locks the actors in the status quo, lowering the hope for change. It feels like a stalemate unless someone is willing to be more open.

By the way I've written a bit about this earlier in the post titled This is how I am

Our fears

Fear also changes the kind of stories you tell yourself. Living in fear means giving up agency, seeing yourself as a passive spectator or a victim. It means seeing yourself as being controlled by circumstances, the actions of others, or your own emotions. And once the story you tell yourself becomes the story of a victim, you will be more and more likely to think and behave like a victim.

Cognitive biases

A cognitive bias is a systematic pattern of deviation from norm or rationality in judgment.
They are basically 'shortcuts' our brains take so it can increase our mental efficiency by enabling us to make quick decisions without any conscious deliberation.
Cognitive biases impact us in many areas of life, including social situations, memory recall, what we believe, and our behavior.

Some relevant and common cognitive biases from the staggering list of more than 180:

Self-serving bias

Self-serving bias is our tendency to blame external forces when bad things happen and give ourselves credit when good things happen. Although it can mean evading personal responsibility for your actions, self-serving bias is a defense mechanism that protects your self-esteem. In the example above, this means that if your pull request gets thumbs up from everyone, you attribute that to you being a fantastic engineer. On the other hand, if you get three comments asking you to change things, you might see others as nitpickers or your environment to be non-supportive instead of realizing you might have some room for improvement.

Confirmation bias

Confirmation bias, also known as confirmatory bias or the "myside bias," is people's tendency to seek out information that supports something they already believe. This type of bias affects our critical thinking, causing people to remember the hits and forget the misses — a flaw in human reasoning. People will often cue into things that matter to them (the things that support their own beliefs) and dismiss those that don't. Think about the other engineer overly obsessed with test coverage.

Authority bias

The tendency to attribute greater weight and accuracy to an authority figure's opinion is at play here. Authority bias is the tendency to blindly follow or believe the instructions and views of a person in authority. We have a deeply rooted sense of duty to obey authority. How do you react when you get a comment on your pull request from a senior engineer you respect? How about if you get the same comment from a junior who just recently started at the company?

So what can we do about it?

Don't forget that we are the storytellers - we have full control over the stories we make up.
Everything starts with awareness.
Stories are part of the software of our brains. They influence how we act, what’s important, and what to do when something goes wrong. But every software program has bugs. Awareness is your first step towards debugging.

Stop from time to time and think about the possibility that the story you've just created is nothing more than a story. Consider alternative stories. Try telling the same story from other characters' side, think about what their narrative would look like.

Next time you find yourself in an upsetting situation, consider changing your story. Try this exercise:
Recognize and acknowledge any feelings of fear. Hint: you may need to look underneath your anger!
Ask yourself, what is it about this situation that is so upsetting? What do you believe to be "true" about it that feels threatening to you?
As pretty much anything else, fear can be tackled one step at a time. There are ways to re-learn to say what you mean and to do what you feel is right. The good news here is that self-reinforcement works both ways. Once you've practiced a bit and proven to yourself that it works (and that it's less complicated than you thought), it gets easier to continue doing it.

We also must allow ourselves to be wrong. If we want to get closer to objective truths, we have to be able and ready to admit we were wrong, especially in the face of new data. If we can’t admit defeat, it makes us less capable of making discoveries in this world. We can avoid biases by being aware of our belief systems, whether our belief is for a religion, a political ideology, a cultural worldview, etc.. Let's be open to disconfirmation, and allow ourselves to be wrong.

Self-compassion is an instrumental skill for reducing defensiveness and increasing your self-improvement motivation. It involves being kind and forgiving towards yourself, understanding that you are human and that other humans experience the same sort of experiences and failure and being able to identify uncomfortable thoughts without judging them.

“Who are we but the stories we tell ourselves, about ourselves, and believe?“
-- Scott Turow

Some fuel for further thoughts

How do you look like as a character in others' stories? Do you like that character? What can you do so that character goes through some positive development?

In case you want to read more about the topics in this article:

I highly recommend 'Games People Play' by Eric Berne from 1964 and it's sequel 'What Do You Say After You Say Hello?' from 1970. The book didn't age particularly well regarding some topics but the basic principle holds.
About cognitive bias: check out this beautiful visual map of cognitive biases or if you like textual data more browse the relevant Wikipedia article
The book 'Buddha’s Brain: The Practical Neuroscience of Happiness, Love, and Wisdom.' - I know, such clickbaity title, but trust me, this book is pure gold.

How to stop winning arguments

2020-09-26T00:00:00Z

I didn’t mess up the post’s title – I do mean you should stop winning arguments. This, of course, doesn’t mean you would start losing them – debates are not zero-sum games, and they are not fights either. We tend to turn them into rows, of course, when things get emotional, but that’s precisely the problem.

Arguments are also not goals, rather tools to achieve them – and those goals ideally should be to have better diversity of ideas, to get to alignment and test our assumptions. All this should take us to a much better place than we would be without debate.

This is easier said than done – our brains play some pretty sly tricks on us, many times without us being aware of what’s happening.

Common logical fallacies in arguments

Once you’ve decided you’d like to have productive arguments you need to identify the typical signs and forms of bad arguments, which, in most cases fall into the category of logical fallacies.

A logical fallacy is an error in reasoning common enough to earn its own fancy name. Knowing how to spot and identify these is an invaluable skill. It can save you time, money, relationships and personal dignity. We’ll focus on the so-called informal fallacies – issues with the content and not the form of your arguments. Wikipedia has a massive list of these, and I’ll only talk about a few frequent ones.

Bulverism

Bulverism is the logical fallacy of assuming without discussion that a person is wrong and then distracting his or her attention from this (the only real issue) by explaining how that person became so silly, usually associating it to a psychological condition. The fallacy deals with secondary questions about ideas rather than the primary one, thus avoiding the basic question or evading the issues raised by trains of reasoning. It is essentially dodging your opponent’s argument by treating them like a psychiatry patient who needs your evaluation to explain why they came up with such a ridiculous argument in the first place.

Person A: “We should re-examine gender-roles in American society, because there may be more beneficial paradigms.”
Person B: “Feminists have brainwashed you; You need to stop listening to people who want to ruin America.”

The fallacy was coined by C.S. Lewis in his essay, First and Second things.

Ad hominem

When people think of arguments, often their first thought is of shouting matches full of personal attacks. Ironically, personal attacks run contrary to rational arguments. In logic and rhetoric, a personal attack is called an ad hominem. Ad hominem is Latin for “against the man.” Instead of advancing good sound reasoning, an ad hominem replaces logical argumentation with attack-language unrelated to the truth of the matter.

More specifically, the ad hominem is a fallacy of relevance where someone rejects or criticises another person’s view based on personal characteristics, background, physical appearance, or other features irrelevant to the argument at issue.

This fallacy is so common that it even has sub-classes describing the multiple ways we aim to attack each other in debates.

Circumstantial ad hominem occurs when someone attacks a claim by saying that the person making the claim is only making it because it’s in his/her interest or because of his/her circumstances. This actually has no bearing on whether or not the claim is true or false. “You only want more women in the engineering team because you are a woman.”
Tu quoque a.k.a. “the appeal to hypocrisy”: Tu quouqe means “you also”. It is claiming the argument is flawed by pointing out that the one making the argument is not acting consistently with the claims of the argument. “Stop telling me sugar is bad for my health; you eat cookies all the time.”
Guilt by association: When the person making the argument is viewed negatively because of its association with another person or group who is already viewed negatively. “Well, you know who else supported civil rights so fiercely? Communists!”
Abusive ad hominem: Attacking the person making the argument, rather than the statement itself, when the attack on the person is utterly irrelevant to the statement the person is making. “I think that you’re stupid and that nobody cares about your opinion.”
Tone policing: Tone policing is an attack that focuses on how someone makes an argument, rather than on the argument itself. “Okay, okay, no need to get so emotional over these things.”
The credentials fallacy is about stating that the person who made that argument doesn’t have sufficient credentials in the field being discussed, while those credentials are not necessary for the argument. “Why are you writing an article about logical fallacies, you’re not a philosophy professor… ;)”
Poisoning the well is a rhetorical technique where someone presents irrelevant negative information about their opponent, with the goal of discrediting their opponent’s arguments. Poisoning the well is a term referring to Medieval attacks on Jewish communities. Without evidence, people would accuse Jewish people of poisoning the town well when there was sickness in the city. This was used as an excuse to attack Jewish people and consider anything they were associated with as a tainted or evil. “You’re a known liar, why should we listen to you?!”
Argumentum ergo decedo, also known as the traitorous critic fallacy, is telling a person who criticised something that they should stay away from the subject of their criticism if they disapprove of the current situation. “Well if you don’t like how we test our code here you can always find another company.”

Straw man Argument

It’s much easier to defeat your opponent’s argument when it’s made of straw. The straw man argument is aptly named after a harmless, lifeless, scarecrow. In the strawman argument, someone attacks a position the opponent doesn’t really hold. Instead of contending with the actual argument, he or she attacks the equivalent of a lifeless bundle of straw, an easily defeated effigy, which the opponent never intended upon defending anyway.

The basic structure of the argument consists of Person A making a claim, Person B creating a distorted version of the claim (the “straw man”), and then Person B attacking this distorted version in order to refute Person A’s original assertion.

Person A: Evolution explains how animals developed, adapted and diversified over millions of years.

Person B: If we evolved from monkeys, why are there still monkeys? And why don’t we have three arms? Wouldn’t that give me a competitive advantage?

Argumentum ad ignorantiam – appeal to ignorance

This fallacy occurs when you argue that your conclusion must be true because there is no evidence against it. This fallacy wrongly shifts the burden of proof away from the one making the claim. Here the ignorance represents “a lack of contrary evidence”.

Common subclasses:

Absence of evidence: “There’s no evidence of bugs in my code, so it must be bug-free”
False positives / false negatives: “I wore red socks and we won the baseball game. My red socks helped win the game.” – “I’ll stop taking antibiotics, I’ve taken them since yesterday and I’m not cured yet.”
Evidence of absence: “All Python code is fast, I’ve never written slow Python code in my life.”

False dichotomy or false dilemma

A limited number of options are incorrectly presented as being mutually exclusive to one another or as being the only options that exist, in a situation where that isn’t the case. For example, a false dilemma occurs in a situation where someone says that we must choose between options A or B, without mentioning that option C also exists.

“You’re either with us, or against us.”

Many times it’s paired with other ad hominem, e.g. poisoning the well or guilt by association:

“If you don’t support the complete rewrite of this service you don’t care about quality”

There are subtle versions too, such as:

“Censorship laws are not tools for suppressing the population, but rather for preventing crime.”

Slippery slope fallacy

When a relatively insignificant first event is suggested to lead to a more significant event, which in turn leads to a more significant event, and so on, until some ultimate, significant event is reached, where the connection of each event is not only unwarranted but with each step it becomes more and more improbable. Many events are usually present in this fallacy, but only two are actually required — usually connected by “the next thing you know…”

“Come on; we can’t support flexible working hours! First, people will show up later and later, leave early then sooner or later, no work will get done!”

“If we legalize pot, then that will lead to every drug in the world becoming legal”

Hasty generalisation

Also known as overgeneralization, this fallacy is drawing a conclusion based on a small sample size, rather than looking at statistics that are much more in line with the typical or average situation.

“My father smoked four packs of cigarettes a day since age fourteen and lived until age sixty-nine. Therefore, smoking really can’t be that bad for you.”

Hasty generalization may be the most common logical fallacy because there’s no single agreed-upon measure for “sufficient” evidence.

There are many many more of such fallacies – the point is that it’s terribly easy to fall into such traps, some people even learned to consciously or automatically use the above fallacies as “techniques” to win arguments – you might be one of them! I, for sure have done this many times, guilty as charged. Wait, did I just overgeneralize? ;)

There are ways to mitigate or at least control such behaviours and fallacies, such as following strict debate formats or having an unbiased, experienced moderator but ultimately real change only happens when we stop wanting to win arguments. An easy way to start is to think back and honestly re-evaluate your arguments once your mind cooled down a bit. Do a “retrospective” of your debates and try to identify your emotions and potential fallacies. If you get into this habit, over time the time window in which you’re able to do this shortens. With some practice, you’ll be able to do this near real-time. The key here is identifying your emotions as they tend to take over control – something called the “amygdala hijack”. Read more of it here: https://www.healthline.com/health/stress/amygdala-hijack.

Techniques to stop amygdala hijack:

Reasoning. This means you use your frontal lobes to think the situation through, review the possible options, and choose the most rational and logical way to respond.
Meditation. By relaxing your body and mind through meditation or deep breathing, you can change your brain’s focus from responding to a threat or stress to inner peace and calmness. This is not immediate mitigation but rather a practice you can get into that has long-term benefits.

The stories we tell to ourselves also condition us for certain behaviours (and in return how we act in arguments can re-enforce those stories, forming a vicious cycle). I’ve written a separate article about the topic: https://ochronus.online/stories-we-tell-ourselves/.

If you identify a fallacy in your reasoning during an argument or you catch yourself acting from an elevated emotional state of mind don’t be afraid to admit it! It might feel like losing face, but it’s actually winning back your already lost face. It’s completely okay to say “Well, I didn’t mean what I just said. I was simply afraid of losing this debate, sorry. Let me cool down and rephrase.” – this shows maturity and good intentions and it can only make your relationships stronger.

The famous Paul Graham proposed a “disagreement hierarchy” in a 2008 essay “How to Disagree“, putting types of argument into a seven-point hierarchy and observing that “If moving up the disagreement hierarchy makes people less mean, that will make most of them happier.” Graham also suggested that the hierarchy can be thought of as a pyramid, as the highest forms of disagreement are rarer.

My invitation is to stop looking at arguments as battles you should win. Instead focus on having constructive, open and selfless debates with the goals of getting to better understanding, diversifying your options and ideas and striving for alignment. This is a bit of general life advice. Still, it’s especially useful in software engineering where most of what we do is a team effort, and the best way to make the most of the collective mind we have is to have healthy, progressive and calm arguments. Think of the last technological decision you were a part of – how did discussions about it go? Could something be improved?

The four dangerous animals of product development

2020-10-23T00:00:00Z

This is going to be a short walk in the product development zoo, I hope you’ll enjoy the ride!

Caveat: what you’ll read about are (usually) not personality types but behaviors in a specific (type of) situation. Acting like a HIPPO, a WOLF, a RHINO or a ZEBRA doesn’t make anyone a bad person. You’re still a team, aim to understand where they are coming from, and, well, they might even be right, with the wrong communication style.

The HIPPO – the Highest Paid Person’s Opinion

It can be tempting to give in to the HIPPOs – founders or CEO or VPS who want to make all the decisions – but don’t let them steer you off course.

Bring everything back to your vision and objectives. If the HIPPOs aren’t aligned with those, you could be headed for dangerous waters.

Don’t let your HiPPO kill your ideas – inform them with data and make them a Data-driven HiPPO!

The WOLF – Working On the Latest Fire

The WOLF has a short attention span and a temptation to jump from one problem to the next. They tend to only enjoy fighting fires, This will disrupt your team’s focus and effectiveness, making you easy prey for your competitors.

Create a process for collecting feedback about problems, bugs and only consider these along with all other requests. Set up triaging and set clear priorities and a method for prioritization.

There’s a whole book on WOLF prioritization: The Phoenix Project

The RHINO – Really Here In Name Only

The RHINO is just there to collect a paycheck without contributing much to the team. They might not be actively impeding your decision-making, but they are not helping much either.

Having a clearly defined prioritization process can help ensure all your team members understand how decisions are made and give them the confidence to actively participate. Hopefully, in this process, everyone is empowered to have a say and it doesn’t turn into “Well our process is that the boss tells you what’s important” – which is exactly how you end up with a team of disillusioned RHINOs.

The ZEBRA – Zero Evidence But Really Arrogant

ZEBRAs think they know it all but rely on their instinct rather than any actual evidence. To stave off the ZEBRAs in your midst, make sure that you’ve got data to back up your decisions.

Come up with quick experiments you can run to test ideas and gather evidence. Push for a data-driven culture.

An interesting article for the HIPPO vs. the ZEBRA: In defense of the HIPPO ... fear the ZEBRA

And one extra…. the RHINO again! This time, Really High value New Opportunity

Usually, it’s a salesperson with an amazing value customer deal for an unplanned feature insisting re-allocating resources to build what’s required to win the deal. The results, sadly, are an ignored strategy and roadmap and resources allocated to serve a single customer.

There are two ways here:

1, Chase the RHINO away: Compare the opportunity cost and value and argue against signing the deal if you have customer insight supporting the roadmap.
2, Tame the RHINO: Adjust the roadmap if the opportunity includes features you already had planned for later in the year.

The top 11 technical interview myths

2020-11-07T00:00:00Z

There are tons of interview myths floating around about the technical hiring process, mostly because it’s usually a black box to candidates. The inherent stress, inexperienced interviewers, tiring challenges, and unresponsive companies are valid reasons for candidates to have a negative view of hiring. Some of these myths work against a good interview experience and the candidates’ chances to get hired, so I’d like to call them out and refute them.

About me

I’ve interviewed a few hundred software engineering candidates in the past 10+ years and designed hiring processes. I’ve been supporting software engineers for 6+ years, working with ~40 engineers as their engineering manager. My experience is limited to startups and mid-sized companies, so take everything you read here with that in mind.

Now let’s see the myths and misconceptions.

You can never be late.

Without question, do you best to be at your interview on time and plan things accordingly, but don’t worry, we know sh*it happens. If you can please let us know you’ll be late or you’d like to reschedule the interview, I promise you it’ll be fine. Nobody in their right mind would try to relate whether you were punctual or not on a single occasion to your future job performance.

Don’t do research ahead of time because the interviewer will tell you everything you need to know.

False, for two reasons. While your interviewer will do their best to give you all the information they think is essential for you, there’s no way of exactly knowing what that is! The other reason is that if you don’t know anything about the company and the role, you’ll seem like someone who doesn’t care where they work and what they do. You probably don’t want that. You don’t need to overdo it and spend hours looking up who the founders’ grandparents were. Just make sure you understand the company’s market, look at the product(s) we offer (if you have time and you’re interested, even try them - we all love feedback!), and read the job description.

They are looking for the perfect candidate.

No, we aren’t. We’re looking for a reasonably competent candidate with the right mindset who’s willing to take this journey of constant growth with us.

It’s not OK to send a follow-up email after my interview.

Sure it is! I even tell candidates explicitly to feel free to reach out to me if they have further questions or feedback! I really do value when folks reach out. I don’t mean “thank you” emails, but actual questions or feedback. Please, no brown-nosing, though - that’s really awkward for both of us and won’t get you anywhere.

They make candidates wait a lot so they can weigh them against each other.

Hell, no we don’t! One quality of a good hiring process is that it should be able to help us decide whether we want to hire that specific candidate independently of others or not. As a hiring manager, I always do the interviews with my mind being set on that if we’re a good match, an offer is going out (unless, of course, headcounts changed in the meantime, but then we communicate that). If you’re waiting too long for us to come back to you, please, by all means, ping us! We might have dropped the ball somewhere – maybe someone is out sick and didn’t have time to ask others to help out, or we simply forgot something. It happens and we’re sorry – don’t assume malice, ask us, please. We should be proactively telling you when you can expect to hear from us and about the next steps, by the way! We do our best to keep those promises.

Recruiters ghost me because I performed badly in the interview.

While I can’t speak on behalf of all recruiters, in my experience, this is not the case! It should not happen. Sure, mistakes happen (recruiters are, believe it or not, humans, too), but the norm is that you get a timely answer whatever the interview outcome was. If you’re not getting that, ping them. Or ping the hiring manager. Probably someone dropped the ball on something. It happens. Ideally, we should be telling you when to expect us to come back to you, so you can know if we’re late or you’re just impatient ;) - if you’re not getting that information from us, just ask at the end of the interview.

If my interviewer is having a bad day, I will probably fail the interview.

Hopefully not. Sure, we are all humans, and our mood influences how we think and act, but a well-designed hiring process should protect against this. Unless I’m actively malicious (and why would I be?! I WANT to hire engineers!), my bias will be called out by other interviewers in the same step or another step, and I’ll need to argue for not hiring you. Honestly, even a good scorecard (the thing we fill out with some standard, guiding questions after the interview) will make me realize I’m just in a bad mood and then I can deal with it. If you only meet 1-2 interviewers during your process, the risk of bias is much higher. While you have no control over who interviews you, you can take a hint from this. While the scene might not yet be 100% rosy, companies are trying their best to stay competitive in the job market, and more and more realize that structured, unbiased, and humane interviews are one key to this.

Smaller companies blindly copy FAANG hiring methods.

Facebook, Amazon, Apple, Netflix, Google have some (in)famous hiring methods. While some companies probably blindly copy those, most don’t. It’d be stupid. They play on a different field with different goals and have a much higher volume of candidate influx. One example is focusing on algorithm and data structure knowledge – most FAANG technical interviews test this. It probably makes sense for them while it doesn’t make much sense for most other companies. Not only that, but it can have a negative effect (other than scaring away good candidates) – being biased towards two kinds of applicants: engineers who are working a lot with algorithms and data structures and fresh graduates, who still have muscle memory of this.

Culture fit == we want people exactly like us.

When we say “cultural fit”, we mean “value/principle fit”. I try to say that, by default, but industry terms die hard. We’re looking for teammates who believe in most of the same basic principles as we do, that’s all. Some examples of these principles are (for us, here at Contentful): transparency, growth mindset, customer focus and teamwork. I can reason why these are important and how they also relate to job performance and how they lead to a happy and scalable organization. It’s not fluffy stuff.

My resume is really important.

Yes and no – yes, to get your foot in the door. It’s also a conversation starter but I’ll be interested in your stories instead when we talk. I look at resumes of candidates already in the loop only to find more information about them – things to talk about, to get some context. One thing about your resume though – it is also a piece of work from you, a signal for me. If it is seriously lacking in some aspect (eg it has serious spelling mistakes), I may see it as a sign of you not paying attention to your work’s quality or not asking for feedback (for someone to review it). By the way, there’s an excellent new book from Gergely Orosz in town about engineering resumes that can help you stand out to the next recruiter or hiring manager – The Tech Resume Inside Out. If you don’t have too much time for this, just update your LinkedIn profile (a good move anyway!) and export your CV from LinkedIn – it is going to be much better than if you try to put it together in one evening alone.

Telling the recruiter I’m also in the process elsewhere is a bad move.

You might think we’ll feel you’re not dedicated to us – but why would you be?! We just started talking 🙂 Nobody’s expecting you to focus on one company! On the other hand, if we really like you and you signal urgency we’ll have the chance to speed things up or even be more generous with our offer to convince you to join us 😉

Some truths about the technical interview

Your interviewer is also stressed and they want to do a good job.

Yup, after a few hundred interview sessions I still practice conversations in my head, I still worry I’ll make a bad impression and that I’ll mess things up. Many other people you will meet are doing much fewer interviews than me. I’m representing both myself and my company in each and every interview. I feel personally responsible for providing a good experience for you and I want you to remember the interview as “Well that was surprisingly good!”.

Not getting hired is not a failure.

Nobody in the hiring process will think of you like that! Trust me on this one. And yes, please do try again! The fact that you made it to the Nth step this time means that we see potential in you. If you reach out I’m more than happy to give tips and advice on where and how to grow.

We are matchmakers, not judges.

My goal is to find a good match between the role I’m hiring for and the candidate applying. This truly goes both ways. I do my best to make sure the candidate would be successful and happy if we hired them.

Read my article with tips on how to ace your technical interview

How many of the points above do you belive are true? Are you relieved after reading my points or do you think I'm just bullsh*tting? Did I miss anything? I'd love some feedback - hit me up on Twitter or just drop an email to blog@ochronus.online.

Acing your technical interview – a hiring manager’s guide

2020-11-12T00:00:00Z

Even though interviewing for a software engineering job can be intimidating and frustrating (with whiteboard exercises, remote coding challenges, and even full days of onsite interviews), it’s a lot easier when you know what to expect and are well-prepared.

I’ve interviewed a few hundred software engineering candidates in the past 10+ years and designed hiring processes. My experience is limited to startups and mid-sized companies, so take everything you read here with that in mind. My advice may not get you into Facebook or Google but will definitely increase your chances at mid-sized companies with a good culture!

In the first part of this article, I’ll give some context, then give you an actionable list to improve your experience and chances in your next interview

If you’re only interested in the actionable list, feel free to skip ahead to it.

What you think about the technical interview might be incomplete

First and foremost, a technical interview is almost never only technical. Up to a certain (and honestly, very useful!) level growing as a ‘coder’ is not that complicated. Many candidates perform pretty well if we purely look at their coding skills.

The thing is, you’ll rarely work alone in isolation on your own codebase. You’ll have teammates, you’ll need to agree on things with them, you’ll build on others’ code and others will build on your code. You’ll need to build solutions with a certain level of quality, in a future-proof way, for extensibility, and with performance in mind. Depending on your role and level, you’ll need to architect systems. You’ll need to mentor other engineers. You’ll need to onboard new team members. You’ll need to proactively reach out to other teams in the company and understand their points of view and problems. You’ll talk to product managers, UX researchers, designers, even customers sometimes. You’ll need to manage projects, make tradeoffs and decisions, and align other engineers with that.

Read my article on the most common 11 technical interview myths

Types and stages of technical interviews

Most companies use a combination of these steps:

Screening call with a recruiter – We’re interested in your basic motivations, we’d like to have a gut feeling about what you’re looking for and do some sanity check here. You might get asked about your salary requirements, support you need for visa or relocation, and timelines (when could you start, etc.). Some recruiters will also ask you whether you have applied elsewhere so they know how urgent this is for them and you.
Screening call with the hiring manager – Expect some deeper dive into your experience on multiple fronts – tech and ‘soft skills’ alike. As a hiring manager, I’ll prepare by checking out your CV for talking points, maybe even your LinkedIn profile, and definitely GitHub. I’m not trying to judge you, I’m just looking for points of connection. I’ll answer any questions you have about the role, the company, the culture, potential teams you’d be joining, etc. etc. My ultimate goal with this is twofold: would we be a good match for your (and vice versa) and whether I think you’d be successful in the role.
Remote technical screening – An alternative, or at some places precursor to the online coding exercise. This is with a human on the other end of the line – solving tech problems together, usually, you walk them through your solution.
Online coding exercises (LeetCode, HackerRank, etc.) – I know you all hate this. We need such a step to filter out people who can’t even code at all early on. You’d be surprised about the number of such applicants. I avoid algorithm/data structure exercises here and try to come up with somewhat interesting ones. Some companies use a much heavier set of exercises and base their judgment of your technical skills solely on this. While I don’t agree with that strategy, you need to get prepared for this, too.
Take-home assignment – this is one of the most polarizing interview steps for engineers. Some hate it, claiming it’s just free labor for the companies and it takes too much time, others love it because they feel they have the freedom of giving it much time, really showing off their skills in their own comfortable environment. Whichever camp you’re in, you can expect some companies requiring this. You usually get a somewhat specified problem to solve and you’re given different levels of freedom on how to solve it – some companies don’t mind you choosing whichever stack you like, others will even specify the framework.
Onsite workshop / remote workshop – I think this is the most interesting of all steps (well, for me at least). It’s about solving problems together with people from the company in a simulated environment. You’ll need to show your communication, decision-making, and even prioritization skills here. Sure, people will look at the quality of your code, too, but ‘soft skills’ are just as important here. We’ll get strong signals about how it would be having you on the team.

Cracking the technical interview

Ask the recruiter or the hiring manager before the interview

Take the guesswork out of the equation. If you feel you don’t have enough information to prepare, just ask for more! We’re here to help you succeed. I really mean it. Sometimes we aren’t doing a great job with sharing enough information proactively about the interview steps but that’s not intentional! I’m always happy to help you prepare better – ask about anything, please. You’re doing both of us a favor with that. Ask during the previous interview step or just drop me an email at any time.

Show up on time

Make sure you’re there on time. If you can’t, for some reason, please let us know, we’ll happily organize for another time, no hard feelings. Showing up on time isn’t only about respecting each other’s schedule – interview time slots are usually 100% utilized and by arriving 10 minutes late you’re reducing your own chance to be successful. You’re also making it more stressful for yourself than necessary. If you need time for commute or for your Zoom/Google Meet setup, think ahead and give yourself a buffer before the start.

Don't jump right into solution mode - read, distill, paraphrase

The biggest mistake you can do is thinking you understand the problem or what’s asked of you and jumping right into coding. Take your time, carefully read the problem statement, distill it, don’t think of solutions just yet. When you feel you understand what’s asked of you or when you thought about clarifying questions to ask, communicate. Paraphrase what you understood from the problem statement so you can verify it with your interviewers. Only when you’re on the same page can you shift into solution mode. Even if you come up with the best solution ultimately if you skip this step I’ll remember and have doubts about how it’d be to work with you. Thinking aloud is really useful here - it will help you and help me too to understand what's on your mind.

Be articulate and communicate clearly

Even if you know your trade, if you fail to communicate clearly during your interview we’ll have no way of knowing. This takes practice for most people, so take your time and prepare! Use standard terms that other engineers can relate to, avoid passive voice, and be able to articulate what’s going on in your mind while you’re thinking. If you need some time to think quietly, say so, don’t just fall silent suddenly. We’re trying our best to communicate our expectations around this but it might be a bit late when you’re in the interview. Trust me on this one, practice here goes a long way.

Ask clarifying questions

While you’d think the interview is about you answering questions, expect that you will need to ask a lot of questions! When you are in the interview and something is not clear don’t default to thinking “Oh god, I should know this, I should understand” – sometimes we are interested in how you behave in such situations, and sometimes we’re just simply not good enough in giving enough context. If you’re stuck, a good technique is to ask for clarification! It’s also 100% OK to say things like “I didn’t quite get that. Could you rephrase please?” or “I’m not sure I understand what you’re asking”. These are good signals! I expect my team members to behave like this. These are not signals of you failing. I know it feels like that, but trust me, it’s just your brain playing tricks on you. I highlight this during the interview several times, to make sure the candidate feels safe asking such questions. Another technique I wholeheartedly welcome is paraphrasing – e.g. “What I understood from what you said is that I should implement this using co-monads” (said nobody ever).

Demonstrate your tech skills the right way

Make us see that you’re deeply proficient in at least one technology. This can be a programming language, for example. Also, demonstrate that you know the adjacent technologies – most companies are looking for so-called T-shape engineers. This means that mentioning other aspects of the problem and the solution goes a long way. For example, if you’re asked to implement a service in NodeJS, mention how you’d deploy, monitor, and scale it, even if that’s not explicitly asked. No need to go into too many details (unless people ask you). If you’re only focused on a single piece of the puzzle I’ll have a hard time seeing how you’d perform well in a changing environment (where you’ll need to make connections and work on multiple zoom levels and be ready). This is a very generic statement and might not be true in the case of highly specialized roles, of course. On the other hand, if you say your primary language is Python yet you can’t seem to show even a basic understanding of it, that’s a no-no. Work on the stem of that T, too. Hopefully, you’ve clarified what you’d be doing on the interview upfront (see advice #1) so you can think about adjacent technologies in advance.

Don’t get too focused or stuck on a solution

Sometimes a solution you came up with just won’t work. No biggie – happens to us all the time too! Just state it and move on. Unstuck yourself. We’re way more interested in how you think about problems and solutions than whether you can come up with the exact right thing on the first try. We prefer failing early. It’s also completely fine to ask early on what we think about a specific solution, you’ll probably get good hints that way.

Demonstrate some interest in the role

The easiest way is to simply ask some meaningful questions. I’m sure you want to know a ton of things about the job! From the tech stack to who you’d be working with, what culture we have, how are processes, what your role actually means in practice, where the company’s headed, are we financially stable, etc. etc. – use your interviews to ask these questions! By this, you’re not only gaining knowledge but you’re also communicating that it actually matters to you where and how you work. A few examples: “What’s the biggest technical challenge for the company at the moment?”, “How do engineers interact with product managers here?”, “What do you dislike the most in working here?”.

Don’t talk badly of a stack or language

Somehow talking badly of languages became a norm on the internet. It’s not only uncool but also demonstrates a lack of deeper understanding and professionalism. We all have our loved and hated technologies but ultimately it’s about different tradeoffs and different tools for different jobs. You can turn your dislike about that piece of technology into a positive thing by objectively arguing why your favorite thing is better suited for the job. The same goes for the way you talk about your previous or current companies – while it’s fine to describe what’s wrong there, please keep it objective and professional. It does help me understand what’s important for you and trust me it can be done in a respectful fashion.

Practice with a friend

This will help you feel so much more confident in an interview and confidence makes a world of a difference! Practice multiple things – from coding to talking about code, speaking what’s on your mind, phrasing things in different ways. Get a friend who can give you feedback. Practice will also give you a good sense of how much time things take – your interview will be time-boxed.

If you get stuck

Don’t panic 🙂 It happens to all of us. Take a moment to think. Catch your breath — clear your head. It’s completely OK to present a partial solution or a differently scoped one. Feel free to ask for some help or pointers. Your interviewers are prepared for this and this doesn’t mean you’re failing. Just be honest that you’re a bit stuck, we’re there to help you! That’s what we’d do with a teammate too! Remember, we'd like to understand how it'd be to have you as a teammate. I'm sure you'd be fine asking for some help in a team, so just do it in your interview, too!

How to stand out in a technical interview and be a memorable candidate

In my experience the most memorable candidates are genuine. They are honest about what they are looking for, they are willing to talk honestly about their gaps, too. They demonstrate that they are not fixated on code only, they understand that solving problems is a complex endeavor on multiple levels. They understand how to work together with others, including other functions. They are life-long learners and can give examples of things they’ve recently learned and also reason about why they chose that specific topic.

Candidates really stand out when they can tell a story of their career – including where they want to be. Good candidates understand and can describe how the next role they want to land looks like. They demonstrate self-awareness. We humans can relate best to stories. Use that! Create a narrative.

Memorable candidates can tell stories about ownership. I don’t mean technical ownership only, but demonstrating end-to-end understanding and care. I know you aren’t a salesperson or a marketing specialist but you can still show that you understand how that last feature you’ve developed is important, how users/customers are using it.

Read my article on the most common 11 technical interview myths

Communication skills for successful software engineers

2020-11-19T00:00:00Z

Communication skills matter a lot in software development. We rarely work alone and the foundation of good teamwork is good communication. Feedback, sharing ideas and sharing knowledge are all based on solid communication skills. To be a successful software engineer in a team you need to express your thoughts in a clear way that’s easy to follow for others.

You need empathy so you can understand how to approach other people. Consciously using communication styles will help you later in your career.

Your communication skills are also very likely to be tested when you’re interviewing – for more on that, I recommend the relevant parts of my post on acing your technical interview.

Let’s see the nuances of all this broken down by each level. Keep in mind that companies will have different definitions for these levels and that these are ranges in reality. I’ll try to be as generic as I can without sacrificing relevance.

Every engineer

The ability to express your thoughts clearly is a must on every level. You will work in a team, and communicating with others is a significant part of your regular job. While you’ll mostly talk to other engineers, assuming a sizeable common vocabulary, you still need to be conscious about how easy your train of thought is to follow.

Empathy is also not optional. Empathy in communication means you can understand what emotions and state of mind others have in certain situations and consider those when communicating. One trivial example is merely waiting for a better time with your question about how the database schema migration goes when you see that the other person is in a very frustrating bug hunt elsewhere in the system. Another is adjusting your message when you’re giving feedback on a pull request, and you understand that the person making the changes is emotionally attached to their solution.

Active listening goes hand in hand with empathy – it keeps you engaged with your conversation partner positively. It is the process of listening attentively while someone else speaks, paraphrasing and reflecting on what is said, and withholding judgment and advice.

Some everyday situations in which your communication skills is essential to your success:

Effective dialogues on pull request reviews
Writing good documentation with the target audience and their (lack of) context in mind.
Giving feedback to others

Mid-level engineers

In addition to the above, more tenured software engineers will need to rely even more on communication to extend their scope of impact.

You will own complete user stories, sometimes even projects, and you’ll be responsible for coming up with plans in collaboration with the rest of the team, your Product Manager, and your Engineering Manager.

You will break down these projects into actionable steps and agree on them with your peers. You’ll need to add descriptions and acceptance criteria to these tasks so anyone can pick them up without much additional context.

Communication here starts shifting as you begin moving into technological and project leadership. Inclusive communication becomes the next milestone – that will be one new key factor in deciding whether you’re successful in your role or not. Whether you can lead a project with truly involving and empowering others will affect the project’s success and team culture and mood, too.

Senior engineers

For senior software engineers communicating on the next level becomes crucial to build out and maintain their network and influence over the organization. Stakeholders are of all kinds on this level, sometimes including CEOs and VPs.

On this level, you are expected to be successful in being the tech lead of a team that involves aligning engineers with your technological vision, being the primary point of contact for other teams, and being a strategic peer for your Product Manager and your Engineering Manager.

You will be forming tech visions, and you’ll need to communicate about those effectively.

To be successful, senior engineers need a wide network of peers across the organization – other senior engineers, managers, and people from different departments, such as customer success, sales, and marketing.

Staff engineers usually talk to VPs (Vice President of X) and sometimes C-level executives too.

Different kinds of stakeholders and peers require different approaches to getting your message through and understanding what’s important for them. Empathy alone is not enough anymore: you need to utilize various communication styles, too. A discussion about a topic needs technical depth when you’re talking to your engineering peers, and your VP will need a birds-eye-view of the same issue in the 30 minutes they can dedicate to listening to your proposal. Non-technical peers require different approaches with a different “language” and taxonomy. This article is a good summary of how situational awareness and communication relate to each other.

(Will Larson has a fantastic site for staff engineers (and their managers) which is a gold mine of useful articles: staffeng.com)

In a study, Peakon found that communication was the second thing most employees would like to change – right after salary.

7 harmful biases in performance reviews

2020-11-24T00:00:00Z

We are all prone to biases. We cannot help but evaluate and assess people and situations through the lens of our own prejudices. When it comes to performance reviews this can have a huge unwanted impact as it influences compensation, promotion decisions, and even firing.

When you give a performance review for a colleague, you’re very directly impacting their career trajectory. Even so, if you’re their manager. Given the weight of this kind of influence, it’s our responsibility to make sure the reviews are as fair and objective as possible.

Not all is lost, though. Once you’re aware of the existence of these biases and the way they work, you can utilize certain strategies (and a good amount of self-awareness) to minimize their effect.

Below, I break down the most common performance review biases and share advice on how to deal with them both as the giver and the recipient of performance reviews.

General advice for managers

One of the best ways to counter bias in reviews is to come up with a great review format that guides people and doesn’t magnify bias effects. Phrasing matters a lot. Setting the tone, being clear about the purpose and scope of the feedback form is key.

Another very important point is to understand that giving quality feedback takes time, a certain kind of focus, and is a considerable effort. Make sure you proactively prepare your engineers for the feedback season and plan for it – one thing that worked pretty well for me is to represent feedback tasks as cards on the team board and even set them as sprint goals. Nothing makes feedback quality deteriorate more than rushing and feeling that you don’t have enough time for it. You can organize feedback training, too, with our without your HR peers.

General advice for everyone

On the flip side of the above – expect that giving feedback is not a trivial task. Take your time, make sure you have a quiet corner, don’t do it in one go, take notes, work on your wording, look at email/slack/pull request history too and treat your peers as customers of your feedback.

My article on feedback might help in that.

Recency bias

Alice had a very strong year, she had great contributions to the projects her team was working on, achieved most of her goals, mastered a new language, and a framework. In the past month though, due to personal issues, she kept her involvement to the bare minimum. In his feedback to Alice, Bob highlights that he expects more from her and that she feels distant from the team. Bob completely fails to call out the amazing job Alice did earlier and the growth she had had.

Recency bias is when recent events weigh much more heavily in your performance review than older, possibly even more significant events. This is partly due to how our memory works and is a completely natural thing, yet its impact can be really bad and can bias your review in either direction depending on what people remember about you recently.

How to deal with recency bias

The best way is to collect feedback more frequently – for example, do a 360 each quarter even if you only have the performance review once a year. Project-level retrospectives can be helpful as well. Some managers keep ‘files’ on their engineers to counter this bias, but honestly, that can easily backfire – it can feel like a shady practice to their teams. Prefer transparent and open frequent feedback instead.

Some people find it useful to keep a personal achievement log, which helps with their self-assessment or calling out things missing from their feedback. If you feel there are important bits missing from the feedback you’ve been given, call those out. If your manager doesn’t encourage more frequent feedback you can still ask for informal ones from your peers at any time.

Similarity bias and Affinity bias

Alice and Bob graduated from the same university and are both huge Star Trek fans – they talk about it all the time, they get along really well and connect outside work, too. Bob’s feedback to Alice is always overly positive and he’s prone to overlooking seemingly obvious gaps in her performance.

We subconsciously tend to rate people similar to us higher. Similarity can mean many things – personality, looks, way of thinking, etc. Affinity bias occurs when we work with someone we feel we have an affinity with; maybe we attended the same college, we grew up in the same town, or they remind us of someone we know and like.

How to deal with similarity and affinity bias

A clear, and transparent performance evaluation system helps a lot here. Such a system is clear and well-understood level definitions, which can guide your focus while thinking about others’ performance. That said, levels are usually not public information in companies, so this won’t help too much with peer review.

Getting feedback from multiple peers can help mitigate the effect of this bias.

Halo effect and horn effect

Alice is really great at debugging and fixing notoriously tricky bugs others usually struggle with. Because of this, she saved the day multiple times. That said, she barely meets her level’s expectations if we look at the wider spectrum. Alice gets really positive feedback from her team highlighting how grateful they are for her being the ‘bug hunter’ and omitting any gaps she might have elsewhere.

Bob meets his level’s expectations in general and is great to work with. That said, he has the tendency to be impatient and cut discussions short because of that, which really hurts his ability to effectively work with others in these situations. Bob gets negative feedback highlighting that he should really work on his temper and communication – not mentioning any of the amazing work he’s done otherwise.

In the halo effect, a single positive event or attribute lifts your review up, and in the horn effect similarly a single negatively perceived action or trait ‘poisons’ your whole review.

This gets even worse if your manager is biased. A classic example of the manager having a halo bias is when they see one of their engineers as the “hero” or the “10x engineer”, being blind about any gaps they might have (btw. check out my older post about hero engineers). An example of a manager having the horn bias is when they stigmatize an engineer as e.g. “unreliable” or “not smart enough” based on a one-off event.

How to counter the halo or horn effects

You might ask “why would I want to counter the halo effect if it results in positive reviews about me?”. True, it might momentarily be even helpful for you, but not having a clear picture of your gaps ultimately does more damage than good to your career. It hinders your potential to grow and if you change teams, managers, or companies you might be suddenly underperforming and you won’t necessarily understand what happened.

To counter the effect of these biases you first need to understand what the main positive or negative thing is in your feedback and have a heart-to-heart about it with yourself. Again, a proper level definition system helps a lot. If you feel that people are generalizing a one-off negative event, ask them to provide more examples of that behavior. You can actually call out that you feel stigmatized by that single event or trait. If you can, highlight counterexamples.

Sometimes phrasing of rating scale points helps mitigate these biases, e.g. if you call the two extremes of the scales “consistently underperforming” and “top performer”.

Idiosyncratic rater bias

Bob is an engineering manager leading a mobile developer team. Bob has deep experience in project management but almost none in mobile development. Bob seems to consistently rate the development skills of his engineers much higher than they really are, while he rates the project management performance of the lead developer lower than it is.

Idiosyncratic rater bias happens when people evaluate skills they’re not good at, higher. Sometimes they rate others lower in things they’re great at. This is rooted in lower standards we have for things we don’t have deep knowledge about and higher standards for things we’re experienced at. In other words, our feedback reflects more on our own skills than the person’s we’re reviewing.

How to counter the idiosyncratic rater bias

To overcome this bias as a manager, try rephrasing your performance evaluation questions for yourself from a different perspective, e.g.:

If this engineer wanted to resign I would try to retain them.

I would want this engineer on my team at any time.

I would hire this engineer again at any time.

Research shows that people are much more accurate when rating their own intentions compared to rating other people.

Also, having a diverse set of feedback from peers can mitigate this (there’s a low probability for every reviewer to be biased the same way).

Centrality bias

Alice is the manager of a team. She hands in her annual performance evaluations, and you notice that almost everyone on her team scored near the middle of the scale. Now you wonder if that’s actually a realistic image or not.

Many managers don’t like being extreme and tend to be moderate in their reviews. When everyone is receiving a rating of 3 out of 5 across the board, there’s no distinguishing the low-performing and high-performing employees. This will result in unfair reviews and people being pissed by lack of recognition and that nothing happens to low performers.

How to counter the centrality bias

Well, an easy hack is to remove the middle of the rating scale, the ‘neutral’ option, e.g. have a scale of 4 instead of 5 to force managers to decide. If you received one of the ‘meh’ reviews, have a heart-to-heart with your manager and highlight where you disagree. For example, if you feel you’ve been doing better in a certain area ask for explicit examples of how you could do better and cross-check it with your data points. Rating on multiple skills and axes can help, too, compared to a single, unified rating.

Contrast bias

Alice is really good at project management. Bob is also great at it, but slightly less so than Alice. Their manager rates Bob low on project management because he cannot help comparing him to Alice. In reality, both are exceeding expectations on their level with regards to their project management skills.

Contrast bias occurs when the manager compares an employee’s performance to other employees instead of the company standard. When employees are ranked in comparison, someone must end up at the bottom, even if they are exceeding the company standard. The problem isn’t the employee – it’s the goal or standard that has been set.

How to counter the contrast bias

The review should have multiple axes and expectations should be clearly laid out in e.g. a leveling system. This doesn’t automatically protect against the contrast bias but it makes it harder to happen. What I’ve found useful as a manager is to separate each review I write with extra time and do something different in between – e.g. write the review for each engineer on separate days. If you feel you’ve been the victim of the contrast bias, always move to refer to the expectation definitions (e.g. leveling system). Point out to your manager how you think you’re meeting/exceeding specific expectations.

Confirmation bias

Alice, Bob’s manager thinks Bob is a great person to work with. They understand each other very well, communication has always been a real pleasure. Alice reads Bob’s peer feedback from Carol, which says Bob’s communication is not so great. Alice dismisses this information.

Alice also manages Carol, who she believes to be a bit too junior. Carol gets overly positive feedback, except for one which mentions an occasion when her pull request was just not up to a certain standard. Alice immediately confirms her belief that Carol has so much to work on.

Confirmation bias is the tendency to search for or interpret new information in a way that confirms our preexisting beliefs. We intrinsically find it easy to believe people who align with us on specific facts, beliefs, or stances. On the other hand, we’re likely to be skeptical of people who don’t agree with us. It can skew the interpretation of valuable performance data.

How to counter the confirmation bias

Turn this around! Look for information that goes against what you believe. Try to find data for it! If you read something that confirms what you already think, immediately check how many times others mention its opposite.

Fighting these biases is not trivial, but as professionals and especially as people managers we have to work hard to be fair, objective, and especially helpful in performance reviews. Knowing your biases will certainly help, but it’s only the first step – I invite you to think back to your latest review cycle and see if you’ve been biased.

There are a lot more biases than the ones listed above – Wikipedia has an amazing collection if you’re interested.

Gergely Orosz has a really spot-on article about this topic as well, I highly recommend reading it: Common Performance Review Biases: How to Spot and Counter Them

Kindness is a hidden software engineering superpower

2020-11-27T00:00:00Z

Sounds fuzzy and a bit bulls*itty, right? Well, it turns out that if your teammates are pricks, you tend to quit or stay and be unhappy and demotivated. This is not fluff; studies and surveys confirm this. We spend a lot of time in our work communities, and it’s vital to be surrounded by people who care, with whom we feel comfortable.

This does not depend on software engineering levels – it’s a universal trait. It’s also technically not a skill, yet there’s a surprising amount of practice involved in getting better at showing kindness. This is not just about having a positive attitude by default – but being genuinely kind to others.

Why is kindness important?
Besides leaders’ responsibility to create humane, caring environments for their teams there are well-understood business reasons, too:

In a 2013 article published in Harvard Business Review, Christine Porath said her work shows that teams that work in an environment where rudeness, bullying, demeaning comments, and insults are commonplace usually become fractured. People lose confidence, have low levels of trust, and become less helpful. Bad behavior, she adds, destroys collaboration, is harmful to mental health, and has been proven to be a significant barrier to efficiency.

Forbes argues that kindness is a competitive advantage. I hope it becomes the standard. In a study, Peakon found that their coworkers were the 4th item most employees would like to change – right after salary, communication, and management.

Kindness helps your peers feel safe, and if they feel safe people take the risks that enable efficient, honest communication and thus real collaboration.

What is kindness?

Kindness is showing interest in your peers’ wellbeing; this goes from simply asking them how their weekend went to remembering they had a hard time with something two weeks ago and following up on that. It’s really these simple, everyday things, but doing them consistently.

Kindness is understanding that we all struggle sometimes.

A form of kindness is when faced with a frustrating situation, we don’t assume malice. Instead, we assume good intentions and reach out to clarify.

One key to kindness is empathy – being able to relate to others, understanding how they feel. There are three kinds of empathy:

Cognitive empathy

Cognitive empathy is about thought as much as emotion. It is knowing, understanding, or comprehending on an intellectual level. Knowing how the other person feels and what they might be thinking. This is crucial, but often not enough since you still can be disconnected from or ignore deeper emotions; it doesn’t put you in another’s shoes in a felt sense. Understanding sadness is not the same thing as feeling sad.

Yet, without this, we can’t even talk about understanding others.

Emotional empathy

Emotional Empathy, just like it sounds, involves directly feeling the emotions that the other person is feeling. It is actually very “biological”, it’s deeply rooted in our so-called mirror neurons. Sometimes this helps the other person (“misery loves company”) but it can easily backfire if you yourself lack the ability to manage distressing emotions. It can really help in forming a connection, though – as it conveys the message “wow, this person really understands me and cares for me”. Just remember, put on your own oxygen mask before helping others.

Compassionate empathy

Compassionate Empathy strikes a powerful balance of the two other kinds above by relying on your emotional intelligence to effectively respond to the situation with a loving detachment.

It honors the natural connection by considering both the felt senses and intellectual situation of the person without losing yourself in the situation. Thus, it enables you to naturally act in the other person’s interest (vs. passively observing or losing yourself to distressing emotions).

Compassionate empathy is the kind that’s useful in most situations.

Remember that I said kindness doesn’t depend on levels? Well, there’s one nuance – the more your perceived power and authority shifts as you level up, the more aware you need to be to practice active kindness. Most people will get less engaged and even demotivated when working with someone cold in power. Another reason is that people look at you for leadership, and your behavior will get copied, so you’re responsible for leading by example.

Why is kindness not trivial?

The main reason is that we bring our personal fears, insecurities, expectations, and context to work. Interestingly, the more skilled your team is, the harder it can get!

We all have a unique background, and not everyone has the same experience that we have. It can be surprising when you encounter someone that hasn’t worked with the technology that you have (“What do you mean you don’t know what a monad is?”). We often forget that the job is not to show how smart we are.

We all have bad days in a bad mood. On days like this, it can take a lot of work for us to come across as kind persons (and it’s all right, you should also receive kindness).

Communication is hard, each message goes through multiple filters by the time it gets to the recipient. Such filters are your tone, body language, phrasing the recipient’s mental and emotional state, their expectations in the situation, cultural and social conditioning. We think we’ve said what we meant to say, but the message easily gets distorted by these filters, e.g. turning a neutral sentence into an attack (“Can I help you?” –> “I don’t trust you can do your job”).

Low hanging fruits of kindness for software engineers

Here is a list of things you can start with right now:

Be patient with career starters. Being a junior developer is very difficult. Provide them a safe space where they can fail and be instructed, with kindness, about how to prevent the mistake again. Proactively reach out and mentor them.
Do not mock someone for their chosen language or framework.
Show forgiveness when something breaks. Outages suck, but even if you can trace it back to a stupid human error, you can’t imagine how that person could have made it; remember that this just shows the system’s weakness and the processes around it. We all make mistakes. Please don’t make it personal.
Celebrate victories, even small ones.
Use inclusive language. You’ll be surprised how bad we are at this, intrinsically.
Learn about body language and understand your default modes there.
Manage your stress (know your limits, make sure you rest and recharge)
Be a compassionate code reviewer, not a critic.
Use humor. Then use some more. Good for you and good for your environment.
In frustrating situations, assume goodwill, not malice. See Hanlon’s razor.
Smile!
Thank people for their help publicly.

Ochronus online

Staying motivated while growing

Engineering managers, stop coding!

From the fact that you became an EM, I assume the following:

Now, you will get tempted from time to time to keep on coding in your team. This can spring from any combination of the following (or others):

Let me give you a few reasons why you should stop right now.

Kill your heroes

premature clarification / intent

wait but why?

umm, you surely aren't suggesting we should keep being late with the project, right?

what should you do if you already have a few heroes?

Excuse no. 13 - this is how I am

"It's just the way I am" is self-limiting. Let me tell you why.

Our society is not set up to encourage or even support change in people after we grow up.

The basics of one-on-ones

The purpose of one-on-one sessions

What to avoid:

Who ‘owns’ one-on-ones?

What to avoid:

Timing of one-on-ones

What to avoid:

A list of random example topics for the one-on-one sessions

Questions vs. directions

Why not just give directions?

You mentioned balance

Ask the question and then shut up!

Silence can grow awkward

You fear they don't know the answer

Am I performing well?

Open and closed questions

Leading or loaded questions

Learning at work is work

Why isn't learning happening?

What can we do then?

Thoughts on giving feedback

The how

The when

Top 12 questions you get as a hiring manager

The 101 of effective goal setting

Performance vs. developmental goals

OKRs, KPIs and SMART goals, oh my

OKRs

KPIs

SMART goals

Not clinging to goals

How can you support your engineers in setting and achieving goals?

On COVID, burnout, teams and self-care

Burnout

Coping with all this as a people manager

You need to talk about it - out in the open.

This situation is highly complex. Don't assume you can consider everything.

People will have different views on this

Showing vulnerability goes a long way!

Care and self-care are extremely important now

The stories we tell ourselves

An example of such a story:

Roots of these stories

Our self-image and limiting beliefs

Our fears

Cognitive biases

Self-serving bias

Confirmation bias

Authority bias

So what can we do about it?

Some fuel for further thoughts

In case you want to read more about the topics in this article:

How to stop winning arguments

Common logical fallacies in arguments

Bulverism

Ad hominem

Straw man Argument

Argumentum ad ignorantiam – appeal to ignorance

False dichotomy or false dilemma

Slippery slope fallacy

Hasty generalisation

Techniques to stop amygdala hijack:

The four dangerous animals of product development

The HIPPO – the Highest Paid Person’s Opinion

The WOLF – Working On the Latest Fire

The RHINO – Really Here In Name Only