David Tate

Mastering the Art (and Science) of Remote Work

Category: hiring

A New Definition of Work Ethic

When I was in college I was proud of how hard I worked.

I started at 6 AM just as the coffeeshop opened, spending most of the day studying, then attending class before working a part-time job until late at night. People told me I had a great “work ethic” when I got into the workforce, which I took as a compliment. In hindsight, what they meant was “that new person is here a lot and looks busy as hell”. In school when I was told I had a good work ethic it simply meant that I studied for long hours in the library and took a long time making my papers just so.

Now I am a professional “knowledge worker” in software development, a field in which you can work hard for 10 hours and then figure out a better solution ten minutes after waking up from a nap. Working as a manager is similar: not doing something smart now can cause months of work later. The rules have changed: how I work matters more now than how much I work. What matters is getting the right answers, not the total of questions answered.

Working long hours is not always a bad sign, earlier in your career it can be a great boost to spend extra time learning and building professional experiences. And when you are starting something you have to work harder to build momentum.

But I don’t want to work with people that will burn themselves out or paint themselves into corner after corner by just grinding away without changing tactics. Not everybody feels this way. I used to work with someone who asked this question near the end of every job interview:

If you were asked to estimate some work and you concluded that it would take between a week and two weeks, and were then told it needed to be done three days from now or the world would end, what would you do?

The first time I heard it I remember thinking that it probably created the impression that they were interviewing at a company that required long hours. The tone of the question, to me, sounded like “how many punches to the face can you take?”. But once I started hearing the answers I realized that you can learn a lot by how people respond to this question. It is an unexpected maturity reading.

I’ve heard the standard not great answers:

I would brew some coffee and just work until it was done. I once worked for 26 hours in a row.

I would get it done no matter what or who stood in my way, including you.

No matter what, I would get the job done – you can count on me.

I would bring my sleeping bag to work, it is always in my car for this reason.

Here are some better answers:

I would ask what was three days away – what is the driver of the deadline?

I would see if we could hire people – my brother in law might be able to help, he is a good man.

I would ask why I was asked to estimate the work if there was a hard deadline that had to be met.

I would sit down with the requestor and brainstorm ideas for how to speed up the effort by cutting out inessential work.

I would sit down with the customer and make sure I understood the problem they were trying to solve – maybe I had estimated a solution to the wrong problem.

I’d let them get away with that once, and then avoid that manager if possible, especially late in the week.

I’d probably ragequit.

If we couldn’t solve it, and it was a real do-or-die situation, I would try my best to get it done within reason, and then in the post-mortem discuss how we got into this situation. If the pattern continued I’d keep pushing for the team to improve, but if I found it was just a cultural issue in which every deadline had extra false pressure I’d have to reassess whether this company was the best place for me.

My version of this question is basically: Do you default to thinking first then working or working first then thinking? Do you understand the downsides of just working a lot of hours under pressure?

When I hear the term work ethic now it means something completely different:

  • When they show up to work, they will show up as a professional ready to work:
    • Well fed
    • Caught up on sleep
    • Excited about their work
  • They will take the right amount of time to figure out what needs to be done; they will ask a lot of questions to understand the proper context where the work exists so they can make smart micro-decisions.
  • Once their path is agreed upon, they will work quickly and efficiently to complete the work, communicating clearly and honestly along the way about how it is progressing
  • After the work is done, they will seek feedback and provide honest and tough feedback on the process itself with the aim of making everything easier the next time.

Work ethic is much more results-focused in my mind now, and means working smart and not just working hard. It speaks to long-term efficiency and effectiveness and not to anything else like how-much-you-want-it and how-much-you-will-give-up. You care enough about the work to give some of your best energy to it, want to get better at it, care about waste during it, work hard when required, and think-then-work smart by default.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Bring Your Own Team

Now here is an interesting idea: front-loading an aquihire by hiring a functioning team rather that a single person. As many of us know developers travel in packs anyway (I have worked with many former colleagues at new places) so bringing on a pre-existing team is an interesting idea.

Some immediate thoughts:

  • Developers might travel in packs, but it is usually over time and not all at once.  If you imagine an entire team leaving a company this seems very disruptive; the entire idea makes more sense for people that have shifted to consulting but tend to still work with a core group.
  • Navigating the waters of interviewing people individually vs. as a group: do you do traditional “tell me about your resume” interviews (ugh) or have them do a pilot project as a team?
  • What do you do when you like half of the team? Once it is time to make the hire / no-hire you might find that one person doesn’t fit your expectations but is crucial to the overall team’s output.
  • On that subject the post mentions engineering being the main focus, but what non-code-writing roles will they end up hiring for?  Would the person to lead the team be a pre-existing Stripe team member?
  • Hiring an entire team means you could need work carved out for them already (this is hard apart from greenfield projects)
  • Maintaining your culture would be harder as they would have a stronger pull towards whatever team culture they have already built.

Interesting idea; and some interesting feedback on the Hacker New comments.

Lessons on Hiring and Networking

