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.
I like design teams built around collaboration and transparency with outsiders, especially engineers. Yet that openness has to be balanced against productivity. Even with formalized designer-engineer connections, I still structure meetings to give designers as much uninterrupted time as possible.
An open structure largely derives from designer/engineer ratios. Across technology, from hot startups to well established brands, designers are almost always heavily outnumbered. And given it’s a fairly young industry, design is often underrepresented in company leadership. Granted, with “design thinking” surging in popularity, that’s changing. But across many companies, it’s still an uphill battle. If you box your design team in, you’ll stack the deck against you.
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.
Fog Creek software has been running a series of video interviews about software engineering. They cover hiring, firing, culture, and much more. Their most recent post with Kate Heddleston is particularly strong. Onboarding, from my experience, is a greatly underrated topic. It makes a huge impression on new staff, and a wrong move here can set the wrong tone for an extended period.
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.
Very solid design (with an unusual color palette) to a free 5-week email course. As author Jarrod Drysdale writes:
The Tiny Designer is a course about the big (monumental, even) design that we can make together. Non-designers will learn the important parts of design, so that you can understand what designers do, achieve your goals, and better communicate your ideas. Designers: learn to teach and guide others through your design process so they’ll better appreciate what you do.
I’ve written previously (and given a webinar) about team relationships and how important collaboration is. This course looks like it could share some helpful, related advice.
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.)
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 don’t buy the story that you’ve either got a natural knack for design, or you’re totally hopeless. And yet I hear designers describe the programmers they work with as “design blind” with a slimy sense of pity; the insidious implication being that designers are not made, they are born — that some special children are ordained by the stars at birth into the sacred order of designers, and all others are doomed to brutish, unenlightened lives of “design blindness”.