DEV Community: Ryan Latta

You’re Agile, Now What?

Ryan Latta — Fri, 10 Nov 2023 00:00:00 +0000

Let’s face it: agile conquered the world of software development. Often, though, I find people are dissatisfied with the results, and in this article, I want to point out a few common things that folks struggle with and what you can do to get some of the results that Agile or Scrum promised.

Estimation and Predictability

The biggest cause of heartburn I see is how teams plan, estimate, and then deliver work within an expected planning window. This isn’t a new problem, just that when folks move to Scrum, there’s an implied expectation that all the fuss around velocity will make things easier and predictable.

I hate to break it to you, but story points, estimation, and velocity are different ways of failing at the same problem.

So let’s stop beating that dead horse for a moment and talk about other ways to look at this problem that keep the spirit of agility intact while also helping answer that age-old question, “When will it be done?”

If we look at any team, and it doesn’t matter how they estimate and plan, we often see a few patterns emerge. We’re looking for the number of work items they complete each sprint cycle. This number tends to converge around a fairly tight range for teams. That’s the number we’ll begin to use going forward.

A fictional team tends to complete 3-5 things each sprint. Want to know when they will finish some work? Count down the backlog and divide that number by the amount they get done. The result is a better, though still imperfect, number of sprints it will take the team to get to that work.

There’s a better version of this, using Monte Carlo simulations, which any PMP should be able to set up for you, but I’m not explaining how to do that within this article.

Equipped with a different yet simple way to say how many sprints for work to finish does wonders for relieving stress and building up trust while also drastically cutting down on the number of conversations around velocity.

Improvement

Folks hate Scrum for how many meetings it has. I get it. I’d hate it if I had to sit through all those often poorly facilitated meetings.

The reason for those meetings is to create a series of feedback loops that the team can use to improve.

If you’re not seeing much improvement with your agile teams, your meetings suck.

Let me break it down this way. The Daily Scrum provides feedback on each day and can be an excellent 15 minutes. The Retrospective provides feedback on the process, team, and product. The Sprint Review provides feedback on the team and product.

All of that feedback, when gathered, can provide deep insight that leads to improvement. If the meetings suck, though, it all falls apart.

I recommend finding a skilled facilitator for these meetings to get teams to improve more rapidly. This facilitator probably isn’t the current coach or Scrum Master. Focus on the Sprint Review and Sprint Retrospective first. They provide the sharpest feedback and mechanism for improvements.

Agility

Okay, this is the obvious one here, but the big promise of agility is the ability to make more impactful decisions rapidly. This is possible by keeping feedback cycles short and having explicit decisions built in.

We improve processes during Retrospectives. We adjust the product in planning and review. We adjust development during planning and Daily Scrum, etc.

Now, while most of us love how adaptable we become if we go agile, we rarely take advantage of this new capability. We still think and work on large chunks of work instead of small ones. Those large chunks take so long the feedback and decisions are dampened.

So, what can we do? The idea is fairly simple, though it takes a fair bit of adjustment. We want to move away from looking at things as a single large chunk like an MVP or roadmap milestone and instead look to much smaller ones within it.

Let me give an example—a company focusing on an MVP. Everyone is looking at the chunk of the entire MVP. That’s one lens that would only provide feedback after months of work. So we make many smaller chunks out of that MVP now. Examples could be that we have some customer feedback on the onboarding process, that customers find the design intuitive, that we have an early commitment from customers to buy, or that we’ve been able to do a safe deployment to prod. Each of these smaller chunks is about getting feedback on the work we’ve done and not so much about how many items we completed.

Chunking for smaller feedback cycles on outcomes is what allows feedback and decisions. If you only look at chunks as scope, the only feedback is if it’s done or not. If you chunk along smaller outcomes like customer delight during onboarding, your feedback is touches scope, design, development, etc., and you have many more decisions available.

These smaller chunks may only sometimes be relevant to senior leadership who look at things on longer horizons. Still, they will appreciate the updates and see things moving well and risks managed. Also, if you’re going to miss a date, the conversation gets a lot easier when they trust that you’ve made many smaller bets very well instead of betting it all on the one big MVP at risk.

So there you go, three things that organizations everywhere struggle with after they adopt Scrum or some other agile framework. Agility isn’t broken, nor is Scrum. The hiccup is that many folks haven’t realized all of the advantages, and small shifts in existing behaviors and perceptions will help everyone realize those advantages instead of suffering buyer’s remorse.

When Abandoning Code Reviews Leads to Better Results

Ryan Latta — Wed, 15 Sep 2021 00:00:00 +0000

The first time I was on a team that abandoned pull-requests and code reviews was back in 2011. I would keep pushing the groups I was in to do the same because the results were much better than the branch-based code reviews.

But First, Why Code Review?

In a nutshell, more eyes are better than just one. Even highly skilled developers make mistakes. So a code review puts a gate in place where more developers come and look at the code before it is merged back into the rest.

Also, while checking for mistakes is of significant benefit, code reviews often serve as one of the primary means for development teams to provide qualitative feedback on the code itself. During the code review, they discuss design, architecture, and larger goals for fixing up the code and technical debt.

To Abandon Reviews, We Must Solve A Riddle

