DEV Community: Gergely Orosz

How to Write a Performance Review as a Developer

Gergely Orosz — Tue, 08 Dec 2020 20:29:55 +0000

Watch this article as a short video on my YouTube channel.

Performance reviews are coming up. I've always found this period nerve-wracking, despite having gone through it so many times, both as an engineer, and later as an engineering manager. Will my manager give me fair feedback? Or will I be in for some unexpected surprises?

The best way to not have a surprise on your review is to prepare your own self-review, and send it to your manager, ahead of time.

Why is this a good idea? Managers will try to gather as much information as they can on your work, when writing your performance review: this is how I do performance reviews for engineers on my team. However, managers will not know about everything you do. They will also often fall victim of the recency bias: weighing recent work more than that in the past.

If you put in the work to write your own appraisal or self-review, you not only make your manager's job easier: you'll also set yourself up for a more fair review.

A possible structure for your self-review

If your company has an evaluation or self-review template, it's a good idea to use that one. For other cases, I've put a template and an example performance self-review together for inspiration. Here's the structure I'd suggest.

1. State the goals/expectations for the period

Instead of jumping in to your achievements, set the stage. In your interpretation, what expectations or goals did you set out to achieve? If your role has expectations defined, those might well be the expectations. If you had previously set goals with your manager, list those.

If you have neither of them, summarize your understanding of your expectation. It's already a problem if expectations are not clear: after the review, it might be worth having a follow-up with your manager to clarify what baseline expectations mean for you, and for them.

Here's this section in the example performance review - one of the goals was to be more involved in the engineering planning / RFC process:

2. List your accomplishments

List out your main results, and larger work efforts. Try to do this in priority order. Use numbers to make things more specifics, where you can - and where they add more context.

Numbers could be things related to the code the code (number of changes, number of languages worked with, number of services worked on and so on), to people (number of people collaborated with, number of teams, number of stakeholders), to business impact (revenue impact, reliability improvements, efficiency changes and others). The self-review is an opportunity to put your work in context: not just the effort, but the result of this work.

For work that has not yet been shipped, using the estimated impact should work just as well. For example, assuming you are playing a key role for an in-progress project, you could say “On track to save $500,000/year by shipping Project Pluto, where I am owning the Luna and Titan components end-to-end.”

Link to specifics where it makes sense, but don't go overboard. The specifics might be design documents, notable code changes or code reviews, or other artefacts. Linking these could give additional context to your manager, and an opportunity for them to spot check some of your most impactful work.

If you have a "work log document", add a link to it at the bottom - here's an example and template for this. It's a helpful practice to keep a document where you keep track of the work you do week-on-week. Julia Evans calls this a brag document:it has other benefits on having your work recognized, like you having a better grip on all the work you do. If you started doing this beforehand, it also makes creating your self-review much faster!

Here's an example of listing out accomplishments using the above principles in this example:

3. Talk about the "how"

Most people would stop by listing their accomplishments. I suggest adding another section where you can list more of the qualitative details on your work: things that might have not had huge business impact, but show the small, but important things. Things like teamwork, collaboration and helping others.

List examples of you helping people within and outside the team. This is a great place to mention thank yous you've gotten from people - even quoting chat messages or emails you've received. Mention names of people and teams who you have helped, or whom you've gotten positive feedback from.

This section is important, as your manager probably doesn't see even half of the positive interactions you've had with people. Show it to them. From the example review:

4. Reflect on levels and competencies

Your manager will need to give you some kind of rating against expectations and competencies. Get ahead of this, and make their job easier, while giving indication of what you think about your own rating.

List expectations and competencies, and give examples on the work that reflects these competencies.

If you have good trust with your manager, you could provide self-ratings for competencies or expectations. If you have less of this, you could just mention areas you have paid special attention to: areas of focus. This is what is shown in this example:

Time well worth spending

Before every performance review period, I'd ask my directs to spend time on their self-review. Many people would leave it until last minute, prioritizing other work, including peer reviews ahead of this one. Some didn't even do a self-review.

Be sure to spend time on your self review, ahead of the performance review process kicking off. If you don't spend time here, you'll have little reason to complain if your manager is unaware of some of your key achievements, and your feedback is more negative than it would have been - had you put in the work. You are also missing an opportunity to reflect on all the things you've done.

Of all the "admin" work you do, this one will have an outsized impact on your career. So put in the work.

I'm writing a book: The Software Engineer's Guidebook on growing as a software engineer: from a junior, through senior to staff and principal levels at tech companies and startups. Subscribe here to get notified when it's out.

Enjoyed this article? Subscribe to my newsletter or read some other popular articles I wrote.

Six Principles Your Resume Should Follow - So Recruiters Will Read It

Gergely Orosz — Tue, 01 Dec 2020 16:49:55 +0000

I've been a hiring manager for several years at Uber and Skyscanner. During this time, I've read hundreds of developer resumes. I've been researching the topic of what good resumes look like, while writing probably the most comprehensive book on developer resumes. I've talked with two dozen tech recruiters and hiring managers at well-known companies: from Facebook and Google, through Amazon, Microsoft, Coinbase, and many others. As a way of paying it forward, this book is free for any developer who does not (or not yet) have a job - no strings attached.

Here are the six key principles worth following, to maximize your chances of recruiters and hiring managers reading your CV.

1. Take a step back to understand who will read your resume

Many people jump straight into writing a resume. However, knowing who will read it is key in deciding what information you should include. People who are most likely to read your resume are:

Hiring managers are the people who opened the job, and would often be your future manager, if you're successful throughout the process. They define the requirements and often write the job description. They set up the hiring process and define who the technical interviewers will be, and what areas they should focus on. At smaller companies and startups, they might screen all incoming resumes. But as the company grows, they won’t have time to do this.
HR generalists might do resume screening at growing companies: the companies who have yet to hire a dedicated recruiter. These people get guidance from hiring managers, and then try to see if there’s an overlap between your resume, the job description, and what the hiring manager asked for.
Recruiters often do most resume screening at mid-sized companies. Some recruiters are more hands-on and understand technical terms better. Some might be closer to an HR generalist in their technical domain knowledge. Recruiters will aim to determine if you could be a fit for the role, based on your resume.
Inbound sourcers are a specialized role within large tech companies who get large loads of applications. They are recruiters who focus on sorting through the direct applications and do this for multiple positions at any given time.
The interview panel is the group of people who would interview you, assuming you made it through the resume screening, and, possibly, a recruiter call. They get your resume forwarded and do a quick readthrough before the interview. There’s no need to impress this group: they are the people who might pay attention to your “interests” section, though, to kick off the conversation with an icebreaker.

Hiring managers are usually the most technical of all, and ones who are most likely to "read between the lines" of your resume. HR generalists and inbound sourcers will usually follow instructions - for example, to look for certain languages or years of experience. Recruiters could be somewhere in-between, depending on how technical, and how experienced they are.

If your resume shows that you are a fit for the job you applied for, everyone's job is easier, regardless if the hiring manager, inbound sourcer, HR partner, or recruiter is screening your resume.

On top of understanding who will read your resume, it's worth getting a sense of what a typical hiring pipeline looks like at the different stages, where the resume screening is the first step of the process.

2. Tailor your resume to the job description

When you apply for a job, you probably feel qualified enough for that listing. You know your own strengths, your ability to learn quickly, and some examples of similar work you might have done, in a different setting.

However, the people reading your resume don’t have any context about you. You can choose how to proceed. Do you give a thorough overview of all your past achievements? Or do you focus on a shorter overview, but focusing on the parts that show why you would be a great fit for this role?

Craft a resume that speaks to why you are a fit for that specific position. Take a “master” version of your resume, then remove parts that hold less relevance to the position. Add examples or experiences that reflect on expectations or bonus points for the job.

