We make successful products for our clients by maintaining flexibility in our process, folding in what we discover and learn as we build. We make projects successful for our clients by delivering consistently, on-time and on-budget. We can only deliver predictably if we’re good at helping clients set a responsible budget in the first place.
Software is never finished, in the sense that a bridge is finished. Besides maintenance, like a bridge, there are always more features that could be added, interfaces to polish, workflow to simplify or extend, integrations to be made, etc. For this reason, it’s hard to be sure, at the start of a project, exactly what the right thing to build is. This poses challenges for determining the cost of a custom software project.
Software and budgeting
The nature of software product development should heavily influence budgeting. Projects which are strongly undercapitalized are nothing but a waste of money, and a recipe for disappointment and anger. Setting the budget before starting the project—something that’s almost always necessary—should take into consideration the fact that you can’t know everything at this point in time. Budgeting happens at the point of maximum ignorance.
In sixteen years of working with clients, I’ve never met one who had more money than ideas. Of course not all ideas are equally valuable. Our role is to help create the best possible software application, constrained by a responsibly set budget.
Budgeting for software development needs to take the nature of custom software into consideration and set everyone—the project, the team, and the client—up for success.Read more »
It seems an inevitable part of the human condition that we hurt each others feelings, confuse our friends and colleagues, anger or worry people close to us. I believe most of the time this is unintended and inadvertent. Regardless of intent, these feelings, if unresolved, can do real damage. My company, as a group of people who work closely together, care about each other, and build value based on trust, wanted to try something to mitigate the damage such feelings can cause.
First, we gave these negative feelings a name. FUDA (we say “foo-da”) stands for Fear, Uncertainty, Doubt and Anger. We have an agreement about FUDA at Atomic Object. It’s a shared understanding you buy into as an Atom. It’s partially a policy, in the sense that it defines expected actions by employees. But it feels to me more like a collective agreement.
Atomic Object’s agreement on FUDA has three aspects:
- Everyone experiences feelings of FUDA from time to time.
- Everyone is expected to actively work to resolve their FUDA.
- If you observe FUDA in a colleague, you should try to help them resolve it.
1. FUDA is inevitable
Feelings of FUDA are part of being human. They are normal, expected, and inevitable. It’s not bad or wrong to have these feelings. What is bad, both for the individual and the company, is to cherish, nurture and hold onto your FUDA.Read more »
I recently spent 24 hours with four of our newest developers, all very recent grads. We ended up calling the time we spent together a Founder’s Retreat. While the intention was that my young colleagues would learn about the company, I too learned some interesting things. We also had a lot of fun together. Sharing culture, history, and values this way is an investment I believe will help us reach our vision of a 100 year old company.
When the idea of an overnight trip with employees younger than my own kids was first suggested to me, I said “sure”, but in truth I wasn’t so sure. Even after brainstorming topics and planning a rough agenda, I had a nagging worry that we might be so far apart in age, interests, and tastes that we’d all find the experience feeling forced or awkward.
Rachael Miller wrote a very nice post describing the retreat, and sharing the perspective of the Cell Zero participants. (Cell Zero is the first cohort of our Atomic Accelerator program for new grads.) Telling stories about Atomic’s early days; doing adventurous things with walls and ropes; team dinner making; quick marches up and down ski hills; watching the sunset—we had fun sharing and learning together.Read more »
One of the things I’ve learned about helping people work well together in business is the power of naming your values, ideals, and expectations. Wielding this tool to best effect is a prime responsibility of company leadership. I’ll give you three examples of ways we do this at Atomic: our company values, a framework for negative thoughts, and a framework for feedback.
Atomic has six value mantras that stand for behaviors and attitudes we hold each other and the company to. We use them internally all the time:
- Give a Shit
- Think Long Term
- Own It
- Share the Pain
- Teach and Learn
- Act Transparently
You can read a lot more about them on our website, since we feel it’s good for clients and prospective employees to know what we care about.
FUDA is a framework of behavior and communication we created ourselves. Pronounced “foo-da” or “fuh-da” (depending on who you ask), it stands for Fear, Uncertainty, Doubt, and Anger. Our company stance on FUDA has three aspects:
- Everyone experiences feelings of FUDA from time to time.
- You’re expected to actively seek to resolve your FUDA.
- If you observe FUDA in a colleague, you should try to help them resolve it.
Giving negative feelings a name, and codifying the responsibilities around them, created a framework for all of us to work better together. I hear people say things like, “I have some FUDA around this topic. Can you help me understand why we made this decision?” And: “Joe seems to be carrying some FUDA about Sally. I’m going to facilitate a meeting with them both.” And: “This is likely to generate FUDA. What can we share to head those feelings off?”
The third example of giving a name to a framework for interacting with each other is not our invention. Kim Scott created a simple model to distinguish between when you’re being a good boss and when you’re being a bad boss. She calls it Radical Candor.
In a nutshell, Radical Candor is the intersection between caring personally for an employee, and being direct with ways they can improve themselves. The most common alternative to Radical Candor is Ruinous Empathy, when you care personally, but avoid giving the difficult feedback an employee needs to learn and grow.
Introducing the idea of Radical Candor, and having a name to refer to behavior we value and aspire to, has helped us talk about the tricky subject of what a good boss (or peer) is and does, and has created a framework for useful feedback that benefits the company through the growth of individual Atoms.
I hear things like, “An RC moment”, and “I gave her feedback after the talk”, and “In the spirit of Radical Candor, I think you set a bad precedent when you…” I constructed a personal Radical Candor radiator on my laptop, with stars representing when I gave valuable feedback, and a happy face representing when I received it.
What’s in a name?
Eve Ensler used the power of naming things to save herself and start a world-wide movement to end violence against women. Examples of the power of language and the importance of the names we give things abound.
While they may seem silly at first glance, our value mantras, FUDA and Radical Candor remind us who we aspire to be, what we care about, and how we’re committed to behaving towards each other. They give us frameworks to talk about important matters, and help in living up to our ideals. Identifying what’s important and valuable, and using the power of language to promote and establish those ideas, is one of a leader’s most important responsibilities.
In the late 1990s, when Kent Beck included “40 hour work week” in the original 13 practices of Extreme Programming, it was in the context of an industry that co-opted the term “death march”. Software development practices at the time were in a bad state: surprises around schedule were common (and almost always negative) because of deferred integration, poor code quality, unrealistic approaches to requirements, and a (false) belief that doing all the planning and design upfront was both necessary and sufficient.
The original idea behind Beck’s practice was to plan to work only 40 hours per week, and if you had to work overtime, be sure not to do so two weeks in a row. The practice came to be understood by some as “never work more than 40 hours”. It was eventually re-named “sustainable pace” as a more nuanced understanding of this important practice became common.
Today, the target of a 40-hour work week represents a progressive standard compared to the status quo in the United States. According to a Gallup poll, the average work week in the US is about 47 hours. I suspect the average for software development is higher than the Gallup poll found. A recent article in the Wall Street Journal describes the 40-hour work week as a radical idea for improving employee productivity and a recruiting advantage.
Benefits of sustainable pace
Sustainable pace has been a key part of our culture from the very beginning of the company. We see many benefits:
- It enables our makers to work productively and creatively for our clients. To no one’s surprise, studies show that working a lot of extra hours has a mean bite from the law of diminishing returns.
- While I believe work is a vital part of leading a fulfilled life, it’s not the only part. We work a sustainable pace so that we have plenty of time to be good spouses, parents, volunteers, and friends, and be happier people as a result.
- People who don’t work a sustainable pace are grumpy, un-collaborative, and no fun.
- Software creation is a profession and a craft. Our disciplines take years to master and constant work to grow and stay relevant. Working a sustainable pace leaves plenty of time for the professional development we all need to be doing.
- A sustainable pace means you’re prepared for those times when you have to work extra for a client or the company; it ensures you have those reserves.
A measure of success
Sustainable pace is one of the rewards that comes from having a predictable process. Predictability comes from skillful makers who:
- know what to build,
- manage code complexity,
- do good task decomposition and tracking,
- test all the way through a project,
- integrate continuously,
- validate with end users,
- communicate effectively with clients, and
- are disciplined about the meaning of “done”.
You can look at the ability to achieve sustainable pace as an indicator of successful projects. To the contrary, trying to fix a bad process, poor practices, or lack of skill and discipline by consistently working lots of extra hours is neither effective nor admirable.
Show me the data
Atomic has very accurate data for the activities of everyone in the company. We’ve always paid everyone on an hourly basis, and we invoice our clients by the hour so we can track against a project budget. Since our time tracking tool generates both invoices and payroll, we’re really disciplined about keeping track of our time.
Average work week
The graph below shows the average hours worked per week by each Atom for the last seven years. For each year (colored line), individual weekly averages are sorted from least to most and plotted on the chart. Each small circle is one person’s yearly average work week. The lines for each year have been stretched to cover the same horizontal distance, even though the number of full-time employees varies substantially from 2009 (15) to 2014 (35).
This unconventional use of a line graph helps visualize several things I found interesting and which are described below.
It’s interesting to note that the company average went up nearly 6% from 2009 to 2014. I’m happy to see that leveling off. On the low end of the scale, it’s good to see that the number of people not working full-time (2080 hours/year) has decreased over time. Clear communication around that basic expectation probably accounts for some of the increase in the average since 2009.
The high end of the scale shows a pattern I’ve observed over time: as your seniority, responsibilities, and past client relationships grow, you tend to work more hours. I’m happy that the upper end of our scale is still in the upper 40s, though that’s something we’ve learned we need to watch closely. We’ve recognized maintenance of prior projects as a source of stress for senior developers, and a challenge to our current structure.
In fifteen years, I’ve never observed our hourly pay motivating people to work beyond sustainable pace. And I’m glad that those putting in extra hours are compensated for that time. With the more common salary approach I suspect the 20% difference between the low end and the high end of average work week exists, but isn’t directly or fairly compensated.
Distribution of work week hours
Averages can hide a lot. Knowing that the 2015 weekly average across the company was 42.7 hours is nice, but doesn’t tell me how often people are working much more than that. The histogram below shows the distribution of weekly working hours for all full-time Atoms in 2015.
The distribution of weekly hours reflects both the week-by-week flexibility we offer employees, and the variability of client and company needs. In return for flexibility, we ask Atoms to put in extra time when a client or the company needs it. Being able to accommodate those needs is one reason being diligent about sustainable pace is important.
While the number of hours per week that is sustainable varies by individuals, this data is useful as a possible indicator of structural problems that can lead to burnout. Employees with the best of intentions and strong sense of responsibility may be trying to out-work what amounts to a structural challenge that consistently overwhelms their work day. It concerns me that 9% of the weeks worked last year exceeded 50 hours.
The advantages of maintaining a sustainable pace of work for all employees are clear. In the long-run, clients win, families win, employees win, and the company wins. Measuring, rather than guessing, and detecting potential structure problems, is one of the many valuable insights that accurate tracking of time provides my company.
I’m the founder of a company that I hope thrives well beyond my lifetime. Part of my job these days, fifteen years from our creation, is to pay close attention to company culture: what it is, how we communicate it, how we transmit it, and how we might usefully adapt it. When I recognized the need for some maintenance of our value mantras, I took it to the people who own them. I was both surprised and happy with what happened.
What’s a value mantra?
We use value mantras as a short-hand notation for what we care about and expect from each other and the company. Those things are a big part of our culture. Until recently we had five value mantras:
- Give a shit
- Teach and learn
- Own it
- Share the pain
- Act transparently
From the original four (“Act transparently” was added in 2012), our values are aspects of our culture that I observed and named. They existed many years before I named them. For example, I didn’t decide one day that I wanted a company where people cared about each other and their work, and where they valued learning, and thus told everyone to “give a shit” and “teach and learn.” I just noticed that these things were true and codified them in our mantras. We use our values frequently; having short, pithy names for them is quite handy. Read more »
We’ve been working for several years to improve the gender balance at Atomic Object, largely because we held “Diversity is good” to be self-evident. But recently I decided it was important to think through this belief and better understand it. Here’s why I think diversity is valuable, and makes my company stronger.
Diversity Means Liberty
Rather than an unquestioned end unto itself, I find it useful to think about diversity as an indicator of something valuable. Diversity in a profession is a measure of society’s success in achieving liberty. It indicates opportunity that can be capitalized on by anyone, regardless of gender, race, country of origin, age, etc.
Presuming there is no profession that is uninteresting to or unachievable by any particular group of people, then a diverse workforce is an indicator that there are no artificial barriers in place in the profession. The “natural” diversity of any given profession, absent of obstacles, is debatable. I believe all professions are attainable and of at least some interest to all groups of people. Increased liberty creates flexibility, greater productivity, and less waste from untapped talent. I think about this as labor market optimization.
In a liberal (in the British sense) society we place a value on an individual’s ability to make their own choices. This concept is famously noted in our Declaration of Independence as “Life, Liberty and the pursuit of Happiness”. Given how much of our lives we spend working, it’s hard to imagine achieving this goal with artificial constraints on career choice. A profession with very little diversity is a likely indicator of limits on liberty. Read more »
Atomic Object joined the ACLU’s Michigan Competitive Workforce Coalition following a couple of eye-opening experiences I had in 2015. The MCWC is organized around the goal of updating Michigan’s Elliott-Larsen Civil Rights Act to include sexual orientation and gender identity. What I learned was that on this issue, it’s not enough to be a company that doesn’t discriminate, and which welcomes and treats everyone respectfully. We’ve been all those things from our founding in 2001. What we haven’t done well in the past is to be explicit and clear about our values and behaviors.
The Atom We Nearly Never Knew
Months after a talented young developer joined Atomic, they shared the fact that as a candidate looking in from the outside, they weren’t at all sure they could be themselves as an employee and not need to hide their sexual orientation. They contrasted this very positively with how things turned out once they were actually an Atom. The fact that they were comfortable as an employee, and didn’t have to waste time and energy masking who they were as a person, isn’t at all surprising to me. The eye-opener was that they couldn’t be sure about this from the outside looking in, even after having gone through our extensive interview process and having read our diversity statement.
In a world of talent scarcity—certainly the one software design and development companies live in currently—it would be foolish to not accommodate a proven employee’s request to move to a part-time schedule if the job allows it.
I think the value equation for part-time knowledge workers is usually favorable toward the company. Presuming part-time work is desired by an employee, this should be a win-win situation. Read more »
I recently avoided a mistake I’ve made plenty of times in the past. The mistake I could easily have made was in how I reacted to an internal screwup. I attribute my better reaction to an experience I’d had a few hours before learning of the mistake we made.
Our marketing manager came up to me, a little upset, and told me we’d had an article published on one of our projects that inaccurately reported the membership of the team, excluding not only all of the designers, but both women who’d worked on the project. She’d heard from one of the designers who was justifiably irritated. Our marketing manager admitted she’d been busy, had handed the reporter off to a developer on the project, then moved on to other stuff she was trying to finish. Read more »