Andrew Crookston

Engineering Manager. 20yrs in tech. Write about engineering and entrepreneurship. Past: @spotify @instacart @lifesum 👨‍🔬 Home DJ 🎧 Swedish 🇸🇪 Ex-SF 🌉

[Andrew Crookston @acr]

Hat tip to @steipete — his "close the loop" framing kicked off the thinking for this piece.

[Andrew Crookston @acr]

Automating real work with AI agents means building loops. The agent does something, verifies it, advances. Repeat.

The interesting question is what the loop needs to include.

Most AI coding harnesses today are runners.

https://t.co/SrITgFg5Qw

[Andrew Crookston @acr]

@twostraws Very happy with my Nudient Thin Case. They look the same as yours after a year and a few drops but it's cheap(ish) to replace. Good grip and slim profile.

[Andrew Crookston @acr]

So true!

[Historic Vids @historyinmemes]

"While spacewalking | realized something, I used to think I was scared of heights but now I know I was just scared of gravity." - NASA astronaut Reid Wiseman

[Kartikay @Kartikayb77]

There is a lot fear about the progress of ai making software engineers 'irrelevant'. Especially among those in college and those just starting out in their careers. I do not share those fears. Because I am not a software engineer, I am a problem solver. A much more powerful title.

[Andrew Crookston @acr]

Agility is both ability to move fast but also the ability change direction and manoeuvre with haste. In order to do that information is needed, and that information needs to be acted on = feedback loops. @allankellynet https://t.co/87eA0HTHwO

[Andrew Crookston @acr]

@ptr So very happy for you to find yourself, and having the bravery for writing this. I know it hasn't been easy but I'm proud to be able to call you a friend. Just amazing to see all the love you're getting in the replies.

[Andrew Crookston @acr]

Agreed. In that situation. Not easy. But also a sign for leadership, bring me something to push, to be positive about!

[Sergio Pereira @SergioRocks]

CTOs and Engineering Managers are in a tough spot right now.

Just a couple years ago, you'd hire 5-10 people per quarter. Convince your best engineers to stay, despite competing offers. And negotiate salary budget increases with your CEO.

Now it's a different market:

[Andrew Crookston @acr]

Still know my ID-number by heart!

[World of Engineering @engineers_feed]

Are you this old? Ah-oh!

[Andrew Crookston @acr]

@aaditsh I pay for a digital subscription for a big Swedish newspaper. Definitely read it a few times per day.

[Andrew Crookston @acr]

@SahilBloom Form does not show in Firefox. I see some "Content-Security-Policy" and "TypeError: styleElement.sheet is null" errors in the console.

[Andrew Crookston @acr]

Just published an article about #git workflows and best practices.

https://t.co/wU8SrYGexP

Strangely, I’ve been sitting on this for four years. Maybe too scared to publish?

#developer #workflow #BestPractice #SoftwareEngineering

[Andrew Crookston @acr]

@engineers_feed $0.18 avg last month. Only 0.43kr = $0.039 for production, rest is taxes and cable fees. Although last December was about 10x that

Stockholm Sweden

[Gergely Orosz @GergelyOrosz]

This is kind of an open secret when talking with founders. It’s much easier to get people to care about the company when they meet other coworkers semi-regularly.

Of course many full-remote companies do a great job with this: it’s just far more work to do, and needs thought.

[*tess @ptr]

When I tell people we didn't use an issue tracker at Slack, I typically get one of two reactions, either "oh thank god" or "how tf did you stay organized?" Here's the thing: we were incredibly organized. Here was our system:

Use a document (and checklists) to track your work.

We used a tool called Hackpad, which Dropbox acquired and became the bones of Dropbox Paper. With Paper we could keep the product brief, designs, and engineering tasks in a single spot. This was immensely helpful for keeping everyone aligned -- there was just one place to check, and no risk of things being out of sync across multiple tools. We'd project the doc during team meetings, and the whole team worked out of this document throughout the day. (This was so effective that it motivated us to build @Balsa to implement the patterns we used at Slack.)

Use a spreadsheet to track status.

We used a simple Google Sheet, with a row for each project, the PM/EM working on it, launch date, project status (red/yellow/green), and a column for comments, which contained a weekly note on how things were going. We reviewed this spreadsheet every Monday in an all-PM/EM meeting with the CPO, CTO, and VPs of Eng and Design.

Use your issue tracker as a bug database.

Issue trackers are great at remembering, but they suck for keeping track of what's happening now. Eng tasks related to a project we were actively working on, including bugs caught in QA, were all kept in a checklist in the project document. Things we knew we weren't going to fix, or that needed to be done by other teams would go into an issue tracker we built ourselves. (We eventually migrated this to Jira.) The issue tracker was helpful for cataloguing things and giving Customer Support a place to search for known defects, but we never worked out of it for active project work.

Closing thought: Most of the time, you just need a document.

Lightweight product process is not anarchy.

As an industry we've been brainwashed for 20+ years by giants like Atlassian telling us the only way to stay organized is to use Jira (or issue trackers like it). This is outdated advice. Issue trackers are designed for a bygone era. Nowadays projects change daily or hourly as designers, engineers, and PMs adapt in real time, tweaking designs, running experiments, and incorporating feedback between research sessions. When your whole team is coordinating in Slack, chiseling tasks into your bug database slows you down and makes you less adaptable.

A doc and checklists. It's all you need. (We're building @Balsa as a builder-focused, dedicated tool for this workflow, but you can do this with Dropbox Paper, Notion, or even Word or Google Docs.)

