Subscribe now

Not all fuckups are born equal

Some fuckups you want to prevent. I think when you ask your engineers for a list of “software engineering fallacies”, those are good candidates. For example, you might want to prevent stuff that causes permanent damage to user data or your company's reputation.

Some things are also enough to discourage via linters / guidelines.

But then, there is a big bucket of fuckups that can happen, and as long as they can be resolved quickly, they should happen on a regular basis.

The alternative is having an overly restrictive system and or process.

Effective learning

Learning by doing is well known to be effective. Combine that with a very specific goal to “fix it ASAP” and you have the perfect opportunity to understand how something works within a few hours.

Here is the scenario:

1. I change something

2. it gets released

3. something is very broken, seems to be related to what I did

4. I start checking, debug the hell out of it, trying to understand how it works

5. I find a solution and release it

6. 3 months later … someone has a similar issue

7. git blame / someone points them to me

8. they learn what I know while we fix it together

9. now we have 2 people who have some confidence when working in this area

This happens organically, at least sometimes. The issue isn’t that knowledge isn’t shared. It’s that risky actions are avoided in the first place.

Proficiency vs Tenure vs Productivity

In my experience companies are focused on proficiency and productivity, i.e. do you know what to do and do you know how to do that within our systems.

While having your onboarding strategy built around these goals is effective in the short run, there is a key element missing: tenure. Think CTO who happens to know the solution to all the most painful problems, because guess what, he’s dealt with them before.

Knowing how something works and why it was built this way, in the context of the team’s and product’s evolution is incredibly valuable. This is true when solving urgent issues but also when planning some of those fun mega refactors.

In a growing team, how do you speed up “spreading tenure”?

Encouraging Failure

The more complicated and brittle the system, the more people are scared to change it. Multiply that by how much of a pain making releases is and you’ve got a whole team that is overly conservative and doesn’t really know how anything works in practice.

On one side, of course you should make it easy to do releases. There are countless books and talks on CD / DevOps / Agile / whatever that attempt to help you do that, or at least sell their consulting services on the matter.

But beyond that, failures need to be normalized. If people see that fuckups are normal and can be resolved, together, quickly, then why would they be too frightened to make a change?

It’s like climbing. Once you experienced that the rope will hold and you know how not to smash into the wall, there shouldn’t be a crippling fear in you about climbing back up, right?

Engineering teams need badges for fuckups! For example:

• I broke the staging DB

• I broke the production DB

• I broke an integration

• I blocked “master”

• I fixed a blocker bug

• I reverted my change

• I fixed something before anyone noticed

• I messed up deployments somehow

• I deployed a hotfix

• I messed up the lockfile

• I messed up the release workflow

• I …… insert something that’s painful to do in your system or process

For companies, having this as part of an engineering culture should be a no-brainer:

• super useful for performance reviews

• a long term onboarding checklist

• a team that's not afraid to break things

• ...

• profit

In summary, the real MVPs on your team are the ones who keep breaking things, because they know the system better than anyone else. Why not encourage exactly that mindset with a hint of gamification and pageantry?

Neither extreme makes for a lot of growth, assuming you get the job of course. But to figure out which job would suit you, you have to figure out what sets them apart first.

To give a quick sample of what I mean, I grabbed a few Senior Software Engineer postings on LinkedIn, for jobs located in Czechia. I’ll highlight some of the things expected in each of these roles.

The jobs

pure storage

• 5 years exp

• working with others

  • strong communication skills

  • leadership

  • facilitation

  • technical writing

Microsoft

• working with others

  • mentor / teach

• testing

McKinsey

• 5 years

• team lead practically

• working with others

  • “communicate at all levels” ~ navigate politics, manage stakeholders and clients

  • can explain technical topics

• expert understanding of DDD

Siemens

• 5 years with that framework

• English

• they list growth mindset twice

Vista

• some OOP experience

• English

• working with others (pair programming, code reviews, communication skills) listed under nice to have

• cloud, REST, CI/CD knowledge also optional

EPAM

• comprehensive knowledge

• English

• discuss topics even before they become tasks

Make

• 5 years

• working with others

  • mentor

  • RFCs (write and review)

  • communication skills

• testing

What’s similar

• can work independently

• 5 years experience usually

What’s different

• automated testing

• range of skills required

• depth of knowledge required

• management skills required

• communication skills required

Sounds like a junior, doesn’t it?

Maybe to you it does. In two of these ads, Vista and Siemens set the bar quite low in comparison. They might be desperate, they might have the bandwidth to teach or the project simply might not require more.

Let’s go back to the key phrase: can work independently. (and productively is implied)

What that requires depends primarily on the size of the team working on the project and the way the company itself functions.

While in a team of 5 people working on a project, especially given some platform support, many engineers fresh out of university can meet the bar.

What do you consider a senior?

In a larger engineering team, the technical bar is usually set higher (to prevent breaking shit all the time), but more importantly, you need to collaborate to accomplish anything, assuming you don’t want to be chased with pitchforks by your colleagues.

Written and spoken communication skills become critical to get anything done! More code, more services, more features, more product terminology, more domains and soooooo many people.

Two big topics start to become requirements at some point

1. not delivering useless crap (agile, product management, UX design & research)

2. delivering fast in a large teams (microservices, CI/CD, DevOps, platform engineering…)

So what is your bar? Well, it’s likely set by the largest team you worked in. Note that it doesn’t really matter if there are 5000 engineers unless they work on the same product.

That’s what often makes agencies / consultancies / dev shops a bit odd to me. EPAM might have thousands of software engineers, but if you are pimped out to work on small projects, working with small engineering teams of the client, your growth will quickly plateau there.

While at Microsoft, there are projects with literally thousands of engineers working on a single product e.g. Windows.

That’s why collaboration skills are critical at Microsoft, while EPAM expects deeper technical knowledge and basically a command of English, no more no less.

How high does the bar go?

There are a few companies here that set the bar high in their own specific way.

Microsoft, due to the scale of the team, expects two things from seniors beyond technical aptitude:

• good communication skills

• eagerness to mentor / teach

In a large engineering organization, that hires lots of fresh graduates, this makes perfect sense.

McKinsey is going in a very different direction. They are a consulting company after all, so these things are more important:

• lead team

• deal with client

In client facing environments, self organized teams aren’t that popular, so here they are looking for a backend engineer who can handle the client and tell the team what to do. If this sounds a little “top-down” keep in mind that consultancies rely heavily on junior talent, so nothing to see here.

Now we’re getting to the fun stuff. Make and Pure Storage are product companies with already large engineering teams, but not the behemoths like Microsoft or Uber.

To be productive in their engineering team, they expect their Senior Engineers to:

• write and review RFCs, do other technical writing

• mentor

• leadership and or facilitation skills

One of them expects a bit more mentoring, the other wants more leadership aptitude. Both go far beyond technical skills when searching for their senior talent.

