Job hopping and what you can do about it

comments 6

The jobs they are a-changin’

When my father retired from his role as a civil servant ten years ago, he had been in his current role for eighteen years. That wasn’t necessarily eighteen years of solid growth and progression, either. It was just eighteen years of grafting the same old, day in, day out, in order to make sure that he provided for our family. Granted, my father was not working in technology, and also granted – and I am sure he wouldn’t mind me saying – he was not as career driven as many of us working in technology are. Yet, the generation that are beginning to retire are leaving behind a work landscape that is radically different from the one that they entered. Jobs for life, secure tenure and final salary pensions are pretty much a thing of the past. The new workforce must be more entrepreneurial, and as a result, they are less loyal to the companies they work for.

The tenure of my father’s last job is almost unheard of in technology. The average time spent in one role has been trending dramatically downward with time. When Travis Kalanick stepped down from his role as CEO of Uber in 2017, he had been in the job for 6.5 years. This was 5 times longer than the average Uber employee at 1.32 years. According to Business Insider, the average tenure at Facebook was 2.02 years, Google 1.9 years, Apple 1.85 years and Snap 1.62. Job hopping has nearly doubled in the last 20 years. The fact is inescapable: it is the world we now live in.

If you are a manager who thinks that your staff are going to stay loyal to you for many years, then you are only setting yourself up for disappointment. But there are ways that you can increase the chance that staff are going to stay longer than average in your organization. Before we look at some techniques that can help retain staff, let’s have a look into why people are motivated to move around.

Why are people changing jobs so much?

There are many reasons why people in the technology industry find themselves with itchy feet. These reasons are not necessarily mutually exclusive, either. They compound to create even more compelling reasons to keep changing role. Job hopping is more prevalent in the younger members of the workforce, but the following reasons are also applicable to staff of all ages.

  • Economic and social instability. For those that are just graduating from university, economic and personal situations are challenging. The increasingly high cost of housing, especially in metropolitan areas where jobs are, and mounting debt from education mean that being able to purchase a home and find a stable job that pays well is tough. Given that there is less to lose, many use their twenties and early thirties as a time to not settle, and instead let their career pull them towards new experiences and locations.
  • Wanting to experience the broadest possible work. Technology moves exceptionally fast. Many companies do not allow enough opportunity for their staff to experience a varying range of challenges and technologies on a regular basis, so leaving to work elsewhere is often less effort than waiting for the latest open source projects to gain traction from within or for a more interesting role to open up in another team.
  • Pay. As disappointing as the situation in, in general, the easiest time to negotiate a big pay rise is when you are changing to a new job. Given how much saving is required to put down a deposit on a first property, it’s no wonder that many people, as they gain experience, find that changing job rather than fighting for an internal promotion is the easiest way of increasing their salary and thus making steps towards securing their financial future. Engineering skills, especially in big data and AI, are in exceptionally high demand and there are many more jobs than there are qualified applicants.
  • Embracing challenge and risk. Changing jobs frequently means that people don’t have to live with long-term consequences. Large, complex, draining projects can create epic amounts of technical debt and maintenance, and changing jobs is a way of always being involved in the exciting stages of projects rather than having to pick up the pieces at the end.
  • Frustration. After the honeymoon period is over and the realities of a new role have settled in, frustration can begin to build. That colleague who is an absolute pain to work with. That manager who won’t allow for any career progression. That death march project that won’t ever end. That old legacy part of the system that keeps blowing up. It’s much harder to negotiate sweeping change from within, and it is often highly political. Sometimes it’s just easier to quit and move elsewhere.
  • Reduced stigma. While thirty years ago a CV listing five roles in six years may have been read with a furrowed brow, our attitude to frequent job switching has changed. If the average tenure at the top technology companies is so low, and they attract the most talented people, then others will feel less worried about the impressions of others when considering to look elsewhere.

I would advise staying neutral on whether changing jobs frequently is inherently bad or good since, as shown in the list above, there are many factors outside of your control that contribute to people wanting to move around. I am not one to judge the lives of others.

Similarly, if you are reviewing CVs, try to remain unbiased about applicants who have frequently changed job; there may be perfectly good reasons. The inverse is also true: people who have been in the same role for a long time aren’t necessarily stale, either. They may just be happy and settled. We’re all different.

