Author: Jason Porritt

Smart Strategies for the End of a Project

We talk a lot about what we do before and during projects: how research, design, and planning (RDP) activities can shape a well-informed project plan, how we can manage a project’s scope to meet a budget, and how we can make delivery to production work for our clients. But what about when that’s all done? What’s important when a project is over? Below are a few tasks that should be considered as a project wraps up. Read more on Smart Strategies for the End of a Project…

7 Tips for a Joyful Return to a Software Project

We start a lot of new projects at Atomic, but we also spend a lot of time working with our clients to continue adding new features to software products that we built some time in the past. I recently returned to a project that I spent nearly two years building after eighteen months away from it, and I wanted to share a few things that can make jumping into a past project a joy.
Read more on 7 Tips for a Joyful Return to a Software Project…

How Do We Know Our Software Works?

Yes, really. How do we know that software we build actually works? How can we know that it works? What observations and actions contribute to a holistic, fact-based, confident understanding that software I just helped build does what it was intended to?

I want you to feel a little anxiety about that question. Forget for a moment that you’re working with smart people who participate in practices that help bolster your confidence. Instead, dwell on the frightening reality that people are flawed and make mistakes on a regular basis. Human communication is always incomplete, good intentions don’t guarantee good results, and it can be genuinely hard to build a broadly-shared mental model about how a problem should be solved. How do we have any confidence that our software works?!
Read more on How Do We Know Our Software Works?…

Technology: More than a Constraint for User-Centered Design

User-centered design that ignores the technical landscape is folly. The designs may tell compelling stories and cause stakeholders to pull out their checkbooks. They may make everyone feel like all those dot voting exercises were time well-spent. But without a healthy view of technology to ground them, they’re nothing but fever dreams drawn in the swirling brainstorm vapors still choking the air in your project room. Read more on Technology: More than a Constraint for User-Centered Design…

Avoiding Bias in our Job Interviews with Scripts & Personas

I hate the idea that we might miss hiring an awesome teammate at Atomic Object — especially if we lose the opportunity for a stupid reason like an unintentional bias in our interview process. Several of us recently read Thomas Ptacek’s post about fixing broken developer interviews, which has spurred our efforts to improve our ability to gather consistent, concrete, unbiased information about candidates throughout Atomic’s hiring process.

As a result, we’ve added two things to our toolbox that we believe are helping avoid harmful bias in our interview process: an interview script, and personas. Read more on Avoiding Bias in our Job Interviews with Scripts & Personas…

Information Architecture: A Whole-Team Discipline

Information Architecture has exceptionally broad-reaching consequences. It affects the software we build, the business model behind it, and the way people interact on all sides of a product. No project can afford to leave team members out of the IA circle.

Fortunately, it can be very approachable.
Read more on Information Architecture: A Whole-Team Discipline…

How to Ace the Non-Technical Part of an Atomic Interview

When we’re hiring at Atomic, we’re obviously looking for people who have maker skills as a software developer or a designer. But that’s just the start. We consider your fit with our company’s consultant culture and values at least as much as your technical skills.

Here are seven things you can do to win our confidence during the interview process.
Read more on How to Ace the Non-Technical Part of an Atomic Interview…

Fighting Project Decision Fatigue with Policy

When it comes to matters of policy, our goal at Atomic has always been to provide “just enough” to avoid unexpected conflicts or confusion. We rely strongly on personal responsibility, transparency, and our self-organizing nature to bring order and direction to our projects and internal company workings.

Atoms enjoy the freedom this brings—we share the burden of learning and making things work the way they should without being bound by miles of policy red tape. We have to live out our “Own It” value mantra.

However, there is a potential cost for this freedom: decision fatigue. Read more on Fighting Project Decision Fatigue with Policy…

First Contact to Offer – Atomic’s Developer Interview Process

Much like working with our clients to design and build an application, putting together an interview process involves balancing competing constraints. We want plenty of time to get to know candidates, but keep time investment within reasonable bounds for everyone involved. We set up defined tasks and scenarios but also want to leave room for open-ended conversations and work.

Read more on First Contact to Offer – Atomic’s Developer Interview Process…