How Much Is Your Resume Worth? – Part 1

resume-reviewer

Have you ever considered how much your resume is worth?  Put an actual dollar value on it?  I sometimes ask people seeking resume help how much they think their two-page resume is worth (hopefully their resume is only two pages and not the 10+ I’ve seen).  I get answers from five cents to “a lot,” but the right answer is: it depends on how much I make.  If I earn $100,000 every year for the next ten years, these two pages are worth $1,000,000 dollars to me.  Think about that for a second.  The resume I thought of as a burden to create and update, which I worked on while watching The Big Bang Theory or Game of Thrones, is possibly worth $1mm or more to me.  What other documents have you recently created worth $1mm+ to you?

While your resume is far from the only factor in getting a job, it is your gateway into getting the interview.  Malcolm Gladwell describes in his book “Blink” how people, especially interviewers, make snap judgments.  When you first meet someone and shake their hand, you make a snap judgment about that person.  A strong handshake might indicate a smart and put together individual or a weak handshake might indicate a timid and unmotivated individual.  The interviewer sub-consciously continues to reinforce that initial judgment through out the discussion.  For example,

“Do you know Java?” the interviewer asks.

You reply, “No, but I read a lot and can quickly learn.”

If the interviewer snap judged they don’t like you, they sub-consciously think, “Hmm, doesn’t seem to have the right skills.  No hire.”  If the interviewer snap judged they like you, they sub-consciously think, “Wow, seems to have a real can do attitude and has great potential.  Hire!”  The very first snap judgment a hiring manager makes about you is based on your resume.

A well organized, easy to read, and error free resume indicates an intelligent and well-organized individual.  A sloppy, dense, or error-filled resume indicates a lazy and “lacks attention to detail” individual.

That is why we said, let’s build something that helps people build the best resume possible, create a great first impression, and get them the right job: The Resume Reviewer.

To Be Continued in Part 2: Building the Resume Reviewer where we’ll get into the tech detail!

We're Hiring Engineers at Ladders. Come join our team!

Why You Should Let Your Best Employees Join Another Team

Another Team

Imagine a fantastic software engineer who’s been working for the same team on the same system for a few years. Before long, she gets promoted. Her colleagues and direct reports love her, but despite getting more responsibilities, she’s growing tired of the same set of technical challenges.

A team is being put together elsewhere in the company in order to build a new system, and she has her eye on that. So she decides to approach her manager about it.

WHY INTERNAL TRANSFERS ARE SO RARE

At many companies, this type of request isn’t greeted too enthusiastically. Plenty of organizations have official policies on internal transfers, but they’re seldom utilized as much as they could be. I once had a manager who would say that a team member of theirs “quit” when they transferred, and actually tried to prevent that from happening. A colleague of mine says he once got scolded by a manager who found out he was using the internal jobs site, and was then “forgiven.” In these situations, company culture undermines company policy.

PLENTY OF ORGANIZATIONS HAVE OFFICIAL POLICIES ON INTERNAL TRANSFERS, BUT THEY’RE SELDOM UTILIZED AS MUCH AS THEY COULD BE.

Explicitly or implicitly, when the opportunity to apply your skills in a different part of the company is discouraged, you’re more likely to jump ship altogether.

For managers, though, it comes down to weighing the costs and benefits. If you discourage or outright reject the transfer request and keep that team member on board, you will:

  • Have a demotivated and unhappy employee on your hands.
  • Deliver a clear message to the rest of your team that there’s no leaving this group; there’s only leaving the company.
  • Eventually—usually within six months—be handed a resignation letter.

If you say yes, you’ll no longer have the great employee on your team, but will:

  • Have the opportunity to negotiate when they can transfer (e.g. one or two months, which is far better than two weeks’ notice), so you’ll have enough time to recruit the right replacement and bring them fully up to speed.
  • Deliver a clear message to the rest of your team that you can have a career here and not just a job.
  • Retain a talented and happy employee who keeps using their expertise on behalf of the company.

GIVE THE GIFT OF GROWTH

Some companies actually excel at letting their top employees move around within the organization in order to develop their skills. GE, for instance, has been known to approach top performers who’ve been in their roles for around one-and-a-half to two years and ask about their next position in the company. The point is to get the best people to stick with GE for the long haul and develop a career there.

For employees, the question is when, whether, and how to ask managers about the possibility of transferring to another team. Some companies don’t require you to do that, but some do. Regardless, those conversations should happen, and managers should encourage them. The ideal manager should be a partner to employees, not someone to hide from. Interest in working elsewhere within the company should never be a dirty secret or interpreted as a critique of a manager’s leadership style.

EMPLOYEES WHOSE CAREERS YOU’VE HELPED ADVANCE WILL REMEMBER THAT

