Over the last decade the bulk of my engineering hires have been US-domestic remote employees. I generally hire full-stack developers, but this technique can be adapted easily to front-end devs and, slighly less readily, to backend developers. This technique also works best for hiring mid-level engineers; you will find it more difficult to use for senior talent.

First, Use a Virtual Assistant

You could do this stuff yourself, of course, but you’re a manager and this is not the highest-leverage task you could be doing with your time.

Bring on a VA that’s good at web research and scheduling. Instruct them to look for portfolio websites of developers who have been freelancing for a couple of years.

• Obviously, the portfolio sites they look for should include the relevant technologies. When hiring full-stack devs I tell them to look for people who put some amount of care into their sites. They don’t need to be beautiful, but they need to be “designed”. Bonus points for links to live projects or a GitHub. Bonus points for a technical blog component.
• (When looking for backend devs, I’m ok with just a technical blog and a GitHub.)
• You want them to find freelancers who haven’t been freelancing for too long, but still seem to be successful in their practice.
• Freelancers who have been doing it successfully for more than a year or so are likely to be independent, self-starters, good communicators, and used to working remotely.
• Freelancers who have only been doing it for 1-2 years are more likely to want out. Freelancing is a tough slog and seems more romantic than it is. There’s a sweet spot you’re looking for: they’ve freelanced long enough to develop those important skills, long enough to be sick of the slog, but not so long that they’ve proven they want to stick with freelancing.

Have your assistant find 25 of these per day or so and dump ‘em in a spreadsheet.

Prune, then Phone Screen

Your virtual assistant may need a couple of review and pruning rounds before they start finding the exact right profile for you.

At this point you should have a freelance project queued up and ready to go. Have your VA schedule time to do phone screens with the appropriate candidates.

During the phone screen, make the following things clear:

• You will start with one small isolated (5 hour) freelance project.
• You will have a regular cadence of small and medium freelance projects after that.

If the candidate does well on the phone screen, hire them for the freelance project. Because a single isolated project is a relatively small commitment for you, you should make the interview process a small commitment for them as well. Don’t drag them through the slog of a 3-interview process. Just a 30 minute phone screen is enough. You will be evaluating them constantly over the next three months, so don’t worry about getting it perfect right now.

Go from Project to Retainer

Now you’ve got a contractor on board. I’m not going to give advice here on how to make isolated projects successful (that’s a topic for another issue!), but make sure you get them all the support they need to accomplish your ~5-10 hour freelance project.

There are three possible outcomes: they do poorly, mediocrely, or well. If they do poorly then you simply won’t rehire them for another project, and you haven’t really spent all that much on the small project. If they do well, queue up another project for them.

If they do well on that second project, negotiate a retainer. You will most likely be able to get a reduced hourly rate in exchange for a consistent 10-15 hours per week. If you paid, say, $100/hr for the first two isolated projects, it’s likely you can reduce the hourly to $60/hr during the retainer period. Freelance hourlys are expensive because they need to cover the downtime in between projects. Remember the advice from step one: you’re looking for people who are probably sick of freelancing. Odds are they’ll be thrilled to get some steady work for a 3-month term.

For the next three months or so keep up the retainer work. This retainer period is in lieu of an onerous interview process — and frankly, it’s better than an interview process. You’re working together and learning about each other, but not yet committed to each other. You’re also not wasting their time, and they’re not wasting yours; you’re getting productive work done and they’re getting paid.

If things are going well so far, allow your team to start working with them more closely. Get some cross-polination going. This is essentially a highly productive two-way interview process.

Extend the Full-Time Offer

After a few months of retained work, you’re going to know exactly what you want to do. There are three options: you can keep the freelancer on retainer as-is, let the contract lapse and move on; or extend a full-time offer.

In my experience, if you get to this point the conversion rate to a full-time employee is very high (assuming your company is a good place to work). You’ve been evaluating each other for the last three months, and both parties will just know at this point. Your team has had opportunities to work with the freelancer, and vice-versa. The freelancer has a very good idea of what life will be like at the company; and likewise you have a very good idea of what their work product, communication skills, and temperament will be moving forward.

Anecdata, Expectations, and Why it Works

