Own your calendar

Every six months, I take a day to review and reflect on how things have been going and the changes that I want to make moving forward. This day is my personal strategy offsite.

As part of the process, I think about the things I want to do more of and the things I want to do less of, and how much time I should allocate each week towards my professional goals. I then create a sample of what a perfect day would look like and a mockup of what an ideal week would look like apportioning my time in alignment with my goals.

With my review and planning done, I go to my work calendar and clean it up to make it look like my ideal week. I delete or stop attending meetings that are not useful. I block out time for focused work on my goals. Then, to give some flexibility for the things that arise, I make sure that I leave some gaps or mark some of my project-work time as “free,” allowing others to schedule it if needed.

Each week has unique challenges: unforeseen work appears, or a critical customer meeting dominates, a work emergency takes over my calendar.

At the end of the week, I look back at the calendar and figure out how much of my time spent maps to my planned time allocation.

Often, I find that new things are creeping in if I am not attentive. As my time starts to diverge from my ideal allocation, I must decide if I change my plan based on my new reality (and possibly adjust my goals) or if I re-assert my plan and delegate or drop the new constraints on my time.

I track each week’s time allocations in a spreadsheet. It helps me understand where I am spending my time over the year. In addition, it makes it very clear if I am spending too much time on low-value work. The spreadsheet also shows if I am unrealistic about how I allocate my time in a week which is helpful for when the next six-month planning comes.

This process may seem very rigid, and in many ways, it is. However, I’ve come to it over the years through iteration after finding myself feeling very busy but not making meaningful progress towards my personal or professional goals.

As we grow in our roles, new opportunities and responsibilities appear. Our peers, team, and others want our input and time. This activity gives us the impression that we are doing necessary, valuable work. At the end of the week, though, we may look at our full calendars and wonder what we accomplished. If this situation feels familiar to you, it may be worth adding some rigor to understand how you want to spend your time and how you actually spend your time.

When, why, and how to stop coding as your day job

By letting go of writing code, you open yourself up to excelling as a manager.

I am a computer programmer.

I was one of those people who started coding at a young age – in my case, on a TRS-80 Model 1 in my school’s library. I loved the feeling of teaching the computer to do something and then getting to enjoy the results of interacting with what I built. Since I didn’t own a computer, I would fill spiral-bound notebooks with programs that I would write at home. As soon as I could get time on the computer, I would type it in line-by-line. When I learned that I could write software as a job, I couldn’t imagine anything else that I would want to do.

After university, I got my dream job writing 3D graphics code. I was a software engineer! I defined a successful day by the amount of code I wrote, the compiler issues I resolved, and the bugs I closed. There were obvious, objective metrics that I could use to measure my work. Those metrics and my job defined me.

Today, I am a Chief Technology Officer, leading software development organizations. If I am writing code on the product, it is probably a bad thing. I now have to define my success by much fuzzier metrics: building good teams, hiring and training good people, setting multi-year technical strategy and vision for the company, collaborating with other departments, and setting and managing a budget. I may have a good day or a bad day, but I have to measure my success based on quarters or years.

My achievements are now always tied to the successes of others. Getting to this point wasn’t easy, but I wouldn’t have it any other way. It was a journey that took years, and the first challenge was understanding that coding was no longer my job.

Why is it hard to stop coding as our day-to-day work?

When I speak to engineering leads or managers working to grow into more senior engineering leadership levels, the question of ‘How much do you code?’ is very often raised. We usually have a hard time imagining that we can still be useful if we don’t code for a significant part of our time. Why is that?

We’ve been traditionally bad at hiring managers in the software engineering industry

Usually, companies choose development leads because they are the best, technically, on the team. I would guess that the reasoning behind this is that it’s assumed that the best developers are the right people to supervise their peers. This practice creates the impression that managing others is a promotion for a skilled developer when, in actuality, it is a career change away from what made them successful in the first place.

The worst managers I’ve had were very talented developers who hated having to spend time doing the boring stuff that wasn’t coding. They resented the time spent away from the keyboard and weren’t always good at hiding that fact.

Many companies now feature dual career tracks for technologists, giving them a choice to advance as an individual contributor or move into management. This choice of career is an excellent thing. It means that if you want to spend your days coding, you can do that without sacrificing your career. It also means that if you desire to find joy in leading teams and growing others’ development and skills, you can do that.