I owe credit to this riddle to one of my first managers who asked:

“What’s so hard about writing a line a code, knowing it won’t break, and pushing it?”

Solving that riddle is what allows a team to abandon code reviews and big merges.

Sadly, simply writing all the answers here isn’t going to help 90% of the folks who read it because they can easily say, “Well, what about…” to just about everything. So I’m going to leave this riddle for you to solve. But let’s address how we maintain the benefits of a code review while abandoning the practice.

Checking for Errors

This one is a lot easier than it sounds. While I’m not going to go into some big thing about the role of QA or whatnot, I’ll go ahead and assert that most groups treat quality as something they deal with later.

Find out if it works in the code review, for example.

To abandon code reviews is to abandon this attitude. Developers must grow in their skill and sense of personal responsibility to only put forth code that they are confident works. When a developer has this attitude and develops the skill, the chances of them producing a significant bug drops to the point where teams can go months without outages.

Design Quality

Now this one is a little trickier. Though if we think back to how the design discussions happen, it’s because people are looking at code together.

What if, and stay with me here, developers did this throughout the development process instead of just at the end?

Like, instead of building a house and then asking what they think, consult throughout the process from concept to implementation?

Several short conversations are pretty easy compared to one large review.

Oh, and if you want to go further, this is why Pair Programming or Mob/Ensemble programming exists. You harvest the best of others throughout the entire process.

It works.

Change Failure

Let’s compare two developers. One traditionally builds a feature, seeks a code review, and merges. The other ships one line at a time, no review, and no merge.

There’s an outage.

Now, when the effort to go isolate the change begins, they take very different courses.

The feature-builder isolates the bug to their feature, but because it was all produced as a large lump of code, they have to fix it as a lump. The whole change needs to get tested and rechecked since all aspects of the feature were bundled up.

The single-line developer realizes the bug is theirs and reverts the single line of code reflexively or fixes the one line quickly.

The traditional developer starts a whole new dev cycle to address a bug buried in their feature-level change, but the other addresses a single-line change. The level of risk and effort is massively different.

This Is Hard, and Uncommon

I’ve had the fortune of doing this trunk-based style development in all manner of environments and domains, which has given me confidence that I can say it is effective in environments with lots of compliance and legal concerns and ones that don’t.

It is hard to do, though. People are truly terrified of what quality issues will arise if they don’t stop and look, but the hiccup is that a review didn’t prevent the error. It just sees it. The way we work that produces errors remains intact. Solving that riddle solves the way we work and nearly eliminates our ability to produce errors.

With that, I’d invite you to discuss the riddle with your team. Let people get uncomfortable with it.

Working in Public: Experiment in Failed Marketing

Ryan Latta — Tue, 14 Sep 2021 00:00:00 +0000

Tomorrow I’ll formally close on an experiment that I’m willing to call a failure a bit early. Why share all of this? Trying, looking at the results honestly, and moving on is a crucial aspect of building any product.

So here’s my latest failure.

Background

I coach tech folk to get jobs and negotiate on the side. This came to a head this year when I was juggling multiple clients and my full-time consulting. So I made an online class.

If you build it, they won’t come.

I’m not good at marketing at all. So I signed up to join a class to help market my online class. The application required that I get 100 people to express interest in about one week.

The Hypothesis

I believed that if I focused my energy on three marketing efforts, I could get 100 sign-ups. They were as follows.

Engage almost daily in career-oriented tweets
Send out pre-written social media on LinkedIn and Twitter 4 times a week
Publish articles to my site and dev.to
Notify my newsletter readers

You might wonder where the step where I build a landing page is. I already built that and had a practiced copywriter look at it and give it a thumbs up.

Results

I got 2 sign-ups—just two. I have about 800 or so followers across Twitter and LinkedIn, my newsletter crowd is around 100, and I have 1200 followers on Dev.to.

While the algorithms on social media aren’t kind, conceptually, I had enough reach to get to plenty of folks.

I’d be lying if I said this doesn’t sting. That’s sometimes part of how the feedback goes. I got a result I didn’t want.

What Next

Well, I’m forming a conclusion based on what I see. While I put forth a valiant effort, the first is that it was more of blasting content and ineffective at driving people to my landing page. This is a well-known thing about social media. Without a bigger and more engaged following, most of my efforts won’t pan out.

Next, getting a job isn’t a constant thing for folks. It happens every so often, so while people might think that what I’m offering might be useful someday, it isn’t pressing today. To put it another way, of all the people who might have seen my posts, a very small number are thinking about jobs.

So I need to find a better way to get to my audience or become a more permanent fixture in the career world.

Someone I’ve followed for a while who built a whole business out of this is named Latesha Byrd, so I know this is possible, but I haven’t cracked the formula yet.

Then, while I was kind of down on myself, something cool happened. People I don’t know started a conversation about my book!

I’m not completely decided yet on exactly where I want to focus my efforts next to get my course off the ground, but there’s an ember of an idea forming. I am sure that I don’t have enough reach to the right audience, and that leaves two obvious choices: Find a way to target better or shift my focus from getting a job to future-proofing your career.

What Recruiters Don’t Tell You

Ryan Latta — Tue, 07 Sep 2021 00:00:00 +0000