You may be concerned off the bat about the success rate of that initial freelance project. After all, if the project is an utter failure, or not usable in your product, you’ve just wasted wasted money! And it is true that the first project is the riskiest. In my experience it goes in thirds — out of three freelancers, the breakdown will be:

• One is a total flop. Pay them anyway, but don’t work with them again.
• One is in a grey-area. The work product looked good from the outside, but it wasn’t really to-spec and it had a number of significant issues. Pay them, but keep looking.
• One will be successful all-around. This is the one that you negotiate a retainer with.

This is why you should choose a small and isolated project for the very first one. A 5-hour project will cost around $500-750 (or so). Frankly, spending $1,000 to find a good freelancer is totally worth it (compare to totally absurd recruiter fees). That third person, even if they don’t convert to full-time, can still be a highly productive contributor.

Personally, I’ve never had a case where I wasn’t able to negotiate a reduced hourly in exchange for a retainer. But I suppose that is a risk as well.

Another possible failure point is the retainer period itself. I’ve had a couple of cases of ending the retainer early. I believe that this was largely due to my laziness early on in the process — not wanting to start the process over again, I probably brought a couple of people into the retainer period that I shouldn’t have.

The final failure point is the conversion from retainer to full-time. In my experience, this conversion rate is very high, around 90%.

When you add it all up and calculate the full-funnel conversion, you’ll end up spending around $2,000 to put a handful of freelancers through the process and convert one into a full-time employee. This is way cheaper than a recruiter, and most importantly that money was spent on work-product. It’s not necessarily a “wasted” $2,000 — you still got real work for that money! On average, I’d say the “wastage” is only about $500; that comes from failures in the first small isolated trial project.

I’ll also note that on average, my retention for employees hired in this manner is four years, and their full-time salaries end up below market, since you’re hiring out of Ohio, West Virginia, and so on.

I’ve had a ton of success with this method over the years. It may or may not work for you, but if you’re looking to start hiring US-domestic remote engineers, you may want to give this a try.

So this week’s CTO Worry is: Remote Work Morale. Specifically, CTOs are worried about the downstream effects of forcing people who were previously colocated into a new and isolated lifestyle.

Remote Work isn’t For Everyone

Teams are typically either distributed or colocated. It’s generally difficult to pull off a hybrid. I’ve seen some hybrid models work, of course; typically when there’s an overseas or satellite office involved. But the big fear today is that remote work isn’t for everyone, and yet we’re forcing everyone to do it.

CTOs are seeing productivity and morale slump. This is a bit disheartening to most of the CTOs who previously reported encouraging early results. What CTOs want to know is: how much of this morale slump is related to WFH vs other factors?

These really are “unprecedented times”. But, anecdotally, I can tell you that each and every time I hired a “non-WFH adjusted” employee (that is, someone who never worked remotely before and didn’t know if it’s for them), it took about 18 months for their WFH status to start affecting their morale.

For this reason alone, I have trouble ascribing the morale slump to the abrupt transition to remote work. Or rather, I have trouble ascribing to morale slump to just the transition to remote work. If, say, there were no global pandemic but for some reason all office buildings just stopped working, it would take a lot longer for this forced-WFH to deteriorate morale to where it is today.

So we must instead look at a combination of factors. First and foremost, all of this is going on during what would normally be the midsummer slump. There’s also obviously a huge increase in background stress due to COVID, the political landscape, and the general sense of instability going around. Added to that is the fact that everybody’s social lives disappeared overnight — forcing WFH is one thing, but at least in pre-pandemic days your remote employees could go out at night. There’s also the fact that most people have cancelled their vacation plans and have literally nothing to look forward to anymore.

That last point is perhaps the most poignant. That famous study of Dutch vacationers suggests that planning the vacation is the best part of the vacation; having a vacation to look forward to 6 months from now can really tide one’s mood over. But now that most vacation plans are scrapped people simply have nothing to be happy about anymore.

What the heck do we do?

Nobody likes their boss forcing them to be social. For that reason I’ve never before supported “mandatory fun”-type activities. Until now.

There are probably two important things you can be doing at the moment. The first is to provide fun social interaction. It’s true that hanging out with coworkers is probably not everyones’ definition of “fun”; but it’s better than nothing. And that’s what we have right now: nothing.