I have been working as a software developer for over a decade to the point in my career where I know hundreds of people that are in my same line of work and can thus give (and receive) meaningful help for people in their career as they try to find full-time or contract jobs. In addition, many of my peers are in the position to hire people at the companies they work for (or in some cases at their companies).

Reaching this point has made me reflect on how I should have been networking with people that I’ve come across all along; how we should all treat each other.

Here comes some bulleted unsolicited advice about hiring. Everyone you work with, please remember the following:

Accept and Expect Growth

The ecosystem in which you operate matters. A great deal. People can be ineffective in one role or company but succeed at another. Don’t judge people based on one job (or even worse one project) at one place. In addition, people change over time – not just technical skills but soft skills as well. Claiming that somebody you worked with four years ago “isn’t good with customers” isn’t valid unless you saw them hit one yesterday with an umbrella (for no reason). If you don’t pay attention to the fact that people grow, then you will discount people that grow a lot, and these are the people you most want to hire.

Don’t Assume Local Reputation is Accurate

At times, you’ll see someone, and this applies more with those in manager roles, that does something that you don’t understand – they fire someone, they stop a project, they are on board with a change that seems destructive, etc. When you are a manager you know more information about what is going on across the company; some of these priorities and realities are quite different from what the average worker sees. Remember that you might not have all the information. Saying that a manager was a jerk because they fired Bill four years ago might not be valid. Bill might have hit people with umbrellas (or hit on people). Find out for yourself if possible, and don’t make a judgement if you can’t find out.

Gossip is (most of the time) about the person communicating it, and not the person being communicated about. Said another way, don’t let other people’s impressions of someone affect your judgement of them – see for yourself how good they are.

Don’t be a Jerk

If you have trouble not being a jerk in general then try this thought exercise: Imagine that every single person you work with will be in a position later to hire or not hire you at your dream job. Try to be professional, polite, and helpful.

Specific Case: Workers that are Different than you

There are two instances of being a jerk I’d like to call out: being a jerk to older workers and being a jerk to women. Unfortunately for our industry, which is full of WDWG (white dudes with glasses), these both fall under “people different than you” for most hiring managers.

Our industry thrives on the language of the now. We talk shop in very specific ways and isolate and eliminate those that don’t seem up to speed with what can help us in our current project. Older experienced developers (whether they have stayed technical or moved into management) use slightly different terms for the same thoughts: they might refer to server-side code as running on mainframes or call what we call ‘pages’ in a web context ‘screens’. They might mention things to avoid more often than younger workers and thus come off as negative. Do not let these slight differences make you not listen to them; they are full of good information.

Our industry seems like it innovates all the time, but the core problems – the really hard ones -remain and have been fought for years. How do you figure out what system to build? How do you write it down so that others can understand? How do you build and test software on large teams so that everything works together? How can you make maintaining the software as easy as possible after everyone leaves? These aren’t new problems and they are the sort of problems with which older workers have decades of experience.

There aren’t a large number of women that are software developers and many men in our industry really don’t know what to do when they come into contact with them at work. Male developers, even those that try hard not to be sexist, tend to assume that women are either less effective or are super-geniuses since they have had to face “hardship” being in the minority. Try to do neither and focus on merit; see for yourself.

Keep in mind one knee-jerk reaction that I’ve seen many males have (and have had myself) – to assume that someone who is better at all the soft skills that surround development { requirements, testing, documentation, team activities } is, therefore, less effective technically. There has been extensive research that women on technical teams are as effective and help build teams by increasing communication while at the same being just as effective on the coding side – do not discount their power.  Just because someone shows up on your team and can speak in complete sentences doesn’t mean that she can’t write code.

Be Aware of Why You Like Working With Someone

As you work with someone see how much you

a) like working with them
b) what their quality of work is like

You can be friends with someone and they can also be good at their job, but be aware that a) affects your judgement of b). Try not to let the short-term employment situation affect your judgement of longer-term skills like attitude and morality.

Handle Recommendations Carefully

This last point leads to the most common failure of the recommendation system by which many developers are found.  Everyone you enjoy working with is in a grey area between you just liking working with them and them being able to get a lot done and therefore not cause you stress.

When recommending someone communicate where this person is on your friend-trust scale. Recommending your cousin because he has good jokes at family reunions and works in your field is very different than recommending someone that you don’t like but respect for how effective he is. I’m not saying you shouldn’t try to help out people close to you socially, I’m just saying that to the employer these are very different situations and that you should be honest about which one is happening.

Practice Networking in its Pure Form

As much as possible try to share what you know with people that ask for help and are trying. Networking is not about doing favors with the expectation of getting one later. If you know something, share it. If you want to know something, ask for help. Networking isn’t about getting jobs; it is about having a crew of pleasant competent people that are on a logical greater team (outside of individual positions) with you throughout your career helping each other become better.

Make a List

Maintain a list of people that are a joy to work with. Maintain a list of people that you would hire to do a job in which all of your personal life savings is invested. For the love of all things keep in constant contact with anyone that is on both lists.

 

Powered by WordPress & Theme by Anders Norén