Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Space!

Space!

By | | Comments 0 Comment

Yes, there are serious logistical obstacles to overcome, concerns about space junk are real, and the cost is likely pretty crazy, but nevertheless, the idea of data centers in space is pretty darn cool. I applaud Google for the audacity of the idea as a solution to a number of problems earthbound data centers present.

Back when I was at AWS, a few times a year they ran an internal campaign based on the Think Big leadership principle. People could submit ideas to an internal tool and a handful would be selected to be pitched to senior leaders. While I had one of mine get to that stage (a fun experience), one that didn’t (but I think should have) was a suggestion to build an AWS region on the moon.

My thinking was simple: when humanity finally gets a lunar colony established, there will likely be a need for easily accessible, low latency compute. And the economic advantages to the “first mover” would be significant. I never got any feedback on the submission, but I’d be willing to wager there’s a secret team somewhere in Seattle or HQ2 working on the notion, especially given the increasing requirements of AI and the fascination folks like Jeff Bezos have with space (to be clear, I’m speculating; I have absolutely no knowledge of this either way).

It’s also nice to see that the idea wasn’t completely crazy if Google is considering an orbital data center, which seems just as hard (if not harder?)

Anyhow, fun things to think about. Also, if the question is “what is your dream job?” the correct answer is “astronaut.” Always.

And finally, IFKYK:

Winning Business

Winning Business

By | | Comments 0 Comment

My team just wrapped up a big proposal. I love the feeling when a month of writing and design work comes together. And it’s not just completion of the response itself that’s satisfying; it’s the culmination of all the groundwork that comes before, often a year or more of it.

Doing sales work requires a certain amount of brazen optimism that doesn’t come natural to many technologists, as we tend to be pessimists realists. To win customers’ trust (and their pocketbooks), you have to believe deeply that you are the best option for success. Deeply enough that it shows as genuine, because this kind of belief can’t be easily faked.

No, I’m not advocating for recklessly abandoning reality or straight-up lying. And yes, things are going to go wrong. We all know that. But the challenge of delivering a solution to a problem can’t solve itself. You can’t work it if you can’t win it. So yeah, you gotta first figure out a way to get into the ring, and leave future problems for your future self. Trust that you’re smart enough to address them, or at least be brave enough to risk failure.

I’m reminded of a chapter from The Geek Leader’s Handbook that talked about various approaches to proving truth in the workplace. While I wasn’t thrilled with the way the book broadly framed “geeks” vs “non-geeks” as fixed categories, it’s certainly the case with many engineers I’ve worked with (myself included) that we tend to disbelieve a statement until it’s proven true, and we especially don’t want to claim a fact without ample evidence. Whereas sales folks can operate more on hunch and gut feeling, believing something is achievable even when the outcome is unsure.

No where does this show up more than in the process of scoping and then selling projects; business folks need a cost (i.e. people x time) but engineers say giving such an a priori estimate is impossible. While the latter is true in the literal sense, it has to be done regardless. Rigid thinkers like myself have to get over themselves and do the best they can.

What I’ve found to work best is to find colleagues who bring a perspective at the other end of the “it must be proven before we call it true” and “it feels true so it is true” spectrum, and partner together on sales efforts. Is that not what we partly mean when we say there’s power in diverse thinking?

It’s even more powerful when some of these colleagues have been buyers of what you’re selling, because ultimately they’re the type of person you have to convince.

Into The Deep End

Into The Deep End

By | | Comments 0 Comment

Something I appreciated about working at AWS is that consultants were not thrown to the wolves without training, the most useful of which was a series of mock customer meetings that modeled likely real-world interactions with both business and IT stakeholders.

Proverbial soft skills are difficult to teach, but they’re critically important, and this kind of simulated experience does a decent job prepping new hires for the challenges they’ll face. And framing it around an actual project might just result in useful artifacts or marketable solutions. Win win!

I’m hoping to eventually replicate this practice at my new gig, and thus wanted to capture a rough online of how I’d structure such a training. Perhaps it makes a case for my prior post?

Participants

  • Project Team (Builders)
  • Customer Team (Customers) – Proxy for a real customer
  • Coach (cannot be on either Project or Customer teams)
  • Sponsor (can be same as coach, but usually will be manager / executive)

Planning Work

(drafted by Project Team, reviewed by Coach, and approved by Sponsor)

  • Define relevance to company objectives
  • Identify participants
  • Capture project title and description
  • Identify objectives
    • Skills to be learned
    • Artifacts to be built
  • Identify dependencies / deadlines
  • Scope guardrails for level of effort
  • Template
    • Participants: (identify every role)
    • Title: (one liner)
    • Description: (should clearly connect to company objectives)
    • Expected Outcomes: (final artifacts should be listed here, but ends, not means)
    • Skills To Be Learned: (be as specific as practical, acknowledging some flexibility may be required)

Customer Meeting Guidelines

  •  All are scheduled and led by the Builders
  •  All are attended by the Builders & Customers
  •  Customer team should “play the part” (within reason)
  •  Coach and Sponsor are optional but active participation should be minimized
  • Meetings are held synchronously and are recorded

Three Phases

1.  Discover

  • Builders review pre-work document
  • Builders develop agenda and questions for discovery session
  • Coach reviews agenda and questions (can be async) and gives go-ahead for meeting
  • Builders schedule and lead discovery meeting
  • Builders capture notes and document requirements
  • Builders follow up with Customers post-meeting to gather more info as needed
  • Builders meet with coach to discuss meeting, review artifacts, and plan next steps (can be async)