I’ve noticed developers often being nervous to remove bullet points from their past experiences. You shouldn’t be. Your resume is a tool to get you the interview. Once making it to the interview, you’ll have the opportunity to talk about the various things that you did that are not on the resume. Be ruthless in removing things that don’t help convey why you are a good fit for the position.

3. Choose a clear, top-to-down template

The benefit of being a software developer is how the format of your resume doesn’t matter, as long as it’s clear. The contents are what is important.

There are many resume templates out there. However, most of them were created for people who want to see pretty resumes. What you’ll want is an easy to read resume. The best template for this is dead simple, and has the layout similar to what recruiters are already used to: LinkedIn.

You won't want to add a photo on your resume, but keeping it easy to read top-to-down makes the job of recruiters much easier. Keep the resume easy to read as you write the contents. You’ll want key details to “stand out” via whitespace or bolding that recruiters and hiring managers care about:

Your name
Location / residence
Dates that tell roughly how many years much experience you have
Languages & technologies you are proficient with
Titles & company names from your past experience
Standout information

Resist highlighting anything else beyond the key pieces of information. Overusing highlighting or bolding defeats the purpose of this tool. Take a look at this developer resume template I created that gives you a sense of an easy-to-read CV.

4. Talk about specifics and impact, where you can

When listing your work and project experiences, focus on what you achieved, as opposed to what you did. For the achievements, try to quantify these with the impact and (business) results. A framework you could use is “Accomplished {impact} as measured by {number} by doing {specific contribution}”. This is similar to the structure Google encourages for resumes. You don't need to use the exact same wording. However, do make the impact clear, what your contribution was, and add specifics where you can.

Use active language that shows what you have done and how you have been proactive. Use active verbs like “led”, “managed”, “drove”, “improved”, “rolled out” over passive ones like “improving” or “rolling out”.

Use numbers to convey the impact of your work, or projects. Numbers grab the attention of hiring managers, and they also show that you are able to quantify the outcome of work, and be specific about it. For example, instead of saying “Built an open source JavaScript project to display dates.”, say “Built an open source JavaScript component for date display. The project has 5 contributors, 120 stars and 4 known production use cases.”

Mention specific languages and technologies that you used towards the end of your description. Impact and your contribution are more important to convey than the technologies. However, it’s worth calling out what tools you’ve used. Mentioning technologies in this context is more powerful for hiring managers and interviewers who are reading your resume in detail. Here are a few examples on how to mention these languages in your CV.

Quantify your impact wherever you can. Most resumes do not contain numbers: if you add these specifics, you will stand out. Instead of saying “Built a tool widely adopted by the company”, say “Led a team of 3 developers to build a dependency injection framework that was adopted by 15 teams and all 50+ developers at the company”. Numbers can be several things: number of people on the team, lines of code, code coverage % before and after, SLA changes, revenue generated by the project. They can be number of users, number of installs, number of five-star ratings, number of customer support tickets you proactively resolved, and many others.

5. Less work experience? Improve your resume throughout your application process

Assuming you have less work experience, your projects section will be an important part of your resume, and one where you'll want to try and stand out from the crowd. Here are a few ideas to do so:

1. Publish projects with good READMEs on your Github page. Aim for the README to have a good summary, screenshots, details on how to run, and how to test. Take inspiration from projects with awesome READMEs.

2. Have tests for your project that can be run. Most bootcamp grad projects don’t have automated tests, such as unit tests or end-to-end tests. Many of them have not heard of TDD (Test Driven Development). To learn more about this, see the Learn Test Driven Development resource.
If you have tests in your project, add a “Running tests” section on your README, to make it clear how anyone can run these. For an example on how to document running tests, see how this is done in a project like Leaflet.
Once you have tests in your code, call this out on your projects. In the project description, mention the code coverage percentage—and see if you can get this higher. Having built a project that is tested will already help you stand out from the crowd.

3. Contribute to other open source projects on GitHub. If you get to merge your pull request, you can claim that you’ve contributed to a project used by more than a certain number of developers. Stars on the project is a metric you can use here. For example, for a project with 28,000 stars, you can state: Contributed to the Leaflet, the leading open-source Javascript mobile friendly-interactive library with more than 28,000 developers using it.

4. Turn takehome projects and coding challenges into fully-fledged projects. Assuming you make it through the resume screen, a next step will be a coding challenge you need to submit. After submitting this challenge, don’t stop there. Continue the work and publish an even more polished solution online, with code on Github, tests in place, and a nice user experience. Consider spending a little money for a domain and hosting, and have this project be accessible to anyone—and add it to your resume.

If your takehome project doesn’t take you to the next round, ask for feedback, and build that feedback into this project. Once you publish a project you’re proud of, you can always send a follow-up to the company, showing them the improved version you’ve built. Don’t hold your breath—but who knows?

6. Be aware of the priority of your resume

The best advice on how to get the attention of a recruiter is to skip the inbound applications queue. You'll hear the advice on getting a referral often. This is because it does make a huge difference.

However, it's not the only thing that can help with your application. Being local to the company, or not needing a visa also makes a difference when being compared with candidates who are not in this category.

From a practical point of view: see if anyone's company in your network is hiring, and look at local opportunities, even at a time of remote work. You might have less competition, and better opportunities to stand out.

What your resume is for

The one goal your resume serves is to convey that you’ve got the experience that the position is looking for. In cases where you do have this experience, presenting this in a way that people will read it might be getting in the way - at least from the things that you can control.

I’ve written the book The Tech Resume Inside Out: what a good developer resume looks like. It's probably the most comprehensive book on this topic in 2020 and is free for any developer currently without a job: if you are in this situation, you can get a complimentary copy here.

I hope this advice was helpful. If you are job hunting: wishing you the best of luck!

If you enjoyed this post, you can subscribe to my newsletter on software engineering and engineering management, read other articles I wrote or check out my YouTube channel on software engineering content.

What part(s) of the tech interview process would you be interested in knowing more of?

Gergely Orosz — Wed, 20 May 2020 13:48:39 +0000

I've started writing a book to give an "inside out" view on the tech interview process. I still remember when I was doing my first interviews, not really knowing what to expect. Then, how I read up what the interview format is like at places like Facebook and different unicorns - going through lots of blog posts, some that contradicted each others.

Right now I'm a hiring manager and I've done hundreds of interviews the past years at large tech companies and startups. And when I talk with people about the interview process, they usually find it fascinating when I explain how recruiters work - and what their motivation is -, why coding itself is not the only thing you want to optimize for, ways people often fail the recruiter screen or how you can (and should) negotiate when you have an offer.

If you had access to a great tech recruiter, a hiring manager, and a technical interviewer, what questions would you ask them? What would you like to know more about, to help more both with your preparation, and your confidence in understanding the process, "behind the scenes"?

Ask the engineering manager: career development paths in tech companies from junior, through senior, to staff

Gergely Orosz — Mon, 13 Jan 2020 22:16:08 +0000

I'm a hands-on engineering manager, with a few years' of engineering management, and a decade worth of engineering across distributed systems, mobile, web and desktop development.

The past few years, I've been helping engineers on my team grow from junior, through senior to beyond senior positions, like staff/principal. I've had pretty good success and a great team to work with, on the way.

In an effort to give back, I've been blogging about my learnings. I've also started writing a book on how to grow, as a software engineer in tech companies, from small ones to larger ones like Microsoft, Uber, Facebook, Google and the like.

I'm be happy to answer questions on career development. - and your questions might also give me further inspiration for topics to cover in this book.

The Biggest Change in the Software Development Industry the Past 10 Years

Gergely Orosz — Thu, 02 Jan 2020 19:09:07 +0000

