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.
It was six months ago now, but I clearly remember the feeling of sitting with my AWS laptop on a Friday morning, knowing it was the last time I’d use it. There’s a surprisingly emotional bond that develops between a technologist and their equipment; I was genuinely sad about turning it in. But handing over the hardware wasn’t the worst part, it was knowing that every digital file I’d created on that laptop would be erased, thus anything I hadn’t transferred to someone else or otherwise handed off for preservation would be gone forever: every half-completed business idea one-pager, all my customer presentations, any little code utilities I’d built. Everything. Four years worth of accumulated artifacts is no small thing, and I didn’t want to see it disappear.
I was in this same situation back in 2014 when I left my first job, and at the time, for confidentiality and security reasons, I’d done nothing I could publish publicly or otherwise take with me. That was unfortunate, and I didn’t want to repeat that disorienting experience. Thankfully during my AWS tenure I’d taken steps to release whatever I could via open source mechanisms. And what I couldn’t directly publish, I’ve tried to capture after the fact on this blog, including this post on how to approach certifications (reconstructed from a talk I gave at an internal conference), my advice on brag documents (also from a talk), and a process for doing project estimation (rewritten by memory from a team wiki page).
Don’t make the mistake I did and wait until the 15 year point of my career to take these sort of steps. And don’t wait until you’re at the end of your time at a company either; like documenting your accomplishments, archival work is best done in real-time. Embracing open source development can help, even more so if your employer is onboard. Push them if you need to (you can find some talking points in this excellent article).
A final argument: continuous improvement is predicated on retention. “Those who cannot remember the past are condemned to repeat it” applies not just to history, and the DRY principle applies across both spatial and temporal dimensions. Or even more simply: save your work!
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.
Tonight I kick off a class from Stanford called Ethics, Technology, and Public Policy for Practitioners. It’s been a hot minute since I’ve been involved with formal education (about 10 years actually), but I’m pretty excited. Not just for the learning, but for the people I’ll meet along the way, who appear to be a fantastically variegated bunch based on what I’ve seen on Slack so far.
Here’s the course description from the syllabus:
Our goal is to explore the ethical and social impacts of technological innovation. We will integrate perspectives from computer science, philosophy, and social science to provide learning experiences that robustly and holistically examine the impact of technology on humans and societies.
Basically it’s Jud catnip. If it sounds interesting to you, I think it’s offered periodically. Here’s a link for future reference.
I once had a customer call me an “idea hamster” because of how easily I went down rabbit trails of ideation when discussing the project we were working on. We had a good laugh about that turn of phrase, and I do see the value in idea generation to some degree, but ideas are easy. I’m not impressed by someone who can come up with many of them (least of all myself). What impresses me is people and organizations that can execute on their ideas.
There might be “second half of life” factors at play as well in my desire to get better at finishing. In the last week I’ve added 10 draft ideas to my blog backlog, and this will be only the first one I’ve published. At the rate I’m going I’ll never get done, which perhaps is a good thing, but still, I want to get a few of these ideas out in the wild, and that means I need to power through the writing part.
If I had one minute to evaluate a job interviewee, I’d put a piece of writing in front of them (either code for a developer or prose for a less technical person) and watch them type it into an editor in real-time. If they are able to do so quickly and with few errors (for some values of quick and few), they pass.
This is completely unfair, and heavily biased towards certain privileges; many otherwise excellent candidates would be missed. But as a first-order approximation, I’d be willing to wager it works more often than not.
I don’t have a ton of tech writers that I read regularly, but one that I do is Gergely Orosz. His newsletter, The Pragmatic Engineer, is incredible, full of insights and advice for folks at any point in their technical career journey.
A recent two-part installment discussed in detail the plusses and pitfalls of trying to measure developer productivity, a notoriously difficult problem in software engineering. It’s one I’ve been thinking quite a bit about recently, in an attempt to balance the business need to understand how much value we can deliver per dollar spent, without devolving into a joyless culture of mediocrity that treats its team like coding robots (which, it must be said, they’re not).
If you’re in the same position as me, I’d encourage you to subscribe to the newsletter and give the articles a read-through, but if you’re short on time, I absolutely love this simply-summarized single objective measure:
Weekly delivery of customer-appreciated value is the best accountability, the most aligned, the least distorting.
Yup, that sums it up. Other measures matter, but nothing beats screamingly happy stakeholders.
While targeted to traditional artists like writers and musicians, both have much to say about broader creative activity, within which technological workdefinitely falls.
P.S. If you’re short on time, you can find a selection of extracts from the latter book in this article: How to Fall in Love with Hard Work.
P.P.S. I almost didn’t write this post because both these books have considerably mixed reviews on Goodreads. But I decided to take their advice, post anyways, and let the reader decide. How meta!
Yesterday we held the inaugural 4S Tech meetup. In my book it was a success, with 8 attendees (including myself), and a nice mix of founders, CTOs from both small and large companies, engineers, and even a person from a venture capital firm. The conversation ranged across a number of topics: how to start a company, dealing with founder fallout, mid-sized opportunities that often go unnoticed, dealing with tech FOMO, and of course, generative AI. I know I had a good time and learned a few things, and given that everyone stayed the entire 2 hour allotted time and beyond, I’m guessing the others did too.
I’m already looking forward to doing it again next week. Can we keep the momentum going? I certainly hope so; if you’re in the area, consider joining us: Thursdays 2-4pm at Mostra Coffee in 4S Ranch.