That sounds hard!

If that’s your first thought, I’d really encourage you to give such opportunities more thought. Not that I blame you. I also find myself exhausted sometimes reading a pile of responsibilities I just don't feel like having. Anyway, I thinks there plenty of benefit to working in such teams once you gather the energy, namely:

• good collaboration → more gets done → more fun

• bigger teams → more impressive projects

• bigger teams → higher / more complex skill requirements → smaller talent pool → much higher salaries!

• bigger challenge, less shortcuts

• more senior engineering roles available

If the first points leave you feeling “meh”, really think about that last one. I’ve written about career paths for engineers that minimize management recently. The problem is, most of those roles only exist in organizations with large enough teams and large enough projects.

TL:DR

Senior ≠ Senior. Pay close attention what you are applying for and whether it’s the right step for your growth.

You might even feel that it’s time to make the leap at this stage in your career.

First up, kudos for considering going into leadership. Capable leaders are always needed. If you’ve ever seen one, you know that they can really have a multiplying effect on an organizations performance.

Is your heart in the right place?

People go into leadership for all sorts of funny reasons. Thirst for power, greed, stupid salary range rules, boredom, prestige, ambition, protecting your team mates from meetings.

Then there is the money. A lot of us get lured into management thinking it’s the only way forward, maybe even told that this is the only way to justify a raise.

The truth is that there are a lot of companies out there that pay similar salaries on IC and management tracks, so there is no need to feel pressured in this regard.

If it’s money you are after, you should change the type of company you are working for (higher paying market and/or industry) instead of aiming for a more senior position within your current market.

It sounds funny, but you’d be surprised how many people find themselves in middle management for no other reason than having been put there by their bosses, often with a bit of pressure around money.

Roles aside, leadership is about influence. The question is, what would you like to have influence on?

1. that the projects you work in run smoothly

2. that the people you work with are happy and motivated

If you know how you’d like to use your influence, and you accept that your individual contributions become secondary, you are already far more prepared for the switch to a leadership position than most first time leaders are.

Which type of management role?

Although all leadership roles have both people and project components, there is usually a clear focus area.

For example, a lead engineer might mentor a lot of engineers, spend time on developer experience, interview candidates… but the main responsibility is to take ownership of a domain within a project and get that thing shipped!

An Engineering Manager often spends time planning feature delivery, doing code reviews, dealing with all the urgent stuff… but the most important thing is the health and growth of the team.

In the end, the parts of the role you can’t delegate are what you should to be interested in. Long story short: if you dread having 1on1s with a dozen people each week, don’t become an EM and if your communication skills are lacking, don’t try to be a tech lead just yet.

Can I try this stuff without all this pressure?

The short answer is yes. the longer answer is - it depends on whether your organization functions based on something called positional leadership i.e. Bob is in charge, because we said so when we hired him, and all decision-making and leadership of any kind defaults to him on the team.

If your influence however depends on your… well … influence, then you can take charge of a project, do your thing, work together with people to get the job done, and then take a break before you take on your next initiative.

Ideally, this means that people actually care about the initiatives they are leading and aren’t “weighed down” by the constant responsibilities that often come with a management title.

So what can you actually do without the title? Taking the example of a senior engineer, you can already:

• mentor people

• interview candidates

• lead initiatives / projects / peer groups

• be a subject matter expert

• influence across teams

• improve onboarding

Nobody forces you to do all these things, which means you have a lot of freedom to explore your interests. That in turn will help you figure out what roles might suit you in the future.

Do I want to be a manager forever?

The beauty of career tracks in software engineering is that you can swing back and forth like a pendulum between management and IC (individual contributor) tracks, while continuously growing the skills required to succeed on both tracks.

This illustration is how I see people and project leadership responsibilities across common job titles. Staying close to the middle (senior engineer, staff engineer) enables you to move to either side for a while with relative ease.

Switching to a leadership position really doesn’t have to be a permanent change in your career and I would argue that for many people it shouldn’t be.

If you are in project focused roles for a long time, it will be hard to take on people management duties like recruiting, 1on1s and career development. The same would be true when transitioning as a seasoned Lead Engineer to EM. Neither is impossible, but it’s a harder shift.

This is why it’s my firm belief that being a senior software engineer in a more established startup is the perfect position to be in as you can explore a lot within your current role, while also having a lot of freedom for your next move, be it EM, Staff Eng, Lead Eng.

As the role tends to give a lot of freedom, I’d say it’s also the right time to explore more lateral moves towards technical writing, technical PM or evangelist roles.

TL:DR

• Leadership can be rewarding, but you should know what you want to influence

• Don’t do it for money

• Management isn’t for life - you can go back and forth

• You can practice a lot of leadership skills without the job title and with a lot more freedom without the constant duties

• Maybe you don’t want to lead and that’s okay, too

For the most part, you can share your interview experience, what it’s like to work there, and your salary. The information you find can be very useful to prepare for interviews, especially if you come across red flags to inquire about.

Let’s compare the biggest of these platforms, how much data they provide and in which region they are active to see when they can come in handy.

A quick sidenote about employer branding.

There are sites that are basically a marketing page for companies to attract talent. If all the content comes from or is moderated by the company, then it’s just marketing, but sometimes it’s more nuanced.

For example, HR departments might ask their employees to leave reviews en masse before big hiring campaigns or specifically target their most engaged talent to leave reviews.

What I generally look for is what employees and candidates have to say about them, not how the company markets itself. The reviews are also a good way to verify whether the marketing materials reflect reality.

I took a sample of 10 companies* I found relevant for the Czech market and I will highlight how many of them I found on each platform and how many review entries are available.

glassdoor

https://www.glassdoor.com

10/10 companies listed

173.321 data points - 86% about Microsoft

The OG of review sites. They are the site with by far the biggest pool of companies and reviews in the western world.

• global

• reviews, salaries, interview reviews

• decent amount of data for well known Czech companies

• interview experience can be useful

• can filter all data by country

• companies can do reply to reviews

atmoskop

https://www.atmoskop.cz/

10/10 companies listed

2.484 data points - 70% about Česká Spořitelná

A Czech platform focused on allowing job hunters to find companies that offer an environment suited to their needs, both in terms of benefits, but also employee satisfaction in relevant areas.

• Czech

• reviews, benefits, “salary satisfaction”

• reviews across all industries and roles

• from tech firms, through post offices to police precincts, they have data about everything

• less commonly used in tech than other sectors

Blind

https://www.teamblind.com/

5/10 companies listed

8.340 data points - proportional to engineers based in the US

I have little experience in this platform as it’s very US specific. It looks like a mix of reddit (forum/advice/leaks), glassdoor (reviews) and a bit of alumni network.

• US centric

• reviews, salaries

• forum style threads about companies as well e.g. twitter layoffs

• mention of layoffs in reviews and posts is common

Comparably

