After holding the survey open a bit longer than planned plus a few delays in data collection, I’m excited to share the results of the State of Work Survey for June 2020.

To everyone who provided input, thank you.

I’m not going to restate the entire report here. I’ll give a few topline findings. For everything else, I’ll point you to the PDF of the report.

• Most (75%) of the respondents are currently working remotely. Only 25% were prior to the pandemic.
• Half of respondents reported that they both work remotely and are in an environment that includes children.
• Respondents generally rated their managers positively (mode of 7 and mean of 7.8 on a 10-point scale).
• Managers report remote-management challenges that fall into three categories:
  • Connection to their team: relationships, engagement, organic interactions
  • Oversight and basic management work: driving results, ensuring employees are doing what needs to be done, accountability, ability to check on work or observe employees at work
  • Coaching and mentoring: determining coaching topics, continual observations allowing course-corrections and broader discussions
• Remote workers identify communication with their manager as the most common new challenge to overcome.
• For employees that are new to remove work, motivation and focus are a major challenge.

My recommendations based on the survey data are:

• Deliberately invest in manager and employee communication.
• Managers should help remote employees set boundaries.
• Operationalize remote behaviors to remove tactical problems.
• Be patient, control what you can, and let the rest go.

Those recommendations are, of course, more fleshed out in the report.

Conducting the survey and analyzing the results was enjoyable and informative for me. I hope there is value in the results to you!

As anyone reading this in real-time knows, the world has looked different to most of us for the past couple of months. I’m curious what that means to everyone.

For me, I started working for a pure-remote company last August, so I had very few work-related changes. On the other hand, I experienced social and family changes. No gatherings, stores and restaurants closed, and most impactful of all, schools closed. That means my kids got to be distance learners, and my wife got to be a distance educator.

Obviously, my experience isn’t typical. Realistically, nobody’s experience is typical. And that’s why I’m running a somewhat unscientific survey, in the hopes of better understanding what everyone is experiencing.

The survey I put together uses work as a touchpoint, but asks about things like kids at home during this.

I want to hear a bit about your experiences so I can get a better idea of how life really looks for everyone. I want to hear from you: employed or not, affected a lot or a little, in the U.S. or not, urban or rural, I’d love to have your input! I anticipate it taking about 10 minutes to fill out the survey, unless you’re going to write a lot.

Your individual responses are 100% confidential.

If you are interested in finding out what I learn, I’ll send a report to anyone who has filled out the survey after I’ve gone through all the responses. I’m planning on finishing analysis within the month, June 2020.

One final thing: to get the broadest possible reach, would you please share the survey with your friends, colleagues, and the rest of your network?

The State of Work Survey for June 2020 will be open for responses through Saturday, June 13.

My team at H.I. Digital Solutions swapped out the database layer of an application. We moved from CosmosDB (a document-style/NoSQL database) to SQL Server.

Some things went well. Some less so. Check out what we learned in the post I wrote: Retrospective on a Database Replacement.

I wrote a blog post for the H.I. Digital Solutions blog!

It’s all about Processes and Outcomes, in case you didn’t get that from the title.

I’ve been thinking a lot about policies lately.

About how they’re sometimes necessary and sometimes not. About don’t scar on the first cut and about how organizational scar tissue can spread to cover related areas of the organization.

I’ve been thinking about the freedom of young companies with no policies, and about the freedom of ossified companies with a policy for everything.

And about how to roll out policies as effectively as possible, and how to make unpalatable policy changes more palatable, and about how to make compliance easier, and about how to communicate policies to new members of an organization who weren’t there for the initial rollout.

I’ve been thinking a lot about policies lately.

After thinking about policies for long enough, I started to ask one of my favorite sense-making questions: what’s the purpose of this? Specifically, here, “what’s the benefit of policies?”

There are policies that are in place for legal reasons, or to make a department’s job easier or more consistent (finance, HR, and IT are the classic examples here). But even in those cases, “because it makes it easier for HR” is too easy an answer.