I recommend structured, fun, personalized activities. Hire somebody to put together a trivia game on Zoom each week; make the trivia categories focus around an individual. “This week is Joe Trivia, with categories like ‘80s hair bands’ and ‘famous world leaders’. Next week is Jane Trivia, with categories like ‘Hamilton lyrics’ and ‘Seinfeld trivia’”.

Why trivia? Because a) it’s fun, b) it’s structured c) it’s introvert-friendly and d) the ability to personalize each week adds a special something.

Making these activities introvert-friendly is an important point you should not overlook. You probably started doing a weekly Zoom happy hour at the beginning of lockdown; how did that work out? From what I’m hearing, most of those Zoom happy hours have already fallen off. Why? Because they’re not introvert-friendly, yet most of your team are probably introverts.

You don’t have to go with trivia, but pick some other social activity that hits those same bullet points.

Oh, and let trivia cut into work hours. Now is not the time to try and squeeze blood from a stone. Right now your goal is not necessarily to boost morale but rather to preserve as much of it as you can. Do the first couple of trivias from 4-5 on Fridays, and if people really love it you can consider making it after-hours. But if productivity is so low now anyway, why worry about that 2% of the week you’d cut into on a Friday afternoon?

The second thing you should do is give your employees something to look forward to, plan around, and anticipate. Tons of Disney trips and week-long jaunts to Europe have been canceled, but renting a house somewhere beautiful and isolated is still a viable vacation option.

Encourage your people to rent a house or go camping for a week. If you can, offer to have the company pay for one or two nights of the vacation. And try to schedule it as far out as you can — send people away to go see fall foliage in a cabin in Vermont. Help book an early spring Hudson River Valley rental house for an employee who you know loves hiking. Give them something to look forward to. Many might be unwilling to plan that far ahead; that’s why you incentivize them by offering to pay for the first night.

This isn’t easy, and it won’t get easier for a while. Schools reopening next month is a huge variable, and things may get worse then.

The most important thing you can give your team is understanding and support. I know that’s tough to do right now; you’re supposed to look out for the business and you need everyone to be as productive as possible. But everybody’s losing this year, not just you. If you hope to thrive when this is all over, you’ll need to have taken care of your people in the interim.

I Wish I Had Better Advice

This newsletter is called “CTO Worries”, not “CTO Solutions”. I discussed these topics with a group of CTOs last week, and this is the best we could come up with! If nothing else, take solace in the fact that nobody actually knows what they’re doing right now. There’s no guidebook. We simply have to rely on our experience and intuition.

We all seemed to agree on the core points though: for the duration of this pandemic we will likely need to take a more active role than usual in our employees’ personal morale. Typically, CTOs worry about team morale insofar as their relationship to their job goes; but a CTO managing a team of 30 simply can’t delve into individuals’ personal lives to help out. Now, you might have to.

You have to make the time to do these things, and you have to advocate for your employees moreso than you ever have. You’d have no problem shelling out $1000 to send someone to a conference; shell out that same $1000 to pay for a nature retreat instead! That simple act of generosity will simultaneously give your team something to look forward to and also show that you’re serious about supporting your people through this.

Hey, you made it all the way down here! That means  you probably found this content valuable. I won’t force you to give me money, I just ask that you share this with your friends.

Share

If  you want to support me writing this content, however, feel free to give me money! Either by subscribing or giving a gift subscription to a friend:

Subscribe now

Give a gift subscription

And feel free to Tweet your tech leadership worries to @bkanber, and I’ll try to address them in an upcoming newsletter.

The team grows and eventually they hire their first PM. The product manager works with the engineers (and sometimes with sales) to help flesh out requirements and acceptance criteria for individual features and sprints.

This works for a while, but as the CEO and CTO face an ever-expanding scope of responsibilities they find themselves slipping on certain things. The product development process as it stands is prone to errors, the positioning hasn’t been updated in a few years, and deadlines have been slipping.

So the founders start the search for a product executive. They post a job listing along the lines of “product executive for high-growth startup”, and title it “VP Product” or “Product Director”.

One of two things tends to happen at this point:

• They go through dozens of interviews without extending an offer, or
• Or they hire someone that only lasts a few months

Mistakes were made. Let’s discuss the common ones:

What’s the Scorecard?