At some point, you’ll get a message from an external recruiter. Maybe it’ll be clever and have some Star Wars reference because all technical folk love Star Wars apparently. It might also be full of misspellings and so off-mark that you wonder why they even bothered.

No matter what, you’ll wind up working with a recruiter, and there’re a few things they aren’t going to tell you that will absolutely impact how easily you get a job.

So here’re things they won’t tell you.

I don’t know anything about development

That’s right! Recruiters don’t know anything about the field of software development. A quick search for them on LinkedIn will point this out.

So when they’re telling you about all the positions, how on earth are they deciding which ones you’re good for and not? Well, they can’t. That is something you have to tell them. They don’t know what React is, or why Javascript and Python are different.

This is also why they can’t ever give you real advice about interviewing. They have no idea what kinds of questions you’ll get asked or what the question even means.

I’ve never worked at these companies

Kind of hand-in-hand here, but recruiters don’t spend any significant time with the companies they represent. They bring clients in, have conversations with their clients, and get feedback when they take people out to lunch.

Beyond that, they have no idea what it’s like in that company. So when they tell you that it’s a great place to work, keep some skepticism in place and see for yourself.

They’ve never dealt with the stress of being there, the camaraderie that exists or doesn’t. They don’t know how the managers actually manage or lead. They’re an outsider and taking what they say on face value about the culture of a place can be disastrous.

I’m going to use your resume and salary information the way I think is best

Recruiters are going to change your resume. The types of changes they make vary, but minimally they’ll reformat it to their stationary. Maximally they’ll re-do it entirely.

I’ve seen recruiters add technologies, re-write experience sections, and more.

Ask to see the resume they’re sending out! You want to know how you’re represented.

One simple mistake recruiters make pretty regularly is when they drop your content into their stationary, they forget to check if they changed the name consistently. So the first page has your name, but the second page doesn’t.

A hiring manager who sees a resume with different names must assume they’re being lied to and will likely throw it in the trash.

Almost every recruiter will also ask about your salary history or goals. They will use this to help filter positions and sometimes use this to “Negotiate” for you.

I wish I could say that recruiters are highly skilled salary negotiators, but I can’t. Since you won’t be in the room when they tell your future company what you made or what you want to make, you have no idea what leverage you have to negotiate at all anymore.

My goal is to get you an offer

They might tell you this, but why I’m calling it out is to make it crystal clear who they work for and what success looks like.

Recruiters are paid by companies to help them fill positions. On average, a recruiter’s fee is 20-30% of the first year’s salary.

So while they are talking to you, they’re looking at a series of positions to fill. If push came to shove about finding an ideal role for you vs. filling a position, they’ll do their job and fill a position. If that is more idea for you, so much the better!

That isn’t to say there’s maliciousness here, but it’s also why you don’t go through lengthy getting-to-know-you steps with recruiters. If you think a position is good, they are going to see it through.

Recruiters’ intent to get you through interviews to an offer is really helpful! I don’t care who you are, but as soon as you want to apply to a company, everyone will go on vacation. Recruiters won’t wait for them to come back and will get everything re-scheduled. When most people’s interview process might take months, a recruiter will get it done in weeks.

That’s awesome.

Should you work with recruiters?

Yes! Absolutely you should. They have access to positions nobody else can get. They will get you through the process better than anyone. They can get feedback along the way. They are worth it!

Just know what they’re good at and what they aren’t. It’s fine to set expectations with recruiters upfront. It’s interesting how both sides of developers and recruiters seem to be unaware of what each other knows and doesn’t.

So talk to them.

If you like this article I'd love your attention for one extra second. I've been helping developers navigate getting jobs and negotiate for years now and I could use your help!

I'm putting together a class and I want to know if you're interested in it. Signing up tells me your interested. If you aren't I want to hear why!

👉Check it out

images courtesy of Unsplash

Does Continuous Improvement and Delivery Make You Agile?

Ryan Latta — Thu, 02 Sep 2021 12:56:13 +0000

I try not to get involved in arguments — but when a debate started in the Dev Interrupted Discord about if exceptional continuous improvement (CI) or continuous delivery CD) makes a group agile or not, I had to jump in. I’ve helped build many high-performing teams with agility, and I know that neither CI/CD nor Scrum makes an organization Agile.

It’s Not What You Do, It’s How You Respond

Probably my favorite way I’ve ever heard someone describe agility was that it’s about moving away from believing we can predict and plan everything to sensing reality and responding to it instead.

Consider two extremes. In the “predict and plan” view of the world, we build a feature list, come up with screens, represent that in a backlog, and dutifully execute in two-week chunks. This approach focuses on accurate plans and predictions in the early stages. Mistakes in the early stage compound rapidly later on.

Are these folks agile? What did they sense and respond to?

A different group has a sense of problems to solve and their relative importance to one another. This group decides the goal for their next investment in a sprint. Every day they look at what happened and determine if they need to change course. They frequently shift direction mid-sprint because they’ve learned something new. Are they agile? What are they sensing and responding to?

Both teams are following Scrum’s rules, but one has lost all its ability to respond to new information, and the other, while it seems chaotic, is using near real-time data to guide their next steps.