Take a simple PTO policy, for example. “Everyone gets 4 weeks of PTO a year. PTO must be approved by the employee’s manager and recorded on the employee’s timesheet.” It’s easy for HR. Making it easy for HR serves the organization. HR does not need to do an exhaustive analysis every time Gerald wants to take an afternoon off. Gerald’s manager just needs to verify that Gerald still has enough PTO available.

That policy also serves the employee. Gerald doesn’t need to worry that someone in HR has it out for him and will block all his PTO requests. He doesn’t need to worry, much, that his manager only wants him to be able to take two weeks off every year. Gerald just needs to budget his policy-granted PTO and request it as needed.

I believe that most of the policies at most of the companies in the world are in place to serve the organization, not the employee. I haven’t seen most of the policies at most of the companies in the world, so I’m guessing here. The hypothetical PTO policy above is easy to administer, takes PTO off the table for negotiations, and places very few restrictions on the organization.

The way policies are written gives enormous insight into the mindset of the organization that created them. If you want to know who the organization cares about (i.e., should you believe “employees are our most valuable asset!”, or similar slogans like “the customer is always right!”), take a look at their policies. Who does it restrict? Who does it require something of?

Let’s make a minor tweak to that policy. “Everyone gets 4 weeks of PTO a year. PTO must be approved by the employee’s manager and recorded on the employee’s timesheet. If the employee has PTO remaining, the PTO request must be approved within two days of the request being made, or a written explanation of the denial delivered to the employee and the manager’s manager.”

The amount of PTO stays the same. The process for approval stays the same. But now the organization is placing restrictions on its actions. A manager can’t “pocket veto” the request or deny the request without explanation. The time frame and explanation for denial both are requirements for organizational behavior. The policy has become much more balanced in whom it serves.

That last sentence is a bit misleading. It’d be more accurate to say the change in the policy reflects a mindset shift by the organization to more highly value responsiveness to employee PTO requests. Policies by themselves are simply reflections of organizational values.

Policies exist along the swing of a pendulum. On one side are policies that solely benefit the organization. On the other are policies that solely benefit the employee. I’d be willing to bet that most policies exist most of the way to the organization side of the pendulum.

The next time you write a policy, or roll out a policy, or demand a policy be written, think about the pendulum. Where does the policy fit on the swing of this pendulum?

Or, if you’re willing to challenge yourself and your organization, place all of your policies on the Policy Pendulum. Start with written policies, but then add in the unwritten ones (“you’re supposed to get a new laptop every three years, but they really won’t approve it until it’s been four years, unless you can convince Gladys it’s not working right”).

If you’re really brave, compare what you’ve found to your organization’s stated values or catchphrases. “We value innovation and autonomy” but our policies only restrict our employees. “We follow a well-defined process to guarantee results” but our policies don’t require the process to be followed.

Without evidence, I believe that an organization that places its policies on the Policy Pendulum congruent with its stated values will outperform an organization that does not. In the organization that does not, confusion and grumbling will result. But in the organization that sets up policies to mirror its values, everyone will benefit from the resulting sense of consistency and correctness.

“The new intern shows up next week.”

You feel excited and ready for that, right?

I don’t know about most companies. I’m guessing most people are happy to have an extra worker around. And most probably don’t know exactly what they’re going to do with their new intern.

Want to know what to do?

Yeah, I can’t tell you. But I can tell you what I do, and why.

Interns, as Joel wrote a long time ago, are a great way to get really good software engineers. That’s the number one reason for an intern program. The number two reason is to get some things done that you wouldn’t otherwise. Not the grunt work of relabeling all the books in the company library, or going through Jira and exporting all the old cases to CSV. The proof-of-concept that’s always just a few months away, or that cool feature that keeps getting pushed back because Accounting keeps asking for the changes to the ledger striping on the reports your team’s software generates. The number three reason is to see how your current team steps up to mentor and lead. And the number four reason is to inject youthful energy into your team, the kind that your world-weary and jaded 25-year-old engineers just don’t quite have anymore.