That’s the first question I ask CTOs looking to hire a product executive. What does the scorecard look like? (If you don’t understand this reference, go read Who: The A Method For Hiring by Geoff Smart and Randy Street.)

It’s surprising just how many CEO/CTO pairs neglect this step. They’re hiring emotionally, looking for a personal connection with the candidate. That’s fine, but not at the cost of ignoring the objective facts.

Before you write the job listing, you need to ask yourself:

• What does success look like in this role?
• What does the average day look like in this role?

In fact, I advise figuring out what the average day looks like and including that in the job listing itself. I give this advice for all job listings, but product executives are such troublesome hires that I think it’s doubly important to lay it all out on the table up-front.

Strategic vs Tactical

I find that product executives fall into two categories, and that in general, an individual strongly prefers one or the other.

Therefore, straight off the bat, CEO/CTOs tend to make an early mistake in expecting that one person can fulfill both the strategic role and the tactical role. This is a unicorn that you should not expect to find.

Things a tactical product executive does:

• Takes measurements, designs A/B tests, looks at data;
• Pays attention to the product development process and tweaks it to improve efficiency or correctness;
• Gets on the phone with actual customers;
• Develops KPIs to track productivity, judge what to build next, and keep the trains running on time.

Things a strategic product executive does:

• Does constant market research to figure out the best positioning of your product;
• Works closely with sales and marketing to execute on positioning;
• Maintains the product and strategic roadmap over a period of years;
• Figures out how to make the product a Purple Cow (see Seth Godin’s Purple Cow)

Again, don’t fall into the trap of thinking you can find someone who excels at both. Even if you find an executive who has proven themselves in both tactics and strategy, you’ll likely soon find that they have a preference for one or the other.

Before you start on this hire it’s important to understand whether you’re looking for a tactical or a strategic product executive. Don’t expect a unicorn.

Not Knowing How To Interview

Sometimes a founding team will get the above points right but still fail at hiring the correct person. This is usually a case of not knowing how to interview an executive when you don’t have the requisite experience in that field. A CTO who has never been a product professional simply might not know the right questions to ask. (Though, again, Who: The A Method For Hiring is a great read.)

The solution to this one is quick and easy. If you don’t know how to interview for a VP Product role, bring on someone who does.

Most likely you have an investor, advisor, or friend who understands both your company’s needs and this VP Product role very well. Ask them for advice, and then bring them in to an interview.

You’re hiring an executive. If there ever was a time to call in favors, this is it. Make sure you hire the right person, and if you need to go so far as to retain a consultant for the interview, then do so.

Clash With The Founders

Sometimes all of the above goes well but the relationship still sours. In many situations, this is related to the inability of the founders to let go of their ownership over product.

Imagine you’re a VP Product just hired by a CEO/CTO cofounder team. They promise you strategic ownership over the product. You, tapping on your decades of expertise, start making changes that you believe will position the product into a growing market. The founders, however, push back and ultimately veto you.

This doesn’t happen just the once, but nearly every time you try and make a strategic change to the product. “But this is what you hired me to do,” you nearly shout. After 6 months of rolling that boulder up the hill, you get frustrated and quit.

This happens a lot. If you’re a founder and you want to hire a strategic product executive, you will have to give up a good deal of your product ownership. If you have faith in the person you hired, you must allow them to run things their own way — at least until they show that your faith is undeserved.

It is very hard for an outsider to step into a startup and take product ownership away from the founding team. The outsider will either have to be bold, or the founders will have to be flexible.

If you think you want to hire a strategic product executive, but know you won’t be able to let go of your ownership, then you can either not hire a strategic product exec, or you can design guardrails for everyone. This really just comes down to the first point of having a good scorecard and clear expectations for what the role should entail.

In this case, the CEO/CTO must decide what parts of product and vision are still owned by them. They must learn how to identify when they’re pushing back because “it’s my baby”. They must learn how to have healthy, honest communication with the new executive they’ve brought into the inner circle. And finally, they must admit and accept that they can no longer run the entire company by themselves.

In Summary

The biggest pitfalls regarding hiring product executives center around a lack of clarity and communication. CTOs and CEOs, because they rarely have professional product management experience, think they can hire someone to “take care of product” at an executive level. It’s surprising how many intelligent people think that a role like this can be simplified that much.