Working with it

Yet, with all of the above factors working against you when it comes to retaining your staff, what can you do? Let’s see.

I chose the heading “working with it” very deliberately. If you think that you’re able to prevent people from leaving then you’re only going to feel extra bad when they eventually do. However, there are strategies that you can employ to increase the likelihood that people are going to stay for longer. Staff who have been at your organization the longest have domain knowledge that cannot be brought in easily from elsewhere. It’s invaluable.

So, what can we do?

  • Map out career tracks. What does progression look like in your organization? What are all of the roles that you have available? What is expected at the levels of seniority in different roles? If you already have this documented, then that’s fantastic. If you don’t, it’s never too late to start. Career tracks can help staff orient themselves with their current position and provide plenty of fuel for conversations about how they can progress to the next level. The simple act of mapping out different career paths is a radical act of showing that your organization cares about retaining and growing its staff.
  • Create opportunities to learn, no matter how small. Make sure that growth is part of the regular conversations that you are having with your staff. Growth doesn’t have to mean constant promotion and pay rises, although those definitely help! Creating opportunities to try new projects, to work on different parts of the application, to mentor junior staff, to try out new technologies and work with different colleagues are all much simpler ways of giving your staff variety and learning opportunities.
  • Encourage side-stepping. Enabling growth isn’t necessarily all about growing upwards and becoming ever more senior in one discipline. Sometimes people leave jobs because they think they might want to change from frontend to backend development. Or perhaps a technical support engineer wants to retrain as a delivery manager. Rather than losing your staff, why not allow this to happen at your own organization? Long tenured staff have a wealth of organizational domain knowledge that is a real shame to lose. Don’t be afraid of dipping into net-negative productivity for a temporary period if it means retaining some talented people.
  • Treat those born in captivity the same as those raised in the wild. Because of the severe talent shortage in technology, companies offer extremely compelling compensation packages to get candidates in the door. Your company may also do the same, but make sure that your existing staff are also able to grow to achieve the same levels of compensation as those that come in from outside. Allow loyalty to your company to be rewarded.
  • Be open about pay. Don’t make pay a taboo subject. Encourage your staff to discuss it whenever they want to; nobody works for free, after all. Convince your organization to do salary benchmarking for each role so that discussions around pay have real context through data. There are a number of services that can help you do this. If a member of your staff feels that they are underpaid despite the data telling you otherwise, turn the conversation towards how they can set growth goals to work towards increasing their pay over the coming year. Use pay as leverage to encourage growth.

In summary

You can’t prevent people from job hopping, especially in their early careers where they have fewer commitments and increased opportunity to explore themselves and the world around them. However, there are many things that you can do to make it more likely that your staff will stay for longer, and these changes will also benefit those that are happily tenured.


* My father’s job was a much less important part of his life than mine is to me, but that doesn’t make me any less grateful for the effort that he put in to make sure that I had a good upbringing. Thank you, Dad!

First principles and asking why

Leave a comment

But why?

I was in a supermarket recently, and at the other end of the aisle I could hear a parent getting continually more frustrated. What should have been a relatively simple trip to purchase some groceries had been turned into a consistent barrage of questions. Their young child had entered the why stage. No action or decision was safe from the dreaded why.

Why were they going down this particular aisle? Why was it cold in this part of the supermarket? Why does cheese need to be refrigerated after all? No topic was taboo. Parents who are unable to deal with the persistent barrage of whys find the dialogue drifting off into the absurd, where they find themselves explaining why trollies have wheels, why shops exist, and why we even need to eat food in the first place. Why? Why?!

Adults find this behavior incredibly annoying. Children in the why phase manage to highlight just how much of the world that we, as adults, don’t tend to spend too much time thinking about. As we age, we reason at ever more abstract levels that don’t need to be concerned with. For example, we don’t care exactly how a car is put together – we just drive it. This ability to think abstractly and to build upon abstract concepts with even more abstract concepts has allowed the human race to flourish. Right now I’m not thinking at all about how my keyboard works, or how my operating system works, or how machine code is being executed by the processor on my laptop. I’m just writing.