I live and work in Cedar Rapids, Iowa. That’s pretty far from MIT, Stanford, Yale. Realistically, I don’t have a shot at recruiting people from the typical software engineering powerhouse schools. I’m okay with that. I’m reasonably close to Iowa State University, University of Iowa, and University of Northern Iowa. There are a few smaller colleges and universities in town or nearby. And there are some pretty solid folks that go to our community college as well.

The company I work for isn’t well-known, even locally. We’re not Google or even Salesforce. We don’t do augmented reality blockchain mobile calorie-counting apps. Unlike some companies, we need to work to get interns. For those of you that are thinking it’s a terrible idea to do a lot of work to get interns, I’ll just point out real quick that recruiting interns is actually easier than recruiting full-time engineers. So we go to career fairs and other recruiting events.

Easy, right? Set up a booth, fill a box with resumes, head back to the office, pass the best couple on to HR, and wait for them to show up in May. Whew! Glad we got through that! Except it’s not quite so simple.

Set up a booth. Make sure it’s aimed at your target audience. They don’t know what your company does, unless you’re Apple or the Army or something. Use your booth to show them what you do and make it indicate in some way what you’re recruiting for. I’m going to tell you a serious trade secret here: I print out a sign with big letters that says something like

• HIRING SOFTWARE ENGINEERS
• FULL-TIME
• SUMMER INTERN

That way, it’s really easy for all those college students wandering around to know what you do. Keep all the graphics that HR and marketing put on your booth backdrop. But make it easy on the candidates. They’re maybe doing this for the first time. They’re processing a lot of information. And probably nervous.

Don’t feel like you need to give away swag. If you do, make it worthwhile. Good pens or pencils. Not gimmicky junk. Unless it’s good gimmicky junk. Back when I was going to career fairs trying to get my first internship, when dot-com craziness was in full swing, National Instruments was giving out bouncy balls with LEDs in them. Way cool at the time. Those “laser balls” got most of the computer science majors at the career fair to stop by their booth.

Where, I suspect, they filled a box with resumes to hand to HR when they got back to the office. That’s the wrong answer. Have a conversation with each person that stops by your booth. Doesn’t matter if they seem to be a good fit or not. You’re trying to figure out if they really are a good fit. Look past the first impression. That awkward, nervous kid? He’ll stop being nervous once you get to know him, and in two years he’ll be pushing his team lead. Of course, once you figure out someone’s really not a good fit, feel free to end the conversation politely. Whether they’re a good fit or not, leave them with a good impression. Heck, if they’re not a good fit, maybe suggest a company that you think might be a good fit (“Hey, listen, I don’t think we’re a good fit for what you’re after, but I was talking with someone I know over in booth 42, and they have a project that sounds ideal for an Agricultural Engineer / Microbiology major like yourself. Tell him I sent you, and good luck!”). It’s the same amount of effort as being rude, and they just might be friends with the exact candidate you’re looking to hire.

During and just after that conversation, before you toss that resume in the box to take back to the office, write down some notes. What’d you think of that person? What projects, experiences, stories, character traits, or behaviors did you notice? How good a fit are they, on a scale you define arbitrarily? Now, I prefer to take notes on their resume, which my current HR department has told me in no uncertain terms I am not allowed to do. The notes are indispensable, though. Even if it’s just a word and a scribble, it can help me remember that, oh, yes, this is the one whose internship last summer dovetails so perfectly with the project I’m planning for this summer that I need to interview them, even with a 2.8 GPA. (Tip: If your HR department tells you no writing on resumes, sticky notes are better than nothing. Even better are clear plastic sleeves (page covers, report covers) that you can put the resume in, so you can draw circles, add scribbles, etc.)

Wait a second. You’re not even back from your first career fair, and I’m already saying “the project I’m planning for this summer.” Yes. You should already know what you want to do, or at least the broad strokes of it.

You should know that for two reasons. At least. First, you need to be able to have an intelligent conversation with the very first student that shows up at your booth in September. “So,” she says, gesturing at your sign, “what will your summer interns be doing?” Do you want to stare dumbly for a minute and then say “they’ll, uh, write software, uh, probably in um, Java?” Or do you want to say “our plan for this summer is to hire two interns to work on extending our EnterpriseFizzBuzz solution to add a BuzzBazzer!”