Instead, recognize that this is a significant hire and you should do a lot of work before even writing your job listing. You should go into the process with a full understanding of exactly what this person’s daily responsibilities should look like, what’s in-bounds and what’s out-of-bounds for them, and what success looks like for you. You should have a scorecard and the first couple of major projects lined up. Discuss these with your candidates to make sure that they lie both within your candidate’s skill set and their proclivities.

Founders must also be careful of the emotional attachment they develop towards their product. If you need a strategic product executive, then you also need to let go of some things to make it work.

Hey, you made it all the way down here! That means  you probably found this content valuable. I won’t force you to give me money, I just ask that you share this with your friends.

Share

If  you want to support me writing this content, however, feel free to give me money! Either by subscribing or giving a gift subscription to a friend:

Subscribe now

Give a gift subscription

And feel free to Tweet your tech leadership worries to @bkanber, and I’ll try to address them in an upcoming newsletter.

Conventional Wisdom Says…

As with home security, most intrusions are opportunistic. Every home or car has a window that can be broken. Yet most intruders will simply check the door to see if it’s unlocked. If it’s not, they’ll go see if one of your neighbors was careless. Therefore a CTO’s first step should be to eliminate all opportunistic attack vectors. (UFO VPN’s logs were exposed via an unsecured ElasticSearch instance).

The other piece of convential wisdom says that you will likely not be able to withstand a directed, concerted attack from a skilled attacker. Therefore a CTO’s second step should be to hire a concerted attacker.

Unfortunately, many companies don’t have the budget for this, so the conversation naturally turns to what other concrete steps CTOs can take to secure their environments. We like security in layers and security in-depth, so don’t look at the following ideas as options to choose from but rather a whole set of tactics and strategies you can implement as they become appropriate for your organization.

OWASP Top 10

Most CTOs agree that the OWASP framework is… shoddy. At the same time, most also implement some sort of OWASP review into their code cycles. Why the apparent hypocrasy?

In an ideal world, all of your engineers would also be security experts. But this isn’t an ideal world, and they’re not. The OWASP Top 10 ends up serving not as a tight security framework, but rather as an awareness campaign. By adding a security or OWASP portion to code review, CTOs hope to attune their engineers to a basic understanding of security concerns. The OWASP Top 10 is an easily-digestible checklist that engineers can glance at before hitting commit; and the hope is that a code reviewer — with OWASP in the back of their mind — will be looking for other potential flags to raise outside of the OWASP framework.

If you’re not doing this already, this is a cheap and easy way to a) incorporate security review into code review, hopefully catching the truly low-hanging fruit and b) force engineers to think about the security implications of their code.

Penetration Testing

If you have a little bit of budget you should hire an external penetration testing firm. Conventional wisdom says you should do this at least once per year, preferably twice per year. Take the pentesting findings seriously. Generally, a pentest report will contain lots of items that you consider to be irrelevant or false positives. Don’t ignore them out of hand! Often, a tiny little vulnerability can be leveraged into a larger one, later on. Just because a pentester wasn’t able to convert a vulnerability into an exploit today doesn’t mean someone else won’t be able to 6 months from now as your codebase and architecture changes.

I also strongly recommend buying a copy of Burp Suite for your team and having a portion of your engineers learn it. You won’t be able to do as good a job internally as a professional firm can do, but even naively running Burp Suite against your app once per month can pay dividends. And similarly to the OWASP approach, making an internal pentest part of your regularly scheduled audits will only serve to attune your team more closely to security concerns.

Bug Bounty Programs

The problem with pentest firms is that pentests will typically only scratch the surface. The pentesting firm is paid to generate a pretty report; they’re not actually paid to discover vulnerabilities for you.

If you can’t afford a full-blown grey-hat hacker to run you through your paces, but you still have some budget left after hiring your pentesting firm, then you should consider running a bug bounty program through hackerone or similar.

Unlike pentesters, bounty hunters are paid per exploit. And they will find exploits. In my opinion this is the single most effective thing you can do with your budget.

You are typically allowed to define the parameters of the bug bounty program; ie “look only for authorization exploits” or “ignore our static-hosted sites”. This is a good way to make sure you don’t blow through a budget in the first week. You must be prepared to pay; expect several hundred to a couple of thousand dollars per exploit. (An ounce of prevention is worth a pound of cure.)