But listening to this child constantly asking why made me think: why don’t we do this more as adults?

Conserving power

In an evolutionary sense, the ability to work in abstractions allows us to conserve vast amounts of brainpower. Imagine the overwhelm of having to concern yourself with how everything works all of the time, from gravity to your musculoskeletal system, to your heart, the hardware and software stacks of your phone, and so on. We wouldn’t leave our beds. Trust in abstractions and analogies allow us to function.

But consider the flip side: how much do we refuse to question because it seemingly is good enough right now? How many poor or inefficient decisions have come of a result of not challenging the status quo?

As a manager, compared to an individual contributor, you have the ability to veto a number of decisions, such as the priority of projects, who to hire and how to get work done. Depending on your seniority in the organization, you may be able to make critical strategic decisions such as whether to move all of your applications into the cloud, whether to acquire another company, or whether to lay off half of your staff after a disappointing year.

You therefore owe it to yourself to improve your critical thinking skills. You can partition these skills into two categories:

  • Using why to critique existing ideas
  • Using first principles to construct your own

These thinking techniques are interlinked. As the child in the opening example showed, continued use of why helps distill an idea into first principles (or lack thereof). When building new ideas, application of first principles should result in well-formed ideas that can stand thorough application of why.

Using questions to interrogate assumptions

Let’s start by exploring the power of why.

A common practice when there is an incident such as downtime of an application, or a critical bug that caused reduced service or corrupted data is a 5 Whys session. It is a technique to uncover the root cause of issues. Typically the application of five iterations of “why?” can uncover the next steps that the team needs to take to prevent the incident from happening again in the future.

As an example, let’s assume that your application is down.

  1. Why? Because the API stopped serving any requests.
  2. Why? Because the latest deploy caused a deadlock when the application started up.
  3. Why? Because the production environment has many more concurrent requests than the testing environment, and a non-thread safe data structure was used.
  4. Why? It wasn’t thought about during development. The tests all passed.
  5. Why? The automated tests don’t cover any high-throughput scenarios.

We hit the root cause by the 5th why. The action is to improve the automated tests to incorporate a load simulation of the live environment.

It’s extremely useful to apply questioning to situations where something has gone wrong. But we should also be applying critical questioning in order to test assumptions about seemingly good processes and decisions. Because humans operate in abstractions, and because we can become comfortable with those abstractions, we can sometimes not question them enough as we should do. A key skill as a manager is being able to question everything for the greater good of the business.

Now, your reason for doing this isn’t because you are trying to be annoying, nor is it because you don’t inherently trust the instruction or direction that you are being given. That couldn’t be further from the truth! Instead, you should be applying a critical mindset to everything that you’re involved in because, when handled personably, it can challenge existing ways of thinking and produce better results.

For example, many businesses operate under the assumption that running any of their applications in the cloud is too expensive in the long term. This thinking can stifle innovation. Let’s apply a similar questioning technique to the 5 Whys example above.

Let’s assume that your team wants to build a new part of the application in the cloud, but are facing resistance.

  • Why? We don’t build applications in the cloud because it is way too expensive.
  • Why is it expensive? When we compare the cost of cloud instances to the cost of buying hardware and paying it off over three years, it costs more money.
  • Why is that the case? We did a comparison of running our existing infrastructure in the cloud two years ago, and the costs were almost double.
  • Which parts were most expensive? Any instances that required reservations of SSDs or GPUs were dramatically more expensive than buying the hardware ourselves.
  • The new part of the application does not require SSDs or GPUs. What would that cost? Looking at the pricing plans now, it seems that the cost of reserved instances is about equivalent to the cost of buying our own hardware. Still, we’re used to buying our own hardware, so we should just do that.
  • But are there other costs with buying our own hardware? I guess there is the time that it takes for us to build and rack the new machines – we could be doing something else instead, plus the extra power consumption in the data center, and the additional spares we’d need to keep as well. We’d also need to deal with anything that breaks, such as replacing drives or PSUs.
  • What do you think about using the cloud for this new part of the application now? Actually, it’s not that bad. We should think about how we can save time and effort by putting more stateless parts of the application in the cloud.