So anyway, after you’ve had intelligent conversations with a hundred career fair candidates, sorted the resumes, interviewed them, it’s time to decide who to make offers to. I could write a lot about that, but won’t right now. For now, I’ll give you the very brief advice that if your interns are going to be working together, hire them as a team. Pay close enough attention that you’re not just hiring the five best programmers. Put together the five candidates that’ll give you the best overall productivity. Programming, design thinking, testing, pessimism, optimism, debugging, lateral thinking, attention to detail, and all those things.

And make sure to introduce the team to each other by email before they start. Give them the chance to opt out, of course. But if they can get to know each other just a little bit, you’ll be setting a much better tone for the summer.

Speaking of setting the tone for the summer, make sure everything is ready when they show up. Easy stuff like desks, computers, chairs. Harder stuff like a defined project, a spec, mentors. Everything.

Speaking of desks and such, do your best to put your interns together and in a decent part of your office. Don’t put them in the copy room closet or by the sales team’s offices where you hear the same jokes re-told on every phone call. You should be trying to sell the interns on the company, even if they’re not a long-term hire.

They’re only going to be with you for 12-13 weeks. If you have a week of getting set up, another week of trying to define a project, and a week at the end of demos and goodbyes, and a few days off around Independence Day, suddenly you’re looking at 8 productive weeks.

Define the project ahead of time. Size it for their team, abilities, and timeframe. Don’t just have it vaguely defined in your head. Write the specification, or the stories, or whatever your organization uses (if your organization’s answer to that question is “nothing”, start with a functional specification, decide to stick to a basic Scrum implementation for just your intern team for the summer, and let me know how it goes). Write those far enough ahead that you’re not scrambling the week before they show up. And build in some contingency work on both sides. If the team is brilliant and everything goes well, have some extra bells and whistles for them to add. If the team runs into roadblocks, someone flakes out, or the project ends up being bigger than you thought, be prepared for what you’re going to cut.

Whatever project it is, make it real work. Maybe you already solved the tough part and need to build the product around it. That’s real work. Maybe there’s a tricky problem you haven’t solved, but with a few weeks your interns should be able to figure it out. That’s also real work. Don’t let it be something that doesn’t deliver value to the business.

I mentioned mentors a few paragraphs up. Pick one mentor per intern. Don’t pair one mentor up with two interns. Yes, I know it’s way more efficient to have Josephine mentor two of them, because she already knows the project, and besides, Theo is really focused on rewriting the Leftpad library in Typescript so he can’t be bothered. One per intern. This helps build relationships and gives a way to deal with interpersonal conflict. Yep, interns have it too. And they’ll have a better experience if their mentor isn’t also mentoring the person they have conflict with.

Figuring out who gets which intern is a bit of an art. You can draw names out of a hat if you want. It’s better to ask a few questions:

• What does this intern need to grow?
• Which full-timer can push this kid technically?
• Who has the ability to give feedback in a way this intern will receive it?
• How will this full-timer lead someone with a different personality and skillset?
• Which interns and full-timers are completely incompatible?

I usually pay special attention to the most- and least-technical intern. If I get them paired up well with mentors, usually the ones in the middle are easier.

Make sure your mentors understand the expectations. Saying “hi” to their intern each morning is a good starting point. You might also very reasonably ask your mentors to:

• Hold a weekly 1:1 with their intern
• Weekly or every two weeks give you an update on their intern’s status, needs, and progress
• Review their intern’s code
• Attend sprint reviews
• Have a daily conversation (doesn’t have to be long) with their intern and check to see if they need anything

You’ll need to make sure the mentors get the time to do these things. And you’ll need to hold them accountable for doing any of these things you tell them to do. Things will come up. “But boss, I got pulled into the meetings with Insuri-corp, and you know what a big deal that is!” For full-timers that want to manage someday, they’ll need to juggle priorities and make time for what’s important (like their team). For full-timers that want to stay technical, they’ll need to be able to stay technically engaged with their team even when supporting other projects. Whatever your full-timer’s career goals, this is reasonable growth to expect.