Regardless of how you do it, agility is a lot more like the second group than the first. You can tell this not by the meetings they have or titles like Scrum Master, but rather by the frequency with which they make decisions that significantly change their direction.

You Have To Have Working Feedback Loops

A way to detect weakness in a group’s pursuit of agility is to examine the strength and length of their feedback loops.

Scrum is a framework, which is a weird way of expressing that it has a few useful pieces and room to figure feedback loops for yourself. The parts it does have, though, are a series of events and structures that provide feedback loops.

A feedback loop is an activity where you can pause to look at the results at the end. A chef that tastes their own food as they prepare it creates a feedback loop. A chef that never tastes their own food or waits until the dish is finished to take a taste, does not.

If you think about the events of Scrum in terms of feedback loops, every activity has a counterpart that closes the feedback loop. Sprints have Retrospectives, Increments have Reviews, and each day has a Daily Scrum.

All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.

Scrum puts the potential to leverage these feedback loops in place, but they don’t work by themselves. So you can easily wind up with a team building a two year roadmap, executing on that roadmap, but never recognizing the signals that there is actually no market for what is being built.

Sponsored Section

One way to ensure quick feedback loops internally? Cutting the review time for code in your development process. WorkerB developer automation tools by LinearB can give your team proactive notifications of changes in their PRs and update developers on long PR review times while correlating the PR to the relevant project issue.

Just turning on WorkerB with LinearB helped Illuminate Education decrease their cycle time by 44%! Learn more about how WorkerB can increase organizational efficiency.

The Rut of Following Form

I often see groups espousing that they are agile because of some activity they do or capability they have. In fact, that very behavior is what inspired me to write this article.

It can be tempting to look at agility as a feature list or series of checkboxes that, if you complete enough, you’ll summit the mythical agile mountain. But if those things aren’t so important, are the rules important at all?

Well, they are, but it’s just not enough.

Organizations and teams put a lot of emphasis on getting the basic structure of Scrum in place but tend to get into the rut of standing pat with those structures, and so the promise of agility remains elusive. These groups similarly work hard to cut things that they’ve been told are not agile anymore. Basically, they focus too much on the form, and not enough on the function.

You have my permission and support to keep using work-breakdown schedules as you pursue agility.

On the one hand, you need the form to be correct, or you can’t get the benefit. On the other, if you only follow the form, you stand in place.

So with my teams, I look to see if our process is “alive.” With a clear purpose for each activity, I can quickly see which of them are exhibiting signs of weakness that will disrupt feedback. Then I can intervene and bring the form back to accomplish its purpose.

For example, in a talk I give about Daily Scrums, I say, “The purpose of the daily scrum is to begin the day’s collaboration and coordination towards a sprint goal.” Most daily scrum meetings miss the mark of that purpose.

Looking at things from this angle, we can mature our forms and get the benefit back.

Change Takes Time

There is a fascinating intersection between these concepts where we recognize we want to address weaknesses in how we practice agility, but have difficulty estimating how to move forward and how long these changes will take.

One aspect to this is that we do need those forms to be in place before we can sense and respond to it. In my experience, a change in these forms takes about three months to normalize in a group.

When I introduce more advanced concepts like Test-Driven Development or Work-in-Progress Limits, I introduce those forms and also hold them in place for three months. This time frame might feel slow, but it comes down to how we as people handle change.

What we’ve done in our past is what frames what makes sense to us today. Our brains crave that feeling that the world works a specific way. When we disrupt that, people’s instincts are to reject the change. Even if it is a rational and logical change, we’ve disrupted what is normal. The three month adjustment period seems to be enough to allow change to take hold and for a new normal to be realized.

During that whole time, though, the form has to be sustained.

So as much as adherence to form can be a trap, it also is the scaffolding for change.

Learn to be Comfortable with Change

My honest advice for leaders who want to make things a bit better is to get really comfortable with microscopic change for a while.

An example might be phrasing a question differently — a small change.

Take an honest look at how you view things working best along a spectrum of plan and predict and sense and respond. Make sure to compare how you think you do to the actions that actually take place. There is usually a disconnect there.

Next, look at an opportunity within the existing forms to strengthen a feedback loop. Using something as simple as phrasing a question differently — a small thing — can completely alter the course of a Review or Retrospective or Daily Scrum. A thoughtful question that encourages feedback can easily improve things..

From here, you can continue this pattern of making small adjustments to how you and others move towards sensing and responding and leveraging the forms of Scrum to become truly agile.
.
.
.

For more thoughtful discussions on engineering and leadership topics, consider joining the Dev Interrupted Discord Community. With over 1600 members, it’s the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

If you haven’t already heard, Dev Interrupted is hosting INTERACT, our biggest event yet. The interactive, community-driven, digital conference takes place September 30th. Designed by engineering leaders, for engineering leaders INTERACT will feature 10 speakers, 100s of engineers and engineering leaders, and is totally free.

Originally published at https://devinterrupted.com on September 1, 2021.

4 Reasons You Didn’t Get The Job

Ryan Latta — Mon, 30 Aug 2021 00:00:00 +0000

Have you ever felt confused and depressed after realizing you aren’t going to get an offer from a company? Sometimes they tell you that you didn’t get it. Often you have to figure it out on your own. Even if you’re skilled at interviewing, you might only have a 1-in-3 chance of getting an offer.

