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.
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.
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.
Tech’s Talent Wars Have Come Back to Bite It
by Erin Griffith
What Tech People Should Learn From This Era of Excess
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
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.
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.
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.
Many good takes: eating popcorn, and watching the crypto bros burn down their empire.
5 key lessons after a week on Mastodon
by Sandra Gutierrez G.
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
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.
Mozrt, a Deep Learning Recommendation System Empowering Walmart Store Associates with a Personalized Learning Experience
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.
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
by Music Business
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.
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.
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.
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.”
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.
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.
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.
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 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!
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.
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.
The planners from the Ink+Volt team helped me build some structure around my strategy, and also regular time to revisit and update it. Kate Matsudaira (who is also a very established technology leader) provides useful structured planning and strategic thinking documents in her newsletter and on their blog. https://inkandvolt.com/blogs/articles