I've been a professional software developer for more than 10 years. With the decade ending, I did a reflection of major changes I've seen in the industry the past 10 years, across mobile, web, backend development and engineering careers. A lot has changed, from Javascript adoption, through iOS/Android growth and distributed systems becoming more accessible. One trend stood out though, that I think is more important than any technology innovation. It's how the "brilliant jerk" developer is slowly being pushed out from better developer teams and companies.

Brilliant jerk developers fading away. In 2010, the industry was filled with "brilliant jerks" and 10x engineers - guys who were supposedly great coders but had zero social skills. If you could not work with one of these people, the blame was on you. With more mature engineering management, managers (and teams) now realize how toxic these people are. Better companies don't hire people with toxic attitude. See also the No Asshole Rule book.

I've experienced this change firsthand. 2010-2015 I had the poor luck to work with a few of these individuals. They were ones who walked over others, were hostile to any form of constructive criticism and made others feel threatened - especially minorities on the team. Managers I worked with had no clue how to handle them, being too afraid to take action. They were afraid to confront them, let alone think of managing them out, as they saw these people were often the star performers on the team - on paper. This was not just small companies: Microsoft was a place I observed quite a few people roaming around.

Starting from around 2015, I am seeing lots of change in the right direction, towards inclusive and safe cultures and teams. People are sharing their negative experiences, calling out companies that handle situations like this poorly. Companies that get a reputation of being friendly to the "brilliant jerk" types see a sharp drop on talent wanting to work there. As an engineering manager, I say no to otherwise talented engineers, if they are hostile towards interviewers or display signs of being unable to take feedback or being overly defensive - characteristics of a brilliant jerk.

I also don't hire engineering managers who do not know how to deal with brilliant jerks on a team. There is only one good way to deal with a situation like this: give feedback, help the person change. If they don't: manage them out for the sake of the team, no matter how brilliant they might be.

Dev.to is a fantastic example of the "no brilliant jerks allowed" rule in action across an online community, making this a safe place for everyone to participate to the best of their ability. Unfortunately, there are still places that pay less attention to spotting people with this behavior, giving them direct feedback and educating teams about microaggressions and the inclusive workplace.

Fortunately, it seems we are at a turning point, as an industry. This is a topic I'm planning on actively exploring in my book on growing as a software engineer, and how role model senior engineers have a responsibility in leading by example on creating safe and supportive working environments - especially for beginners and those new to the company and industry.

Here's to hoping that by 2030 we'll look back and ask "What do you mean by a brilliant jerk? Haven't come across one of them in a decade..."

Readable Code

Gergely Orosz — Fri, 27 Dec 2019 16:08:13 +0000

Good code needs to meet two key requirements. First, it should be correct: when executing, it should produce the result that is expected. Second, it should be easy to read for other developers.

Coding is a social activity. Your code does not exist in a vacuum, just implementing a lone task. The code you write will be re-read by many other developers, who want to either understand or modify how your code works.

Why readable code matters

Why is readability so important? It's because checking if the is correct is relatively straightforward. Unit tests are excellent ways to do this, but manual tests or monitoring the system also help catch incorrect code.

While incorrect code cannot hide for long, unreadable code can go undetected for a long time. It keeps silent in the codebase until another developer comes along and tries to understand what the code does. They might be trying to fix a bug or adding a new feature. They might want to understand what this unreadable piece of code does and perhaps also need to change it.

When the code is not readable, the engineer changing the code next will burn a lot more time on what should have been straightforward work. They might misunderstand the code and use it in ways it was not meant to be used. They will then spend multiple iterations getting the change right. Or they might change the code, unintentionally breaking functionality elsewhere. If there are automated tests for the breaking functionality, this is only a minor annoyance. If there are no tests, this will lead to more problems and more time spent on making this change correctly.

In some cases, the other developers might spend so much time, failing to understand the code, that they might completely rewrite it: deleting the original code and writing a new implementation. Of course, when rewriting something completely, perhaps not all edge cases will be covered. This will result in more time spent on the rewrite than the time it took to write the original code.

The biggest risk that non-readable code brings is that it starts a pattern of poor readability. The engineer making a change burns a lot of time to figure out how the code should work. Instead of making the code more readable, they make the smallest possible change possible, resulting in even less readable code. And the person coming next will spend even more time understanding the code, unintentionally breaking the system, or just giving up, deleting the code and rewriting the whole thing.

Non-readable code is a large contributor to technical debt. While tech debt can build up for a variety of reasons - a lack of automated testing, lacking processes like CI or CD or poor onboarding and documentation - non-readable code is a major driver of the tech debt that slows teams down.

Readable code, together with well-tested code, are the two most important principles that pragmatic engineers follow. Readable and well-tested code is what makes refactoring, extending, and modifying parts of the system straightforward. Readable and well-tested code is the foundation of a solid codebase, where engineers are confident and quick to make changes.

What is readable code?

Readable code will mean slightly different things to each person. It varies between teams, companies, and programming languages. There are two groups of important people who are judges of how readable the code is: yourself and everyone else who will later read the code.

Readable code starts with code that you find easy to read. When you finish coding, take a break to clear your mind. Then try to re-read the code, putting yourself in the mindset that you know nothing about the changes and why you made them.

Can you follow along with your code? Do the variables and method names help understand what they do? Are there comments at places where just the code is not enough? Is the style of the code consistent across the changes?

Think about how you could make the code more readable. Perhaps you see some functions that do too many things and are too long. Perhaps you find that renaming a variable would make its purpose clearer. Make changes until you feel like the code is as expressive, concise, and pretty as it can be.

The real test of readable code is others reading it. So get feedback from others, via code reviews. Ask people to share feedback on how clear the code is. Encourage people to ask questions if something does not make sense. Code reviews - especially thorough code reviews - are the best way to get feedback on how good and readable your code is.

Readable code will attract little to no clarifying questions, and reviewers won't misunderstand it. So pay careful attention to the cases when you realize someone misunderstood the intent of what you wrote or asked a clarifying question. Every question or misunderstanding hints to opportunities to make the code more readable.

A good way to get more feedback on the clarity of your code is to ask for feedback from someone, who is not an expert on the codebase you are working on. Ask specifically for feedback on how easy to read your code is. Because this developer is not an expert on the codebase, they'll focus on how much they can follow your code. Most of the comments they make will be about your code's readability.

If both you and other developers are happy with how readable the code is, you're on the right track. Many principles can help the code become even more readable and more clear. But before you go too deep on these, focus on what matters. Focus on the code being easy to read for you, and for the people you work with.

Principles of readable code

There are numerous principles on what readable code is. For me, readable code means following these principles.

Single responsibility. All building blocks - classes, methods, variables - follow the single responsibility principle: every building block does exactly one thing. This makes it easy for the person reading the code to understand what this responsibility is. It also makes it clear what part of the code needs to change.
Well-structured. The codebase is easy to navigate around, as functions, classes, modules follow a logical structure. Formatting is consistent across classes and the codebase.
Thoughtful naming. Class, function, and variable names all help understand what is happening, and making reading more seamless. Code that has good names often had developers spend multiple iterations coming to these clear names.
Simple and concise. The code tries to be as humble and simple as possible. Developers don't use fancy tricks and also avoid over-complicating things. Functions are mostly short, making them easy to read. Classes are also not overly large.
Comments explain the "why," not the "how." Most of the code can be understood by itself. Comments fill in the remaining gaps.
Continuously refactored to keep being readable. Codebases grow. As a simple class gets more responsibility, it grows in size and complexity. Readable codebases stay readable due to continuous refactoring. The new, complex class might be broken into multiple parts or changed other ways to stay easy to read.
Well-tested. Well-tested code can be modified quickly and without fear of breaking things. Having the code tested via automated tests is important for the code to stay readable. Without tests, refactoring the code becomes risky, and developers eventually stop doing it. With tests, there is no excuse on why not to make even large and risky refactors, that keep the code easy to read.