I want to share a few reasons that aren’t obvious but are reasons why even a perfect interview isn’t enough.

You Were Interviewing For a Different Job

It might surprise you to find out that just because you applied for a job, you aren’t always interviewed for that same job.

A developer I coached went to interview at a place and felt like they did amazing but found out they didn’t get the offer. By asking someone who worked there, they found out that someone more senior quit the day before the interview, so they interviewed him for that more senior position.

Unknown to him, he was getting interviewed for a more senior position.

You’d be surprised how often this happens. Someone quitting, or your application may convince people you’re a better fit for a different job. Then without realizing it, you’re interviewing for something completely different.

They Already Know Who They Want

The best way to get a job is through your network, so when a new position opens up, people naturally think of folks they know who would be a good fit.

To be fair, and make sure things are all above board, many companies require that a public posting go out and conduct interviews. This happens even if they already know who they want.

You might have applied and interviewed for a job that never existed.

This situation happens when companies do big staffing changes, and new leadership comes in. They want to bring their favorite people with them, and that means you never had a chance.

They Don’t Know What They Want

When you apply to a role that looks new in a company, you’re stepping into uncharted waters. The company will have an idea of what they want, but that is about it.

That means they also don’t know how to interview you.

So you might get asked a bunch of questions that you answer great but fail to convince them that you’re right for the job. That’s because they don’t know what they want and also asked poor questions.

Titles in our industry that are notorious for this are Front-End Development and Full-Stack roles. The industry still isn’t sure if Front-End is a designer or a developer, and you’ll get very different interviews depending on that opinion. Full-Stack folks face similar ambiguity problems.

You can interview perfectly and not get the offer because they just aren’t sure what they want yet.

The Cold Interviewer

Ever get interviewed by someone who seemed like they didn’t want to be there? I call this a “Cold Interview.”

The problem is that they came into the room not wanting to do the interview, and their attitude taints everything you say. When they think back, they’ll remember the irritating and frustrating experience and attribute that to you.

When a manager is a cold interviewer, their lousy attitude can cost you the job.

Keep Interviewing

You’ll find advice everywhere to target your interviews, and that is good advice after you’re good at interviewing. However, if you’re still struggling to interview and you can’t get an offer one in three times, keep interviewing everywhere. Hone your interviewing skills.

Once you can get offers consistently, you can target your efforts to the companies you think you want to work for. Bear in mind, though, there are no guarantees here, and there is always a chance that you don’t get the job even if you execute flawlessly.

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

image courtesy of Unsplash

Building a Resume With No Dev Experience? No Problem!

Ryan Latta — Thu, 12 Aug 2021 00:00:00 +0000

Time to address one of the most common questions I get from my clients, “What if I don’t have development experience?”

We All Start There

We all got jobs without prior development experience, which means you can too. The trick is knowing how to leverage your past.

Sadly, job postings scare people away from applying since they want two years of experience and 85 required skills.

While this article isn’t about reading job postings, knowing that everyone starts without experience means you can too.

Your Non-Dev Experience Is Valuable!

Take a step back for a minute and think about if you were a leader in a company. What qualities you’d like in your employees?

More than likely, you’d come up with a list with some things like:

Dependable
Detail-oriented
Good communicator
Team player
Focused
Takes initiative
Finishes things
Results-oriented

So if you’d want someone like that on your team, what do you think the chances are that someone else wants that too? Pretty high!

What you want to do is look at your previous experience and focus on highlighting these qualities. Let’s say you worked at a fast-food place.

Instead of writing, “Prepped meals according to the standards.”

You might write, “Worked on a team that served 2000 customers daily in a high-paced environment.”

Hopefully, it’s pretty clear which one would get the attention of a manager.

Surprise Them With Cool Experiences

I’ve worked with lawyers, healthcare folks, and all other kinds who have transitioned to tech. While all of them were terrified of their lack of development experience, they had amazing stories and value to bring to the table.

For years I kept my job doing ocean rescue as a teenager on my resume because it guaranteed that someone would ask about it. Bonding over fun stories is a big part of successful interviewing, and non-development experience excels at this.

We’re naturally curious about what other people have been through, and when you have a varied history, that is a superpower compared to folks who have done only one thing.

The trick is to tell your stories and make it clear how what you learned prepared you for today.

I used to close my stories about ocean rescue with something like, “So I’m comfortable with high-stress situations.” That line would show up because, at some point, we’d talk about projects and deadlines and stressful or difficult situations. Well, a story about life-and-death pretty much puts an end to the concern about that.

Bring The Attributes and Stories Together

To make the most of your non-development experience, identify those attributes like above and focus your experience to emphasize them and any other result a business would care about.

Then, reflect back on those jobs and see what stories come to the surface. If you can relate any of those stories to those attributes, you’re ready.

Now, when a manager reads your resume and sees that you deliver results and have all the qualities they’d love in an employee, you’ll be ready to interview with great effect.

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I launched an online class that guarantees to get more interviews, offers, and negotiate higher pay.

You can find out about both here.

image courtesy of Unsplash

Hey Devs, Your Portfolio Won’t Get You a Job, But Your Resume Will!