Speaking of growth, running an intern program can stretch you. Instead of handling one project, you’re handling two. (Or instead of n, you’re handling n+1.) Here’s what you can reasonably ask of yourself:

• Talk daily in the stand-up so the interns are comfortable with you. Make sure you’re providing actual value.
• Talk to the mentors at least weekly about their interns.
• Sit down at least monthly with each intern/mentor pair to check on how things are going. If you don’t have a preferred way to handle this, try:
  • Ask them:
    • “what’s going well?” or “what do you like?”
    • “what’s not working well? or “what don’t you like?”
  • Ask the mentor:
    • “what’s going well for them?” or “what are they doing well?”
    • “what could they do better?”
  • And have a good, constructive conversation about the answers.
• Let the interns focus on good problems (e.g. a choice of algorithms, implementing an API) with appropriate guidance. Help them avoid bad problems (e.g. not enough network ports in the intern area, IT won’t give needed permissions to the share drive).

At the end of the summer, you’ll start to realize the interns are going to go back to school. Finish well. I’ve found that a formal (evaluated) presentation of the intern project is a great way to do that. Give the intern team a heads-up about what’s going to happen, and have them present to your whole department. Have them demonstrate their project, talk about what went well, what adjustments they had to make, and what they might have done differently.

Once they finish their presentation, thank them for spending their summer with you. This should be brief–don’t embarrass them or overshadow their presentation.

Individually, invite the good ones to come back. Maybe that’s to intern next summer, to co-op during the school year, or work full-time. Offer recommendations to those that deserve them.

HR may have an “exit interview” which consists of getting their keycards and laptops back. Don’t rely on HR to get you actionable information to improve the intern program, unless you have an amazing HR department that also understands software development. Have a useful last one-on-one with each intern (you can invite the mentors, but I usually do this without). Find out what they thought of their whole-summer experience. Take notes. Use that to figure out how to improve the intern program for next year. And give them a fair assessment of their work, their professionalism, how they’ve grown, and what you see as next steps for their career. If their future isn’t at your company, say so. I’ve had some brilliant interns that I’d have loved to work with, but whose paths were elsewhere, and I’ve helped them get where they wanted to be.

On their last day, or as close to it as you can come, take your interns, mentors, and anyone else they connected with to lunch. Pay for the interns’ lunch, at least (your company’s policies on paying for food may vary; even if you have to pay it out of pocket, do that).

Back to HR real quick–they’ll probably verify contact info for each departing intern to mail W2s and all that stuff. So they’ll probably tell you it’s taken care of. Ignore them when they tell you that, and get contact info from each intern. HR won’t stay in touch and build relationships with your soon-to-be-former interns. That’s up to you. Let them know when you’ll be at a career fair at their school or interviewing on campus. (While you’re there, buy them dinner if it fits into everyone’s schedule.) If you found out they’re really interested in no-electricity woodworking, send them the video you ran across about the guy who built a whole house with a handsaw and a hammer. You never know, that video may be the difference between them ending up working at Netflix or coming back to work for you. Or if they do end up working at Netflix, it may be what gets them to recommend you when a position opens up there. You definitely don’t want to rely on HR for that kind of thing.

There. You’ve just gotten most of my secrets for running a decent intern program. The ones you didn’t get are the ones I just didn’t think of as I was writing this. I’m okay sharing this, even with those of you that recruit interns from the same schools, looking for the exact same students I’m looking for.

The simple fact is, some work goes into putting together a good intern program, and a lot of people just won’t do it. It doesn’t hurt me at all to share information with people who aren’t going to put it into practice.

And if you do put it into practice, and word gets around that your intern program is better than mine, great! The students that you recruited instead of me? They’ll have a better experience with you than with me. That’s good for them. And it encourages me to get better.

“The new intern shows up next week.”

I hope you say “Great! We’re ready!”