There are many great books and other resources that go into far more depth on what readable code is and ways to make code more clear. I especially recommend the books The Art of Readable Code and Clean Code.

What does readable code mean to you?

This article was originally posted on The Pragmatic Engineer Blog

About me: I'm an engineer turned engineering manager, working at the intersection of Silicon Valley & European startups and tech companies. Follow me here and on Twitter. I am writing a book on growing as a software engineer - read more about it and sign up for updates on it here.

Don't Work Alone

Gergely Orosz — Thu, 05 Dec 2019 10:42:40 +0000

One of the recurring things that come to bite me and my team is having a less experienced engineer or new joiner work completely alone on a project for weeks or months. We’ve done this multiple times, and the results were always similarly dire. The engineer ends up building something slightly - or very - different than what we intended to. They took a lot longer to do it - and their morale was down, due to feeling lonely and unproductive this time. They did make mistakes, but did not have anyone give them feedback, to learn from it. Every time we sat down and did a retrospective on what to do different, next time, we agreed on the same thing: have someone to work with from the start.

Now, as a practice, I always make sure non-senior engineers don’t work completely alone, no matter how small the project at hand is. This often means that second engineer is a “part-time advisor” or buddy. This setup has worked far better. Now, the less experienced engineer has someone to bounce ideas off and plan with, someone to consistently review their code, and someone to hold them accountable to their progress. If they are a really productive and autonomous developer than the second engineer doesn’t have much work to do. However, if they are going down the wrong path, the other developer can help them out much earlier. Also, this setup is great for informal mentoring and faster professional growth.

If you find yourself working alone - and don’t have a manager who sets up some kind of pairing - then take steps to fix this. Ask another engineer on your team to be your buddy for the project, doing a quick check-in with you every day, and reviewing your planning and doing code reviews. If they politely decline, talk with your manager, and try to convince them of the productivity benefits for the team. Sure, the more experienced developer will need to spend more time with you, but in return, you will not only get things done quickly but also grow faster. Soon, you’ll be able to help others on the team, in a similar way.

This article was originally posted on The Pragmatic Engineer Blog

About me: I'm an engineer turned engineering manager, working at the intersection of Silicon Valley & European startups and tech companies. Follow me here and on Twitter. I write longer essays on software engineering on my blog, The Pragmatic Engineer. I also send a monthly newsletter with notes on software engineering, tech leadership and interesting things I've been thinking about.

On Getting Promoted as a Developer

Gergely Orosz — Sun, 06 Oct 2019 18:47:10 +0000

I've had a pretty good run with promotions lately. When I transitioned from being an engineer to management, I had eight people report to me. Two years later, all of them got promoted to the next level, as well as a few other developers, who joined my team later on. I've since helped people outside my team put together successful promotion cases and have been a member on a few promotion committees for engineers. Recently, I also got promoted to the next level of engineering management.

Promotions become a sensitive subject for developers, sooner or later. When joining a company, few people have this on their mind - rightfully so, as engineers are focusing on getting up to speed. But as time goes by, and as more and more people get promoted around them, promotions become top of mind for many. As a manager, it naturally became a topic I frequently found myself thinking about.

This article collects advice on promotions that I've been giving to engineers on my team - many of whom have since been promoted to that next level.

Do your preparation
Set your sight on the promotion
Get help & frequent feedback
Put in the work
Stay grounded
Help others

Do Your Preparation

Once you decided you have some interest in being promoted, start with gathering information on the basics, and assess how realistic a promotion for you is.

Understand the promotion process at your company.

Every company has a different process for promotion. While similar companies might have similar processes, but don't take this for granted. If there is information written down on the process, that's a great start. The best place to start with is asking your manager. As companies grow and mature, promotion processes change. The most common types of promotion processes I've observed are these three ones:

Informal promotions: managers decide who gets promoted. Several managers getting in a room, then coming out with a list of people promoted is the typical process for smaller startups and companies. In the meeting, managers present people on their team, and the group decides if they are ready for promotion.
Semi-formal promotion process with a manager-heavy promotion committee. As the company grows, getting all managers together becomes difficult and overly time-consuming. Also, the biases of the previous process start to be a lot more visible. Leadership will aim to put a process in place that is more scalable and fairer. This usually begins with writing down basic expectations for each engineering level and requiring managers to submit short documentation on why the engineer on their team is ready for promotion.
Formal promotion processes: promotion packages and committees. This is the type of process companies like Google, Uber, and several large tech companies follow. It requires having clearly and extensively defined job ladders, with clear expectations at each level. The idea is to make promotions as unbiased as possible. In return for a more fair and transparent process, far more documentation is produced. Extensive self-reviews, peer reviews, and manager reviews are written. A promotion committee formed of senior engineers and managers decides on whether the promotion can go through.

All approaches have their benefits and drawbacks. Know what your organization is following, so you have a better idea of how you and your manager will have to prepare for it.

Assess yourself

Most tech companies follow an approach of promoting people to the next level, who are already performing there. Promotions are usually a recognition that your impact and skills are consistently exceeding what is expected of you, and they are in line with what is the norm at the next level.

So how are you doing, compared to the next level? Answering this question is a lot easier when you work at a company, where competencies and levels are clearly defined in a document, that you can reference. Some good examples of well-defined competencies include the likes of Monzo, Square, or Rent The Runway. If your company has well-defined competencies, read through the expectations at your level, and the next level. Make a list of skills that you've demonstrated and the impact you've delivered and how it matches those expectations.

If your company doesn't have clear competencies and expectations, you still need to figure out how you are doing against current expectations. You'll also want to know what is expected to get to the next level. As a rule of thumb, to be considered for promotion, you're expected to do very well at your current level. So you can start with getting feedback on your current performance, talking with the person who is in the best position to give this feedback to you: your manager.

Get your manager on your side

No matter what process your company follows, if your manager does not support a promotion, you have very slim chances of getting there. So make sure to get your manager on your side. How do you do this? Ask them about how promotions work, what their philosophy on promoting is. Ask them how they would rate your current performance, compared to the current and the next level. Depending on your manager, you might decide to bring this up step by step, but you'll need to have an honest conversation about this, sooner or later.

This kind of conversation always felt awkward for me, as an engineer, and I avoided it for a long time, in my career. Looking back, I wish I hadn't. There's a simple reason why.

It is in the best interest of your manager for you to be promoted - when you are ready. Managers are judged by their ability to have their teams deliver better outputs. They do this by having their engineers be more efficient as a team. For the team to be more productive, engineers on the team need to grow to be more efficient, reliable, and senior. One of the externally visible indicators of growth is promotions. A promotion implies that the manager helped this person grow - either by mentoring, coaching, or just getting out of their way. A manager, whose team is becoming more senior indicates they are doing an excellent job cultivating talent.

So we know that promotions make managers look good. Still, there are plenty of developers who think "my manager would never promote me.". Ask yourself: why is that? A manager whose directs are stagnating starts to draw unwanted attention, both from above and from their team. If people keep getting average or poor performance reviews, never being up for a promotion, that also doesn't look good on the manager. So after you've asked yourself why your manager doesn't seem to want to promote you, ask your manager as well. It is in their best interest to tell you what the areas are that you can and should grow.

Be realistic in promotions above the senior bar

Typically, being promoted up to the senior level is mostly based on gaining skills, demonstrating those, and delivering impact. However, above the senior engineer level, other factors come into play.

First, there might be a budgeting limit to how many people can be promoted to higher levels. Some places require a business case on why a lead, staff or principal engineer is needed for a given team or area. If there's no business case, you might not be able to be put up for promotion. This is true even if you might have a fair chance of being promoted otherwise.