https://www.comparably.com

8/10 companies listed

6.264 data points - completely disproportionate review volume vs company size and age

A site for companies to advertise themselves, with a lightweight reviewing feature. There is an odd mix of employer branding and corporate branding here.

• US centric

• reviews, salaries, interview reviews

• the few companies that are active here are tech companies with strong employer branding. can’t say that all the reviews sound super genuine

• no filters by country for data published

Fairygodboss

https://fairygodboss.com

5/10 companies listed

294 data points - 90% from Microsoft

This platform is a job board or aggregator, but with the huge bonus of adding metadata about the companies related to gender equality with ratings and reviews.

• lightweight reviews

• no salary info

• no data about Czech companies, only relevant if you search for big corporations

Kununu

https://www.kununu.com/

5/10 companies listed

4.433 data points - distribution feels proportional to headcount

Unlike other platforms, the reviews are structured like satisfaction surveys, so the data is far more organized.

• DE, AT, CH

• good overview of benefits and culture

• most structured review data

• reviews, salaries

• company culture indicator (traditional vs modern)

Summary

Each of these platforms has their unique value proposition for both employees and companies. Not discussed here, but they all function as job boards as well.

Generally speaking, you can get a solid amount of data about larger companies hiring in Czechia from Glassdoor and Atmoskop, while German speaking countries are covered very well on Kununu.

In the end, it mostly boils down to where you job hunt and which industries you are interested in.

If you can, please take 5 seconds to answer these questions to make this article pop with moar data ✨

1] The companies sampled were: Red Hat, Microsoft, Applifting, Kiwi.com, GoodData, Seznam, Kiwi, Productboard, Avast, Workday, Ceska Sporitelna incl Erste. The data count is the sum of reviews, salaries, interview reviews etc (not incl e.g. benefits section on glassdoor) not filtered by date or region.

Without further ado, here is the surviveintech job hunt tracker. Smash that duplicate button and you are good to go! It's a simple toolkit you need to start your job search and stay organized in the process. Everything from defining what you are looking for to keeping track of applications

I want to make your life a little easier by helping you pick the right sites to spend time researching.

There are two main groups here, job boards which require you to apply with a CV, and resume platforms which for the most part take your work experience and your job requirements and try to match you with the right company.

Job boards

Even though almost all job boards allow you to upload a CV and let recruiters reach out to you, I find that most people don’t want to invite that volume of messaging. Job boards make money the same way ads platforms do. You pay to have your ad displayed. Duration and placement affects price.

Jobs.cz

https://www.jobs.cz/

They have been around for a long time and are still a staple on the Czech job market. If you upload your CV here, you’ll have recruiters calling and emailing within minutes.

+

• salary filter

• remote / home office filter

-

• search - as this isn’t a tech specific job board, they have a full text search instead of relying on tags. Unfortunately that comes with limitations forcing you to search for multiple job titles

• salary ranges not visible

monster

https://www.monster.com/

Maybe the oldest global job board that’s still around and kicking. In many ways the big brother of jobs.cz, which has its pros and cons.

+

• remote filter

• very big pool of ads from many countries

• some salary info available

• solid search, although it will return some false positives

-

• the new UI can be tedious if you don’t want to sign up

• very limited filtering - probably the only way to sift through relevant jobs is to go one job title + country at a time

• lots of recruiting agencies advertising here which creates noise among ads from companies

• no salary filter

LinkedIn

When you really think about it, LinkedIn is essentially monster with forced signup, a feed and a messenger.

+

• very big pool of ads from all over the world

• can get a little career inspiration from other profiles

-

• almost no filters

• no salary info

• applying often has to be done via terrible career sites forcing you to reenter your profile data

• no filter on recruiters or sales contacting you

• job recommendations mostly useless

• weird / creepy "whose viewed my profile" feature

startupjobs

https://www.startupjobs.cz/

Just a few years ago, this was the place to be. These days, it’s just another job board, a little more targeted as it’s mostly tech companies and agencies recruiting here.

+

• salary ranges provided (although sometimes uselessly broad)

• most dev roles advertised as remote

-

• too local - you won’t find anything above standard Czech rates being advertised here

• remote working conditions vary a lot and lean more towards home office as a benefit than fully remote models

RemoteOK

This one, as the name implies, is targeted at remote workers. Most of the companies are startups of all sizes.

https://remoteok.com

+

• remote targeted and region / timezone usually specified

• salary ranges specified (BUT some of these are estimations made by the platform)

• good filters

-

• a lot of companies that hire remote only within their own country

• beware of scams

climatebase

https://climatebase.org/

Sometimes we forget, but we can actually choose to work on things we find meaningful, which these days, for many of us, is fighting climate change. This platform is targeted specifically at helping you find a job within companies fighting climate change from various angles.

+

• basically a boutique of companies to pick from

• solid role grouping enabling good filtering

• at least some salary ranges are provided

• very cool to filter companies based on approach to fighting climate change

-

• few remote jobs available in Europe

• even fewer jobs available without working US time zones

• recommended jobs in weekly emails not targeted to remote + region unfortunately

Resume platforms

Although many job boards have some similar functionality, these platforms aim to create a smoother, more personal experience. You create your profile, add your preferences and either you send a DM to companies or they DM you.

These platforms usually make a commission when you are hired through them, the same way a recruiter would, just at lower rates.

honeypot

https://www.honeypot.io/

They are pretty well known on the German market, but are slow the grow across the EU unfortunately.

+

• nice signup flow

-

• not available in Czech Republic, even though they advertise remote positions

• useless unless you want to relocate

techloop

https://techloop.io/

I know techloop from the Czech market, but it was actually quite big across Europe at one point. Since they were acquired I saw the quality of job posts and rates advertised go down.

+

• hidden gems - early stage startups recruiting here, too

-

• many low quality ads

• companies contacting you who don't meet e.g. your salary requirements

cord

https://cord.co

I think I was invited here by a recruiter once and since then I occasionally check in. They also started publishing content related to career development in tech.

+

• good quality job postings

• salary ranges everywhere

• good filters

• rare finds - you can find some early stage startups here

-

• response rates vary, no guarantees

• many jobs remote only within the country (US, UK especially)

• practically no change in the list of companies hiring so little incentive to check back in

Summary

Not all job boards are created equal. There is a lot of variance in the types of job ads you will find on each and the type of data they contain. In general, ease of use suffers a lot if the site is not tech industry specific and therefore can’t provide a useful grouping, which of course doesn't mean, that those sites would be a waste of time.

You can’t constantly keep track of every platform, but you can pick two and make a point to review the listings on a regular basis for specific roles and locations.

As I’ve described in this post about finding remote jobs, this hunt requires patience, even more so if you don’t want your working hours restricted e.g. to US hours.

The motivational content, the flattery, the employer branding. It’s mostly fake.