Ryan Latta — Thu, 12 Aug 2021 00:00:00 +0000

“It’s a six-figure piece of paper,” is what one of my clients said about their resume not too long ago. They started their career from scratch within the past three years and never used a portfolio to get their jobs.

If you’re ready to get back weeks or months of struggle building a portfolio, this article is for you. It’s time to master your resume.

They Are the First Thing People See

I wrote another article about the people involved in the hiring process, but everyone sees your resume first.

The Human Resources person screens you into a candidate pile or the trash based on your resume.

The Hiring Manager reads a pile of resumes and chooses who to trash and who to interview.

Your peer developers see your resume first before they go in to interview you.

That resume that so many people barely keep up to date is the first impression you make on a company. What is even crazier is they’ll read your resume in sixty to ninety seconds to form that opinion.

Convincing a company that you’re worth an interview in that short time frame is the entire job of a resume. So, learning how to build a great one is the difference between no interviews and constant interviews.

If Your Resume Sucks, No Portfolio Will Save You

Let’s go a little further though, and say you have a resume, portfolio site, GitHub page, and so on. How do they find all of those things about you?

They’re on your resume.

One way to look at your resume is that it’s a landing page for who you are. Even if you built a portfolio site to the same effect, they land on the resume first.

So, when you have a manager land on your resume, you’re hoping they are convinced within a minute to investigate you further and decide you’re the right fit.

Sometimes I get asked about the efficacy of this stuff, and while I can prove with data how effective resumes are, the usefulness of a portfolio site varies widely. Almost everyone will look at one, provided your resume stayed out of the trash, but it convinces someone to do past that is a shot in the dark.

Let’s say you have a terrible resume and a great portfolio. Your resume is trashed, and nobody sees the portfolio. Let’s say you have a resume that isn’t bad but doesn’t stand out and a great portfolio. You didn’t get trashed, so you were likely to get an interview anyway, and your portfolio cements that decision.

Now let’s go the other way to see why this is tougher than it looks. You have a great resume and a bad portfolio. You don’t get trashed, but show the manager that you’re sloppy and unprofessional and wind up in the trash.

Most of the time, your portfolio will only round out the impression they already formed from your resume, and if you do a poor job will kick you out from an interview.

While there are many articles on portfolio sites, few are written from the perspective of how a manager will judge you. I hope your CSS is formatted correctly.

They Help You Interview

Resumes for technical folks will almost always have an experience section. Yes, especially if you don’t have previous development experience.

A good resume acts as bait for your interview. When managers read your resume, they’re looking for a bunch of stuff, but one of those things is what to ask you about. You can predict what they’ll ask you about from your resume.

Why this is important is that the more time they’re asking you about your experience and past, the less time they’re asking you absurd technical questions.

Knowing they’re going to ask you about a specific thing means you can be ready to take that opportunity to build a relationship and convince them you’re the right fit.

A five-minute conversation about what you’ve done and learned is way more favorable to you than listing the Big-O of various sorting algorithms.

They Are Quick To Make

As developers, we love making stuff, but we have to be realistic about the amount of effort things take. A portfolio site that gets interviews is no small thing and often takes months of building and tweaking.

A resume, by contrast, takes a few hours to a day to build one that will get an interview 60% of the time. A day or so more, and you can get to 100%.

Don’t get me wrong. I’m not saying you shouldn’t build a portfolio site. They can help you stand out when done well. But most people put it in the wrong priority by spending their time on that first.

Instead, prioritize your effort around the least time and highest yield. Here’s an example:

Resume
Cover Letter
LinkedIn
Portfolio
GitHub

You might have noticed I put cover letters in there, and you’re wondering if I’m from the 50s. Cover letters are portfolios in written form. What I mean is they are only looked at if your resume is good and can help you stand out if you’re careful. They are also optional and don’t have consistent effectiveness.

I know I’ve had interviews based entirely on my cover letters because that’s the exact feedback I’ve heard, but I also know plenty of managers won’t read them. This is exactly like portfolio sites. The difference is a cover letter takes minutes or hours to write.

Shift Priorities

If you’re considering getting into the job search or in the middle of it, look at your priorities. If you haven’t invested heavily in your resume, go back to it.

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I just launched my first ever online class that guarantees to get more interviews, offers, and negotiate higher pay.

You can find out about both here.

Build a Resume With This Successful Format

Ryan Latta — Thu, 12 Aug 2021 00:00:00 +0000

Now that we’ve covered the value of resumes and common mistakes that will prevent any resume from succeeding, its time to talk about the core elements your resume needs.

Simple and Clean Formats Win

A great resume design and format answers two questions for the reader with almost no effort:

Can you do the job?
Do I want to work with you?

Cleverly designed formats, while attractive from a distance, force the reader to bounce around the page to find answers to these questions instead of having the most impactful information first.

So, while a format that is nice to look at is helpful, if it annoys a hiring manager, it is now working against you.

How to Order Your Information

In resumes I advocate for putting the following sections in your resume in this order.

Skills
Awards (Optional)
Experience
Education

Skills

Your skill section needs to represent your technical skills and relevant knowledge. This can be a simple list.

Now, people get worked up about how much to put here and how much to put here. You can put something if you’re comfortable talking about it. You need to put minimally what matches the job description.

