Jud – Page 7 – Making Of Things

Put Aside The Ranger

By Jud | November 4, 2023 | Comments 0 Comment

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.

Give And Ye Shall Receive

By Jud | November 3, 2023 | Comments 0 Comment

Open rebuke is better than secret love. Faithful are the wounds of a friend.

We’re in the midst of performance review season, a process I enjoy. Really! Of course performance conversations can happen throughout the year, but there’s something especially valuable about a concentrated time of reflection and intense discussion. Describing strengths, celebrating successes, identifying growth opportunities, rooting out behaviors that are holding someone back; these are all reasons I became a manager in the first place.

It isn’t just a manager’s job, though. It’s incumbent on us all to both be seeking feedback on ourselves (especially critical feedback), and to give feedback to others. The responsibility of Radical Candor applies to everyone.

This responsibility can feel like a chore, if not a terrible annoyance. Pointing out shortcomings or negative behaviors in colleagues is uncomfortable at best, and if not done with grace and from a foundation of trust, can be damaging and career limiting. But when the feedback is honest, timely, actionable, and includes both positives and critiques, it is a great gift to the receiver. An act of love, even. We don’t use that word often in the workplace, and that’s unfortunate. Genuine human connection is the foundation of anything worth doing. It’s good for you, it’s good for your colleagues, and it’s also good business.

If you don’t know where to begin giving feedback, I recommend the SBI framework for guidance. And no matter if you discuss in person or provide in writing, you should give your feedback some thought ahead of time (and maybe take a few notes). I promise that it gets easier the more experiences you have giving it, though it will always be an emotional process, and that’s a good thing.

Keep It Secret, Keep It Safe

By Jud | October 27, 2023 | Comments 0 Comment

AWS recently announced that blocking public access to published AMIs will be enabled by default. This is good news, as it’s an easy way to accidentally leak sensitive data. When I first started using GovCloud (2015 maybe?) I remember stumbling into a set of AMIs that, based on their names alone, clearly weren’t intended to be shared. Thankfully a quick note to AWS support and the offending party squared things away post haste, though I’ll never know if damage had already been done.

Horror stories are easily found online of the easiest way to make this mistake: turning on public access to an S3 bucket. Thankfully AWS has made taking this step difficult; in our internal accounts, in fact, without getting prior approval, creating a bucket with public access would get you a Sev-2 page in about 15 minutes. Unfun.

Which is why I found it so surprising to discover that in GCP, the only way I can tell to host a static website behind a CDN is to make the backing cloud storage bucket public. I mean, I recognize by definition it’s okay for the data to be Internet-accessible, but it meant turning off the “don’t allow public cloud storage” block project-wide, which seems a bad idea. Bad enough that the moment I hit that button I got a security warning via email. Am I missing something here? Would love to know if there’s a better way.

In any case, it’s going to be an adventure learning all these subtle differences as I broaden my cloud experience. Passing certifications is nice, but it’s no substitute for kicking the tires.

(Editor’s Note: I’m chuckling to myself as I add Amazon LP tags to a post that’s partly about GCP. Those things are burned into my brain forever).

Clear Eyes, Full Hearts

By Jud | October 25, 2023 | Comments 1 comment

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.

Cerberus

By Jud | October 15, 2023 | Comments 1 comment

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.

Like Tears In Rain

By Jud | October 8, 2023 | Comments 1 comment

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!

Terminus

By Jud | October 5, 2023 | Comments 0 Comment

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.

Raise Your Ebenezer

By Jud | September 28, 2023 | Comments 0 Comment

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.

Happy documenting my friends!

School’s In Session

By Jud | September 27, 2023 | Comments 0 Comment

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.

Forth Eorlingas

By Jud | September 23, 2023 | Comments 0 Comment

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.