That’s fine, as long as you are aware of it, but I doubt that someone joining the platform especially when starting their career can know that. They might buy into it the same way teenagers looking at instagram influencers might believe that that beauty generated by filters is attainable, real or a worthwhile pursuit.

It might not be toxic, but…

all this deception can’t be good for us, right? Take for example:

• you aren’t as hot as recruiters might make you believe

• most of the content comes from HR people and influencers - that’s not a representative sample of the workforce

• most content from companies either advertises their product or themselves as suppliers or employers

• certifications are a HUGE industry - some have value, many don’t

• there is networking outside these platforms and many of the best opportunities never make it to LinkedIn

• linkedin profiles don’t have to be honest - real careers are neither as clean nor as interesting, and sometimes, like with resumes, people flat-out lie

• salary information you find here or on glassdoor gives you little indication about your earnings potential

At the end of the day, it’s a platform built for recruiters to have the biggest possible pool of CVs to search through. Almost all features are targeted at recruiters and sales people. Some of these things are relatively harmless, but I want to zoom in on the content authors.

Who posts on linked

I’d group most content into these buckets

• press releases e.g. release announcements

• company PR stuff e.g. look at our cool new office, or project we did or how super eco conscious our company is

• influencer content - yes, linkedin is packed with this garbage

• managers (esp. HR) expressing their opinion on things loosely related to their work

Content from managers is usually a humble brag about their company’s new progressive policy with a bit of debate in the comments, which ends up being very “employer-sided”. It’s execs, HR people, recruiters debating this stuff. You know that no-one has asked employees for their opinion when you hear stuff like:

• people don’t quit because of money

• flexible schedules mean you should just be cool with work creeping into evenings and weekends

• quiet quitting is people being lazy / soft / dishonest

• we shouldn’t raise salaries above the local market because we’ll turn our cities into dystopian shitholes

All this is normal manager talk offline already and now it’s become common on LinkedIn as well. If this is what you hear at work and see online, you might even believe it and that certainly isn’t to your benefit.

Let's look at two big topics, where the narrative doesn't reflect the reality.

Working hours

About 15 years ago, policies like “flex-time” were common in central Europe, especially in international companies. It enabled employees to leave a bit earlier today and start that much earlier e.g. on Friday. This was a huge benefit especially for anyone with a life outside of their jobs, who might be heavily constrained by strict working hours.

Today, knowledge workers are rarely required to count their hours. The company is trusting you to get your work done. Often there is a commitment to some core hours to ensure everyone is reachable at certain times and things can run smoothly, but everything outside that is up to you and your colleagues.

Things get a little weird when you start to feel some pressure in the air about working longer hours e.g. to compensate for some inefficiency or to meet a deadline.

The exploitive bit comes when you do your work, do your hours properly, but then, you need to attend some more evening calls and a hackathon and stay late for an all hands. You can’t balance the hours, because you have shit to do, and as hours are no longer counted, fulfilling your commitments is all that matters. So do you commit less or suck it up in the name of “flexibility” and “equity”, risking burnout in the near future?

Salaries

By far the biggest mess of a topic in my opinion are wages. Not only is it a legal minefield to speak about your salary with your colleagues, there are many countries including the Czech Republic where it’s culturally frowned upon to speak about money as it can appear boastful.

If you don’t happen to have a beer with someone who tells you otherwise, you might assume that all engineers earn more or less the same, let’s say within a ±25k CZK range. Within the Czech Republic, the range is actually around 50-150k. There are engineers with surprisingly low salaries, but there are people earning far more than you ever thought you could, without selling your soul and becoming a manager.

Because when you cross the border and a position that’s worth 100k here, pays 200k and 350k overseas.

This isn’t unique to software engineers either. UX, Product, Sales… same story.

These salaries were always available for agencies, but very rarely for the employees without giving a huge cut to the company.

Since COVID, the market has become far more open towards the west.

That puts local tech companies in an awkward position. Catch up to the Germans, or come up with an excuse not to. If you look at LinkedIn, it seems that they choose the latter with some rather phenomenal mental gymnastics.

I read a recruiter calling 10k / MD sci-fi, but these rates have existed on the Czech market for many years in certain niches, and they are becoming far more common as many western companies, eager for talent and now equipped to handle remote teams, are hunting in markets where they can offer people huge salary raises instead of in their own saturated market.

These companies don’t need to advertise a lot as they have a very easy time poaching top talent with the offers they can make. When that happens, people absolutely do quit because of money.

Summary

Everyone is selling something. It’s the internet in 2022 after all. But on LinkedIn, as the product being sold is often a job, it’s a lot more subtle and often deceiving. It’s worth keeping in mind who is advertising what and to take it with a grain of salt.

Remote ≠ Remote

Working remotely comes in many flavors. One version many of us discovered during covid is regular work, just from the comfort or chaos of your home office, with all or more of the same meetings.

On the other side of the spectrum there is async work, where you aim to minimise all synchronous interactions. In a nutshell, as few meetings as possible and lots of smart ways to navigate people working at more or less random hours.

I want to focus on helping you find work, that’s as far on the async spectrum as possible, as it will give you the biggest flexibility.

Expectations about working remote

It’s important to be honest with yourself about whether you want to work remote, before you start going down this path, otherwise, even if the money is good and the work is interesting, you’ll likely be miserable.

Async work patterns

Working async requires solid written communication skills of every single team member. As most communication, especially outside the team won’t happen in conference calls, writing great Docs, RFCs, Bug tickets and Code Reviews carries a much bigger weight.

Study up on the tools and communication patterns that exist in remote organizations. Maybe you can even implement some of them in your current job!

As you have less face time with your colleagues, remote organizations tend to prioritize offline and online team building activities. You might travel occasionally to spend some time together or you might play some online games as a team / organization.

work delivered > working hours

Every company is different in how and to what extent they measure performance, however, in remote organiations it’s safe to assume that you will be judged more on merit, than on whether you show up.

a bit of extra paperwork

Working in tech in the Czech Republic you are likely used to being a contractor. It comes with a little extra paperwork, which you can handle yourself or hire an accountant for.

As many remote organizations are quite young and nimble, you might be lucky enough to get tools like deel which make this part much easier.

the clear upsides

The remote work you can find will likely pay much better than Czech companies, or more specifically, offices located here. These organizations compete for talent globally / regionally so they are likely to pay German, UK or US salaries. That is a 2-3x multiple. This applies to all roles, not just software engineering!

Your schedule shouldn’t be blocked by mountains of meetings, so you can expect to have a lot more focus time at your disposal.

Expectations for the hunt

The job hunt will take a while. You might get lucky and find something within a few weeks, but you are more likely to passively search for the right company with the right position for a few months.

That being said, you are much more likely to find a great job if you invest time hunting. Going through countless job adverts on a regular basis also has the positive side effect, that it helps you figure out what you really want to do. That helps you narrow your search, but also allows you to give a better answer than “meh” to the “what made you interested in this role” question.