A fun exercise here is to get your team to tighten up security as much as they possibly can, until they’re convinced that the app has no holes. Then open up the bug bounty program and watch as your team realizes they’ve reinvented Swiss cheese.

White-Hat and Grey-Hat Researchers

Everything above really only aims to secure your application or software. But just as most undirected attacks are opportunistic, most directed attacks involve some social engineering. This is why conventional wisdom says you won’t be able to withstand a concerted hacker.

The only way to get a handle on this is to preemptively hire a concerted hacker. If you’ve run a bug bounty program already, then a white-hat hacker may not be able to find too many (or any) software exploits. But a grey-hat researcher who also uses social engineering almost certainly will find a way in.

This is where things get really messy and difficult to control. Think about all the ways “trusted users” could (accidentally or nefariously) exfiltrate data from your app. Every admin panel is a risk, and every person with access to an admin panel is a risk.

I still see companies using production exports as seed data for local development. This is both a terrible idea and also a common vector for data leaks.

The important questions you have to ask yourself here are: who has access and how, how do we protect data even when “trusted users” are involved, how do we set up layers of security to mitigate or minimize social engineering, and how can we best monitor for “funnies”?

Because every organization is different, the best thing to do here is to hire a skilled professional to put you through your paces.

Monitoring, Routines, and Incident Response

A healthy organization doesn’t just do these things once a year or once per quarter. They maintain a state of constant vigilance. They install intrusion detection and network monitoring software, use tools like Amazon Macie to detect accidental PII leaks, and most importantly respond to incidents in a predictable and timely manner.

I find about half of startup CTOs have no incident response policy in place whatsoever. This is also a bad idea. Many companies are in an in-betweeny state: they do have an on-call rotation for engineers, they have some monitoring and firewalls, but have no actual policies in place for what to do when they find something. So the on-call engineer calls their boss, and their boss makes an ad-hoc judgement call. Most people are not crisis experts, so it is tough for me to advise allowing people to make ad-hoc judgement calls while they’re under duress. This is how security incidents get swept under the rug.

A better approach is to have scheduled audits and a well-defined incident response policy. When an engineer finds something funny, they should be able to look at their checklist or flowchart and be able to respond to the incident with confidence. When their boss is called in, they should be able to look at the flowchart and the risk categorization of the servers/systems/data that was breached, and know exactly under what conditions customers and authorities need to be notified, and how.

Most CTOs wait until their first security incident to figure this stuff out. That happened to me nearly a decade ago, and it’s not a comfortable position to be in.

This all feels like paperwork and most techies hate paperwork, so unfortunately most ignore it.

Fortunately, the various compliance frameworks make it easy to wrap all this stuff up into a single procedure. GDPR, ISO-27001, SOC 2, and the NIST framework all require that you have risk classifications as well as incident response procedures. So in this case you can drop two birds with one stone: pursuing compliance will also prepare you for these eventualities. Even as a company with little or no budget, you can still strive to hit all the GDPR/ISO/NIST checkboxes even if you don’t pay for a certification at the end of the day.

There are two major, non-technical advantages to pursuing these frameworks. First, they force you to maintain a dataroom with good paperwork. It’s time-consuming to set up, but easy to maintain once it’s in place. Second, they force you to continually audit and record your procedures.

Fortunately for us, our dataroom has only one security incident filing in it. But it does have dozens of audit reports, attestations from engineers about training they’ve received, checklists, procedures, form letters, and anything else we could possibly need if facing either a security incident or an audit from a regulatory agency. The peace of mind that this offers a CTO simply can’t be measured in dollars.

In Summary

All CTOs must practice defense-in-depth. It’s too easy to focus only on software and code security, however, so you must also take a close look at your people and processes.

As always, if you’re not an expert in something, hire an expert. Get an external pentest once per year, pay for internal Burp Suite training, start a bug bounty program, hire a greyhat.

If you can’t afford to hire an expert (and even if you can), strive to make security cultural. Train your engineers on security practices quarterly. Make security review a part of code review. Train your non-engineers about PII, data exfiltration, and social engineering.