Second, above the senior engineer level, you might find it challenging to find projects that are large and impactful enough to warrant a promotion. For example, your team might be busy shipping small, incremental features, that have little complexity, but decent business value. You almost certainly won't be promoted beyond the senior level by just doing great work here. This is a case where you need to take ownership of your career and decide how to move forward. Do you wait around for a new opportunity to come by? Do you move teams, to lead work on a complex and impactful greenfield project? Do you propose a new initiative that has a massive business impact, convince stakeholders to kick it off, and end up leading it? There are no simple answers: you'll have to take the initiative, gather support, and ultimately take smart risks in your careers.

As you move up the career ladder, it gets harder and harder to get to the next level. It's a similar challenge on the developer ladder, as it is with management. Going from manager to director is usually similarly difficult, as it is going from senior engineer to staff or principle.

Set your sight on the promotion

Once you know how the promotion process works, have assessed yourself, and have your manager on your side, it's time to focus.

Set goals to close the gap on areas you lack for the next level

There will undoubtedly be several areas you need to either get better at or demonstrate impact. This might be ranging from areas like software engineering, executing with impact, designing solutions to complex problems, collaborating better with others, and many more.

Set S.M.A.R.T. goals that will help you get there - specific, measurable, attainable, realistic, timely. Set goals that are only dependent on you, not on external factors, like being given an opportunity. For example, if an area you've identified to improve is to get better on architecture, don't set a generic goal of you architecting a complex project. But you could set a goal of thoroughly reviewing at least one proposal per month, mentoring at least one junior engineer for 3 months on this area or reading a relevant book and presenting learnings to your team and organization the next 2 months. If you are confirmed to lead a project, you could set the goal of getting your proposal reviewed by two people senior to you, who are outside your team.

Act and take responsibility like you're already at the next level

There are two kinds of promotion cases. One is a dead-simple one: the engineer has, without doubt, been executing at the next level for a long time. The other one is more challenging: the person shows lots of promise, but there are a few areas where they fall short from the next level. This second type of promotion case is the coin-toss-type, where the outcome could go either way.

When you're working towards a promotion, aim to consistently perform at that next level: don't limit this only to your focus areas. If you're aiming for the senior level and your team's project is at risk, set up and help the whole project succeed. If your manager is asking for volunteers for a chore that is boring, but important and no one is stepping up, consider putting up your hand. On top of smashing this work, automate parts of it, to make it easier for the next person on the team to do it.

Keep a log of your achievements and impact

When the time comes for your manager or you to put together a promotion case, the first question will be on what you've achieved, that warrants this promotion. By that time, you will have forgotten much of the great work you've done. So get ahead of this and start writing up all the work you're getting done.

Start a brag document or something similar, that you continuously keep up to date. Share this with your manager, so they also are aware of all the work you're doing. No one knows the work you do better than you do. You'll likely surprise your manager with how many additional things you're getting done. And you'll make both of your lives easier when you do get put up for promotion.

Get help & frequent feedback

Working towards a promotion is no short process: it can range from a few too many months. It's easy to lose track of how you are doing and if you are still on target for demonstrating that you are at the next level.

Get a mentor in the company, to help you

While your manager is probably on your side with working towards a promotion, there is only so much feedback they can give you. You can speed up your professional growth by getting a mentor, who is another engineer.

Try to find a developer who is already at the next level. Even better, if they have been promoted within the company. Ask them for mentorship specifically on growing to the next level. Share your assessment and goals with them and ask for feedback and help on helping you grow to that next level.

Within my company, I've noticed that developers who proactively set up these kinds of mentorships saw multiple benefits. For one, they became a lot more strategic about how they wanted to based on feedback from their mentor. These mentors usually have been with the company for longer and helped the engineers navigate some of the not-so-well-documented parts of promotions. Second, even when they were not promoted, developers with mentors bounced back a lot easier. They had their mentor on their side, who were invested in them getting to that next level. This made it easier for these developers to pull themselves together, keep being great at their game and land that promotion the next cycle.

Ask for regular, explicit feedback

Setting goals and working towards them is one thing. However, especially when you're working towards a major milestone like a promotion, getting regular feedback on how you're doing is just as important.

Make a point to regularly present progress you think you've made to your manager. Ask feedback from them about your progress towards that next level. Have conversations early, on whether they support you being up for promotion at the next cycle. Even if the answer is "not yet," get them to help define actionable things, that if you complete, you will be ready for that next level.

Put in the work

If you've made it explicit to your manager and mentor that you are working towards a promotion, put in the work. In the months leading up to the nomination, double down on performing at the next level, getting things done and helping others.

Don't alienate your peers

A mistake I sometimes see engineers do is being so focused on their promotion is they end up damaging the team. Come promotion time, and they often end up not being promoted, as it's clear that they were the opposite of a good team player. More and more companies are careful - rightfully! - to not promote people who pull the team down.

Elbowing people out of the way to reach the goals that you set for promotion is a bad strategy. First, it's very short-term thinking. The same peers you might walk over might be asked for feedback at promotion time. But even if they aren't, it's a sign of immaturity. The more senior you get, the more you are expected to be a great team player while delivering solid results. It's not always an easy balance to strike. But if you catch yourself pushing ahead with your goal, in a way that upsets people on your team, consider changing your approach to be more collaborative.

Don't kick back, even when you feel things are in your pocket

Once, a developer set the goal with their manager, that if they successfully lead and ship ComplexProjectX, they will be up for promotion. The project went well, and the person went up for promotion. As this person heard the good news, they kicked back, letting go of the project, without delegating anything to others. As the project was rolling out, more and more issues surfaced, with no one taking action. Eventually, the rollout had to be reverted.

This happened right before the promotion committee met to discuss the case of this engineer. In the discussion, they agreed that while this person showed great skill in many areas, they displayed immaturity by disappearing the eleventh hour from the steering wheel. There was no communication and no good explanation of why this happened. The person was not promoted that cycle.

Stay grounded

Don't believe anyone who promises you a "sure promotion."

The first thing I tell all engineers on my team is that neither I nor any manager can guarantee a "sure promotion." If anyone tells this to them, don't believe it. I've seen too many developers getting burned by promises like this. Even with the best meaning manager, there are many reasons why that "sure" promotion won't materialize.

First, any manager can unexpectedly leave. The most common bitter story goes like this: "Manager X promised I'll be promoted, based on the great work I did. Then they left. My new manager did not honor this promise and decided against promoting me". The second reason is that any manager can misjudge either how well their direct is doing, or the political situation around promotions in the company. As tempting as it is to believe good news around "already in the pocket" type statements: don't. You're setting yourself up for disappointment if you take promises like this at face value, however sincere they might be.

Don't have promotion be your only goal

However well you might be displaying performing at the next level, and however much your manager supports you, you might not get promoted. If your only goal was the promotion itself, you'll be demoralized and might consider quitting and looking for a new job, just because of the outcome itself.

I once had an engineer who I strongly supported, and I was 100% convinced they would get that promotion. They still didn't, despite me fighting for this person, going high up the chain to make my case for them. After this, I became even more committed to helping this engineer be recognized in the next cycle. Luckily, this developer was not only focused on the outcome but cared just as much about growing in other areas. The next time, they smashed the promotion process and continue to have a high growth trajectory.

If your primary goals are about professional growth, even if you are not promoted, you will have gained valuable skills. These skills might be things like conveying engineering best practices, mentoring others, leading projects, sharing knowledge, and others. Focus on these skills over just the promotion. Promotions will a hit or miss, based on the process your company follows. But no one can take away your growth from you.

Promotion is not the only way to get positive feedback

Many people look at promotions as a validation of having done a great job. However, while a successful promotion does mean stellar feedback, most of the positive recognition you'll get won't be via promotions.

You'll get feedback every day from people who work with you, people saying things like "thanks," "you really helped me" or "I would have been stuck a lot longer without you." You'll get feedback from your manager and mentors. And, of course, there's that formal performance review, where your manager will also summarise the great stuff you did - along with areas to improve. Getting a bonus or a pay rise is also all positive feedback - and all of these will happen far more frequent than promotions.