Track down the jobs

Although a lot of job hunting can be done passively, I recommend investing at least a few hours spread over a week to skim over a few hundred job adverts. You should try to understand what kind of roles are out there, how they are usually described, what skills they need, and ideally, how much they pay.

I recommend checking my job board review to figure out where to spend time researching.

If you want to go the extra mile, it’s worth keeping an eye on funding news and tech conferences to find growing startups hunting for talent. You can find some really interesting companies like this, so if you are looking for a specific industry or tech, this will pay dividends.

Let them come to you

There are hordes of recruiters out there looking for talent. Sometimes they might annoy you, but most of the time, they are your best shot to even find out about certain jobs.

You need to make sure you are making it easy to be found for the right roles.

After sifting through job adverts, you should know which titles you will aim for. If you haven’t already, write CVs specific to those roles. I can recommend this ebook if you want a solid guide with templates.

Once you’ve got your content ready, update your LinkedIn and other resume profiles you intend to use and then, the waiting can begin.

Keep track

It’s easy to get lost in all this, so I find it best to start a spreadsheet / notion page and keep track of:

• applications

  • who has which CV

  • when did you submit

  • stage

  • last contact

  • contact person

  • applied via (recruiter, job board, career page)

• companies

  • name

  • why they seem interesting

  • career page link

  • articles if relevant

When I last hunted for a job, doing this definitely helped me stay focused to keep searching instead of settling for something mediocre.

Good luck on your remote job hunt!

Maximize choice

You always want there to be a large amount of job opportunities relevant to you, with a high level of variance. That means that if you want to switch your specialization, or do a bit more people management, or do the same work for a different industry, you could make that switch easily, without a demotion in between.

The biggest red flag detectors

• is it generic or specific in terms of skills (Rails dev vs full stack software engineer)

• is it generic or specific in terms of industry / segment / subject matter (ecommerce dev, scrum master, automotive xyz)

• is it in English or in the local language (English preferred, even if there is a language requirement later)

• could you explain it to your grandma (if she understands what you currently do, so will everyone involved in the recruiting process)

When you turn it around, this is what you get:

• broad responsibilities

• broad skillset

• clear, universally understood job title

Nice generic jobs, that everyone understands, which give you huge amount of choice. That's the sweet spot.

If your current job title sucks

When the only problem is the title, it's acceptable to adjust your LinkedIn to your needs.

Maybe put the official title in brackets on the CV, so if you are a RoR developer officially, but you actually do React, JS, Rails, Java, Docker, MongoDB - just call yourself a full stack engineer.

Even the overlord of tech recruiting Gergely Orosz wrote something along those lines in this ebook.

Sometimes this is just cosmetics, but sometimes this is an exercise, which can help you figure out what role you are aiming for, so you can mold the current job into that.

I've realized that quite often, you have a lot of control over what you do once you are hired, so it's nothing audacious to adjust your role towards the one you want.

An innovation officer might turn into an agile coach, or a reporting analyst will be a BI developer. Same job for the most part, but with a big leap in salary and amount of job opportunities.

What I did with my confusing title

I had a job title which was making it harder to get hired. I was called a Director, which sounds fancy, because in product companies, Director means responsible for 50+ people. I was a Team Lead / Engineering Manager in reality.

My role was 0-90% hands-on, depending on who you asked, rest was various management stuff.

After a couple of months, I acted as a senior engineer / tech lead with a few management duties, focused on hands-on work, because those achievements would be important to get myself hired again.

In the meantime, I also applied to Engineering Manager roles, because that role can also range from pure management to senior engineer who manages some people, too.

You'd be surprised how often you can walk the line between roles without noticing, which comes in very handy when it's time to write CVs.

A year later I was out, back to a beautiful generic role, which won't turn into a dead end.

If I didn't pay attention, I would have been promoted and gotten stuck in general management role, which I wanted to avoid at all cost. It could have the death of my software engineering and technical management career.

Important side note

You can do the same job, but earn a lot less and be in a much more conservative environment, because one is a product company and the other isn't.

Product companies, as in, usually VC funded, are focused on growth over efficiency.

That translates to a very different mindset. If you keep counting pennies, and worrying about ROI of every bit you spend, you won't end up with the best tools, or attract people who want to flex their creative muscle to build the best products. But I digress.

Job titles that are common in product companies have also found their way into all fortune 500 companies, so most likely, you have identical titles already.

If however, you have very different titles at your company, it's probably a good idea to find the role you want in the product world, and start aligning yourself towards it. You are preparing yourself for that job, while also making the recruiters' job easier by highlighting your overlapping experience.

Think about the recruiters

After referrals, recruiters are usually your best chance at making less obvious transitions in your career. They can enable you to get a chance, which is often all it takes. That being said, don't make it harder for them than it has to be.

Understand the roles you are interested in and write CVs (yes, multiple versions based on the role) tailored to make your case for that role. If you feel that your CV could use some work, I can recommend this guide. It definitely helped me during my last job hunt.

Learn to explain your current and past roles in plain English. Hiring managers will try to assess which areas of the role you are already confident in, and where you will need some help. If they don't understand what you do now, they can just guess, which usually doesn't work in your favor, unless they are very desperate to hire. I find this especially important when you are coming from a corporate environment, with its own jargon.

And last, but not least, have a chat with some friendly recruiters. A good recruiter can be an incredible resource to understand roles, companies and hiring processes.

As COVID-19 hit, they pulled the plug on our team. Our team didn't have enough influence or a mission that was generating revenue. We were out.

This is a collection of thoughts on the limitations of being a satellite team i.e. there are one or more primary offices and there is you, the smaller one, a few hours away from everyone.

Challenges

Scheduling across the globe

If you need to discuss anything, ask someone a couple of questions, have a 1on1, plan… everything requires scheduling discussions and everyone will need to show some flexibility, but odds are, being the small office with less people attending, you'll be the one having calls at 7am or 11pm more often.

Remote Readiness

You need to teach video call etiquette. Mute yourself, connect individually, cancel early, turn on the video. You know, the usual. But every company goes through this awkward stage when the habits aren't there yet. Thanks to COVID-19 everyone went through a bootcamp experience. That being said, an open office layout won't suddenly be more conducive to conference calls. The other set of barriers that may feel permanent are around tooling. Choosing and adopting the right tools that enable distributed teams is hard, especially in larger organizations.

Objectives

Being colocated comes with its benefits. You can talk to people anytime, and that's hard to get around with technology. Once you don't share the space, clear roadmaps, frequent all-hands meetings and transparent online discussions become critical.

Influence

The issue with having influence from afar has a lot to do with the water cooler effect I think. Not only do people gossip in the kitchen, but important decisions are made during quick discussions while making coffee. These decisions are invisible unless they are later documented and that's a habit that isn't developed without strong leadership and discipline.