OK, so the example is a little contrived, but I hope that it illustrates a point. We can use questioning to break down assumptions to their root (i.e. an assumption that all cloud compute is too expensive) and then see whether that still holds true. Using this technique with skill can potentially save you and your business a lot of time and money.

Thinking from first principles

When we use critical questioning to challenge existing assumptions, we dig right down to the building blocks that those assumptions are based on. These building blocks are called first principles. By definition, a first principle is a self-evident proposition or assumption that cannot be deduced from any other proposition or assumption. In the above example, the first principle that the assumption was based on was that all cloud compute was too expensive, but that wasn’t actually true.

When approaching new problems and coming up with your own ideas, you should think in terms of first principles to improve the clarity of your thinking. As mentioned previously, our ability to think in abstractions can weaken our judgement, as those abstractions may no longer be as true as they once were. Also a similarly dangerous evolutionary trait is our ability to think in analogy, where we make assumptions based on the comparison of two things that are not actually related. We can also be on top of Mount Stupid.

For example, if your boss approaches you saying you need to build something like Facebook for marketers, then the critical thinking that should have been done to fully explore the problem is being masked by analogy: of course, Facebook is successful, so if we just replicate that for another problem domain then it will definitely be a success, right? Wrong. Instead, you need to think from first principles. What does Facebook for marketers actually mean? Is it about connecting marketers together? Is it about sharing insight or information with each other? Is it enabling communication within a company, or globally? Is it simply being able to easily search for data within their business? What problem exactly needs to be solved?

It’s always easier to reason by analogy than first principles. I recommend watching this video about first principles thinking by Elon Musk. Despite the extra brain power required, thinking in this way leads to better outcomes. In the video, Elon describes how thinking in analogy created an assumption in the industry that batteries would always be too expensive to build. But instead, thinking about the problem from first principles, by researching the cost of each individual component and calculating the cost per kilowatt hour, revealed that previous analogy was not at all true, unlocking Tesla as a business. And as of the time of writing, they’re doing pretty well.

In summary

A key to growth in managerial roles is not simply efficient execution of whatever work that you are being given. Excellent managers are also able to think critically and apply first principles thinking to whatever work they, or the business is doing – it leads to better decisions, less wasted time and money, and more innovative products that solve users’ problems. Encourage this mindset with your team and colleagues.

Working with Sales

comments 2

We don’t sell, we close

What’s your relationship with the salespeople in your organization? Do you even talk to them? Is there a culture of us and them in your company? Do you feel like they see your department as unwashed geeks and you see theirs as a herd of Patrick Batemans wearing Submariners? I hope not!

Regardless of your own relationship with the salespeople in the organization, you have to have utmost respect for them: they close the deals that bring in the money that keep us all employed. Kudos to them.

Although we as engineers may have a stereotype of salespeople as the hustlers of big deals, commission cheques and the wearers of flashy Swiss watches, the art of selling big enterprise deals requires real talent, artistry and chutzpah. These people are at the periphery of the business, often away from home at the other end of the world on puddle-jumper flights, fighting the good fight to sell the stuff you’re building.

What do salespeople do all day?

As a manager in engineering, it’s extremely useful to include some salespeople in your network inside the business. Before we look at some ways that you can work more closely with salespeople, and most importantly, make their lives much easier, let’s have a look at what they typically concern themselves with.

Now there are many different types of sales roles in the world of SaaS. Those roles can range from those who contact leads who have requested demos or who have been identified as prospects at events to qualify them as worth pursuing further, through to senior salespeople who spend multiple quarters crafting multi-million dollar deals. In the same way that your most senior engineers can have a dramatic effect on the future health of the company, the same is true with the most senior salespeople. A landmark deal can secure years of runway and growth.