Stay patient and be positive. It's a long game.

I've had a talented developer with a few years experience join my team, who was itching to get to the senior level. They had a friend who had been promoted to this level recently, and they felt that this friend was ahead of them. This person was frustrated when, after going through their self-assessment, I told them they have far too many gaps compared to the next level to go for promotion this cycle. I said that even if they put in the work, I can't see them going up for promotion before the next cycle, which was 9 months away. I suggested we put a plan together to make this happen.

First, this person was upset and thought I had it out for them. Slowly, after calming down, we put together a plan. Step by step, we made progress, and they started to realize just how much work they have to do. In the end, 9 months later, they got promoted. They still barely have 5 years experience and are already the senior level. For reference, it took me far longer time to get to the same level. Still, unlike them, I never felt behind.

Does an extra 6 or 12 months make a difference in your career? The earlier you are in it, the more you think it does. However, after a while, you might realize that it's not a sprint, but a marathon. While you might get promoted a few years into your first job, promotions will slow down over time: they'll be a lot more challenging to get.

Play the long game. Be positive and focus on your continuous professional growth. Treat your growth like a journey, not a competition of promotions. You'll be a lot more balanced by doing so.

Help Others

Getting promoted within a company is never an easy achievement. When you succeed with this, consider giving back and taking someone under your wing, helping them grow. Let others know you're open to mentoring others. If you see someone in your team, who has good potential to grow and you feel you can help, offer to mentor them.

Even if you've not yet been promoted, do help others grow and get recognized for their growth. If you work in a company that has a more heavyweight promotion process, with peer reviews, you might be asked by others to give peer reviews for their promotion. If you joined at a higher level, other engineers might approach you for advice on growth.

Don't forget that promotions are a recognition of your growth. And one of the best ways to grow is to teach others, via mentoring. Keep being approachable and helpful, and pay it forward. You'll learn more, make many allies, and your career will be a far more enjoyable journey this way.

This article was originally posted on The Pragmatic Engineer Blog under Software Engineering Promotions: Advice to Get to That Next Level.

Software Architecture: Clear and Simple Design is Underrated

Gergely Orosz — Tue, 24 Sep 2019 19:04:06 +0000

I had my fair share in designing and building large systems. I've taken part in rewriting Uber's distributed payment systems, designing and shipping Skype on Xbox One and open-sourcing RIBs, Uber's mobile architecture framework. All of these systems had thorough designs, going through multiple iterations and had lots of whiteboarding and discussion. The designs then boiled down to a design document that was circulated for more feedback before we started building.

All of these systems were large at scale: hundreds of developers build them - or on top of them - and they power systems used by millions of people per day. They were also not just greenfield projects. The payments system rewrite had to replace two, existing payments systems, used by tens of systems and dozens of teams, all without having any business impact. Rewriting the Uber app was a project that a few hundred engineers worked simultaneously on, porting existing functionality to a new architecture.

Let me start with a few things that might sound surprising. First, none of these designs used any of the standard software architecture planning tools. We did not use UML, nor the 4+1 model, nor ADR, nor C4, nor dependency diagrams. We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows, similar this one describing information flow or this one outlining class structure and relationships between components. Two diagrams within the same design document often had a different layout and were often added and modified by different engineers.

Second, there were no architects on the teams that owned the design. No IT architects or enterprise architects. True, neither Uber nor Skype/Microsoft have hands-off software architect positions. Engineers at higher levels, like staff engineers, are expected to still regularly code. For all the projects, we did have experienced engineers involved. However, no one person owned the architecture or design. While these experienced developers drove the design process, even the most junior team members were involved, often challenging decisions and offering other alternatives to discuss.

Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature, such as Martin Fowler's architecture guide. No mentions of microservices, serverless architecture, application boundaries, event-driven architecture, and the lot. Some of these did come up during brainstormings. However, there was no need to reference them in the design documents themselves.

Software design at tech companies and startups

So how did we get things done? And why did we not follow approaches suggested by well-known software architecture approaches?

I've had this discussion with peer engineers working at other tech companies, FANG (Facebook, Amazon, Netflix, Google), as well as at smaller startups. Most teams and projects - however large or small - all shared a similar approach to design and implementation:

Start with the business problem. What are we trying to solve? What product are we trying to build and why? How can we measure success?
Brainstorm the approach. Get together with the team and through multiple sessions, figure out what solution will work. Keep these brainstormings small. Start at a high level, going down to lower levels.
Whiteboard your approach. Get the team together and have a person draw up the approach the team is converging to. You should be able to explain the architecture of your system/app on a whiteboard clearly, starting at the high-level, diving deeper as needed. If you have trouble with this explanation or it's not clear enough, there's more work required on the details.
Write it up via simple documentation with simple diagrams based on what you explained on the whiteboard. Keep jargon to the minimum: you want even junior engineers to understand what it's about. Write it using clear and easy to follow language. At Uber, we use an RFC-like document with a basic template.
Talk about tradeoffs and alternatives. Good software design and good architecture are all about making the right tradeoffs. No design choice is good or bad by itself: it all depends on the context and the goals. Is your architecture split into different services? Mention why you decided against going with one large service, that might have some other benefits, like more straightforward and quicker deployment. Did you choose to extend a service or module with new functionality? Weigh the option of building a separate service or module instead, and what the pros and cons of that approach would be.
Circulate the design document within the team/organization and get feedback. At Uber, we used to send out all our software design documents to all engineers, until there were around 2,000 of us. Now that we're larger, we still distribute them very widely, but we've started balancing the signal/noise ratio more. Encourage people asking questions and offering alternatives. Be pragmatic in setting sensible time limits to discuss the feedback and incorporate it, where it's needed. Straightforward feedback can be quickly addressed on the spot, while more detailed feedback might be quicker to settle in-person.

Why was our approach different from what is commonly referred to in software architecture literature? Actually, our approach is not that different in principle, to most architecture guides. Almost all guides suggest starting with the business problem and outlining solutions and tradeoffs: which is also what we do. What we don't do is use many of the more complex tools that many architects or architecture books advocate for. We document the design as simple as we can, using the most straightforward tools: tools like Google Docs or Office365.

I assume that the main difference in our approach boils down to engineering culture at these companies. High autonomy and little hierarchy is a trait tech companies and startups share: something that is sometimes less true for more traditional companies. This is also a reason these places do a lot more "common sense-based design" over process-driven design, with stricter rules.

I know of banks and automotive companies where developers are actively discouraged from making any architecture decisions without going up the chain, getting signoff from architects a few levels up, who are overseeing several teams. This becomes a slower process, and architects can get overwhelmed with many requests. So these architects create more formal documents, in hopes of making the system more clear, using much more of the tools the common literature describes. These documents also reinforce a top-down approach, as it is more intimidating for an engineer, who is not an architect, to question or challenge the decisions that have already been documented using formal methods, that they are not that well-versed in. So they usually don't do so. To be fair, these same companies often want to optimize for developers to be more as exchangeable resources, allowing them to re-allocate people to work on a different project, on short notice. It should be no surprise that different tools work better in different environments.

Simple, jargonless software design over architecture patterns

The goal of designing a system should be simplicity. The simpler the system, the simpler it is to understand, the simpler it is to find issues with it and the simpler it is to implement it. The more clear language it is described in, the more accessible that design is. Avoid using jargon that is not understood by every member of the team: the least experienced person should be able to understand things equally clearly.

Clean design is similar to clean code: it's easy to read and easy to comprehend. There are many great ways to write clean code. However, you will rarely hear anyone suggesting to start with applying the Gang of four design patterns to your code. Clean code starts with things like single responsibility, clear naming, and easy to understand conventions. These principles equally apply to clear architecture.

