How to manage one to ones

Dear new developer,

Hopefully you’ll work in a place where you’ll have regular one to ones with your manager. I find these helpful for building a relationship and engaging with your manager and your reports (if any). I even did them with my co-founder when I founded a startup.

These meetings tend to be 30 minutes and on a regular cadence (weekly, biweekly or monthly, typically). If you are face to face, you can have them in the office, but going for a walk or to lunch is a great way to mix it up as well. If you are doing them over video chat due to being in different locations, it’s best to have a great internet connection, a quiet space and video turned on. There are nuances you pick up via someone’s face that you’ll miss if you only have their voice.

The purpose of these meetings is to keep communication lines open for both parties. It also helps both parties get to know each other as people. People generally react poorly to surprises and stress, but building the relationship and communication practices before any of these situations arrive (and they will) will help the team to navigate them.

It’s worth stating that as a new developer, you probably don’t have a lot of influence over many things. In fact, you might not even have a one to one. If you don’t, the first step is to ask for a regular meeting with your supervisor. You can start with a monthly 30 minute meeting, which shouldn’t be impossible to schedule. I’d frame this request in terms that are helpful for the company and your supervisor:

  • I want to understand where we are heading
  • I want to know how I can best help you and the company
  • The insights I gain will help me be more effective in helping the team

If you do have a one to one, you can use it to share knowledge and gain understanding. Here are some tips for making the most out of your one to ones as a new developer.

First, schedule (or ask for) regular meetings at a time that works for both of you. Be cognizant of each other’s schedule (does someone like to get up early or work late? Are you in the same time zone?). Scheduling these back to back can be helpful for a manager. And scheduling them outside of “in the zone” blocks of time can make sure that there’s time for other work to be done.

The fact that the meetings are regular is important. They don’t have to last the entire scheduled time, but the manager should never cancel them, and if they must be rescheduled, do that promptly. (This meeting is very important for you as a new developer, and the manager should treat it that way.) If your manager is stretched too thin or is for whatever reason not treating this like an important meeting, suggest decreasing the frequency.

Regular meetings establish the relationship. If the only time you are meeting with your manager is when there are issues, you need guidance on work to be done, or at your performance review, that relationship won’t have the time to grow.

As the employee, come to a one to one with your agenda. I use a google doc in reverse chronological order, with the current meeting at the top. If you can, share this with your manager. Over the week or weeks between your meetings, add items to this doc. This can include items such as:

  • How should I have handled situation XXX?
  • I’d like to learn more about NoSQL databases; what are the opportunities at this company?
  • I’m struggling with XXX, do you have any suggestions?
  • What are the challenges you see facing our team during project YYY?
  • I heard a rumor that we’re opening a London office; is there anything you can tell me about that?

In general, topics should be about professional challenges, discussions or opportunities. Some chitchat about what you each did over the weekend is good social lubricant, if you both feel that way. (I’ve struggled in the past with connecting to reports, but found that discussing their out of work interests can lead to good conversations and a stronger relationship.)

I like to record action items for myself and the other party right in this google doc (sometimes the action item may be as simple as “bring this up again in three months”). This means that when the next one to one comes around, I can see what we discussed last time and if there was any progress. This doc is also great for preparing for your performance review, sharing with a new supervisor, or even just to see what you’ve done or been concerned about over time.

Another thing that I’ve had to learn over the years is that one to ones are a great place for me as an employee to ask for what I want. It’s awkward for me, because I’m a people pleaser at work, but if I don’t ask for what I want or need from my supervisor, how will they know? Now that doesn’t mean you can ask for the moon, but if you see opportunities in adjacent areas to your current work, ask for them.

If you see technologies that you think would make everyone’s lives easier, ask if you can investigate them. If you see a conference or other educational opportunity, ask if there’s money for you to attend. I remember at my very first job, I was interested in learning about databases and database administration. I asked my supervisor about doing a three month internship in that group, and they let me do so. I learned a lot about the data driven mindset during that time.

What is said in a one to one should be kept private, unless sharing it is discussed and both parties agree. Keep the agenda doc between the two of you. I think this article, “The 1-on-1 Disclosure Framework”,  covers the levels of privacy very well.

Finally, it’s worth acknowledging that there’s a power differential in every one to one, based on the fact that the manager influences and/or controls the employee’s role, salary, and job. This meeting isn’t about being buddies or friends, but rather about building the person to person relationship that will allow both parties to thrive and help the company with its goals.

Sincerely,

Dan

Three principles for guiding your development career

Dear new developer,

I thought this article nicely laid out three principles to guide a developer’s career.