So what do they concern themselves with?

  • Building relationships. Software companies with sales organizations of a decent size will typically work on deals that are worth quite a lot of money. This means that they aren’t the kind of deals that close very quickly. The length of time it takes from a lead being qualified to the paper being signed is called the sales cycle and for the biggest deals the sales cycle can potentially be years. This means that your salespeople will be continually working on building the relationship with their prospect throughout the cycle, ensuring that what they are selling is what ultimately gets chosen.
  • Solving problems with the technology that you are building. Every client has different problems that your software can solve. Your salesperson will think creatively about how your software can fit into their daily lives so that they can do their job better, faster and more efficiently. This can be as simple as demonstrating the power of the software through to building a compelling story of how their whole organization could change around it.
  • Working on revenue targets and growth. Always be closing: this is slightly tongue-in-cheek with a reference to the quite epic monologue in Glengarry Glen Ross (warning: very strong language) but it rings very true: sales is about closing deals. It’s not about turning up and giving a pitch in the hope that someone will bite, it’s about being creative, hustling, getting on that plane or train, learning about prospects, getting their interest and then getting them to sign on the dotted line. Sales organizations hold themselves to typically quarterly targets and they have to hit them (and you thought that your deadlines were bad). They’re the frontline indicator of the health of the business. If they’re closing lots of deals, it’s probably a function of their confidence in the product and the great work you’re doing. If they’re having a bad quarter, it could quite possibly be an indicator of something else that’s wrong in the organization, but they get the flak. Remember this.
  • Understanding what the market wants to buy. They are uniquely placed to see what kinds of problems clients are trying to solve and what kinds of existing tools they are using to do it (if any!). They can also use the relationships they build to see that there are entirely new, untapped areas of the market to sell to. Also, they can alert you to when there are cheap ambitious startups that are trying to undercut you. Is the market becoming more specialist and is after point solutions rather than software suites? Is the market becoming more price sensitive and as a result you need to adjust yours?

So now we’ve taken a look at what salespeople concern themselves with, how can you help them do their job even better? Let’s be honest – it’s a world away from you working on the code with your team. Or is it?

How can you help salespeople succeed?

There are a number of ways that you can help your sales staff do their job really well. Let’s take a look at some of them.

  • Get to know them. You’ll have more in common with them than you think: you’re making the stuff that they sell! Introduce yourself, spend some time talking to them about their job and what their current challenges are. Buy them a coffee and have a chat. As mentioned at the beginning of the article, some organizations have an us and them culture between engineering and commercial. You can bridge this gap.
  • Prioritize uptime, speed and stability. You might have the best features in the world, but if they’re slow, buggy and ragged around the edges then that won’t matter one bit in a demo. Keep experimental or slow features behind feature flags. Ensure you’re fixing stability issues as a priority. Remember that demos may be occurring on different continents to the one that you’re on, and consider your SLAs carefully. A simple, fast tool can make a feature rich slow tool look awful when they are pitched side-to-side.
  • Deliver on time. Since the sales cycle can be a long one, especially when your software is going through lengthy procurement procedures, remember that your roadmap is a key persuader to the potential buyer. If you’ve promised to drop a feature this quarter and you don’t, then your salespeople will look like they’re overpromising or that there isn’t company-wide alignment on the story and the discipline of delivery.
  • Work on cadence. In addition to delivering on time, you’ll want to work on your cadence of delivery with your team. Software that has regular updates looks cared for, alive and driven by creative people. Sequence your projects so that you can keep releasing new things regularly. If you have large pieces of architecture work that will take months to complete, try to combine them with lots of small enhancements so that your salespeople can show that you’re always shipping.
  • Promise at the right granularity. This point is aimed more at product, but you can help lobby the cause as an engineering leader. Roadmaps that go into to much granularity before the unknowns have been worked out will fail to deliver. Prime your salespeople with roadmaps that provide high granularity for features very close to release, but talk in general terms about what you’re doing six months from now. Describing that the latter half of the year will concern itself with “solving our most common data export problems” is better than saying you’ll be “allowing data export from all 25 components” because it gives you more flexibility in the scope of the project. It’s hard to fail at the first promise.
  • Use their expertise as stakeholders in new projects. If not already, as per your product marketers, invite key salespeople to join your team’s demo meetings and kick-offs for new projects and solicit their feedback regularly. They’re working on the periphery of the business and have some of the most up to date information from the field: key missing features, what competitors are selling, and how you stack up against them.

In summary

The sales staff in your organization have more in common with you than you might think. They’re fantastic people to have closer to your team to get a temperature check on what you’re building, and they have the most up to date information on how you’re stacking up against your competitors. Go and talk to them.

Thank you to Joakim Nilsson for the comments and feedback on my draft of this post.