So what is the role of architecture patterns? I see them similarly in usefulness as coding design patterns. They can give you ideas on how to improve your code or architecture. For coding patterns, I notice a singleton pattern when I see one, and I raise my eyebrow and dig deeper when I see a class that acts as a facade, only doing call-throughs. But I've yet to think "this calls for an abstract factory pattern". In fact, it took me a lot of time to understand what this pattern does and had my "aha!" moment, after working with a lot of dependency injection - one of the few areas, where this pattern is actually pretty common and useful. I'll also admit that although I spent a lot of time reading and comprehending the Gang of four design patterns, they've had far less impact on becoming a better coder than the feedback I've gotten from other engineers on my code.

Similarly, knowing about common architecture patterns is a good thing: it helps shorten discussions with people, who understand them the same way as you do. But architecture patterns are not the goal, and they won't substitute for simpler system designs. When designing a system, you might find yourself having accidentally applied a well-known pattern: and this is a good thing. Later, you can reference your approach easier. But the last thing you want to do is taking one or more architecture pattern, using it as a hammer, looking for nails to use it on.

Architecture patterns were born after engineers observed how similar design choices were made in some cases, and those design choices were implemented similarly. These choices were then named, written down, and extensively talked about. Architecture patterns are tools that came after the solution was solved, in hopes of making the lives of others easier. As an engineer, your goal should be more about solving solutions and learning through them rather than picking a shiny architecture pattern, in hopes that that will solve your problem.

Software architecture best practices, enterprise architecture patterns, and formalized ways to describe systems are all tools that are useful to know of and might come in handy one day. But when designing systems, start simple and stay as simple as you can. Try to avoid the complexity that more complex architecture and formal tools inherently introduce.

This article was originally posted on The Pragmatic Engineer Blog under Software Architecture is Overrated, Clear and Simple Design is Underrated, which post contains a section with tips on getting better at designing systems.

Growing the product-minded software engineering muscle

Gergely Orosz — Tue, 17 Sep 2019 11:51:41 +0000

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. I've worked with many great product-minded engineers and consider myself to be this kind of developer. At companies building world-class products, product-minded engineers take teams to a new level of impact.

Sherif Mansour, PM at Atlassian wrote an excellent article on product engineers, and how product managers can identify these people and work well with them. His takeaway is similar:

Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager.

He also quotes Jean-Michel Lemieux, head of engineering at Shopify who defines product engineers like this:

Once you have the product foundations, you need devs who engage with the 'why', actively. Engineers who have the thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books. Bad ones cut too many corners. Great product engineers know that minimum lovable products need the right depth to be considered during the build phase.

Teams who are working on user-facing features, collaborating with product managers are environments where product-minded engineers can have a huge impact. They often become key contributors, the goto people for product managers and frequently advance to being team leads. So, what are the key traits of product-minded engineers, and how can you work on becoming more product-minded? This article summarizes 9 traits I've observed these kinds of people share, and my suggestions for any engineer to grow their product-minded muscle.

1. Proactive with product ideas/opinions

Product-minded engineers don’t settle for getting a specification and jumping to implement it. They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better.

2. Interest in the business, user behavior and data on this

When coming with ideas, product-minded engineers don't just get these from thin air. They take the time to understand how the business works, how the product fits in, and what its goals are. They are also empathetic about how the product makes users feel and how those users benefit from using this product. They often dive straight to data about business and user metrics, getting their hands on this data however they can. They might access it directly - if this is possible - or approach the product manager or data scientists to get this kind of information. They do this because of their curious nature. This is the next trait I've observed.

3. Curiosity and a keen interest in "why?"

Product-minded engineers like to understand the "why?" behind all things. Why build this feature for the product, why not the other one? Why ship this first milestone, instead of choosing another one, that's a lot simpler to build? How will things be measured - why don't we choose a more thorough way to measure things?

They are autonomous in finding answers they can, by themselves. They turn to the product manager and other people in the business for other, product-related questions. Even though they ask many questions, doing this frequently, they manage not to annoy people, as they've built up strong relationships with them.

4. Strong communicators and great relationships with non-engineers

Product-minded engineers like talking with people outside engineering, learning about what and why they do. They are smooth communicators, making it clear they're interested in learning more about how other disciplines work. I frequently see them grabbing coffee, lunch, or doing a hallway chat with non-engineers.

5. Offering product/engineering tradeoffs upfront

Because they have a strong understanding of the product "why," as well as the engineering side of things, they can bring suggestions that few other people can. For example, when scoping the effort to build the product, the engineering effort to build a key feature might be significant. Many engineers would start to look for ways to reduce the effort and try to figure out what the impact of the reduced effort would mean for the feature itself.

Product-minded engineers attack this problem from both angles: both looking for engineering tradeoffs and what the product impact is. They also start making product tradeoffs, evaluating the engineering impact. They often go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller.

Juggling both the product and engineering tradeoffs and the impact of each is a unique strength product-minded engineers have. They can quickly go back-and-forth between the two sides of the same coin: product features and engineering effort and tradeoffs. Because they do it all in their head, using their engineering and product insights, they get to valuable conclusions remarkably quickly.

6. Pragmatic handling of edge cases

Edge cases are a funny thing. On one extreme, engineers often forget about many of these, having to come back to addressing them, after getting feedback from people testing the product or end users. On the other hand, handling all possible edge cases in a new product or feature can take a lot of time.

Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work. They are focused on the "minimum lovable product concept" and evaluate the impact of an edge case and the effort of handling it. They come with good middle-ground suggestions: mapping out most things that can go wrong and bring suggestions on what edge cases need to be addressed, before shipping even an early version.

For example, if one in a thousand users might be hit by an error, they will consider the effort to fix it and think about what happens if they don't do anything. Can customer support help the person in this case, during validation? Can the user just retry and succeed the next time? Can the product be slightly modified, so this edge case won't occur?

7. Quick product validation cycles

Even before the feature they are working on is production-ready, product-minded engineers find creative ways to get early feedback. This could be doing hallway testing with colleagues, showing the work-in-progress feature to the product manager, organizing a team bug bash on the beta build, and many other, creative ways. They are continuously thinking:"how can we validate that people will use this feature, the way we think they will?"

8. End-to-end product feature ownership

Most experienced engineers own their work end-to-end: from getting the specification, through implementing it, all the way to rolling it out and validating that it works correctly. Product-minded engineers often go a step beyond this.

They consider their work done only after getting results on user behavior and business metrics. After rollout, they still actively engage with product managers, data scientists, and customer support channels, to learn how the feature is being used in the real world. It can take weeks to get enough reliable data to draw conclusions. Even though they might be working on a new project, they make checking on the results one of their top priorities. It's not a time-consuming activity, but it needs that additional persistence from someone wanting to know: how is my work really doing?

When a feature performs worse than expected, they are curious to understand where the mismatch was. They are just as interested in finding the root cause between the product plan and the real world result, as they are to debug a hard-to-reproduce bug in the codebase. They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.

9. Strong product instincts through repeated cycles of learning

A typical project for a product-minded engineer usually goes like this:

They ask a lot of questions to understand exactly why the product feature is being built.
They bring suggestions and tradeoffs to the table, some of which are included in the revised spec.
They build the feature quickly, getting early feedback, as they do.
After shipping the feature, they actively follow up to understand if the feature lives up to the expectation.
When it does not, they dig deep, to understand why it did not and learn something new about product usage in the real world.

After each project, their product understanding deepens, and they start to develop better and better product instincts. The next time, they'll bring even more relevant suggestions to the table. Over time, they become a goto person for product managers, their advice being sought well before projects are kicked off. They build a strong reputation outside the team, opening more doors for their continued career growth.

Tips to become a more product-minded engineer