Personally, I’ve had two people approach me about transferring to other groups during the past six months. One person wanted to increase the breadth of their experience, and the other wanted to be in the group focused on services (back end is their passion). Both of those employees brought a lot to my team. But after talking it out with them individually, I said yes to both. I knew they’d be able to grow and follow their passions, and it was my job to encourage that.

Sometimes managers are in a tough spot. What should you do if you’d like to help your employees grow in a different part of the company, but the organization frowns on that? Some managers’ judgment will be questioned if they let top performers leave. That risk is real, but it’s better to err on the side of doing right by your employees.

If you do, you’ll ultimately be doing right by your company, too—even if it isn’t exactly seen that way. The reality is that people now change their employers more often than ever, so minimizing that churn can be a good thing. What’s more, employees whose careers you’ve helped advance will remember that. You may be losing someone great now, but they might come back into your professional life sooner than you’d expect.

Post originally appeared in Fast Company.

We're Hiring Engineers at Ladders. Come join our team!

Managed Chaos: Empowering Your Engineering Team

I believe in the software engineering team using COBOL and Fortran ’77 (so much better than ’66) to develop the best modern websites.  I believe in them using note cards and excel files and Jira and Trello to organize the Agile Product Backlog, and using nothing at all.  I believe in the teams having a leader and having no leader.  I believe in what the team wants to do.

While a bit tongue-in-cheek, I truly believe that a successful, innovative, and evolving organization must encourage its members to decide how they get the job done.  Trust the team to find what works best to achieve their goals, which of course should be aligned with the company goals.  The effective leader provides vision, values, and transparency.  The leader must protect the team by setting up the metaphorical guardrails by the cliff’s edge, but between those guardrails create an open and fertile environment for the teams, who are professionals and most likely smarter than the leader (that’s why you hired them!), to do what they do best.

If you want to achieve the best, get out of their way and trust!

That said, how do we prevent the organization from falling into chaos where one team is using Clojure, another Haskel, another Go, another Agile, another Waterfall, ad-infinitum?  If we allow that sort of chaos to ensue, the engineering team will have serious issues with business continuity (shoot, Bob the COBOL guy just left – who here knows COBOL, anyone, anyone, Bueller?), hiring, and maintainability.  The other extreme, which large organizations often adopt, is a regimented approval process for all technology, down to the version level.  Do you want to use Scala 2.11.7?  Well, write up a report, submit to the engineering committee, POC, review, and 6 months later and dozens hours of your time, maybe get Scala on the restricted list.  Maybe.

But there is a better way to do it and that is Managed Chaos.*  Chaos can be detrimental, but if properly managed, it can be a powerful tool for an engineering organization to embrace innovation and drive the business forward through technology.  When the software engineering team comes to you asking to use COBOL, say, “Yes! I support you.  But, I do have some questions.  Where do you plan on finding COBOL engineers?  What about mainframes?  I don’t have any here.  Also, can you build websites in COBOL?  Didn’t know that.  How will you leverage other teams to get the help you need since no one here knows COBOL?”  If the team has justification and has reasoned out how this will drive the product and team, allow the chaos to happen.  You have managed the chaos by asking the right questions, thinking things through, and aligning to the business and product. You have embraced change that can drive the business and product forward by giving your team control (e.g. the tech stack).

Create a great engineering environment by giving your team control.

What you really are trying to avoid is the “Oh, yeah, we should have thought of that” statement after the fact.  For example, if our Data Science team wants to start using MongoDB and our Platform team wants to use Cassandra, that is totally fine if they have thought it through and discussed why each team needs to use a different no-sql databases.  That is Managed Chaos.  We don’t want to have the discussion 6-months after implementation and say, “I guess there is no reason we couldn’t have used the same.”  That is just chaos.

Another example is from a recent decision by one of our Agile teams at TheLadders.  Most teams are either singularly use either Jira or Trello.  However, one team for our Professional website decided they want the Product Owner to create user stories in Jira and the Engineering Tasks be broken down and estimated in Trello.  I was dubious – really, both?  Isn’t that, well, chaotic?  It isn’t.  The team had thought though the complexity and determined it worked for both the product owner and engineers, and I’m happy to say they were right.

In conclusion, don’t be afraid of change, don’t be afraid of the decisions your team makes, and don’t be afraid of managed chaos.

 

Managed Chaos is similar in concept to Fractal Organizations.  Below is a great description from Pravir Malik on how a Fractal Organization works:

“In meta-theory all instances of organization, from the smallest, such as an idea or a person, to the largest, such as global markets and planet earth herself, are fractals:  the essence of their way of being is repeated on scales both smaller and larger than themselves.  There is however, a particular class of fractals, that of progress, of which The Fractal Ladder is an ever-present manifestation, which spawns organizations that are truly progressive and sustainable in nature.  In the scheme of things this class of fractals is of critical importance, and to master its replication and to fully understand the impact it will have in creating sustainable and dynamic organizations is a practical necessity.”

We're Hiring Engineers at Ladders. Come join our team!