Crafting a resume as a technology leader is about more than listing roles—it’s about showcasing achievements, leadership, and strategic impact. Learn how to tailor your resume, highlight cross-disciplinary management, and leverage tools like LinkedIn and personal websites to stand out for executive roles.
A common discussion with people I mentor is how to properly structure a resume or Curriculum Vitae. It comes up often enough that I felt compelled to write about it last year: “Sweat the details on your resume, especially if you are a developer or technology leader.” In the last few weeks, I have reviewed multiple resumes from folks hoping to achieve a director-level or above role. I wanted to share some lessons on how an executive-level resume differs from others in Technology.
As a technology executive, your resume is your calling card—a teaser trailer for your professional achievements. Crafting a resume that highlights your leadership journey while demonstrating value is an art form, particularly as you aim for senior roles like VP, CTO, or similar. Here are key takeaways and strategies to ensure your resume stands out.
Tailor Your Resume for the Role
Your resume isn’t a one-size-fits-all document. Different audiences—recruiters, hiring managers, or automated systems—expect varying levels of detail. To make a strong impression:
Create multiple versions of your resume:
Short-form (2 pages or less): Use this for recruiters or direct submissions. Focus on succinct highlights that convey your biggest achievements and relevant experience.
Comprehensive (full-length): Maintain this detailed record for Applicant Tracking Systems (ATS) or contexts where exhaustive experience matters, such as certain consulting or academic roles.
Use strategic brevity: Each version should prioritize accomplishments and impact over exhaustive lists of tasks or skills. At the bottom of the short-form resume, include a URL to your full-length resume, LinkedIn profile, or personal website for those who want more detail.
Tailor content to the role: If applying to a startup, focus on entrepreneurial accomplishments. For a multinational corporation, emphasize experience working with large teams or global operations.
Focus on Achievements, Not Responsibilities
Leadership resumes should emphasize measurable outcomes rather than generic responsibilities. This allows you to demonstrate value and differentiate yourself from other candidates. Consider these approaches:
Use metrics whenever possible: Quantify your achievements to provide concrete proof of your impact. For example:
Replace “Managed a team of data scientists” with “Grew a data science team from 5 to 20 members, delivering a 10x cost efficiency improvement in critical business processes.”
Instead of “Improved system performance,” say, “Increased platform uptime from 97% to 99.9% while reducing hosting costs by $500,000 annually.”
Highlight transformative initiatives: If you drove major changes—like adopting a new technology stack or transitioning a team to a new operating model—emphasize these innovations and their outcomes.
Demonstrate multi-disciplinary management: Showcase examples where you’ve managed diverse teams or disciplines, such as engineering, product, and design. For example, “Led cross-functional teams spanning software development, UX design, and data analytics to deliver a platform used by over 10 million users.”
Put Your Most Recent Role First
Your current or most recent position carries the most weight. It’s likely the first thing a recruiter or hiring manager will read, so ensure it captures attention:
Make it prominent: Place this role on the first page and dedicate the most space to it.
Emphasize scope and results: Clearly articulate the scale of your responsibilities, such as budget size, team size, and direct impact on the company.
Focus on strategic leadership: Highlight initiatives you spearheaded and the outcomes they achieved, particularly those demonstrating thought leadership, cross-functional collaboration, or innovation.
Save earlier roles for subsequent pages, reducing detail as you go further back in time. Roles older than 10 years may only need a line or two unless they’re particularly relevant.
Position Skills Strategically
Technical skills are critical, but how you present them matters:
Avoid generic lists: Instead of placing a large block of skills at the top, embed them within descriptions of your achievements. For example:
“Led migration to AWS Cloud, saving $1.2M annually and achieving 99.9% uptime.”
Highlight relevant expertise: Tailor the skills you emphasize to the role you’re applying for. If you’re aiming for a director role in AI, showcase experiences involving ML frameworks and tools like TensorFlow or PyTorch.
Subtly include soft skills: While technical skills are important, leadership roles often require strong interpersonal and strategic abilities. Show how you led teams, resolved conflicts, or drove cross-departmental alignment.
Summarize Career Progression
Rapid promotions and career growth can be a powerful selling point, but they need to be presented succinctly:
Highlight trajectory: For example, “Promoted from Senior Machine Learning Engineer to Head of AI within three years.”
Simplify titles: If your roles had incremental changes, summarize them into a cohesive narrative. For example: “Advanced from Senior Engineer to Director of Engineering over six years, culminating in leading a 50-person team and delivering $20M in annual revenue growth.”
Emphasize leadership: Show how your roles evolved to include greater responsibility, larger teams, or more strategic initiatives.
Cut the Fluff
Hiring managers and recruiters skim resumes. Get to the point by removing irrelevant or overly detailed information. This will make your resume more focused and efficient, ensuring that only the most important details are highlighted.
Avoid generic claims: Statements like “Proven leader” or “Results-oriented professional” don’t add value. Instead, provide examples that demonstrate these qualities.
Skip common experiences: Transitioning to remote work during COVID-19 isn’t unique. Focus on outcomes that set you apart.
Reduce early-career details: Unless highly relevant, roles from over 10 years ago should only include titles and dates.
Use LinkedIn and a Personal Website for Depth
Your LinkedIn profile and personal website can complement your resumé by providing additional details and ensuring you’re findable by recruiters:
LinkedIn:
Include all positions and significant accomplishments.
Add media or links to showcase notable projects, talks, or publications.
Use keywords strategically to improve searchability for specific roles.
Personal website:
A personal website can be a dynamic portfolio, host your detailed resume, and provide links to your projects, publications, or conference talks.
Organize your website by sections, such as Leadership Roles, Key Achievements, and Speaking Engagements, to make it easy for recruiters to navigate.
Use your website to expand on areas that wouldn’t fit in a resume or LinkedIn profile, like detailed case studies or thought leadership pieces.
Think Like a Hiring Manager
Your resume should:
Reflect strategic thinking: Tailor information to the audience and highlight your ability to align your work with organizational goals. This approach will make your resume more strategic and thoughtful, resonating with the hiring manager’s perspective.
Demonstrate leadership: Showcase your leadership skills by using examples of team management, cross-functional collaboration, or strategic initiatives. This will make your resume more confident and assertive and reflect your leadership potential.
Inspire curiosity: Provide just enough detail to make recruiters and hiring managers want to know more about you.
Remember, the goal of your resume is to secure a conversation—not to answer every question upfront.
Advice for Aspiring Executives: Breaking Into Leadership Roles
If you’re seeking your first executive-level (Director or above) role, your resume needs to convey readiness and potential:
Reframe your achievements: Highlight instances where you took on responsibilities beyond your official role, such as:
Leading cross-functional initiatives.
Mentoring junior staff or peers.
Driving strategy or innovation.
Show leadership impact: Even if your title doesn’t reflect it, focus on achievements that demonstrate leadership qualities, such as:
“Initiated and led a company-wide migration to DevOps practices, reducing deployment time by 80%.”
“Mentored three engineers who were later promoted to senior positions.”
Emphasize thought leadership: Include speaking engagements, publications, or significant contributions to open-source projects to showcase your influence in the field.
Network strategically: Your resume is only part of the equation. Attend industry events, contribute to discussions on platforms like LinkedIn, and seek mentorship from executives who can provide guidance and referrals.
Communicate readiness in your summary: Begin your resume with a compelling summary that positions you as an emerging leader. For example:
“Engineering Manager with a proven track record of driving strategic initiatives and leading high-performing teams, seeking a Director role to deliver innovative solutions at scale.”
Breaking into executive roles requires showcasing your potential and articulating how your experience aligns with leadership expectations. By tailoring your resume and approach, you can make the leap into senior management.
By taking a strategic, minimalist approach to your resume, you’ll showcase your accomplishments and demonstrate your ability to communicate effectively—a critical skill for any technology leader.
At least once a month, someone in a 1:1 or a mentoring session will ask me why I write these articles or give talks at conferences and want to know how they could get started themselves.
It can be daunting if you’ve never published something with your name attached or spoken in front of a group of your peers. The most common fear I hear is that people are afraid that they “have nothing to say” or relatively nothing to say that is new.
I give everyone the same advice.
You are the only person in the world that has your experiences. If you tell your story, no one will have heard it before.
A talk on Typescript would be interesting to more people than you might think, but a talk on your experience using Typescript for the first time and the things you learned as part of that experience will be interesting to nearly everyone, even if they aren’t interested in Typescript itself. Every software developer has had the experience of using a new language on a project. Experienced Typescript developers are interested in the problems people new to the language face. People interested in learning Typescript will be interested in your experience. You have something to say that people will want to hear!
If you are worried about writing about something for fear that you will say something wrong and be called out for it, no one can correct you about your own experiences. If you want to give a talk but are worried that someone in the audience will contradict you, it’s important to remember that by being the person standing on the stage giving the talk, people will assume that you know what you are talking about.
While putting yourself out into the world can be scary, reminding yourself of the above may help you overcome that fear. Remembering that you can build up your experience in many small ways is also key. Very few people have their first public speaking experience in front of hundreds of people or have their first blog post go viral (for the wrong reasons).
Why do I write and talk?
Every person will have their reasons for wanting to share their knowledge publicly. I have several reasons why I choose to.
To share knowledge
Over the decades, I’ve gained a lot of hard-won knowledge and learned a lot from others who have been generous with their wisdom. I try to share what I’ve learned with my teams and the people I mentor, but widely sharing knowledge takes a long time. Posting and giving talks is a faster way of sharing the lessons I’ve learned.
To save time
In my mentoring, I often find myself repeating the same advice over and over. That will frequently prompt the subject of a new blog post or talk (such as this one). As a benefit of posting it somewhere, I can refer someone to it for more information. It helps me save some time in a conversation. If a person has already read the post or seen the talk, we can focus on the specifics of their issue and get deeper faster.
To understand something better by explaining it to others
Writing a post or talk also allows me to crystallize my thoughts on a subject. So often, we come to a way of doing things over time and don’t consider why we do things that way or how we came to our approach. Writing out how I approach a subject helps me understand myself and why I do things. My decisions became much more deliberate once I started blogging and talking.
Employer Branding
As a leader of an organization, I’m responsible for hiring well. One of the best shortcuts for hiring is for candidates to know how your organization functions. That helps to select candidates who are interested in your way of working and select out those who would be happier elsewhere. The Netflix Culture Deck is a famous version of this. Informing candidates about your company is employer branding. How do you tell them? Blog posts and talks are great ways to do this.
To Meet People
I’m an introvert, and meeting new people is something I need to force myself to do. When I attended conferences, I would hang out with people I already knew or sit by myself. Being a speaker makes things much easier for someone like me. People will approach me because they’ve seen my talk and have questions or comments. Now that I’ve been speaking for years, people approach me before I talk because they saw me speak at a prior conference. It makes things much less awkward for a person like me.
To Find Customers and Learn from Them
We build software for people. Speaking about our product or product development can be helpful information for potential customers. When researching a software product for my company, I often look at the tech talks or technical blog posts from the company’s technology team. I want to know how open they are about their issues, the kind of stack they use, and whom in the company I may want to reach out to if we have questions or a problem (and not have to go through the sales team).
Personal Branding
While many people think this is why most people blog or speak to promote themselves (carrying with it a sense of icky egomania), for most of my friends who are frequent writers or speakers, this is usually the least important reason or not a reason at all. There certainly is a benefit to having your name attached to a well-known talk or often-shared blog post. I’ve been approached for new jobs because people have read something I wrote or seen a presentation that I gave, but this happens far less often than you might think. If your primary reason for writing or speaking is to get “famous,” there are better ways to do that.
How you can get started
Just do it
“All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer.” ? Ira Glass
The best way to do it is to do it. Create a blog. Give a talk to your team. It probably won’t be very good. When you are getting started, you aren’t perfect. It’s a skill like any other. You must develop it; the only way is to do the work. I’m an ok writer. My taste still exceeds my ability, but I write much better today than when I started blogging. My early posts are embarrassing to me now, but I’m glad I wrote them. Otherwise, I wouldn’t have improved at all. I’m thrilled that my earliest talks aren’t on YouTube. They were cringy. Through practice and repetition, I’m a much better speaker now and can give an opening keynote to 5000 people without having a panic attack.
Pedestrian: “How do I get to Carnegie Hall?” Street Musician: “Practice, Practice, Practice”
Start Small
It’s easy to create a blog. Plenty of free platforms exist to do just that. Create an account and go! Give yourself a goal, such as one blog post monthly if you don’t enjoy writing. One blog post per week if you are ambitious. The trick is to make it a habit. Writing isn’t something I do naturally; I must make myself do it. My posting is extremely infrequent when I don’t have a blogging goal.
You can propose talks to every conference in the world from the day you decide that you’d like to become a speaker. Still, getting started with presentations in your own company or at a local meetup is probably better to build your skills and confidence. They are much easier to get into and more forgiving of inexperienced speakers. Some conferences pride themselves on giving first-time speakers opportunities and coaching. However, I would still look for any opportunities you can to practice giving talks and not count on those. While I haven’t tried it, many people have raved to me about their experiences with Toastmasters International.
Read/Watch
To be a writer, you must be a reader. Find blogs that you like and follow them. They don’t have to be about technology. Read not just for content but for style. You are trying to understand blogging, not just the subject. How do writers you like address their audience? Are they formal or personable? Do they use complicated jargon, or do they try to address wider audiences? Understanding what resonates with you in the writing of others will help you inform your style. It also helps you to understand the conventions of the medium so that you can embrace or ignore them (as you wish). Every YouTube video says some version of “hit the subscribe and like buttons,” for example.
Watch recorded talks from conferences, and find the presenters you like. How do they structure their talks? How do they organize their slides? How do they involve the audience? Similarly, what are the conventions? What things do you want to adopt or ignore? I can say that when I was trying to improve as a speaker, I would try to adapt cool things I saw other speakers do. I still do some of those things, but have found my version. Great artists steal, but eventually, you should find your version of an approach.
Build Up
As I said above, improving writing involves writing as often as possible and reading as much as possible. Improving speaking also requires repetition, but it is harder to find public speaking opportunities.
Giving talks within your company or local meetups will be easier than at national or international conferences. If you feel comfortable and want to grow your experience, expand your subject beyond technology. Find opportunities to give talks about your favorite hobbies. Try different structures, like Pecha Kucha or PowerPoint Karaoke.
You could also write talks and record them, then post them to YouTube.
Once you have some experience and gain some confidence, you can start applying to speak at conferences. Some excellent resources for CFPs are linked below (Call for Proposal/Participation/Papers). Writing talk proposals is a skill in itself, but it will also benefit from practice. If you strongly about a talk idea, try writing the proposal for it in different ways. Do your best to tailor your proposal to the conference. Reference prior year’s schedules to know the kinds of talks the organizers prefer and what successful proposals look like.
Be patient and persistent. It may take many submissions before your first conference talk is accepted.
Your talk was accepted!
Congratulations! It’s exciting and a bit scary. If the conference offers coaching or speaker preparation meetings in advance, take advantage of them! It’s an excellent resource for an inexperienced speaker.
Different people have different processes for preparing for a conference talk. What works for one person may not work for you. I will describe how I prepare; you can try my method. Feel free to adapt it and make it your own.
I often write my proposals based on ideas I have. Once one of them is accepted, I will sit down to write the actual talk. I usually start with an outline. It is usually far too long for the time I have to give the talk, but it is easier for me to remove than to add often. I typically budget for one slide per minute. For a thirty-minute talk, I will expect to need thirty slides. I don’t necessarily spend the same amount of time on each slide; it just helps me set my expectations.
I don’t focus on making the deck too pretty at first. I want to get the content and some initial timing correct. Once I complete the first draft, I will try giving the talk to see how it flows. Often, that will help me identify extraneous or missing elements. I then refine the deck, try giving the talk again, and further refine it. I may go through many passes of practicing and refinement before I feel comfortable with the flow and content. As the talk feels more “solid,” I will pay more attention to the timing. Am I close to the desired length? A bit over or under is easy to fix, but if the talk is far too long or short, I will need to make some more radical changes.
Once the content and length are close to where they need to be, I will focus more on the structure of the slides. I will break up slides so as not to have “walls of text,” or I may move the text off of the slide entirely and move it to the speaker notes.
Once the design and structure of the slides feel right, I will continue to practice to get a feel for the timing of each slide. I want to have a rough timing in the speaker’s notes to know if I’m getting behind or ahead of where I expect to be when presenting.
Finally, as the day of the conference approaches, I will continue to practice the talk. I don’t want to memorize; I may want to remember some key phrases, but I want to have the structure of the talk memorized. On multiple occasions, the projector or presentation computer has failed, and I’ve given my talk without slides, adapting the message and content to the lack of visuals. It gives me confidence that, as a speaker, I know my presentation. Because I do not memorize it, I can adapt my words to address members of the audience or earlier talks without worrying about losing my place.
A Secret about Speaking and Giving Talks
The more you do it, the more you’ll be invited to. I still submit CFPs for conferences I am anxious to speak at or haven’t spoken at before, but about half or more of the talks I give are now at the organizers’ invitation because they have seen me speak before.
Similarly, while I continue to publish on sites I control, I get many more invitations to contribute to larger sites because the editors have read something I have published elsewhere.
I wish you the best of luck on your writing or speaking journey!
Slideology by Nancy Duarte If, like me, you are not a graphic designer, this book will help improve the design of your slides
Scott McCloud: Understanding Comics Ted Talk One of my favorite speakers. Watching this talk inspired me to move to a much more visual slide style (with less text) and to vary the cadence of my slides.
“Thought Leader” TED talk Parody from CBC Radio, “How to sound smart in your TEDx Talk” by Will Stephen These are parodies, but they do an excellent job exposing many of the tropes of popular public speakers, specifically the TED talk style. When I started speaking in public, I consciously adopted many of these tropes to help me be more confident. While I’ve shed many of them over the years, I haven’t shed them all.
We often hear about empathy as a singular concept—a soft skill, an essential quality of being human that connects us to others. But empathy comes in two flavors. It has shades, and understanding them might make us better humans.
We often hear about empathy as a singular concept—a soft skill, an essential quality of being human that connects us to others. But empathy comes in two flavors. It has shades, and understanding them might make us better humans.
Two Sides of the Same Coin: Logical and Emotional Empathy
– Emotional Empathy: This is the classic definition of empathy that most of us are familiar with. It’s feeling what another person feels. If your friend is sad, you feel sad. If they’re excited, you feel their joy. Emotional empathy happens almost instinctively. It’s raw and visceral.
– Logical Empathy: This form is more calculated. It’s understanding what another person feels without necessarily feeling it yourself. It’s more about perception, awareness, and insight. It’s about seeing things from their perspective, even if you don’t feel their viewpoint.
Emotional empathy might be more natural for some people. You know the type, those who can feel a room’s mood as tangibly as a physical touch. I’ve always admired that, but it wasn’t me.
And then there are others for whom logical empathy might be more innate. These individuals are perceptive, analytical, and capable of seeing a situation from various angles without becoming emotionally entangled. Many of us who make our careers in technology are attracted to the industry because we have these skills.
Learning the wrong lessons early
Most of my first jobs were at large companies with very competitive and hierarchical cultures: IBM, Silicon Graphics, and Microsoft. Microsoft in the 1990s was legendary for its’ hyper-competitive culture. I worked there for eight years. Microsoft taught me that I had to expect that other teams were constantly looking for how to undermine mine and that every outstretched hand was likely masking a knife held in the other hand behind the back. I eventually realized that the environment was a bad fit for me, but sadly, I didn’t get out until I had internalized those lessons.
After Microsoft, I sought out more collaborative environments, but I struggled. I constantly expected ill intent behind every action from a peer. I knew that this was hurting me and that I needed to move to a mindset of expecting positive intent from others, but I didn’t know how to rewire my brain.
A Splash of Insight: David Foster Wallace’s “This is Water”
My epiphany came when someone recommended that I read David Foster Wallace’s commencement address to Kenyon College, “This is Water.” If you haven’t read or listened to it, it’s enlightening. Wallace talks about default settings, the unconscious, automatic ways we interpret everything around us. He speaks about learning to think more compassionately and understanding that everyone around you has a unique inner life full of dreams, fears, and struggles. And it’s not always about feeling their pain; sometimes, it’s about understanding their pain.
Wallace’s speech was a masterclass in logical empathy. And it gave me a better way to try and understand others’ intents, especially when you don’t know someone well.
Developing Logical Empathy When Emotional Empathy Feels Unnatural
So how can you foster logical empathy if emotional empathy doesn’t come naturally to you? Here’s a roadmap:
Listen More, Talk Less: You don’t have to feel what someone else feels to understand them. Listen actively, engage with their words, and seek to understand their perspective.
Ask Questions: If you don’t understand something, ask. Asking not only clarifies but demonstrates that you are engaged and interested in the other person’s perspective.
Seek to Understand Their Context: What could be the pressures on them that they may not be vocalizing? If you are talking to a salesperson near the end of the quota, could they be pressured to make their quota? Is the Product Manager being held to unrealistic expectations by their boss? Leverage what you know about the business or organization to understand what subtexts may be unsaid.
Reflect: Spend time thinking about the perspectives of others. Consider why they feel the way they do. Analyze their thoughts without judgment.
Use Imagination: Try to visualize the scenario from their perspective. This mental exercise helps in understanding without feeling.
Practice Compassion: Logical empathy may not be instinctive, but it’s still a form of compassion. Approach situations and people with an open heart, even if it’s an analytical one.
Embracing Both Forms
The truth is logical and emotional empathy are not mutually exclusive. You can be someone who mainly engages with logical empathy while still having the capacity for emotional empathy and vice versa.
The real beauty lies in embracing both and recognizing that there’s no right or wrong way to connect with others. It’s a journey, and it’s one worth taking, regardless of where you naturally fall on the empathy spectrum.
In our complex and diverse world, empathy in all its shades is more than a desirable trait; it’s a necessity. Understanding how you relate to others and working on enhancing that connection, be it through emotional or logical empathy, makes you not only a better colleague, friend, or partner but a more complete human being.
This exploration of empathy, fostered by wise words from thinkers like David Foster Wallace, has been a personal awakening. It’s water, and now I see it.
Your resume is a simple enumeration of your experience and the first sample of work you are presenting to a potential employer. Many developers neglect the quality of their resume because they aren’t comfortable with writing, not comfortable talking about themselves, or simply because they don’t think it is important.
Photo by Vanessa Garcia
Every hiring manager has things that will influence them positively or negatively about a person when reading their resume or CV. Given how critical attention to detail is for developers and technical leaders, lacking attention to detail is a warning flag for me and many other leaders I speak to.
Your resume is a simple enumeration of your experience and the first sample of work you present to a potential employer. Many developers neglect the quality of their resume because they aren’t comfortable with writing, not comfortable talking about themselves, or simply because they don’t think it is important. When there are shortages of skilled developers, hiring managers will often overlook formatting, spelling, or grammar mistakes in a resume. When the hiring manager has multiple good choices for a role, seemingly small things can make a big difference in the perception of you as a candidate.
Weaving in the Details
Remember that your resume is more than a list; it’s a story of your professional journey, skills, and aptitudes. The quality of this narrative directly impacts a hiring manager’s perception of you. So, while it’s crucial to include your significant accomplishments and skills, attention to detail helps to fill in the gaps and provide a comprehensive picture.
For example, including specific project details, like what technologies you used, your role in the project, and the quantifiable results, can set you apart from the competition. These details reveal the true extent of your abilities and demonstrate your authentic experience as a technologist and your focus on the outcome, not just the output of your work.
Evidence of Care and Dedication
Meticulous attention to detail on a resume is a positive signal to employers. It’s a testament to your dedication and commitment to excellence. On the other hand, errors, inconsistencies, or vague descriptions can give the impression of carelessness or lack of effort. Spelling and grammar mistakes, easily caught by a spelling or grammar checker in a document editor, are red flags. If you have front-end or user-facing application development experience, inconsistent or poor formatting questions your skills.
Detailing Technical Proficiencies
Specificity in listing your technical skills is another area where detail matters immensely. A generic mention of “programming languages” won’t do the job. Instead, list each language and technology you are proficient in, ideally linking them to your professional experience or projects.
Compatibility with Job Descriptions
Lastly, close attention to the job description can make all the difference. Customizing your resume to fit the specifics of the role shows a proactive and thorough approach.
How to debug your resume
Use a spelling and grammar checker.
Have a friend (preferably someone experienced in reviewing resumes) proofread it.
If you are putting your resume into a language where you are not a native speaker, have a couple of people who are native speakers read it over for tone and phrasing.
If you are unsure how to phrase something, find other resumes (or LinkedIn profiles) from folks with similar experiences to see how they express it.
If you are updating your resume with new experience, read it thoroughly to ensure that the new and old sections have the same tone of voice and style.
Once you have made your changes, put your resume aside for a day or two and then reread it with fresh eyes to catch anything you may have missed.
These things seem obvious, but I can’t count the times I’ve found glaring errors in resumes where the candidate did not follow those steps.
Don’t disqualify yourself for silly reasons!
Attention to detail in a resume could be the difference between getting your foot in the door or having it firmly shut. As a technical professional, your attention to detail should reflect in your work, and there’s no better place to start demonstrating it than your resume.
A well-crafted, detailed resume is your representative in your absence, showcasing your abilities and a testament to your commitment to precision. So, the next time you revise your resume, remember to keep the details in focus. It might just be your key to the next big opportunity.
Your resume is an opportunity to illustrate who you are as a professional and how you approach your work. Attention to detail not only elevates your resume above the rest but also demonstrates the values essential to success in technology: meticulousness, precision, and a deep understanding of your craft. The details aren’t just details; they’re differentiators.
Not long ago, I was mentoring someone starting a search for a new role. The person was curious about how to interview a prospective employer.
Not long ago, I was mentoring someone starting a search for a new role. The person was curious about how to interview a prospective employer. I wrote explicitly about this in a blog post a few years ago (https://leaddev.com/professional-development/taking-thoughtful-approach-job-search-process), but I think I was able to further distill some of the ideas in our conversation.
There are three things when considering a new role assuming the basics (i.e., pay, benefits, location) make sense.
Can you be successful at the company?
Does the role move you toward your career objectives?
Are you excited about what you will work on?
Suppose you can get all three. Wow! Take that job! Two of the three is pretty good, but it likely means that you should not expect the role to be long-term unless you misjudge the situation or something changes. One of three? Take it if you must but have an exit plan.
If you are in a decent role today, you can always choose to keep looking rather than take something that doesn’t meet enough of your criteria. While the lure of something new might be tempting, it can be hard to understand a role before you are established in it. If your initial investigation raises questions, it may be better to keep your search going.
The critical element is knowing yourself and the perspective role well enough to make the determination (the technique I describe in the blog post referenced above is helpful for this). If you don’t know what you want, keep exploring. Look to new roles to increase your skills or experience with industries, company size, or company culture.
Once you know the conditions where you do your best work, where you want to go with your career, and what excites you to work every day, you can put together questions to ask when talking to the recruiter or as part of the interview process.
Try to avoid asking direct, obvious questions. If the interviews are going well, people may tell you what you want to hear. For example, asking, “How is the work/life balance at your company?” is less likely to be helpful than asking, “What times do meetings usually start or end during your day?” If several employees tell you that their day starts early or ends late, you will see some work/life balance patterns.
Another problem with direct questions is that they reveal more about you than you might want in an interview. For example, when a candidate asks me a direct question about something specific, such as raises, review processes, or work/life balance, it tells me not just that they are interested but that they may have had bad experiences with this in the past. If I get a sense of a bad experience, it will usually prompt me to better understand the nature of their concerns. If you are concerned about review processes, for example, I wonder if you have received negative reviews in the past and what was the story behind them. So, asking more generally about how often the company performs appraisals and the process will elicit less concern than asking how employees can appeal negative reviews.
Ask indirect questions about how the work is done, the day-to-day responsibilities of the role, and what conflicts arise. Look for clues in the answers that speak to reality. You may find some of your interviewers are more forthcoming and open. Leverage that transparency. Find friends or friends-of-friends that know people who work there to get the unvarnished truth.
But also realize that companies evolve just as people do, just as you will. So even if things are good for you initially, they may not stay that way.
So, when your three-of-three company becomes your two-of-three company, you may wait things out to see if things will change, but you also might want to start looking for your next three-of-three company. Although every company will have good/bad periods, once you have been at a company for a while, you’ll understand if the current situation is temporary or part of a more permanent shift.
Of course, in today’s job climate, you might need to take that one-of-three job or even zero-of-three position. If that is the case, don’t despair. Instead, focus on taking care of things until you can find a role that fits you better. Tech is cyclical, just like the broader economy. If you can wait it out, things will get better.
In the last post, I shared the books that I found worth recommending that I read in 2022. The next post shares podcasts that I found valuable. In this (longer) post, I will share links to the blog posts from 2022 that I think are recommendation worthy. I’ve broken it into sections based on content.
As a CTO, I spend a lot of my time thinking about building effective technology organizations, and I’m always looking for new approaches or lessons in the space.
The pandemic has caused nearly two years of collective trauma. Many people are near a breaking point.
An airplane passenger is accused of attacking a flight attendant and breaking bones in her face. Three New York City tourists assaulted a restaurant host who…
If you are wondering why people are such jerks now…
Learn about the How HashiCorp Works project and why there are links to internal HashiCorp materials in this article. Our…
I like the movement in making how companies work transparent. It is useful to read as a leader and a great recruiting tool for those companies. I always wonder how much reality matches the shared documents. If you know you will share with the public, you are likely to be a bit more aspirational than actual, but it is still useful to read.
Medium sees more employee exits after CEO publishes ‘culture memo’ – TechCrunch
The sign that Netflix’s culture had irreversibly started to…
The genius of Netflix as an employer was that it has always been very upfront about who it is and how it works, with the understanding that anyone taking a job there knows what they are getting into. This works great until the culture starts to change, so this isn’t about an individual employee being unhappy. It will be interesting to see how Netflix navigates this (or doesn’t).
Culture as a Product: How HubSpot Built its Famed Startup Culture
Around Boston and beyond, HubSpot is known for its strong entrepreneurial culture . The company has received many awards over the years and was recently named…
Hubspot is an interesting company. Having read Disrupted (https://www.amazon.com/Disrupted-Dan-Lyons/dp/0316306096) I am a bit skeptical of how they talk about themselves, but of course, one always should be. That said, even if the public face of companies’ cultures is more aspirational than real, there is still something to be learned. I didn’t decide that the 37 Signals books were worthless because when under stress, the company didn’t live the values they proclaimed.
Bolt Loaned Employees Thousands to Buy Stock—Then Laid Them Off
The challenge of startup options is that employees rarely are allowed to sell them. When a startup has been around a long time, and startup options are starting to expire, but employees have had the liquidity event necessary to have ready cash to exercise their options, what are they to do? A company I was in also considered a loan program for employees but decided it was potentially problematic. Bolt learned that lesson the hard way, and their former employees are worse off for it.
A big 32-hour workweek test is underway. Supporters think it could help productivity
This article was originally written for LeadDev . In tech, we talk a lot about failing fast: implementing small, incremental…
I talk a lot about failure, failing fast, etc… This article is an actual case study in how to recover when your team has a big failure. I always like real-life stories instead of vague opinion pieces.
Career Development: What It Really Means to be a Manager, Director, or VP
It’s no secret that I’m not a fan of big-company HR practices. I’m more of the First Break all the Rules type. Despite my general skepticism of many standard…
There are tons of posts and books about being a line manager. There are substantially less about levels beyond that. I’m always looking for informative articles or books about more senior leadership levels. This was a decent one.
There is a euphemism in rocketry often heard at SpaceX – Rapid Unscheduled Disassembly. A catastrophic explosion, in other words. Until now, it was not…
The speed of Elon’s decline from “genius who can see a better future and bring it about” to “asshole snake oil salesman with a narcissistic personality disorder” was sudden by any measure. How do we keep people like this from ruining our favorite apps/sites? By keeping ownership and infrastructure distributed…
Remote Work/Return to the office
For the last couple of years, the push and pull of remote vs hybrid vs back-in-the-office has been a major story in the work press. I’ve already made my decision that I’m going to keep working remote and will choose companies that allow me to do that, but in all of this discussion I’m also looking to understand how other companies are approaching things.
Why workers are calling BS on leaders about returning to the office
This may be losing some of its value as it ages, but speaking as an all-remote company CTO, if you don’t listen to your employees about how they want to work, I’ll be happy to take them off your hands.
The Future of Work Isn’t Fancy Tech. It’s Remote Work and Smarter Management
The remote/office debate is dying down any time soon. There is more pressure on returning to offices now, but there is also more resistance. Given the layoffs, employees may not feel empowered to resist the call to return to the office, so maybe that will gain ground.
The Worst Part of Working From Home Is Now Haunting Reopened Offices
Few people are as knee-deep in our work-related anxieties and sticky office politics…
If a primary driver for bringing people back to the office is better collaboration, you may want to consider how your hybrid remote/office system is set up.
How to embrace asynchronous communication for remote work
How to get started with async GitLab believes that…
The secret to successful remote work (especially if the team is spread across time zones) is moving to be asynchronous first. The companies that have been distributed for long periods and have scaled have embraced this, but it is harder than it seems, and many companies struggle. Even those that have always been distributed. This GitLab guide is very helpful.
Web Technologies
I spent much of 2022 learning more about WebAssembly as we launched PyScript at Anaconda. I think that it has some amazing potential and is one of the most important technologies of the last few years.
This article explains the concepts behind how WebAssembly works including its goals, the problems it solves, and how it runs inside the web…
If you are in technology, you need to understand WebAssembly and how it can be used. It can potentially be more transformative than many of the technologies we depend on for software development today.
A short history of Flash & the forgotten Flash Website movement (when websites were “the new emerging artform”)
This post is a transcript of a talk I gave at UCSC. Thank you for inviting me! I’m sharing it here because It’s a GOOD summary of the history of a technology…
If you were active on the web in the 90s and early 2000s, you will remember the explosion of massively creative web experiences propelled by the Macromedia/Adobe technology Flash. While you can still create those kinds of experiences using modern web technologies, it now requires a level of coding expertise that puts the programmers in the driver’s seat instead of the artist/designer and requires a team instead of a single creative person.
The genius of Flash was that it made complex interactivity and visuals easy for many artists to create, and the result was beautiful chaos. The web is just a bit more boring for the death of Flash.
Spotify’s grand plan to monetize its open source Backstage project via premium plugins
Backstage was created when I was at Spotify. Even in its earliest days, it solved many problems for us in a massively micro-service architecture. It’s cool to see how it has developed over the years, and it was also cool to see that Spotify had open-sourced it. I think it is interesting that Spotify is doing this experiment, but also disappointed because I know of at least one company formed by ex-Spotifiers that were trying to build companies on top of Backstage.
Google: The Model Your Site Was Built On Is No Longer Feasible
Hours before Elon Musk closed his deal to buy Twitter, he published an open letter to advertisers. Musk knew that big companies, in particular, were anxious about…
“Free speech” and an advertising-based revenue model are incompatible.
Web3/Decentralized Web/Metaverse
When blockchain emerged, I spent some effort to really understand it. Then I realized that it was a technology searching for a use case fueling a tulip-like baseless speculative market. When Web3 started to emerge, I delayed judgment until I could understand it better. While I believe that there are people who believe that it can fuel a world where creators have more ways to be paid for their work and other such lofty goals, the practicality of it is that very little of those schemes require the blockchain, and most of the people in the space are just trying to make a quick buck before the tulip market collapses.
You’ll probably hear the fuzzy term web3 bandied about in the press if you read tech journalism. Sprinkled around, all these articles are all manner of…
The title says it all.
Crypto and Twitter Are Imploding at the Same Time and It Is Glorious
I’ve been on Mastodon since 2017, but my usage really increased since the acquisition of Twitter. There have been a lot of stories talking about how people are abandoning Mastodon, but even if it doesn’t become what Twitter was, it is still a vibrant community.
There’s No Fixing Meta’s Metaverse, Scrap It, Start Over
I spent 6 years working on the metaverse at Microsoft during the 90s. While the technology has drastically improved, the reason we didn’t get the metaverse back then is that no one could figure out something to do in the metaverse except shoot each other or have sex with each other. All the folks working on metaverse now have learned nothing from the multiple generations of attempts that preceded them. There is still a smug belief that “if you build it, they will come.” The problem is that there is still nothing to do once they show up.
If these problems are intrinsically linked to consolidated tech giants like Meta, Google, and Amazon, why not embrace technologies that decentralize power? This has become a key issue for Brewster Kahle, the 61-year-old founder of the Internet Archive…
Having participated in various forums and working groups for decentralized web stuff over the last few decades, I’m consistently excited by the possibilities and enthusiasm of the folks who work towards those goals and disappointed by their naivete about what people are willing to put up with and how commercial entities are incentivized to coopt and pollute the technologies that do gain some momentum.
Your organization should run its own Mastodon server
Whether you are a large company, a political party, an international news agency, an NGO or a government institution, you should seriously consider running your…
What is the point of having a decentralized web if you don’t own your own part of it?
Twitter Turmoil: We Need an Open Protocol for Public Discourse
Do we want to stay on a social network that shows such callous disregard for its own people? That is the question many of us have been asking as news hit this…
All the agility has been sucked out of agile projects Doing agile is not the same as being agile Agile projects have become bloated, lazy waterfall projects…
One of my biggest pet peeves is people deciding that a bad experience they had with a poorly implemented framework or process must mean that that framework or process is clearly bad and that anyone who had a good experience is lying. So many of the “I was involved in a poorly run agile project and so agile must all be a lie” or “my company tried to do the Spotify model, and it didn’t work; therefore, it must not work at Spotify either” type posts just show the ignorance of their authors and nothing else. While I was worried this article was just another one of those, the author is concerned more about poor agile processes and not agile itself. He even gives some good advice. So worth a read.
Machine Learning
Mozrt, a Deep Learning Recommendation System Empowering Walmart Store Associates with a Personalized Learning Experience
We developed Mozrt, a deep learning recommendation system for Walmart Academy App, the training content portal for Walmart store and Supply Chain associates.
Walmart built a massive technology team in its fight with Amazon. It is good to see them sharing their work.
ChatGPT and the Google and Microsoft chatbots get all the attention now, but before that was GPT3, which also remains the only LLM with the ability to train on your own corpora.
Building Communities
Why Communities Are the New Business Currency | HackerNoon
We’re no longer content with one-way interactions with businesses. We want to feel like…
If you can’t tell from the previous post, I spent some time updating myself on building virtual communities last year. This is a good starting place for folks looking to understand the value.
It needs to be said again, perhaps this time more strongly. Your Blog is The Engine of Community . Dammit. Blog More You are not blogging enough.…
Scott Hanselman thinks developers should be blogging more, and when they do blog, it should be on their own platforms. And he’s right.
Music Industry
I’ve been involved in music as a musician, radio DJ, label owner, and streaming software creator since I was 15. I was delighted to rejoin the music industry in December when I took on the role of CTO at DistroKid.
With 100K tracks uploaded a day, a longtail music cull is coming – Hypebot
Lucian Grainge doesn’t like that people aren’t listening to Universal Artists as much, so he’s putting pressure on the streaming services to remove content he doesn’t think is good. The problem is deciding what content is good and what content is bad. Streamers already remove fraudulent content. So, who decides if your band shouldn’t be on Spotify because you might take a stream away from Justin Bieber (who himself was discovered because he uploaded his songs to YouTube). Gatekeepers are all about protecting their interests at the cost of innovation and getting others a shot.
Why Amazon VP Steve Boom just made the entire music catalog free with Prime
It’s never been clear how much Amazon cares about music streaming as a business. It’s always been an also-ran in the streaming wars that only has listeners because it is an add-on to Prime and is the default service with Alexa. Amazon hasn’t invested much in the service, but maybe that is changing now…
A former co-worker reached out to me recently. They are a director of engineering at a midsize startup and just got their first headhunter inquiry for a CTO role. Having never been in the role before, they wanted to know what the position was like and how to prepare for the interviews.
I realized that while there are some books on technology leadership careers, there aren’t many resources explaining the most senior levels. My goal is to provide some insight and advice for those interested in someday becoming a CTO.
I’ve been a CTO for five and a half years
I’ve worked at a hundred-thousand-person company, seed-stage startups, and many of the variants in-between. I started as a developer and followed a traditional path of moving up to more senior levels on the development track and then moving to lead, engineering manager, director, VP, and now chief technology officer. I’ve been the CTO at three different companies in two countries and three parts of the technology industry. I’m part of a few networks where I meet and talk with CTOs of all sizes and stages of companies.
I’ve learned that one reason there isn’t a good reference for the role of the CTO is that the size of the company and the expectations of the CEO define the job. Some of my role expectations and responsibilities are like those of many of my peers at similar-size companies. However, there are also significant differences in our expectations from our executive peers and boards.
Because of the variability of the role, I will broadly share my direct experiences, joined with an understanding of the expectations of other CTOs that I know.
The early-stage company CTO is often the developer-in-chief
At earlier stage companies, the CTO is often the technical co-founder. They are likely the developer who built many of the earlier versions of the software and helped hire the original development team. Their responsibilities are primarily technical: driving architecture, doing advanced development tasks, and creating technical vision.
Frequently, the first CTO of the company is hired for their ability to code and not their ability to grow or manage a team. Depending on the person, they may also lead the development team. Still, often the team’s management will eventually move to another person, an experienced manager, who may report to the CTO or be a peer to them.
The early-stage CTO is the leading technical voice for the company externally, especially if they are a co-founder. They talk to investors and potential partners and meet with potential vendors. If they also manage the development team, they will solely represent engineering in the senior leadership team. As a result, they will have responsibility for the decisions made by the engineering team. Nevertheless, if they do not manage the team directly, they might not be involved in the decisions around the day-to-day operations.
A mistake that inexperienced founding CTOs often make is that they don’t understand their role beyond coder-in-chief. They focus solely on the technology and are not active participants in the company’s leadership. As a result, they do not work cross-functionally. CTOs fixated on the how without the why or what will not be in the role very long once the company grows.
If they have no experience leading an engineering team or organization, the early-stage CTO will be challenged to grow with the company. If they cannot scale, eventually they will end up in a subordinate role reporting to a more experienced CTO hired to replace them.
The midsize company CTO is responsible for leading the organization, corporate strategy, and making technical decisions
Once a company reaches a size at which it needs new processes and structures, the scrappy leaders who helped get the company off the ground are often replaced with more experienced leaders knowledgeable in taking companies through the next growth stage. If the CTO hasn’t grown into the larger role, they will be part of that replaced group.
The midsize company CTO is a full-fledged executive team member working cross-functionally and meeting with partners, investors, and customers. Frequently, the midsize company CTO will also manage the engineering organization. The CTO is responsible for setting technical direction, making sure good architectural decisions are being made, and establishing best practices and working methods. They are still expected to have good technical depth, but don’t often actively contribute to shipping code. A red flag for me personally is seeing a CTO role description where the expectation is to lead a 50-plus-person organization while also actively coding on the product. It means the executive team does not have appropriate expectations for the role.
A midsize company CTO spends significant time establishing culture and practices for the teams they are responsible for; they are also very directly accountable for the organization’s decisions and its track record of delivery. The CTO meets internally with members of the other functions, such as sales, marketing, HR, and finance, to share direction for the organization and get feedback. The CTO is responsible for the administration of the teams, including the budget.
The CTO is also responsible for hiring, performance management, and team structure and may be very active in their teams’ recruitment and interview processes, especially in a scale-up type of company.
A CTO leading a more extensive development organization must be a generalist, understanding different roles and responsibilities. Their remit may include Corporate IT and Technical Support. In some companies, they may also manage the business analytics, security, product, and UX teams. A CTO who is too focused on the areas closest to their background or does not respect non-coding functions will not succeed.
As a midsize company CTO, you will often spend as much time with your peers and their teams as you spend with your own. As a result, you will need to learn about their functions and how your teams can work together. CTOs who “stay in their lane” will not be seen as an equal member of the senior leadership team and may lose their say in decisions that affect the organization.
It is very unusual for someone to move into a midsize company CTO role without having some experience leading a multilevel-development organization and working with other business functions.
Growing (or moving) into the CTO role
If you are a manager or a manager of managers with the goal of being a CTO, there are a few things you can start to focus on that will help you on your path.
Learn about the business your company is in
Offer to sit in on sales calls, on user research interviews. Try to understand the company’s financials when the CFO presents them. If you can’t, make a friend in the finance team and ask them to explain them to you. Understand the KPIs not only for your team, but also for the teams around you.
Learn about the other functions
Get recommendations of reading or conference talks from your peers in the product, UX, and marketing teams. Think about how their work influences yours, and yours influences theirs.
Respect and learn other technology areas aside from your own
If you lead an area you don’t have personal experience in, approach the people in that function with respect and a genuine desire to understand their work. They want to help you know what they do and how they do it.
Hone your craft
Hopefully, you are already working on deepening your skill as an engineering manager or director, but are you trying to understand the bigger picture? Read other companies’ (public) handbooks, engineering blog posts, and conference presentations about their ways of working. What practices are interesting? Which can you try in your team? How do you think they will scale, or what issues do you think they may have?
Ask your CTO if there are tasks they can delegate to you
The best way to learn the job is to do the job. Even better is having someone who is already doing the job explain to you how they perform it so you can help them.
Start thinking in terms of strategy
The main difference between the expectations of line managers and senior managers is the emphasis on strategic thinking. Executives contribute to the company’s strategic planning and use their understanding of the company’s goals and the current situation to make sure that their teams are setting up the conditions for the company’s success. Strategic thinking is a learnable skill, but it takes practice.
The rewards of being a CTO
Being a CTO was not what I imagined it to be when I first decided it was my career goal. It is a lot of work, carries much stress, has fewer perks than you might think, and can be somewhat lonely. However, it is also the most personally rewarding job I have ever had. With the challenges, there is also incredible responsibility, tons to learn, the ability to influence the company’s direction, and the chance to affect the lives of dozens or hundreds of people on your team. I have yet to regret my choice to pursue this role.
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, a critical customer meeting dominates, or 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.
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.