Some of you might feel weird about me qualifying skills by things you can discuss, but your interview is a discussion about your skills. By putting there you’re inviting your interviewers to find out what you can and cannot do and how deep your knowledge is.

Another way to look at it is, you don’t decide if you have enough of that skill, your interviewers do. So if you can discuss it, list it.

Awards

If you have awards or any other kind of flair that you think will help you stand out, I like to put that next. What you list here will likely be of no relevance to your reader, but pointing out that you won some competition gives the indication that you’re above average.

I simply put the award and the date it was awarded. Since my reader doesn’t know anything about it, I want them to see that I earned the award more than taking up space explaining what it is. Let them ask about it in the interview!

So awards, public speaking, publications, certifications are all things that can go here. Keep it short.

Experience

This and your technical skills are the two most important sections. For your experience, you can list any and all experience you have starting from your most recent and going back.

For each one you want to list the company, title, location, and 3-5 bullets that indicate the outcomes you contributed to.

Pay attention to that last statement. Don’t put in your experience that you, “Wrote code.” You’re a developer, literally everyone writes code. Put what changed in the team, operations, or business as a result of you coding.

This is where you stand out from everyone else. When everyone else writes that they wrote code, you deliver results and hiring managers will choose that every time.

Education

This comes dead last because it is the least important to managers. Even if its top of mind for you as a recent graduate of any program, it just doesn’t make much of a difference to hiring managers.

When you list your education, list the school or program, the degree or certificate you got and when you graduated.

Don’t list your grades or GPA ever unless it’s required. People are sensitive about academic performance and doesn’t make you look better.

Update Your Resume!

So with that, take a look at your resume and put your sections into this order. When you’re done, put yourself imagine you get to make the call of bringing someone in. Now look at that your resume and ask yourself, “Can they do the job? Would I want to work with this person?”

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I just launched an online class that guarantees to get more interviews, offers, and negotiate higher pay, or your money back.

You can find more here.

Avoid These Resume Mistakes That Are Keeping You From Getting Interviewed

Ryan Latta — Thu, 12 Aug 2021 00:00:00 +0000

In this next article in my Six-Figure Resume series, I want to cover some myths and mistakes people make in crafting their resumes that hurt your chances or guarantee that you’ll get disqualified from a job early.

The One-Page Resume Is a Dangerous Myth

Starting off, you’ll find advice everywhere saying to fit your resume into one page. I’ve surveyed and interviewed hundreds of managers over the years, and here’s the bottom line.

Multiple pages in your resume will not hurt your chances.

The trick is that because managers read in sixty seconds, that first page makes the biggest impact, and the others build on it.

So you can think of it as a great first page earns reading the second and so on.

I’ve seen resumes that are fourteen pages long, and no, they didn’t all get read because we all knew what we needed in sixty seconds. Simultaneously, even with no previous development experience, my clients and I started with 2-3 page resumes and get interviews almost every time.

Stop Using Skill Ratings

Kind of hand-in-hand with a lot of one-page templates, there are ratings for technical skills. This is something you don’t want to do either.

Let’s say you rate your skills on a scale of 1-5, and you’re still in the first few years of your career. You might rate yourself with one to three. Does a company want someone that isn’t skilled?

On the other hand, if you rate yourself on a four or five, someone may show up with a decade of experience and interview you as though you’re the expert that you claimed.

In other words, those skill ratings only work against you, and since your rating doesn’t match how your interview views those same ratings, it’s a recipe for disaster.

Typos, Grammar, and Spelling

It may seem silly, but mistakes like these stand out like a sore thumb when someone scans your resume. Now, as much as we’d all like to believe that the content is king, these mistakes completely sour the experience.

So make sure you get these things right because you’ll wind up in the trash if you have these mistakes.

Things you’ll want to check:

Consistent punctuation
Make all the formatting even and consistent
Don’t write run-on sentences
If you Bold or Italicize do it consistently
Spelling, especially in your technology & keywords

A little tip for spelling since we use a lot of proper nouns for our technology is to lowercase all of them to allow spell-checkers to catch mistakes in their spelling before you uppercase it again.

Even Your Name and Location Can Cause Problems

You’d be amazed at how many resumes show up on manager’s desks with different names on the various pages. While this mostly happens with recruiters and consultancies, if you’ve downloaded a template, triple-check this.

Nothing puts your resume in the trash faster than looking like a liar, and a different name begs them to ask if this is your resume or not.

Putting your location used to be standard stuff in your resume, but if you’re targeting a remote job, you’ll want to consider removing your location.

The reason is that some job postings may say remote, but they mean mostly remote or temporarily remote. This is especially true with COVID-19. When companies see that you live somewhere else, they may screen you out because of a concern that they’ll have to relocate you someday in the future.

By removing your location, you don’t let them screen you pre-maturely, and you force them to ask in an interview.

Time to Check

Take a look at your resume and see how many of these mistakes you can correct. Working through this list will improve your rates of getting interviews almost instantly.

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I just launched my first ever online class that guarantees to get more interviews, offers, and negotiate higher pay.

You can find out about both here.

image courtesy of Unsplash

How To Put Your Resume To Work And Get Interviewed and Promoted