We fear becoming ‘non-technical’

We joined the technology industry to be close to technology. We fear that by moving away from coding, we will morph into the classic ‘pointy-haired boss’ – ridiculed by the people on our team and unable to understand what the developers are discussing. I won’t say this can’t happen, but it won’t happen on its own. It will only happen if you choose to avoid technology once you move into the management role.

As you take on broader leadership responsibilities, you will need to learn and understand new technologies. Moving beyond the specifics of your expertise is necessary for you to move up in management. I have managed developers coding in at least a dozen languages on the backend, frontend, mobile, operating systems, and native applications. I have also managed testers, data scientists, data engineers, DevOps, Security, designers, data analysts, program managers, product managers, corporate IT teams, and some other roles I don’t even remember anymore. It isn’t possible to be an expert in all those fields. I need to take the lessons from my time as a developer and use them to inform my understanding, help me learn new areas, and give me empathy for the people who work for me.

It isn’t that you will become non-technical. It is that you will become less narrowly technical.

As a new manager, we are often expected to continue coding

It is common to move from being a developer on a team to managing that team. As the new manager, this means you are still responsible for part of the codebase. Unless you immediately start leading a large group, your new role still requires that you spend a significant portion of your time coding. This expectation makes the transition to the new role more comfortable – but it can also be an anchor that holds you back from embracing your new role as your management responsibilities grow.

We still see ourselves as a resource that can ‘save’ a deliverable

As a manager, you are accountable for the results of your team. If the group is struggling to make a deadline, it might be tempting to jump into the weeds to try and help the team finish the project on time. While this is sometimes the right decision, it can also make the problems worse because the team loses the person who looks at the more significant issues and coordinates with other teams to get more help or prepare them for the delay.

Why do we need to stop coding eventually?

We don’t need to stop coding, ever. However, once you move into engineering leadership, it will need to become a smaller and smaller part of your job if you are working to lead larger teams or broaden your responsibilities scope.

I had led teams before I was a manager at Adobe, and I had always spent a significant part of my work week contributing code as part of the groups I was in. At Adobe, though, my team had grown to be fourteen people, with another four dotted-lined to me.

I had been the primary developer for a part of the project, and I took pride that I was still contributing important features to every release. However, my management responsibilities were starting to fill my work weeks. Between 1:1s, sync meetings with other teams, and other manager work, my feature development time was increasingly moving into my evenings and weekends. My features were often the last to be merged and usually late.

The company had two mandatory shut-down weeks. To work during this time, you needed the prior approval of a Vice President. The team was preparing for a release, and my features were still in the to-do column; I met with my VP to get his permission to work over the shut-down week. He asked me, ‘Who is the worst developer on your team?’ I hemmed and hawed – I didn’t want to call out anyone on my team, and I hadn’t even really considered the question. Seeing my uncertainty, he answered for me. ‘You are! You’re always late with your features. The rest of the team is always waiting on you. If you were a developer instead of the manager, you would be on a performance improvement plan.’ He was right. My insistence on coding was hurting the team, not helping it.

Taking on the lead role doesn’t mean you should stop coding immediately, but it does mean that your coding responsibilities should now be secondary to your leadership ones. There are other developers on your team, but there aren’t other leads. If you aren’t doing your lead job, no one else will. Similarly, your professional development’s primary focus should now be on your leadership skills, not your coding skills. You are moving into a new career, and if you don’t work to get better at it, you will find yourself stuck.

As your leadership responsibilities increase, you should transition your development responsibilities to other people on the team. This transition is good practice because delegation is an essential part of leadership.

How do you stay ‘technical’ when coding isn’t your job anymore?

As I said earlier, staying technical is a choice that you need to make. Hopefully, one of the primary reasons you chose to make a career in the technology industry was that you were interested in it, so this shouldn’t be a problem.

As I also said earlier, as you develop as a technology leader, your focus broadens as your scope widens. 

The best way that I have found to remain a credible technologist for my teams is to be interested in them and their work. To do this, talk to the people on your team and take a genuine interest in the things they are working on. If a technology comes up in a meeting or 1:1 that you don’t know, add it to a list of things to research later. Then, dedicate time in your week to go through that list and learn about the technologies well enough to have your own opinions about them. This practice allows you to have further discussions with whoever mentioned the technology to you.