If you work on a user-facing product, here are a few tips I've seen work well, to growing your product-minded muscle.

Understand how and why your company is successful. What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?
Build a strong relationship with your product manager. Most product managers jump on the opportunity to mentor engineers. Having engineers be interested in product means they can scale themselves more. Before coming in, asking a lot of product questions, take time to build this relationship and make it clear to your product manager, that you'd like to get more involved in product topics.
Engage in user research, customer support, and other activities, where you can learn more about how the product works. Pair with designers, UX people, data scientists, operations people and others, who frequently interact with users.
Bring well-backed product suggestions to the table. After you have a good understanding of the business, the product and stakeholders: take initiative. You could bring small suggestions to a project you are working on. Or you could suggest a larger effort, outlining the engineering effort and the product effort, making this easy to prioritize in the backlog.
Offer product/engineering tradeoffs for the projects you work on. Think of not only making engineering tradeoffs for the product feature your team is building but suggest product tradeoffs that result in less engineering effort. Be open to the feedback on these from others.
Ask for frequent feedback from your product manager. Being a great product-minded engineer means you have built up good product skills, on top of your existing engineering skillset. The best person to give you feedback on how you're doing on the product skillset is your product manager. Reach out for feedback on how valuable they see your product suggestions and ask for thoughts on areas for further growth.

This article was originally posted on The Pragmatic Engineer Blog under the product-minded software engineer.

Hacks to Grow as a Developer: Grab Coffee with an Experienced Engineer You Don’t Know

Gergely Orosz — Wed, 11 Sep 2019 10:07:30 +0000

While I do my best to keep doing networking, I have to admit that I don't think I'm that good at it. At least the traditional sense of go-to-a-meetup-and-talk-to-people type of networking. This is despite me being an extrovert and having attended many meet-ups and tech conferences, doing small talk with lots and lots of people. Still, I rarely felt that I got much out of a five-minute lightning conversation, beyond saving contact details for later or adding the person on Twitter or Linkedin.

A surprisingly efficient networking method I found was doing cold reach-outs to more experienced software engineers, offering to buy them coffee or lunch. In exchange, I asked them to share their advice on {topic they are experts on, and I'd like to get better at}. This is kind of like cold sourcing for hiring. Except it's not about hiring and you're not a recruiter. You're not selling anything, but asking for advice on something they are busting with advice on. These are the things that bring the chance of getting a response from a developer from zero to quite likely to respond.

I started doing this when I started at Skyscanner in London. It was a new and small office at the time, and I missed having people around me to learn from. I set myself the goal to meet one person per month. I started by both asking around friends for recommendations of the best people they've ever worked at. I also browsed my second-degree Linkedin connections, then shooting off a message to them, being clear on TODO. Here's the type of messages I would send out:

Hi X,

Y recommended I reach out to you as one of the best iOS engineers he's worked while at CompanyY. At Skyscanner I'm the first - and currently, only - iOS engineer in our new London offices and a relatively new tech lead as well and I'm looking for people to learn more from.

If you have time, love to buy you a coffee or lunch at a time and location that works conveniently for you. I'm really interested to chat about your experience on leading a team while being a top individual contributor, as well as any advice you might have about balancing tech work, recruiting and mentoring others. In return, I'd be happy to share my views on iOS, how I'm approaching building a new app and anything else that you might find interesting.

I also understand that you might be busy, so no worries if you wouldn't have the time!

To my surprise, almost all engineers accepted, and we set up coffee or lunch, having a great conversation. I met many interesting people this way, some of whom I'm still regularly in touch with. I put decent effort into these reachouts and here are a few, useful ground rules on reaching out this way that help setup good conversations.

Shared connections help with these kind of reach-outs. The software development industry is small and assuming you know a few people local people, and probably already have hundreds of second-degree connections in your local area. It's nice when the reach out does not come from a complete stranger.
You're the one asking for a favor - be clear on this to yourself. This means you'll want to accomodate around the other person for time and location. Make it easy for them.
Think of what you can offer, in return. You might feel that you have less to offer, but do some research on what this person does. Especially if you are meeting someone who is more of a peer - like I had, in many cases -, offer to share your experience on the field.
Be early and come prepared. You want to get the most out of this time, so draft up topics you'd like to get their input on. Try not to be late.
Pick up the bill, no matter what the other person suggest. Again, it was them who volunteered the time
Pay it forward/pay it back. The next time someone reaches out to you, try to think of ways of having a conversation that fits into your already busy schedule. If you already used this method, you're just paying back. If you're being reached out of the blue, try saying yes and see what happens.

What I did not expect was this approach to be far more valuable than just a one-off networking session. In all cases, I had fascinating conversations on problems they were facing and found myself explaining the biggest challenges on my plate. Sometimes, these were problems that I've been working on for weeks. After this conversation, I always came away filled up with ideas, inspiration, and often with a new solution in mind for the difficult problem I was facing. I also came away learning a lot about how other companies work, how another person approaches problems, and what they think about different technology topics.

Another thing I got out of these sessions was validation. Either myself or the other person would talk about an unconventional thing I was doing, that few people talked about online. Quite a few times, I found out that it wasn't all that unconventional - they were either doing, have done or planning to do the same thing. For example, this was the time when the internet was full articles on how moving fast and breaking things works so well for Facebook - and all startups would be wise to follow. I worked at a startup, on a small product, but had my own reservations. In these conversations, I got validation that others feel the same way, which led me to writing down my thoughts on the dilemma of moving fast without breaking things.

These sessions were far more of a refresh than I expected them to be. It was so nice to step out of my day to day work bubble and talk about professional things about someone who works in the industry but in a different place.

Developers buying coffee and having a chat with other, local developers is an underrate hack for professional growth. It is also under-used. I know this because although I reached out to many experienced engineers to meet them and learn from them, I've had very few people reach out to me this way. On one end, I'm not surprised: cold reach-outs are weird to do, and it takes guts to do this. On the other hand, I'm telling you: you do it. Do it to learn about what it's like to work at another company. Do it to get tips from them on how to become a better engineer or other things you admire them for.

Whenever I get a reach-out from a person in the local developer community, I make a point to try to make time for this. I do this, frankly, because it's a lot of fun. It's also learning something new for me. It might help with career opportunities for either of us, down the line.

I find catching up like this also to be inspiring and something different from my day-to-day. Just how inspiring? This post would not have been written if a developer in Amsterdam had not reached out me this way. They wanted to chat more about what it's like to work at Uber and how it's different to freelancing and agency work, that they have experience with.

It was a great chat. We need more of these.

This article was originally posted on The Pragmatic Engineer Blog under Growth hacks: coffee with an experienced engineer you don’t know.

About me: I'm an engineer turned engineering manager, working at the intersection of Silicon Valley & European startups and tech companies. Follow me here and on Twitter. I write longer essays on software engineering on my blog, The Pragmatic Engineer. I also send a monthly newsletter with extended notes on software engineering, tech leadership and interesting things I've been thinking about.

I've worked at fast-growing startups and Silicon Valley tech companies for the past seven years. AMA.

Gergely Orosz — Mon, 09 Sep 2019 13:58:07 +0000

I've been working at well-known tech companies since 2012, in London and Amsterdam: at Skype/Microsoft (when Microsoft acquired Skype), at Skyscanner (when it became a unicorn) and at Uber for the past three years. I've had many conversations with people online and offline on what it's like to work at places like this, compared to other environments: from what the work culture is, to how things get done, how things are tested or how much truth there is to some of the articles you might read online - and many more.

Feel free to ask anything about work, career, engineering practices or anything else you find interesting or are wondering about.

As a disclosure, I can't talk on behalf of the companies themselves - they're all very large, so whatever my observation was, might not be true for all parts (and it might also be outdated knowledge). I can definitely share my experience, learnings, and patterns I've seen to hold across these kinds of places.