[*tess @ptr]

We designed, built, and shipped Slack's Do Not Disturb feature in four weeks, between Thanksgiving and Christmas 2015. (We wanted it out for the holidays so folks could snooze notifications during their time off.) Here's how we pulled it off:

Know what you want to achieve.

We knew customers were increasingly unhappy with how noisy Slack's notifications could be. Especially off hours or during deep work. We knew we needed two things:
1. DND hours, for nights and weekends
2. Ad-hoc snooze ability, for meetings and deep work

Be ruthless about scope.

Nothing was bolted down, and everything was up for grabs. We cut the ability for custom snooze length -- in the first version, you had to pick your snooze duration from preset options, and they were capped at 24h. We cut weekend DND, which felt like a brutal omission. (Turns out it didn't matter as much as we thought! We didn't get back to it until 2020 -- five years later -- because it just wasn't as much of a customer priority as we expected.)

Secure stakeholder buy-in continuously.

When you're shipping fast, there's no time to wait for reviews. We invited stakeholders to our Slack channel and I kept a running changelog in our project document, with notes posted in Slack, so everyone always knew what was changing and what the finished product would look like. When we were cutting scope or tweaking designs I sent updates to Stewart directly and we incorporated his feedback straightaway.

Consolidate everything into *one* document.

To keep everyone tightly aligned, we created a canonical document somewhere between a product brief and a PRD, which also contained design documentation and the engineering task list. This document was changing daily (sometimes hourly). To keep things straight and help stakeholders stay informed, I wrote a running changelog at the top of the document, including bullets for each update and a link to the relevant section. With this doc, everyone from team members to the CEO knew where to go, knew the information was up-to-date, and could keep up without re-reading the entire doc. By the time we launched, this doc was 10+ pages long. (Long is okay! The important thing is that it's consolidated, and that people can find their way around.)

Skip the issue tracker.

This one surprised me the most: the team was adamant that we work out of a document, not an issue tracker. We didn't write user stories. There was no task breakdown in Jira. In fact, if we had done these things we never would have shipped on time, because we would have spent all our time updating our tasks as our plans changed daily. Not to mention how reluctant teams are to constantly adjust course when a detailed plan is chiseled into your issue tracker.

We did track tasks! We just did it as checklists in the doc. This made cutting scope, tweaking requirements, and catching+fixing bugs much lighter weight and helped us move at lightspeed.

Final thought:

Do Not Disturb was the first feature I worked on at Slack. The playbook I learned challenged a lot of my presumptions about building great software, and it made me a better, faster PM.

As a PM some of these pieces might be out of your control, like flexibility on scope or continuous access to stakeholders. But some of the more tactical bits are things you can do today, like letting go of your issue tracker and consolidating all your documentation into a single point of reference. (We built @balsa to reflect how we documented projects at Slack, so if this speaks to you, check it out!)

Good luck out there!

[*tess @ptr]

When it comes to PM, stored knowledge deteriorates so rapidly that you should try to create as little of it as possible.

You are probably writing too much down, at the cost of more important things like talking to customers, iterating on designs, deep diving into analytics, etc etc.

I'm not talking about skipping writing down the problem you're trying to solve when you build a feature. I'm talking about the 100s of stale Jira tickets you'll never close, the sprawling Notion, carefully organized and full of outdated documentation.

You ain't gonna need it... and it's slowing you down.

Cut the anchor. You probably just need a list of what your goals are, and a checklist of the tasks you need to complete to get there.

[Andrew Crookston @acr]

I wrote a new post on WIP limits and the value of keeping them low. https://t.co/W1Sd5jQN2q #productivity #engineering #management

[*tess @ptr]

How to prioritize a product backlog, in 9 easy steps. 🪄

Many PMs struggle with this. You don't have to.

If you have a list of ideas already, you can do it in under an hour.

1. Create a blank spreadsheet (e.g. https://t.co/qfJPiWOVeX)
2. Add column headers: "Project", "Reach", "Impact", "Confidence", "Effort", "ROI"
3. Write your ideas in the Project column
4. In the "Reach" column, guess the # of customers who will use the feature (very rough! 10? 100? 1000?)
5. In the "Impact" column, guess the % improvement on the customer's life (again, rough! tiny = 10%, medium = 100%, high = 200%, etc.)
6. In the "Confidence" column, guess the % chance you will get it right on the first try (again, very rough: closing a commonly requested feature gap = 100%, never-tried experimental idea the team is excited about = 25%, etc)
7. In the "Effort" column, write the # of person-weeks required (e.g. 2 people for 2 weeks = 4 -- this is a great spot to bring your eng mgr peer into the convo)
8. In the ROI column, calculate: Reach*Impact*Confidence/Effort
9. Sort by ROI

Boom, done.

At this point you will probably wince at some of the results -- this is your intuition telling you either:
a) there's a mistake somewhere in your estimate of reach/impact/confidence/effort
b) you are more attracted to some ideas than you should be, in light of your alternate options
c) you have large projects that could be broken down in ways that would isolate the higher ROI bits

Building a ranked backlog is easy once you know how to do it. The hard part is applying your judgment to the results, and transforming the backlog into a sequenced roadmap that factors in people's availability, need for quick wins vs. longer term investments, tech debt, refactoring, etc. Having a great ranked backlog puts you on the path.

Good luck!

[Andrew Crookston @acr]

@evernotehelps yo you just dissapeared 8 days of notes and todos. How do I get them back!?