Finally, hope for the best but plan for the worst: make sure you have clear incident response procedures, make sure you have an email template informing customers of a data breach prepared, make sure your data room is up-to-date, make sure you know how to contact the appropriate authorities based on your jurisdiction.

And most of all, make sure to keep your front door locked even though you have that huge window in your living room.

Hey, you made it all the way down here! That means you probably found this content valuable. I won’t force you to give me money, I just ask that you share this with your friends.

Share

If you want to support me writing this content, however, feel free to give me money! Either by subscribing or giving a gift subscription to a friend:

Subscribe now

Give a gift subscription

And feel free to Tweet your tech leadership worries to @bkanber, and I’ll try to address them in an upcoming newsletter.

Most of the time, tech leaders face common and relatable problems. We face growing pains as companies and have to figure out how to balance our teams, provide career paths for employees, and so on.

Today though, in mid-July 2020, we’re facing some pretty uncommon problems. I’m hearing lots of new concerns from CTOs over the last four months: employee health and safety, economic collapse, shifting to work-from-home, figuring out how best to support Black Lives Matter, and whether (or how) to attempt a slow shift back to office work.

My plan for this newsletter was to go over old conversations, because over the years I’ve found that there are a finite number of core CTO concerns. But that type of advice isn’t as valuable today. The next few newsletters will therefore consist of more timely topics, and this week’s will be COVID-19.

Here’s what I’m hearing CTOs worry about most.

Are you keeping your offices?

What are your (company’s / team’s) overall plans regarding office vs work-from-home moving forward?

This question was more popular back in May and June, as many companies were adjusting to remote work and trying to figure out if it was viable long-term.

I’m seeing about 60% of companies and teams keeping their office situation “as-is for the foreseeable future”, meaning that they’re going to keep the office but continue to WFH until it is safe or until some other factor changes. In general, these respondents are larger companies with a lease on a single large office space.

I’m also seeing most companies with multiple offices trying to figure out how to combine/reduce/eliminate office space. Here I’m seeing all sorts of permutations; keep the NYC but close the midwest, keep the west coast but close NYC, eliminate the overseas office and have them be WFH, etc.

Of course, a number are going fully remote now. The companies that I see doing this already had a good remote culture in place while maintaining a colocated office. An interesting thing to look out for is how sales and marketing teams will adjust to remote work; the companies I see going full-remote already have a solid product/engineering remote culture, but colocated sales/marketing. This isn’t necessarily a “CTO worry”, but we will need to figure out how to keep extroverted members of the team (regardless of department) fulfilled through quarantine and remote work.

In short, everyone’s just doing what seems best for them. I do worry that some companies are underestimating the effort it takes to develop a strong remote culture. Everyone pulling together to tough-out a few months of WFH is different from shifting your organization to a permanently distributed one, so watch out for landmines here.

Leave a comment

We have people desperate to come back to the office.

Are there any policies that make sense?

This question circulated around in mid-June as NYC had flattened the curve and kept it flat for a bit. THE RESPONSES TO THIS QUESTION ARE THEREFORE OUTDATED.

I DO NOT RECOMMEND YOU ATTEMPT A TRANSITION BACK TO THE OFFICE. Cases in the USA are surging as of this writing and I strongly recommend everyone continue strict social distancing and work-from-home policies.

Now that the disclaimer’s over: last month, I discussed with several CTOs what a return back to office work might look like. Is it possible to do it responsibly? If so, how would it work?

There was unanimous agreement on the following points:

• Return to office work would be opt-in, and ideally limited to the lowest-risk population (how a company could enforce this was beyond us)
• Office occupancy would be kept very low, 25% or less
• Good office ventilation (open windows) required
• The company would need to provide PPE and at very least, cleaning equipment and training, or at best, daily professional cleaning

However, even then, we still couldn’t agree that it was a good idea or safe to return to the office. We brainstormed for a while and came up with some more bullet points to play with:

• Only people who can walk to the office can use it (ie no commuting allowed)
• Co-working in Central Park with PPE and social distancing
• Only one person in the office per day

And even then, we still couldn’t agree that any of this would be a good idea for the company to officially support. So, even when the curve was pretty flat and we were feeling confident, we couldn’t come up with a great way to return to office work quite yet. At best, we were able to come up with a few safety precautions. Again, I do not advise anyone to attempt to return to the office unnecessarily. It is all of our responsibility to flatten the curve.

