Never pass up an opportunity to express gratefulness, especially in the workplace. In my (almost) 45 years of life, I’ve never heard someone say “You say thanks too much, please tone it down.” Do it often, do it out loud, and do it in front of an audience.
That being said, the object of your expressed gratefulness matters. What you praise is what you encourage to happen more often. But the converse is true too, what you don’t praise you will discourage. And if your praise for a person’s work is disproportionately towards things less important to their job, you may be having the side effect of making them feel they aren’t actually doing a good job with the things that do matter.
Of course, that may literally be true. You may be using praise of the inconsequential as a defense mechanism to avoid hard feedback of what is consequential. Or you may not be. But if your praise quotient is out of alignment, the individual you’re praising will have to guess. And that ambiguity can be disheartening.
I don’t pretend to know everything that’s going on over at OpenAI, nor all the eventual lessons that will come from it, but unlike most tech-elite brouhahas this one might actually matter, as there’s a strong possibility taming artificial intelligence is “the final boss of humanity” (as one of the players in the ongoing saga has said).
Played around some yesterday with ChatGPT’s voice chats, and can totally see how we’re not far from deepening the emotional attachments to our devices. Her has never felt more prescient or likely. It’s mandatory viewing.
So you want to become (or have been told you now are) a technical team lead? Awesome, congratulations! You’re in for an excellent adventure. But if you’re wondering where to begin, and what’s going to change, lucky for you I’ve been there myself, helped several others through this transition, and have captured some lessons you can apply:
First, make sure everyone on the project knows you’re the technical lead. This isn’t about ego or power, it’s about clarity of function and accepting responsibility. With that comes the need to be responsive; availability for conversation is now part of your job.
Next, get to know the team personally and earn their trust though human connection. You cannot be everywhere all the time, so you need people who are comfortable coming to you with challenges both technical and otherwise. If there are folks involved external to your organization this is doubly-important. Identify a go-to person on that external team and engage with them regularly one-on-one.
Get to know the team professionally as well. What are each individual’s strengths and weaknesses? What technical skills do they have, and what parts of the system need those skills applied? What are their communication styles and ways of being motivated? Personalize your approach with everyone; it’s your role to put them where they can thrive, which in turn maximizes collective success.
Have a generalist mindset. Get to debugging level competency across the entire tech stack, no excuses. You don’t need to be the best at everything, in fact you shouldn’t be, but you should know what good looks like so you can ensure it’s happening.
There’s one area, though, where your knowledge should be unrivaled, and that is understanding your customer and the business case you are there to solve. Get familiar with their requirements and deadlines. Stay connected to your stakeholders, listen, ask questions, and then push their objectives down to the people in your charge. Once again, this is especially important if there are subcontractors who have a limited view of the big picture.
Make yourself present in meetings, erring on the side of being overly-present (especially at first). Requirements gathering session? You gotta be there. Sprint planning and backlog grooming? Not optional. But that deep dive on a bug or tricky technical problem? Maybe let your tactical experts handle it, or at least have them gather the data and come to you if they run stuck or need a decision.
Speaking of decisions, apply wisdom to the ones you can delegate and ones you cannot. Specifics will vary project to project, but in general the more reversible a decision is, the less important it is you make it. Another rule of thumb: as soon as you know how to do something well, it’s time to teach someone else to do it, while you take up the next challenge no one else is equipped to solve. Fail at security and you fail full stop, so keep your eyes on anything that could jeopardize it.
High-level architecture and technology choices will matter more in the long run than anything decided in a code review, so keep your nitpicks to yourself. Speaking of code reviews, their value mostly comes in peer to peer cross-checks. If you think you have to approve every line of code yourself, you’re doing it wrong. Treat your attention like the precious commodity it is.
Your good intentions of ensuring quality code and other deliverables won’t be enough. Establish quality mechanisms: automated linting and security scans. Automated testing. Continuous deployment. These are your eyes and ears, and more important for you to establish and monitor than you building features at their expense.
Take failure personally. Things will go wrong; the minute you blame those under your charge, you’ve lost. Instead, turn your gaze inward to what you could have done better. When you hold yourself to the highest standard, it calls others to do the same.
Finally, don’t stop listening and learning. Get feedback, even when it’s hard to hear, and act on it. Also, there’s tons more out there on being a tech lead, go do some searches and read up. Perhaps you’ll even (gasp) find counterpoints to my above arguments. That’s great! Ultimately you’re a technical lead to serve and empower, and that requires judgment on when to follow the rules and when to toss them and do what’s gotta be done, because no job is below you. Be the person who brings the coffee and donuts, orders the pizza, serves the drinks, and cleans the conference room afterwards.
Sound hard? It is. It’s gonna take a different set of skills and a significant amount of time. You’re going to have to let go of some things you’re used to doing and some things you’re good at (and probably enjoy doing) to find that time. But when a team you’ve led accomplishes more than you could ever do on your own it’s a unique kind of reward.
Amazon promotions require “best reasons not to promote” to be documented, both from a manager and from any colleague who provides formal feedback. Arguably it was the most important part of the process, because it demonstrated that input came from individuals who could see the candidate clearly enough to speak honestly about both their strengths and their shortcomings.
When coaching candidates for promotion, I recommended they write their own version of that section, and then we’d review theirs alongside my own. Why? Because if you shy away from your deficiencies, you have no counterargument to them. They’re going to be found out anyways by any competent promotion evaluators, so why not get ahead of the curve.
I don’t pretend this is easy, especially for people who have battled insecurities or have lacked encouraging support throughout their careers. But it’s essential for making meaningful career progress. When advocating for yourself, look your shortcomings straight in the eye.
There isn’t a day that goes by that I don’t miss my Dad, but this week I’ve been particularly reminded of him being the reason I rarely feel insecure in naming my professional weaknesses. What a tremendous gift from a parent, the words “I love you” and “I’m proud of you” spoken aloud, simply and frequently. I must have heard those words hundreds of times. Thousands. So often that their truth got into my bones. I believed him then, and I still do now, even though he’s gone. Thanks Dad.
I’m coming up on six months since I took the CTO job at RIPL. Enough time to meet the team and get settled in, even bring a few tactical benefits that solve immediate needs. But the real work begins now, that of strategic planning that sets us up for long-term success.
Operating in a C-Suite is new to me. I don’t have a point of comparison, but so far it’s been great. Between the three of us we have a well-distributed set of skills and experiences, which means we can lean into our strengths while knowing the others have our blind spots covered. In many ways we’re operating as a coalition of equals more than a hierarchy; of course there’s deference when required, but the level of mutual trust is such that it doesn’t really come up often. And I genuinely enjoy the company (in both senses of the term). Not sure if this is rare or common, but I’m grateful either way.
Perhaps this is how the best leadership teams operate, more like a unified whole than a siloed set of individuals? It’s an idea worth exploring further; the Freakonomics episode Are Two CEOs Better Than One is probably where I’ll start.
A corollary to the above, especially given I’m the oldest person in the group (a fact worthy of its own post), is that finding mentorship from professionals with more experience in my role means that I have to look to sources outside my employer. It’s why I’m trying to build a better professional network through activities like starting 4S Tech, attending CTO Lunches, joining the Rand Leadership Slack, and taking a tech ethics class. I consider these efforts part of my job, because I owe it to my company to develop myself further.
Ending conversations is always a bit awkward, whether it be in-person goodbyes, the “uh, are we done?” Zoom meeting closer, or wondering if an email chain needs a final “Thanks” acknowledgement.
Real-time text-based exchanges are particularly tough. Here’s my question: is an emoji response a sufficient message that “yes I got your message, I’m acknowledging that, but I’m not keen to talk further”? Is the vibe different if I send the emoji as a standalone response vs applying the emoji as a reaction to the last message I received?
Need some help from someone in the know, which probably means someone younger than myself.
Good technologists stress the importance of capturing information in written form. Examples are myriad and diverse: design decisions, code comments, commit messages, operational runbooks, and performance feedback, all of which benefit from being documented for future reference. In this post I want to suggest another data set worth capturing: your work history and professional accomplishments.
Sometimes referred to as a brag document, and much more than just a résumé, a complete log of your work can serve you in several ways. It’s useful to provide to your manager and other leaders during performance reviews season, or to make a case for a promotion. When it comes time to search for a new job, you’ll be prepared to recount your experiences in detail, and provide concrete examples to questions (a post for another day, but good interviewers love specifics). And when you’re discouraged about your future or feel like an imposter in your present, you can review your past successes and remember that you belong.
No amount of detail in your brag document is too much. Start with the what and where, and be specific about your role in the work. Add artifacts wherever possible, such as public links to code, articles, blogs, press releases, or anything else you can think of. Don’t have public artifacts? Make some if your situation allows. I even collect screenshots/photos if they’re not proprietary, or if they help me remember the people that contributed to successes.
Speaking of which, including information on who, when, and why are also critical (and easy to overlook). No one cares about technical minutia if the work didn’t make a difference. Write down the difference you made! Metrics are best (e.g. increased sales, more users, faster response times, people helped), but anecdotes work too. Capturing timeframe is useful to understand context when relating to other work. And documenting who you worked with is useful for multiple reasons: one, it ensures you remember a network of folks who can vouch for your work should you need it. And secondly, it provides context on the level that you were operating at within your organization. This was one of the tricks we Amazon Bar Raisers used to suss out a job seeker’s influence: were they talking regularly with customers and other stakeholders outside their immediate team? How far outside? And were they peers, managers, directors, executives? This context was directly applied to leveling decisions.
Capture your work log in situ. The longer you wait, the less likely you are to remember correctly (“the strongest memory is weaker than the weakest ink” as my childhood pastor used to say). Having a regular cadence can work well. Friday afternoons especially so, as that’s a great time to reflect on your weekly accomplishments.
It’s not just you that’s likely to forget if you wait too long, but so will others who can provide feedback on your work. Few things are more powerful in a brag document than actual quotes from project stakeholders. It can feel awkward to ask, but get over yourself and do it. Ask for both the good and the bad, accept it gratefully, and save it away alongside the rest of the details about a project.
“the strongest memory is weaker than the weakest ink”
If you’re just starting out, don’t overthink the arrangement of info in your brag document. Pick a tool and get started. Especially don’t wait for a manager to do this documentation work for you; career development is your responsibility first, and besides, they probably don’t see nearly as much as you do (doubly true in the age of remote work).
Eventually your document is going to need some organization. The objective is to tell a coherent story that captures the reader’s interest. Chronological order is probably the easiest, and can work if well if you have a mostly linear career progression. Clustering activities by industry or domain packs the most punch if you’re trying to make a case for your expertise in a specific area. Ordering accomplishments by impact, with most impactful first, is a great way to highlight the value you can bring. If you’re building a case for a promotion, you should consider aligning your document to the next-level role guidelines provided by your organization (and if you don’t have such guidelines, ask for demand them).
Finally, I suggest keeping two versions of your work accomplishments. One internal to your current employer that has maximal detail, and one you keep personally, edited down to comply with any non-disclosure or confidentiality requirements you might have. The latter is the perfect source for résumé material when needed.
Pro Tip: When creating a piece of code or infrastructure that you only need for a short period of time, mark it as temporary, and ideally include a date after which it’s safe to delete. That way in the future, if you forget to delete it yourself, when some person comes across it, they know it can be cleaned up without risk.
This is doubly important if the temporary thing you’ve made opens up a potential attack vector. The canonical example is adding remote IP addresses to a security group, which I had to do just today:
I view the above as a corollary to the Shopping Cart Theory. The world thanks you for your service.
My first real job was at Burger King, which I got at my dad’s behest the summer of 1994. I was only 15 years old, and what I could do was pretty limited (no food prep, nothing to do with the deep fryer, couldn’t even do dishes because of knives). But what I could do was operate the register and take orders. On balance it was a positive experience, not least because it taught me how to talk to strangers.
I’ll never forget one particular aspect of my training. There was a question we were expressly forbidden to ask when interacting with customers, and if we ever did, even accidentally, our manager would yell at us from across the kitchen. The question?
Is that it?
Why was it verboten? Because it shuts down conversation. In social situations humans are wired to want to answer questions in the affirmative, and a “yes” response to that question means no more items to add to the order, and my corporate overlords definitely didn’t want us to encourage customers to stop adding fries, drinks, desserts, and more. What question were we instead instructed to ask?
Is there anything else?
The difference is significant, as an affirmative answer here encourages the customer to go ahead and keep ordering, subtly suggesting that perhaps there’s more they would enjoy. I realize now, though, that there’s an even better way to nudge a person to continue speaking what’s on their mind.
What else?
I first picked up this simple but effective question from one of my managers at AWS, as he would use it throughout our 1-on-1 meetings to get me to be honest about what I was thinking and feeling about my job. This question works because unlike the prior one, it assumes that a person already has more to say, nudging them to say it. I know it worked on me (I had no shortage of opinions to share, no doubt).
It reminds me of another short but powerful prompt that can take a conversation to the next level:
Tell me more.
When trying to listen actively, it can be a challenge to think of relevant follow-up questions in real-time, especially with a person who’s taciturn, or if you don’t have a prepared agenda. “What else” and “tell me more” are great because they can be used at any lull in the conversation; keep them at the ready, and they won’t let you down.
“For millions of years, mankind lived just like the animals. Then something happened which unleashed the power of our imagination. We learned to talk and we learned to listen. Speech has allowed the communication of ideas, enabling human beings to work together to build the impossible. Mankind’s greatest achievements have come about by talking, and its greatest failures by not talking. It doesn’t have to be like this. Our greatest hopes could become reality in the future. With the technology at our disposal, the possibilities are unbounded. All we need to do is make sure we keep talking.”
Decent lighting is essential when wanting to exude professionalism in a video call. But sometimes you either don’t have equipment at hand or don’t want to mess with it. As a stopgap, I’ve discovered that if I open up a few browser windows with light backgrounds they can help illuminate my face, but the results are a bit bluer than I’d otherwise prefer.
It got me thinking if I could build a simple website that would be nothing but an adjustable color background. Behold, the webcam light tool. Not only is the color adjustable via HSL (hue, saturation, lightness) sliders, there’s also a slider in Kelvin if you want to pick a color temperature instead. Color values are saved to browser local storage and remembered on subsequent visits, and automatically synchronize in real-time if you open multiple windows.
With a pair of tall and narrow windows, one on either edge of my ultrawide monitor, the results are pretty good. Chalk one up for creative solutions!
If you found this blog helpful and want to say thanks, I like coffee.