They were:

  • follow your taste
  • find community
  • take risks

Each of these really resonated for me. The first because the wide world of software can lead to analysis paralysis, so you should really have some way of deciding what you want to work on. When you are starting out you don’t have too many ways of doing so. Taste is better than random choice.

I’ve already written about the benefits of finding community (online or offline) and how it can help you grow.

Risk is an area I haven’t covered much on this blog, but in my own career I have overvalued stability. If I had it all to do over again, I’d take more risks, because I fall prey to overestimating the impact of failure on my life. (Of course, that’s easy for me to say looking back.) An example of that is that I waited until I was in my 30s to really commit to a startup; I had the skills to do so earlier, when it would have been easier financially, but I was too afraid to give up the stability and money of the consulting I was doing.

Here’s an excerpt from the article about following your tastes:

The default path is to follow what’s popular or prestigious. That can lead to a bunch of problems: What’s prestigious is already highly competitive. When you compete with smart people in a game that has established rules, just keeping up will take most of your time. That leaves little time to explore what interests you. When you don’t explore what interests you, you won’t understand things as deeply, and that leaves you with an undifferentiated skillset.

The whole thing is worth reading.

Sincerely,

Dan

On mid-career challenges

Dear new developer,

I really liked this post on mid-career challenges. I know you’re new, but you’ll be mid-career before you know it!

I’m in a position right now where I have to figure out what comes next for me and how to navigate the challenges of getting there. I made it to senior engineer, I wrote a book, I spoke at a bunch of conferences, switched from ops to dev back to ops again — so now what? For some people, mid-career looks like figuring out what your next set of career goals might be, what you might want your next 10 years of work to look like. For others, it might mean changing careers — you might be in a position where you’re quite senior in terms of core skills such as communication, team dynamics, and project planning, but you came into tech from another field so your coding skills still have leveling up to do.

As you get your legs under you as a developer, it’s worth peering into the future so you can set yourself up for success. Setting goals is part of that. So is learning from other’s experiences.

As usual, the whole post is worth a read.

Sincerely,

Dan

Manage your career

Dear new developer,

You have to manage your career. If you don’t, no one else will.

This means three things.

  1. Know what you want.
  2. Communicate that.
  3. Make moves toward it.

Let’s talk about each of these in turn.

“Know what you want” is the hardest part. Because we are lucky to live in a world with lots and lots of options and opportunities. You can focus on one of a 100 different kinds of software development. And that is to say nothing about other related opportunities (product management, teaching, engineering management, etc) where your developer skillset will help set you apart.

My advice here is that you should pick one and follow it while it is interesting. If you have fundamental skills (problem solving, learning, listening, typing), you’ll be able to transition between areas. It may not be an easy transition and you may pay a price in terms of compensation or status or ego. You may have to spend precious time outside of work getting up to speed. But no decision is permanent. So pick what is interesting. Commit to it for a period of time (six months, a year). Realize that you can change (though, as mentioned above, that may have a cost), so commit.

“Communicate that” because if you don’t talk about what you want, you will have a hard time getting it. This is because people generally want to help, but need to know how to help. So, communicate your desires to your manager, to your communities, to your friends, to your co-workers. You don’t need to mention it every day, and you should tune your communication to your audience.

For example, if you are a web developer and want to be database focused, then volunteer to work on database projects. Mention it to your manager at your 1:1s. If there are people that are doing database work at your company, ask if you can meet them regularly.

This doesn’t mean you can avoid the web development work for which you are paid. What it means is that you can tune your work environment toward your interests. Not immediately and not at all companies, but often.

“Make moves toward it” means you aren’t just talking about your desired direction, but you are actually taking steps toward acquiring skills and doing that work. To expand ont the web developer -> databases example, take action. Present on databases at a meetup. Do a brown bag on databases at your company. Read a book about databases. See what you can apply to your current work.

However, sometimes you can’t make a move internally. Maybe the opportunity just isn’t there. Maybe the company needs you in your current spot. You may have to switch jobs. That’s OK.

Don’t burn any bridges, but when it is time to move on, move on. Find a new job with your new skills and knowledge, hopefully from the community you’ve found. Give notice and head off to a new adventure. (Don’t forget to connect to colleagues on LinkedIn.)

What’s the alternative? Floating through your career, buffeted from opportunity to opportunity, or worse, from job you’re afraid to lose to another job you’re afraid to lose.

That doesn’t sound like much fun.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

No choice is permanent

Dear new developer,

Sometimes when you are thinking about a new job or shifting to a new position in a company, it can feel overwhelming. What if I make the wrong choice? At least, I’ve often felt that way.