Career Advancement

I would argue, that what sets a Senior and a Staff or Principal Engineer apart is not deeper expertise. It's the scope of the work that changes dramatically. Mentoring, recruiting, architecture and roadmap discussions become critical parts of your work and they all take a talking to a lot of people all over the organization. Unless the organization is very remote friendly, I think the roles of the people in the remote office are capped to that office's mission.

What helps

Regular catch-ups

You can be super proactive, shift your work hours, whatever, it won't be sustainable. Regular catch-ups with your peer group work wonders in my experience. The downside is, you can't force people to take these calls at 10pm, so the ones with lower morale can easily dig themselves deeper by isolating themselves further.

Autonomy

We had our own project for a while. That worked very well. Before and after that morale tanked. If you have a remote team or you are thinking about building one, make sure they will be able to function on their own, without constant reviews and planning needed with the wider organization.

Make it big

When companies build R&D centers in Prague, they make them big. At least twenty engineers big and I understand why. To have sufficient influence and autonomy, you need to be able to design, plan and ship entire products on your own.

Hindsight

Three years later, I work in a startup which is not only fully remote, but encourages all forms of asynchronous communication. In this environment, those issues I listed practically don't exist. You have other challenges, but for companies, which can make the shift to accommodate fully remote work, they and the people they hire will probably be much better off than building offices around the world.

First, imagine a world where we jump straight into our tasks:

• long running tasks

• tasks spilling across cycles / sprints

• defensive estimations

• pushback against those estimations

• optimistic estimations that the team can't live up to

• exhaustion

• repeat - with less motivation and reduced confidence

That's not a healthy way to deal with uncertainty, right? No one is satisfied in this situation and there is definitely resentment in the air. So what can we do instead?

We could go all out, like Share Up method does, and make sure risks become the central point of conversation by making them the first tasks to tackle in every single initiative.

But that might be quite a heavy change in your team to change to a different organizational system so instead, why not get into the habit of highlighting uncertainties as they appear and then allocating time to explore those uncertainties in a controlled manner.

When do we need POCs

Let's start with a rough definition:

• an experiment

• to prove a concept (duh)

• in a small amount of time (usually a few days max)