Ryan Latta — Thu, 12 Aug 2021 00:00:00 +0000

In this last article in my Six-Figure Resume, I want to put all the pieces together into a process that allows you to refine your resume and improve your interviewing rates.

Don’t Let Your Resume Collect Dust

That phrase, “Dusting off the resume,” exists for a reason. Far too many people ignore their resumes after they get their job.

I highly recommend visiting your resume at least every three months.

When you keep your resume updated with current accomplishments on the job, you’re better prepared for when a new opportunity shows up, and you have a record of your best results for when you have performance reviews.

In other words, your resume can pull double-duty.

Adjust Your Resume For Each Job

When you apply to a job, take the opportunity to make changes to your resume before you apply. While this sounds like another chore in an already soul-crushing process, there’s a lot of benefit to it.

First, you can, by simply re-ordering your technical skills, make it easier for a hiring manager to see you’re a fit by putting the skills in the description first on your resume.

Second, by looking at your resume with the question in your mind, “How can I make this even stronger,” you can find opportunities everywhere to make a minor tweak to catch someone’s eye.

Last, by refining your resume each time, you have the ability to find out if your tweaks help or not.

Track Your Results

So you’ve made some tweaks to your resume before you send it into a new job. Make a note of the company, the posting, when you applied, and what version of your resume you used, and record a date two weeks from now.

All of those bits of information aside from the two week-thing help you stay on top of things when you start getting multiple interviews from multiple companies in a week.

Knowing what version of your resume you used helps you see which tweaks work and which don’t. You’re using data now to refine your resume!

The two-week thing is primarily for your mental health through the process. Job hunting is soul-crushing, and knowing you applied without hearing anything back is a lingering demoralizer. By declaring that two weeks from now, you’re moving on, you can help end that long emotional drain by letting yourself forget you ever applied there. If they didn’t get back to you in two weeks, move on.

Some companies are slow and will get ahold of you months later, but when you’re not emotionally vested in that, you can let it be a fun surprise.

Start Applying

If you’ve fixed the mistakes and format of your resume, you’re ready to start applying now that you know how to optimize the results through continual refinement. So, dust off that resume and never let it collect dust again!

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I launched an online class that guarantees to get more interviews, offers, and negotiate higher pay.

You can find out about both here.

image courtesy of Unsplash

Avoiding a Common Mistake Searching for Jobs

Ryan Latta — Wed, 11 Aug 2021 00:00:00 +0000

Maybe you’ve felt like you can’t quite find enough jobs that match your level and experience? Not enough junior positions or lead positions? I want to outline a few things about how job postings work to help you find more opportunities.

There Are No Standard Titles

Not many people pause to think about this little truth, but there are no standard titles associated with our jobs in our industry. Some conventions are followed more widely than others.

For example, new devs tend to target junior or entry-level positions. While the intent of this is spot on, the hiccup is that searching for these literal terms only helps you find the companies that use that title. They miss all the opportunities at companies that simply don’t have that title!

The higher up you go, the problem shows up again. Everything past Senior lacks any real convention. So you might be a principal at your company, but searching for principal only finds companies who share that title. You’re missing every company that simply doesn’t use that title.

Full-stack folks share the same problem as well. This is a term many devs pursue in their growth and learning but isn’t a term that is the exact equivalent in a title for companies. In fact, full-stack can be a red flag to see in a posting as it can mean doing multiple jobs at once for the pay of one. But, you might not know DevOps is another word that keeps you in the same realm of full-stack work.

Bottom-line, there are no standard titles in our industry and narrowly searching by title excludes every company that doesn’t have the same title.

Search Up and Down

One technique to get around this is to search for the title you think you want, then one that you think is a title above and a title below.

This will give you a ton of potential jobs, and many won’t be of interest to you. However, you’ll avoid missing out on a lot of possible openings based solely on title discrepancies.

Maybe another odd example will help. In the finance world, the running joke is that everyone is a vice-president. Would you ever think to search for a vice-president job after a few years of experience? You’d miss out on jobs in the finance sector if you didn’t try.

Read the Postings to Decide

Alright, how do you know if the posting is one that you should consider applying to? There is a lot I can put here, but there are only two things that I think are critical before you decide to apply.

Primary skill match
Years of experience

Please read my explanation on these, don’t skim. People mess this up all the time!

For primary skills, you want to look at the long list of skills in the posting and identify the ones you think are the most critical for the job. In a Front-End Job you might see React along side some other stuff like Node, Bower, Gulp, etc. React is the primary skill and the others are supporting skills. If you have the primary skill you’re good to go. You don’t have to match everything!

As for years of experience, look at what they’re asking for and subtract 5.

Years of experience trip people up, but it isn’t a hard rule, just like education isn’t one. Subtracting 5 is a helpful rule of thumb that will let you start applying for jobs and get interviews. The more senior you get, that rule for five can eventually become 10.

More Opportunities!

There you go, a quick way to find more opportunities in your next job search by recognizing there aren’t standard titles and how to decide if you’re a fit without a title to help. Good luck!

If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.

Second, I just launched my first ever online class that guarantees to get more interviews, offers, and negotiate higher pay.

You can find out about both here.

images courtesy of Unsplash