Leave a comment

We have a team member who’s always been a bit abrasive in written communication.

They’re good in-person but now that we’re remote, it’s becoming a problem. How can we address this?

There were a few variations of this question recently, but it boils down to the basic issue of an employee who was “marginally toxic” pre-COVID becoming more toxic now that communication is largely written and asynchronous.

The obvious reaction to this is “you should not retain a toxic employee”. Since this isn’t a 1-on-1 advice session, only you can know your circumstances. Perhaps it is not possible to let that employee go.

I find that whenever there’s a discussion of a toxic employee, the first question that must get resolved is one of self-awareness. How aware is the employee that their own behavior is seen as toxic? Have you (the manager) ever addressed it with them directly? (A surprising number of managers only dance around these issues, but it’s important to have the hard conversation.)

One idea that floated around this conversation was a code of conduct or a looser “styleguide” for Slack/GitHub/Jira tasks. I’ve not seen anyone implement this yet, so the jury’s out for now.

One of these conversations landed on a good point: if you decide to retain an employee that you know is toxic, it’s now entirely your responsibility to a) figure out why they’re toxic in the first place and fix it and b) protect the rest of your team from that toxicity at all costs.

This really only applies in cases where someone is just marginally toxic, and perhaps is just reacting to recent circumstances rather than displaying chronic behavior, and is also otherwise a very valuable team member.

In one case, the employee in question was one of the early team members, had always been pleasant to work with, and developed some of the core systems early on. However, this person had become more abrasive in written communication over the last year (still pleasant in-person), and it reached a breaking point during the early weeks of COVID lockdown (with no more redemptive in-person meetings).

We discovered that the employee had long shown signs of unhappiness in their work. After contributing and developing core systems, that person’s role shifted to maintenance and support, and had become increasingly frustrated with seeing his work be managed by sales managers and customer demands. Additionally, this person was now in the customer-support loop, and spent most of their time just adding reactive patches, doing maintenance, and fulfilling feature requests.

This is fortunately one of the cases of employee toxicity that may be resolvable. A recommended course of action was to immediately eliminate that employee’s customer support duties (as that seemed to be a large point-source of stress for the employee), and then to figure out if there are any greenfield projects they could take on in Q3.

The moral of this story: some employees are slowly and quietly driven to the brink by the circumstances around them. It’s easy for a manager to accidentally lead someone into a situation like this. If you see a typically-reliable employee start to become more difficult, you had better take a step back and try to figure out if there is a root cause nearby.

Leave a comment

How are you adjusting your roadmaps for Q3 and Q4?

Everyone’s Q1/Q2 roadmaps got messed up — and now CTOs are wondering how other companies are adjusting to this. They’re asking questions like: how far out are you roadmapping? How are you adjusting for remote/WFH? Are you incorporating plans for office reopening?

I’m hearing most CTOs assume that their teams (if not their companies) will be WFH through the rest of 2020 at least.

I’m also hearing some CTOs making downward adjustments to WFH productivity modeling. One CTO said “I’m assuming 4 productive hours per day per employee”. The general consensus is that productivity is a little lower at the moment, but we’re all hoping it’s a temporary condition caused by undue stress, fear, and unexpected life changes.

Overall, it seems like it’s not a bad idea to plan for a less productive Q3, and use the next quarter to focus on how we can support our employees through this transition so that they can approach normal productivity levels again in Q4.

Another general consensus seems to be that nobody is long-term roadmapping at the moment. Most are looking only a quarter ahead, and trying to bullet-point out two-quarters ahead, but all are braced for goalposts to move rapidly and unexpectedly.

Companies who typically do big, annual roadmapping exercises in Dec/Jan are still planning on attempting it. Perhaps we’ll stabilize enough in Q3/Q4 that a 2021 roadmap is possible to plan.

But for now, don’t sweat it. Do your best to plan Q3 around helping employees thrive remotely, and take it sprint by sprint for now.

Thanks for reading this July 12th edition of What CTOs Worry About. Please subscribe and take part in this week’s subscribers’-only discussion.

Have your own CTO or tech leadership worry? Tweet @bkanber #ctoworry and I’ll try to fit you in to the next newsletter!

And don’t forget to tell your friends!