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.
As designers it’s our responsibility to create an environment that encourages open communication with developers, as early as possible in the design process as to avoid problems like this. We need to let them into our world, help them understand what we’re trying to achieve and allow them help us to achieve it in the most efficient way. This constant stream of communication should continue right up to the launch of what you’re building. It keeps everyone involved aligned with the vision, it helps to form a strategy best for achieving the goal and creates a friendly, open and honest culture in the workplace.
Writer Shawn Blanc on smart custom perspectives in Omnifocus:
In short, you should create your own custom perspective for “Today”. And let that list show you all the tasks which are either Due today or which are Flagged. When you are doing your daily review and scrubbing your list, don’t think about what’s due — because it should already be given a proper due date — instead, just flag the tasks you want to get done that day. Then, go to your Today perspective and now you’ve got a list of items which are both urgent (i.e. due today) and important (i.e. flagged).
Bingo. When I started using Omnifocus, virtually everything had a strict due date, which became maddening after time. When everything is “due”, it’s hard to manage what is really important. Overall, be less aggressive with real due dates unless it’s really due.