If you get interested in what you learn about the new technology, you may want to keep trying to understand it better; you may read more or embark on a personal project using it to gain more practical knowledge. As I said, it isn’t that you have to stop coding, it is that, eventually, it shouldn’t be your day job anymore.

By taking an interest in the technologies your team uses in their work, you deepen your empathy for them and expand your own knowledge. You’ll be able to discuss the work, ask reasonable questions, and make connections to other things happening in the organization and your own experience. This way, the people on your team know that while you may not be able to step in for them, you understand their work and care about it.

Success is defined differently when you lead people

The feeling of accomplishment that comes from completing a cool user story, deploying a new service, or fixing a difficult bug is significant. It is a dopamine hit, and just like other dopamine-inducing behaviors, it can be hard to stop.

Having a great 1:1 or leading a productive team meeting can also feel good but in a more esoteric way. As a team leader, you need to learn to perceive the success of making others successful. Success takes longer, but the feeling is more profound and more rewarding.

Having a release resonate with your customers, being able to easily justify the promotion of a developer that you have mentored, and having someone accept a job offer for your team, are all fantastic feelings. In the day-to-day, watching stories get completed, helping resolve the issues when they aren’t, and seeing people get excited about the direction you’re setting for the team can leave you feeling satisfied at the end of the day.

Being a technical leader doesn’t mean writing code every day

As you grow in your new leadership career, you will need to devote your time to mentoring, developing, and leading your team. As you spend less time in your code editor, you will find new challenges in strategy, clearing roadblocks, fixing broken processes, and new tools like HR information systems, slides, and spreadsheets (it isn’t as bad as it sounds). You will spend less time learning all the intricacies of a specific language or toolchain and instead learn about how systems interact, understand when to build vs. buy, and learn about entirely new areas of technology. And you can still code, but make sure that you aren’t the developer holding your team back.