• disposable (it's an experiment after all, not the real deal)

Basically, when you have no clue how long you will need to accomplish something or if you are uncertain about the approach, it's time for a POC.

Sentences that scream POC to me:

• we need to make a change that will affect every single service we've built

• we want to try this cool new framework that promises better developer experience

• we need to add a dropzone feature to let people drag n drop files into our app

• we hate our tech stack but we don't have enough information to pitch any alternatives

• we know it will be a horrible pain to implement X - we could try these two things

• we should stitch something together quickly before we agree to work on this

• there is this cool new service we want to integrate

Once you've reached the conclusion that a topic is drenched in uncertainty, you need to outline the scope of your proof of concept. What do you aim to prove? How? Within what time frame? What would be considered a success? Do we need to find alternatives if this approach fails or do we stop pursuing this topic?

What POCs can do for you

Writing and then performing these tasks diligently can be a huge asset when it's time for performance reviews. You end up helping the entire team by:

• protecting developers from committing to very risky tasks

• help bring more predictability to the roadmap

• anticipate risks

• think about architecture early

• document benefits and drawbacks of approaches

I believe if you want to prove that you are senior material, or rise even higher in the ranks, you are setting yourself up for success. After all, what we expect from experienced people is to bring stability to the table, and that's exactly what you can do by managing risks and tension in the team at the same time.

Thinking in Experiments

Having an approach centered around experiments does not come naturally to many people. If you have an academic background, maybe, but for many of us, it feels a lot more natural to say "sure we can, let's give it a shot".

Luckily, we learn very quickly from failure and pain, so it won't be long before you get the strong urge to look for a healthier approach.

What we end up doing, is separating the "what" from the "how". The delivery from the preparation and experimentation. All the "how" task needs to accomplish is to sufficiently define the scope of the "what" tasks. And it gets to do that, without the time pressure of having to deliver on any requirements. It needs to document the results of the experiment.

Keep it practical and lean

It's important to note that these tasks should have tangible results. There should be a pull request or a codesandbox that serves as proof and often as the example for the implementation.

This is different from an RFC (Request for Change) which can include examples, but doesn't have to.

At the same time, you should aim to remove everything irrelevant from the equation whenever possible. For example, if you can answer your question within a code sandbox, implement it there. It will be a much faster and serve as better documentation, than working in the real application.

However, if the uncertainty lies is integrating something into an existing application, you need to figure out how to implement as little as possible, while tackling as much as possible risk.

This may sound daunting, but keep in mind, that you are doing this as a team and you nobody can anticipate all risks. Every bit of uncertainty you handle upfront is a win!

When you start a job, you should know what they are expecting from you, especially during the first couple of months. All too often, this is not clearly communicated, which puts you at risk of being fired for underperforming or having to play of politics to appease the right people.

Having ambiguous expectations gives a lot of power to your boss, as any day, they can change their minds about what they expect from you. You can receive great feedback for months and then, for some reason someone starts to perceive your differently, and all of a sudden that same work won't do.

I hoped you would...

Imagine your boss tells you to focus on topic A, while your team assumes you would pull your weight on B, which you neglect as you've been given different priorities.

If you are lucky, someone might share their views with you in the form of feedback, but even then, you are new, you have no official guidance, so you don't know who to trust.

What makes this pattern even more troubling to me, is that there will be half a dozen people who hoped you would do certain things.

On one side, it's nice that people visualize your success, but it would be even nicer if they ran it past you.

Sooner or later, someone gets mad enough at you for not performing according to their personal expectations, to complain. That can snowball into formal warnings or a quick termination. That tough conversation usually includes "I hoped you would".

Whether you actually get fired or not, you probably don't want to stay in a place where people resent you, so the damage is done.

Set yourself up for success

To avoid getting into this game of Russian roulette, I highly recommend starting during interviews to ask about these topics to gauge what you can expect in your first months:

• performance review process and frequency - what are the measures? who picks them? what were the measures related to your role last year / period?

• onboarding - do you get a list of onboarding tasks? is there a sign off? is it formal? how long does it take and what does it cover?

• are performance goals the driver for salary increases and promotions?

• what is the role - is it specific enough? or is it pick your own adventure?

• what are the expectations for this role?

• what are the expectations for this position? (project / team specific)

What you are looking to avoid is your employer judging you based on: gut feelings, favoritism or through blindly following bureaucracy.

Situations worth avoiding

Unless you want to be the one who puts this in order, keep your eyes open for red flags.

It's easy to look past these topics and assume it will all work out. The problem is that these situations rarely resolve in an amicable way.

When someone is fired a year into a job, because expectations weren't clear, a misunderstanding, that could have been addressed has turned into a very dramatic situation and a lot of time has been wasted on both sides.

I've sat on both chairs in that situation. As a manager, you feel guilty for not addressing the issue during the probation period. As an employee, you are shocked that for so long you misunderstood what was expected of you.

If you can, it's really worth saving yourself that trouble.

But that attitude, while serving your employer well, can hurt your wallet, your health and your career.

Let's have a look at some interests you might have and see who would benefit from you pursuing them.

There is quite a bit of overlap there, but the support of your employer is generally conditional. They don't invest in you out of the goodness of their hearts. Your boss might, but the company wants a return on investment or at least to know that the alternatives are more expensive e.g. replacing you.

The constants

• the contract

• local laws

• policies

• everything else your employer signed

It's worth keeping in mind what you've signed and occasionally revisiting those documents. In my experience, you can be a lot calmer about dealing with your employer if you are familiar with your basic rights as an employee or contractor.

The variables

• your boss

• economic climate

• network in the company

The network you've built within the company is prone to change, even more so in startups. People leave and relationships change as well over time.

If the company feels, that they will suffer economically in the upcoming years, they will be keen to cut costs. That cost could be you.

The relationship you build with your boss will determine how strongly they will vouch for you when it comes to a substantial raise and also how hard they will fight to keep you around when it's time to cut waste. Building trust would be ideal, but that takes time, so how you are perceived by your peers and your boss is unfortunately pretty important.

Let's get real

Up to this point, we've looked very broadly at demands you may have towards your current employer and how those match up with their needs.

Let's take an example with real number. The cost of staying in your current job.

Here is the situation:

• current monthly salary - 3000 EUR

• asking for 10% raise

• receive 4% raise

• boss says you'll get a promotion next year for sure (you give that statement a 50-50 chance, you estimate a promotion would be about 15%)

You start responding to some recruiters and you get these offers within a few weeks:

• A - 15% - 3450 EUR - same country

• B - 25% - 3750 EUR - same country + promotion

• C - 40% - 4200 EUR - remote company i.e. different market rates apply

So remember, someone is telling you, it will all be cool, just wait another year.

Let's run the numbers and see how much waiting a year would cost you.

Let's say you are in your twenties and you are put in this position. Even if things worked out the way your current employer says and they do promote you, you are losing a stack of money that could buy you a new vespa or an amazing vacation with your partner!

On the more pessimistic / realistic side, we are already in apartment down-payment and new small car territory with those figures.

Within a year you'd have the money for a car or the down payment for a studio apartment.

Play with those numbers a bit. What if you sit there for another 4% year? Or maybe you have an example of your own you can run the numbers on.

I'm not advocating for everyone to keep switching jobs.

However, I do believe that this is a healthy confrontation with reality, on how much it can cost you to think of your boss and employer as your friend who looks out for you. Employers have their own interests and those may not match yours!

Job ads are notorious for this. They feel mostly like marketing or "employer branding" to me, instead of giving an accurate picture of the role. But if you look carefully and gather a bit of contextual data, you could decipher them!

Let's start with the information that is usually there

• title

• your boss

• industry / environment

• benefits

• tech stack

If you are lucky you also get

• project description

• salary range

• working practices

Let's take a look at those one by one and try to figure out what they could mean.

Title

There is only one thing I usually try to figure out and that's objective seniority and management responsibilities.

Any title that contains the prefix Director, Lead or Manager will have leadership duties associated with it in some form. The bigger the org and the further from consulting it is, the more responsibilities and direct reports you can expect. For example a Director of Software Engineering can have responsibility for anywhere between 5 and 100+ people so be mindful of the context.

I find that seniority is very relative in terms of skill, but quite consistent in terms of responsibilities relative to the size of the team. For example, as a Senior you are expected to handle large initiatives within the scope of the team independently, including all planning and communication. More senior titles assume cross team scope.

As teams grow and applications become more complex, getting things done requires a lot more skill. Therefore, try to understand if taking this job would entail more responsibility or increase in complexity (or both).

Your boss

In certain roles, they will highlight who you report to. It can be a good clue if the job and company description was too vague.

• to the CTO as an engineer -> very small tech team

• to an innovations manager -> corporate land

• to a team lead -> possible more old fashioned culture

• to an Engineering Manager -> probably a modern software company

• to a Delivery Lead / Manager -> agency / consulting world

For figuring out what's behind a (management) title it's often best to search for people in that role at that company on LinkedIn.

Industry

When it comes to industry you should try to answer two things: Where does the money come from and how much red tape is there surrounding it.

When they speak of clients, it's most likely an agency / consultancy so the money is tied directly to hours billed to the client.

Beyond that, it's important to check if the company sells software i.e. you'd be working on a product or if they build their internal tools. In one case, you are a cost center, in the other scenario, you build things to generate revenue. Very different animals in terms of culture and salaries!

And last but not least, you need to figure out how regulated this space is. Certain industries will have much more stringent requirements and they will reflect how much red tape you are likely to encounter. The amount of bureaucracy people associate with an industry tends to be a reflection of the culture you'll find in the companies working in that space.

Project

The main thing you want to figure out is: Is this project about creating more revenue or optimizing costs?

For example, if you are building a large feature that's been requested by many enterprise users, you will probably encounter higher pressure, but also higher rewards.

If on the other hand, you are working on optimizing the amount of time spent on support tasks e.g. by automating data imports, the environment might be lower pressure, but if the company isn't doing too well, this team is much more likely to have their budget cut.

Tech stack

When you are in technology keyword town, you should be concerned with:

1. is it a good fit for you

2. is it modern - how new is the application, how well maintained is it

3. is it exotic - due to real need or gut decision

It's very unlikely that you will get a clear answer just by reading the listed technologies, but it should tell you what to ask about during the interviews.

Working practices

Time to brag and tell everyone how smart and different we are, woo!

• hackathons - free overtime, yay! very likely a young crowd, can be fun though

• we release n times - try to figure out if it's automatic or if there is a manual process involved. that speaks mostly about their CI/CD capabilities and the amount of trust they've built with their tests

• ____ rotations - any mention of round robins is a sign that teams are self organized and don't rely on managers

• we do TDD - means do it or get out; they might teach you though

• we don't do ____ - we are very very smart. look out for this at the interviews

Benefits

• the country specific standards - in the Czech Republic that's 25 days vacation, 3+ personal days, private pension of 3%, meal vouchers, gym vouchers.... these are derived from local corporate tax rebates so scroll past them

• industry standards - mac pro and sometimes choice of linux

• gear budget - ask about how to access that cash, but generally any kind of freedom in how you equip your home office is a good

• learning / conference budget - same, ask, can be great, can be typical expense process in disguise

• yoga / Pilates / whatever - they shell out 100$ per month on virtual classes or give you a subscription for an app that costs less than a good coffee per month

• flexible benefits - buy (almost) whatever you want - this is becoming more popular. you'll love it!

• stock options - yes we get it, you are a startup, BUT if it's not a startup, cool, because you might be getting already publicly traded stock at a discount so that's a complicated but pretty neat bonus

• snacks - a fruit bowl in the kitchen for the most part. just like coffee, unless it's somehow exceptional in quality, they may as well not mention it

• non standard items - if it's there, it will be the most "honest" one, because someone probably made a real effort to make it happen

You can never get the full picture from a job posting, but it's really worth paying close attention to details.

It will also get easier as you spend more time in the industry, because you get to know the company names and the culture associated with them, so you will know what to expect from their alumni.

Good luck on the next job hunt!

This guide is meant is a quick and simple introduction into agile software development terminology. These are the terms you'll encounter on a regular basis, in every company that ships software these days.

Roles

Let's start with who does what. Titles may differ but you'll encounter more or less the same roles in every product team that builds digital products.

• The Product Person aka Product Owner, Product Manager, Business Analyst

  They decide on priority and whether something is worth investing in based on the teams' estimation.

• The Organizer aka Agile Coach, Scrum Master

  Find and remove anything that slows down the team. Very often the secretary of the team.

• The Technical Lead aka Team Lead, Tech Lead, Engineering Manager

  Usually in charge of all things that require long term planning including hiring and software architecture in relation to the team. Often acts as a filter between product and engineers.

• The Engineer aka Dev, Engineer

  Build it and make sure it works as requested.

• The Tester aka QA Analyst / Engineer, Tester, SDIT - Software Developer In Testing

  Make sure it works correctly and that bugs that make it to production are rare.

• The Systems Person aka DevOps, Systems Engineer, CI/CI, Cloud Engineer

  Handle anything from automation, monitoring, deployments to security. Usually more cloud infrastructure focused than oriented towards process improvement.

• The Designer aka UI / UX Designer, Researcher

  Figuring out what to build, how it should look and behave. There is a wide spectrum here between user research and UI design, which is often covered by specialists in those areas.

Organizing Tasks

In the agile world, we like to get real fancy with our TODO lists, especially as the team grows.

• The story

  A task phrased as a sentence e.g. As a reader of this blog, I'd like to learn the most common phrases in "agile" in 5 minutes or less.

• The Backlog aka Ice Box, TODO

  A backlog is the collection of all feature requests, bugs and other tas

• The sprint

  For this time frame, the team plans a certain set of tasks. It usually lasts for two weeks.

• The sprint goal

  An overarching goal for the group of tasks the team has planned. Useful when figuring out priorities among the tasks when time is running out.

• The status meeting aka Standup, Daily, Daily, Check-in, Sync

  • Format - multiple times a week, max 30 mins

  • Goal - check in on progress towards a team milestone e.g. a sprint goal

• The prep meeting aka Sprint / Backlog Refinement or Grooming

  • Format - minimum once per sprint

  • Goal: make enough tasks ready to be worked on for the next couple of weeks

• The planning meeting aka Sprint Planning

  • Format - often a grueling 4+ hours meeting split into explain and estimate VS plan what we can fit into the sprint

  • Goal - Agree on a chunk of work, that we are confident enough to get done within the next sprint

• The Retrospective aka Sprint Therapy

  • Format - usually once per sprint

  • Goal - look back at how we did and how we can do better either in terms of organizing ourselves or how we work together

• The Experiment aka Spike, POC, that odd task

  • Format - A special task, often limited to 1-2 days

  • Goal - Figure out what will make it hard or get an idea of how long it will take. Don't actually build the thing. You document the results and throw the work away.

Methodologies

There are as many methodologies as there are consulting companies in this space, but these are the ones you are most likely encounter on a nearly daily basis.

• DevOps - The idea that I merge my PR and in a little bit it will be in prod automatically

• Kanban - in software when people say this they mean they work without sprints

• Scrum - a company that sells certifications. a lot of what we associate with agile is actually scrum jargon

• XP - Extreme Programming - very collaboration oriented rituals for development teams

• the agile manifesto - the OG - the original doc that started it all

A few minutes to bug report bliss

First, make a video instead of focusing on the ticket. A short narrated video is an extremely dense way to communicate. They are far more useful than any jira checklist for the person fixing the bug. Often these videos can incorporate context about the broken feature, which can be extremely useful context when trying to fix the problem.

1. is it just me?

2. is it just this browser?

3. is it just this user?

4. is it just this "product"? - product is a placeholder for project, report, invoice - whatever "things" you have in your application - check another one

5. is it the on all environments? - compare production to other environments. do they behave the same?

6. are there any errors? - check the browser console for errors, the network tab for failed requests and of course, don't forget about visible errors on the page

The rest of the steps, like digging in the logs or comparing versions, or checking what was recently released, can all be done later. If you can answer the above questions, you already have a good sense about the level of urgency, while allowing the developer to fix the issue much faster. These steps should also not require any special accesses, so everyone on the team can perform them.

Collective ownership of quality

Often it's QAs and engineers who get to deal with all the "it's broken" and "it's URGENT". I've often seen triage processes and bug report templates put in place to mitigate the chaos, but in my experience, those improve some things, while they also slow things down a lot, which is counterproductive when it comes to bugs!

Collective ownership of product quality is what I believe all teams should aim for instead of blindly relying on a process.

Sharing the load ends up allowing us to fix issues faster, while also giving everyone on the team a much better understanding of the product by becoming familiar with the nuances of the applications' behavior. That familiarity reinforces ownership. For me, it's always been a satisfying feeling to understand the product I work on and at the very least, not feel lost in it.

Give it a shot and let me know in the comments if found this useful!

Fear and anxiety can play a huge role in our working lives, if we let it. I believe that the sheer amount of tools and technology we need to keep up with as engineers, along with this estimation-focused environment are making this job more emotionally draining than others.

Frank Herbert, Dune

Let's look at some situations that can freak us out pretty easily and how we may be able to avoid falling into these traps.

I broke something

You recently made some contributions. A week later a bug breaks the application and you can just feel that it's your fault. People quickly start to point at your change as the potential cause. As you start investigating, your slack notifications are going wild.

I don't have enough time

You thought you'd finish your task by tomorrow, but you see that it will take you at least another five days at this rate. Your calendar is overflowing with meetings. The new team members are eating into what little focus time you have left.

I don't know how to do this

It can be hard to admit. For juniors and seniors alike, especially if the environment doesn't feel welcoming to this level of basic vulnerability. Mindfulness can help us become aware of our feelings of inadequacy, but there are also practical things that can help us steer situations in our favor.

I've felt all these things in my career and I still do on a regular basis. But with practice, I've learned to notice what bothers me quickly, which allows me to influence the situation.

Instead of letting a stressful situation ruin my week, I aim to resolve it within a tough hour or two. The difference in productivity and well-being is enormous! If you feel that something is missing from this cheat-sheet is missing, please let me know in the comments so we can all be better equipped for those tough days.