Engineering managers get a high quantity and variety of inbound requests. At any point, you can be on the hook for the status of individual projects, career growth questions, support issues, and more. Questions and expected follow-ups can pop up in many contexts, be it 1:1s with reports, standups, or cross functional meetings. Managerial triage and delegation are commonplace that makes handling asks from all sides especially important.
However, none of this was apparent to me in my first engineering management role. Even when I caught up with reality, I naively expected to handle the increased load without issue. I organized my to dos in a trusted app setup. I could juggle taking detailed notes while simultaneously participating in meetings with ease. But at some point, a few months in as my number of reports increased and work volume spiked my system started to break down. I was dropping follow-ups. I would bury away action items in notes I would forget to review later. It was at that point I realized I had to adjust my workflow. One of the biggest lifts came from adding ticklers to my routine.
I define a tickler as a reminder of anything that I need to review on a future date. For example, a Slack thread where I’m waiting for a response. Or a good idea that comes up in a meeting that I don’t have time to process now but potentially will later. I generally structure ticklers in the form of simple questions:
Tot, a scratchpad app for macOS and iOS, has graduated from a side experiment to an essential part of my workflow in a matter of weeks. I highly recommend giving the app a try on Mac (it’s free), and if the design works for you, buy it on iOS.
Admittedly, when I first saw Tot pop up on social media and sites like MacStories, I was skeptical. There are already hundreds of note taking apps available on the App Store. Given several options like Bear and iA Writer nail the basics so thoroughly, with strong aesthetic design and years of iteration, it’s hard to see how any new competitor can stand out. But I’ve always had longstanding respect for The Iconfactory in terms of their attention to visual design. $20 later (more on that price in a bit), equipped with Tot’s iOS and Mac apps, I dove in to give it a try.
Engineers tend to dread meetings, and for good reason: bad ones can be soul crushing. Not only are bad meetings a waste of everyone’s time, it can make the meeting’s organizers look incompetent. Paradoxically, as engineers grow in their career, meetings grow more important. You attend and organize more of them, and as a senior voice in the room, your words can have an outsized impact.
Meetings get a bad rap. Well run ones are an efficiency multiplier, leaving people energized and productive, and a team more cohesive. The right meeting can even turn around an otherwise doomed project.
One of the easiest ways to improve the quality of your meetings is to prepare for them. Without preparation, you’re fighting an uphill battle against context switching; one minute you’re coding and the next you’re in “meeting mode” without clear direction.
Capturing and organizing tasks is a highly personal exercise. Some turn to simple tools like pen and paper or a Google Doc. Others prefer complex systems with filtering, contexts, and customization like Omnifocus.
After trying several options, I’ve found a sweet spot between these extremes with Todoist. It provides some structure for work, but remains flexible for whatever flow I’m managing. That said, the basics I outline here should work with most task management systems.
An archive from my earlier webinar hosted by InVision. I cover techniques on equipping your tech team for responsive web design and native design across mobile devices. The techniques are admittedly derived heavily from Agile methodology (daily standups, project self assignment) but I’m a true believer they can boost productivity across many team structures.
Andy Hunt, one of Agile Manifesto’s original authors, wrote a controversial post recently. He makes several arguments about Agile’s failings, and this one especially resonated with me:
Since agile methods conveniently provide some concrete practices to start with, new teams latch on to those, or part of those, and get stuck there.
I’ve seen this phenomenon firsthand. A team settles on a system as the solution to their productivity problems. They get bogged down in rules and convention, and integrate too quickly. The process stalls and dies. As Hunt argues, without flexibility, the company loses sight of their productivity goals.
I’m giving a free webinar over at InVision a week from today (6/9) at 3pm EST. It’s all about building responsive teams, teams well equipped for responsive web design and native design on multiple, changing devices. No prerequisites – if you’re a designer, developer, project manager, or practically anyone working in or around a tech team, hopefully you’ll find something of interest. Just register in advance and you’ll be able to stream the video and audio live. (I expect an archive of the talk will be up later as well for those who can’t make it.)
I use ColorSnapper most days to select and compare colors on web sites, Sketch files, and more. I’ve tried other color pickers, but this app remains my favorite. Version 2.0 adds a smarter magnifying glass, Alfred-style color export formats and other enhancements.
When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.
To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.
I’m a huge podcast fan, usually listening to several during my work day, especially when I’m cranking out code or debugging. Yet I’m also very picky – I have my favorites I listen to religiously, but rarely venture into new territory.
Yet even with that backstory, about twenty minutes into my first Design Details episode, I was hooked. It’s got solid guests that get asked a diverse set of questions. And unlike most podcasts, the show notes are time stamped and very detailed.