[This was originally posted at https://leaddev.com/skills-new-managers/when-why-and-how-stop-coding-your-day-job]

Presenting Remotely

While I am an experienced video-conferencer and a reasonably experienced presenter, presenting to a remote audience is still something I am learning how to do. Having just given a talk this morning, I did want to share some things that are working well for me at the moment.

The Tools

Today I presented from my Mac Mini, and so used a separate webcam. The important thing here is that it was placed above my eye-line and not below. This is a lot more flattering of a view (i.e., not up your nose). If you are presenting from your laptop, raise it so that you get a similar angle.

I only have a single screen, so in presentation mode, I would lose my presenter view. Personally, I heavily rely on the presenter’s view. So I used my iPad with Duet to have a second screen. I use keynote primarily. I’ve noticed that Google Slides doesn’t work well with this setup.

You see my headset mic. Obviously, for a presentation to a group, you want the highest quality audio, an inexpensive headset mic works well. I prefer this over the iPhone style headphones (corded or cordless). The sound is better. If you use a wireless mic, make sure it is fully charged before you begin. At some point, I may switch to a podcaster desk mic, as the headset isn’t that flattering.

What is missing here is a good light. I have a big window to my left and a smaller one in front of me, so I get some natural light. However, most of my lighting does come from ceiling lights, which is not the most flattering on video. I ordered a you-tuber-style ring-light, but it is taking a very long time to arrive. I’ll need to find the optimal place for that light so that it isn’t casting weird shadows on my face.

Presentation Style

If you see me speak in person, you will know that I have a tendency to walk around on the stage and use my hands.

When presenting from a desk, I “bring in” my movements a bit so that they don’t go beyond the video frame. I watch myself out of the corner of my eye to know the edges as I am talking.

I have sometimes used a standing desk configuration to be a bit more natural. Still, given the constraints of standing in one place when speaking versus sitting, I think I prefer sitting.

You need to be more effusive, more visible when presenting with slides through a video conferencing system. You will be seen in a small video window in the corner, so you want to be more than a “talking head.”

The Environment

Before I talk, I will usually check what the background behind me looks like using zoom or Photobooth on the mac. That gives me an idea of what is visible behind me when I am talking. I generally try to clean up, so that there isn’t a mess for people to focus on. I will sometimes add a few small things of visual interest in the background, though. I think that is more humanizing and also gives some easter eggs for the audience.

Be careful when previewing what you think the audience will be able to see in your environment. On multiple occasions, I have cleaned up to the edges of what I saw as the video frame. Only to find that zoom had been showing me a cropped view of what everyone else could see. Quite embarrassing to watch a recording and see a pile of stuff on your floor that you didn’t realize other people could see.

Substance Over Style

In the end, everything above is about polish, not content. If you have something novel, something interesting, to say, that is the most critical thing. If you have a limited time to prepare, focus on making sure that what you present will be useful and informative to your audience. Rehearse your talk so that you feel comfortable presenting it and can smoother over any hiccups with technology or literal hiccups.

If your content is right and you are comfortable presenting it, your audience will remember it as a good talk. Then you can focus on cleaning up that pile of t-shirts in the corner of your room or make sure that you don’t look like a vampire because of the lighting.

If you are upping your remote presentation game, I’d love to hear your tips in the comments.

The Personal Strategy Off-site

If your company is starting to plan for getting back into your office, now is a good time for you to schedule a personal strategy day.

The Whirlwind

In the whirlwind of the day-to-day work, it is often hard to carve out time for something that does not have a specific deliverable. Working from home can be even more challenging because of the additional pressures of helping your family. In the tech lead training program I am doing at Onfido, we are currently discussing how to be more strategic leaders. A familiar dictum of strategic thinking is the criticality of taking the time to think and plan.

The Personal Strategy Day

Liminal spaces are the transitionary spaces between things. In the liminal space between moving from working at home to being back fully in the office environment, you have an opportunity to try something new—a personal strategy day.

Block out a day in your calendar as people start moving back to the office. There will be some turbulence then as everyone is transitioning. It is the perfect time to start thinking about what you want to accomplish for yourself and your team before the whirlwind starts up again.

The Personal Off-site

Companies schedule off-sites to get away from the distractions of the office. If you can find a “third place” (a place that is not your office or your home) where you can focus, that is ideal. If not, book a secluded conference room in your office, or find an empty desk far from where you usually sit. If you are still at home, let your family know you are working, and need some blocks of focused time.

Focus

Don’t read your e-mail. Don’t take any meetings. Your job on that day is to think and plan. To help me focus, I will usually print out whatever supporting materials I think I need and work on paper to avoid the lure of the notifications and other electronic distractions. Think of this as a gift of time and focus that you are giving yourself.

What to consider

Think of the time before the lockdowns began. You may have just been starting on your 2020 commitments and deliverables. What was going well then? What were your concerns? Now think through what you have learned about your team, the work, and yourself during the lockdown. What do you want to keep, and what do you want to discard as you go back to the office? What about the industry you are in, and the world at large has changed? What new pitfalls and opportunities are there? Now think ahead to the rest of the year. What new goals should you have for yourself and your team?

Take notes. Write things down. You will want to refer to them as you go through the year to revisit or remind yourself of your thinking.

Now make a plan. Not too detailed because the world is going to keep changing. Detailed enough that you feel as if you have something against which to execute. Write that down also. With milestones, if possible.

Finally, think about the process you just completed. Did it work for you? Would you do it again? If so, what would you change next time?

Retrospect and Revisit

This whole process may take anywhere from a couple of hours for you to an entire day. Don’t be too preoccupied with the length of time you spend. You are starting to build a practice of taking time for strategic thinking, so this is about taking more time than you have before.

If you found this valuable, you may want to plan your next strategy day for six or twelve months from now. Again, block it out in the calendar early and protect that time!

You may also find that it is good to schedule smaller blocks of time, weekly or monthly, to revisit your plan, track progress, and make adjustments. These blocks of time are strategic thinking too!

Conclusion

If you struggle to keep time for strategy, building a structured approach like a personal strategy day may help you create a practice. Using the liminal times like transitioning from lockdown back to whatever it is that comes after is an opportunity to block and protect time. The liminal times are also crucial for strategy because your past assumptions are likely no longer correct, and there may be some opportunities or challenges that weren’t visible before.

Some resources

I’ve spent the last several years building a structured personal strategy process for myself. Many people have inspired my practice. Their suggestions may inspire you as well.