2.  Design

  • Builders design architecture/approach based on discovered requirements
  • Builders capture design and a build plan in a scope document
  • Coach reviews scope document (can be async) and gives go-ahead for meeting
  • Builders schedule and lead design review meeting
  • Customers give go-ahead to proceed (or iterate with Builders until ready)
  • Builders meet with coach to discuss design meeting, review artifacts, and plan next steps (can be async)

3.  Demonstrate

  • Builders execute on the build plan
  • Builders engage Customers and Coach as needed to address blockers (can by async)
  • Coach reviews completed artifacts (can be async) and gives go-ahead for meeting
  • Builders schedule and lead demonstration meeting
  • Customers give go-ahead that build is complete (or iterate with Builders until ready)
  • Builders address feedback and deliver final artifacts to Customers
  • Builders meet with coach to discuss demo meeting, review artifacts, and capture final thoughts / next steps
Eighteen Speed Upgrade

Eighteen Speed Upgrade

By | | Comments 0 Comment

A couple of months ago, on a whim, I applied to a training fellows program. I ended up not seriously pursuing it because of an already full “day job” workload, but to be considered I had to write an argument for why I’d make a good trainer. Thought I’d post it here for posterity:

I’ve been communicating technical topics to varied audiences my entire career across a number of dimensions. As both an individual contributor and manager I have:

  • Sat alongside Air Force crew members in flight to teach them how to operate a map display I implemented
  • Designed and led classes for technical writers to teach them computing fundamentals (including complex cryptography topics) and how they relate to electronic voting systems
  • Run workshops within Amazon Web Services on my approach to passing cloud certifications (I’ve also written about that here)
  • Mentored numerous junior and mid-level developers on how to make the transition to technical leadership (see thoughts I wrote on it here)
  • Embraced “learning in public” by writing on technical topics as I explored them, for example, Know Thyself (and my blog in general)

Further, the last 5 years of my career have been in a direct consulting capacity, where I routinely interact with both business and IT leaders at the C-suite equivalent level in state and local government to show them how cloud technology can transform and improve the services they offer their residents. I’ve done this both as a leader within a large organization (AWS) and as CTO of a small organization. I have extensive recommendations on LinkedIn that back this up.

None of this experience would matter, though, if I didn’t want to see others learn and grow. I’ve worked to cultivate a joy that comes from seeing others succeed vs just enjoying what my own two hands can build, which I wrote about here.

Paved Paradise

Paved Paradise

By | | Comments 0 Comment

One of the things I tried to do when I was a manager at AWS was connect members of my team to the broader internal community. Generally I found that, when asked, most folks were willing to jump on a call and share their wisdom and perspective from a different portion of the company.

In a particularly memorable such conversation, I’d invited Becky Weiss to present at one of my team meetings. I won’t forget something she shared that day: her love for a particular AWS service, what it enabled for experimentation and learning, and how unique an opportunity it was to have it available to us, because it was internal only (a fact Corey Quinn has bemoaned).

I took it for granted at the time, which was a mistake. Sure could benefit from it now.

They Who Pass The Sentence

They Who Pass The Sentence

By | | Comments 0 Comment

That feeling when I run terraform apply in production:

Thankfully I’ve never had an outcome quite this dire, but I’ve seen databases go up in smoke, amongst other infrastructure-as-code disasters. Tread lightly!

Oh, The Places You’ll Go!

Oh, The Places You’ll Go!

By | | Comments 0 Comment

Today marks the 10th anniversary of this blog. It’s been quite the career journey since I sat down to write my first post, appropriately titled Hello World.

At that time, I was sitting in a drab cubicle in a perfectly ordinary office building, probably gingerly sipping a cup of coffee (I didn’t start drinking coffee until about that time, if you can believe it) and getting ready to start my day of rewriting a large Perl application to meet a silly set of coding standards.

At least the conference room was kinda cool

Today, I sit writing this in the Rose Reading Room of the New York Public Library, about to embark on a morning of (hopefully) focused effort to provide architectural guidance and documentation feedback on a couple projects I’m overseeing. In the afternoon, I have a project kickoff to attend, and will likely have a smattering of emails and Slack messages to respond to.

Not a half bad backdrop

Such is the life of a CTO. Gone are the days of 9-5 coding. Little did I know back when I started writing here (let alone 25 years ago when I was earning my computer science degree) where my career would be headed or what it would entail on a day-to-day basis. But that’s pretty normal it seems.

If you’re here, thanks for reading. I hope to keep doing it for another 10 years. But for now, time to get back to the day job.

2 + 2 = 4

2 + 2 = 4

By | | Comments 0 Comment

I talk often about Conway’s Law, both here and in real life. I also talk often about working in the public sector. But for some reason I’ve never mentally put the two topics together and drawn the inevitable conclusion discussed in this article: Conway’s Law at Government Scale.

I’ve read Recoding America, and generally agree with the notion that a product operating model makes sense and leads to better outcomes. But here’s the thing: change comes slowly, if it comes at all, and solutions are needed now, across many domains.

I’m grateful for the work of those whose role is to reorganize and rethink government, and wish them success. But in the meantime, I see my role as working within the structures that exist now and doing the best that can be done. Projects can succeed, even with constraints.