Product Engineering and Learning Leadership, currently in CivicTech

Engineering as a consultant

I asked on #randsleadershipslack about some issues I'm having giving my direct report good direction as we both ramp up on a new company, new way of working, and new project. Carter Baxter sent me a link to this guide (that he wrote!) for 18F:

18F guide to consulting engineering

Consulting organizations need consulting engineers. These are people who can straddle the line between strategy and engineering, and who can bring their software engineering experience to bear on understanding and solving a broad range of partner problems. They’re not “developers who consult;” they’re “consultants who code” — people who can team up with with, coach, and mentor their partners.

I'm definitely going to be digging into this some more, but I loved the bit above, and this:

You can also be highly effective bolstering the qualitative data being gathered through research and user interviews. Most engineers tend to be very good a pattern-spotting, finding the sticky piece(s) in large systems, and analyzing available data and visualizing how things fit together. These are all highly valuable skills in a path analysis team.

Engineering as a consultant

Impostering

Have you ever had that “I’m in over my head, and they are going to find out” feeling? Or maybe felt out of your depth? Like you guessed or BS’ed your way out of a situation? Or like you don’t belong and have only made it this far by sheer luck? Do you ever feel like a phony or a fraud, petrified that, at any time, someone was going to call you on it?

Ashley Jannsen, via the Rands Leadership Slack.

Work with Care

I started this site as Navalogue, intending to be a blog about my personal journey starting a new role at Nava. I decided though that I wanted to be able to separate the site from that specific context -- as well as avoid potential conflicts -- so I've re-named and re- branded (before properly launching... does one "launch" blogs these days?) as Work with Care.

Read more on the about page 😁

Work with Care

The Importance of Community

I was diagnosed with ADHD a few years ago. This came as no surprise to anyone that knows me, but was a bit of a surprise to me. I grew up with 2 family members who were high on the "-hyper" scale, so my inattentive ADHD slipped under the radar and left me feeling unseen, misunderstood, and convinced I was just bad at life.

When I finally got my diagnosis, I knew I needed help -- and went looking for a community where I could connect with other folks who understood me, could see me, and could speak to the things I was learning about myself. I found a great community on Discord, and spent a year or more connecting to these people who got me at a deep level. We shared stories, memes, advice, frustrations, and tips on navigating the world as neurodivergent people.

While our society here in the US is loudly individualistic, the only places I've found the connection and meaning I need is in community and the relationships formed there.

My Next Community

Starting a new role is scary, starting my first supervisory role even more so. I've been doing a lot of reading (some of which I've started posting here), but I realized that I was going to need a community beyond the 4 walls of my home, and beyond my virtual "office" I would inhabit for work.

So I bit the bullet and reached out to join Rands' Leadership Slack and I'm already picking up tips and resources on topics like learning to lead with ADHD (very relevant) and writing about your work ("1. write, 2. all the time, 3. go to 1.") and I'm sure I'll have plenty more to share as time goes on.

Project vs Product Focus in Software Projects

When I had applied to Nava, I was chatting with a friend who has worked in #govtech, and he described traditional government contracting as "service and staffing"-focused, and newer organizations like 18F and Nava (formed in the last decade or so) as "product" companies. I didn't quite follow the distinction, and reached out to my circle of people on Mastodon for their thoughts:

I've been interested in for a while now, but only recently had someone describe previous structures of government contracting as "services"-oriented vs modernization efforts from the last decade (as seen in work by 18F, Nava, and others) as "product"-oriented.

Anyone got links or reading material on the difference?

Carter Baxter kindly responded:

@sivy I think what you're looking for is the difference between project (time-limited, with an end date to construction, like a building) and product thinking (iterative and ongoing as long as there are user needs). IIRC, the 18F Derisking guide talks about it a fair bit about it. This is also a nice guide from a quick search: johnfarrier.com/projects-vs-pr

That post by John Farrier is super-helpful, and contains this succinct gem early on:

On the other hand, a “software product” is an outcome of one or more software projects characterized by its ongoing lifecycle, market focus, and continual evolution to meet customer needs and adapt to market changes.

Thanks Carter, I'm reading this now, and have the 18F Derisking Guide queued up as well.

API Patterns for Microservices

Some of the patterns on api-patterns.org were familiar to me from past projects, but some weren't. Going to spend some time (eventually) reading up on these.

API Patterns for Microservices

Credit where due

Simon Willison's TIL on building a blog in Django formed the heart of this quickly-built site.

Bookmark: How to Rands

How to Rands -- one of Michael Lopp's posts on how he works and likes to work with others. I found it super, super helpful and want to write something like it for myself.

Reading: Rands in Repose Again

I've rediscovered Michael Lopp's Rands in Repose blog again. I read his writing for many years, then just... didn't. But I always enjoyed it and learned something, so here I am again (I'll follow up with particular posts or bits I like).

Reading: Radical Candor by Kim Scott

Radical Candor was recommended to me recently. I'm not usually a person to read management books, but I picked it up and started high-lighting my way through the preface, introduction, how-to-use-this-book... and am finally working on Chapter 1.

It's interesting so far, and I can see how 1. it could be misinterpreted as enabled assholes, and 2. how privilege and diversity really need to seriously be considered while reading the book.

Reading: Radical Candor by Kim Scott

Joining Nava

Aug 1 of this year, I was laid off from YouGov -- see that post for more on the work I got to do while there.

Happily, October 28th I start a new role at Nava. As I wrote on LinkedIn:

Nava's mission to bring people-centered, modern solutions to federal, state, and local governments really connects with my career-long obsession with discovering and meeting users' real needs through technology, design, and communication. The organizations Nava helps are often serving some of our nation's most vulnerable people, and I'm really excited to be connecting my passion to their (now Our!) mission.

So... life change means writing a new blog, right?

Steve, you say, don't you mean blog post?

Nope, new blog (built on Django this time).