Every choice you make has effects. When you choose to study ruby, you can’t also study python (opportunity cost!). When you work at a company, you will learn how that company works, but not about how other companies work.

I sometimes have FOMO (fear of missing out) when I commit to one path. “What would have happened if I had gone down another path?” I wonder.

That’s OK. I think it’s human. But you still have to make a choice.

I remember talking to a friend once about making decisions. She said that she likes to make a decision as late as possible. I think this is a good practice. Gather the data you need and can get without asymetric effort (that is, the larger the issue is, the more effort you should put in–I should invest more effort into learning about joining a new company than I should into learning a new project within the same company, for example). Make the decision as late as you can, because you’ll learn more as time goes on.

However.

It’s also important to realize that few decisions are permanent, especially as a new developer in your career. You’ll have flexibility in terms of geography, type of company, type of job, size of company, business domain. Some shifts may be easier because of your history and the aforementioned effects (shifting from being a web developer to being a backend engineer), some may be harder (changing from a web developer into an embedded systems engineer), some may be well nigh impossible (changing from a web developer into a compiler developer), but some change will be available to you.

What this means to me is that decisions which seem crucial, critical, life-changing, are, but that if you make an incorrect decision you can change. And that, for me, takes some of the pressure off.

Sincerely,

Dan

PS, as Kendall pointed out, there are some decisions that are essentially permanent. But most career decisions aren’t.

Types of companies that use software

Dear new developer,

In my experience, three types of companies use software. Software is as prevalent as accounting, so every company uses it in some way.

  • Those that sell software to help build software, software product companies. Examples from my career: Oracle.
  • Those that sell software, often called product companies. Examples from my career: The Food Corridor, Katasi.
  • Those that sell hours or knowledge of developers and other software professionals (PMs, designers, etc). Examples from my career: XOR, Culture Foundry.
  • Those that sell anything else and use software to help. Basically almost every other business. Examples from my career: 8z, Phoenix Enterprises.

As a new software developer consider where to seek employment, they each have strengths and weaknesses. It’s worth talking about these so you can find a company that aligns with where you want to go (remember, every place has its warts).

Software product companies

Pluses:

  • You are the end user, so having user empathy is easy.
  • Software developers are highly valued within the organization.
  • Lots of focus on building out higher leverage software processes.
  • When successful, these companies have great gross margins and can afford good pay and benefits.

Minuses:

  • Developers often start companies like this, so there’s a lot of competition.
  • Jobs are desirable, so may have a long interview process with a lot of hoops.

Product companies

Pluses:

  • You can go deep into a particular business domain.
  • Software developers are key components of such a company’s success, and are treated like it.
  • They often have recurring revenue and a business model that allows for good pay and benefits.

Minuses:

  • Can be harder to get hired than in other types of companies because jobs are more desirable.
  • May be boring to be in same domain for long periods of time.
  • May use older technology depending on the age of the company. Legacy systems make money!

Consulting

  • You often skim domains, so you can get some variety of experience in different types of businesses.
  • Always new projects to be on, often means new technology to evaluate and learn.
  • An hour worked is often an hour billed, so your efforts are directly related to revenue.
  • If you are looking to go off on your own, these consulting businesses are easy to start (no overhead, no investment in building a product, you just need a laptop and an internet connection and someone willing to hire you).

Minuses:

  • As an employee, you need to realize that there is no real exit strategy for the founder(s). Which is fine as long as the founder is still interested in running the business.
  • There is limited recurring revenue, which means that the business goes through cycles of grow -> shrink -> grow -> shrink.
  • Lots of lots of effort in finding new projects and clients.
  • Because of the sales cycle, it is hard to specialize as a consulting company, sometimes you take projects because you have to pay bills.
  • Can have tight deadlines and lower profitability, which affects your experience as a developer.

The rest

Pluses:

  • Often have stable businesses.
  • Software quality and process tends to lower in non software focused companies, making it easier to outperform competition.
  • Software quality could be competitive advantage.
  • You’ll have the chance to learn about and work in a non software business domain.

Minuses

  • Developers won’t be as highly valued at some other types of companies.
  • IT/software can be seen as an expense rather than a revenue generator, especially if not affiliated with revenue side of the business.
  • Sometimes you may be alone or in the company of expert beginners.

Each of these types of companies has different strengths and can be a good fit for you early in your career. Consider what excites you and what is available in your job market when you make the choice. It’s also worth reminding yourself that since as a new developer you’re judged on potential, any choice you make to go into one type of company or another isn’t permanent!

Sincerely,

Dan