Atomic Object launched a new website back in November. While I believe the end result is very good, the time and effort it required surprised me. In the process I think I figured out why it is difficult to market companies like Atomic, and why it’s often done poorly.

I’ve come up with a HierArchy of Relative Difficulty (HARD). Where your company exists on the HARD scale determines how much time, money and expertise you’ll need to effectively market, or conversely, how likely you are to be marketing your company poorly.

Not HARD

No slight on the widget makers of the world, but their marketing challenge is pretty straightforward. The picture below illustrates the situation. Companies that make a concrete product have a straightforward marketing challenge. Describing the product isn’t difficult. It has known features, materials, quality, costs, and benefits of use. The marketing can be directed to the person who will both buy and use the product.

Figure 1. Marketing a widget

HARDer

A service is inherently more abstract than a product. Service companies therefore have a tougher job in telling their story. The features and benefits of their service are less concrete. Pricing may be more complicated, and the relationship with the customer is more intimate and less transactional. Quality is more subjective. There are no materials.

Figure 2. Marketing a service

HARDer still

When your company offers a service that you sell to your customers to create something another group of people actually use, you’ve taken a big step up in HARD.

Figure 3. Marketing a service to create a product for your customer’s customer

Innovation service firms like Atomic are in this category. What we sell—our expertise and ability to create software products—is inherently abstract. The multi-party nature of what we do raises a lot of big questions:

• Which story you should be telling: the end user’s, the client’s, or your own? (All of them, I believe.)


• How do potential clients search for your service: by what they want, or by the practices and process that creates what they want? (Both, we find.)


• How do you describe what your service will cost? (Depends.)


• Can your service be marketed in isolation from the people who provide it? (We don’t believe so.)


• Do your clients care as much as you do about your super awesome, highly refined, carefully crafted practices and process? (Probably not.)

Why vs How and What

All of these factors complicate your marketing strategy and messaging. I believe they also explain why so many innovation service companies end up telling the story of “What” and “How”, but not “Why”.

As an example of this, consider Atomic Object. Our “What” is easy to describe:

We design and develop custom software products.

And all of us who are successful with an innovation services firm can describe in gory detail “How” we go about doing this:

Pair programming
Ethnographic research and contextual inquiry
Decomposition and buffered estimation
Mood boards
Spikes
TDD
Design patterns
Iterations
etc, etc, etc.

When you’re faced with crafting a message, organizing it into an information architecture, and creating a fresh new visual and interaction design, this all gets real—and really complicated. Thinking it through in order to ultimately wrestle our marketing monster down to a new website caused us to crystalize our company’s “Why”:

Atomic Object

“To pursue success for our clients — or die trying.”

Communicating that mission statement in our new website took us to a very different end result than if we’d gone down the “what/how” road.

HARDest of all

The pinnacle of my HARD marketing scale is a challenge that a few of Atomic’s clients have posed. In a few cases, we’ve sold our software product development expertise to our client to create a framework for their clients to offer a service to their users. This is a complicated story to tell, and therefore a very difficult service to market.

Figure 4. Marketing an abstract service to clients creating an abstract service to sell their customers and be used by our customer’s customer’s end user.

HARD but useful

For innovation services firms, knowing about the HARD scale does not unfortunately make the marketing challenge any easier to resolve. But it might be helpful to figure out what to expect, and why these projects can be so difficult.

The post What’s so HARD about Marketing a Software Development Company? appeared first on Great Not Big.

      

Related Stories

• Give a shit vs Care deeply

 

I made an interesting discovery recently while spelunking in our time tracking system. The distribution of sick time, over all the people we’ve ever employed, very closely follows a logarithmic distribution.

All Atomic employees track their time on all activities, whether billable client projects or internal work. We’ve been doing that since we started, so our time tracking tool has nearly 13 years worth of data (679,263.25 hours, over 86 people). We find this data invaluable for analyzing our business, making staffing decisions, estimating, planning, and juggling responsibilities.

The graph below shows total sick time (blue bars) for all past and current employees, sorted by largest to smallest, left to right. The smooth blue curve is a logarithmic function. It has an R² of 0.989 with the data. The red bars show absolute variance of each blue bar, versus the log function, at each point.

So what?

“But!” I can hear you protest, “you’re mixing together employees of 13 years with those that have worked for only 2 months. This doesn’t mean anything!”

True, I’m not normalizing by employee tenure. When I noticed this relationship, I wasn’t checking on any particular employee. I was just exploring sick time data. I was playing scientist, not pointy haired boss.

But I don’t agree that this doesn’t mean anything just because it isn’t normalized to employee tenure.

Our sick time policy has always been, “take what you need”. It’s fine at Atomic to stay home when you’re sick. In fact, I’d argue that it’s encouraged — no one wants to share germs, or have germs shared with them. Sometimes people aren’t so sick that they can’t work from home; sometimes they are. Our policy doesn’t force you to work when you’re sick. Nor does it incentivize you to take sick time because you’ve “earned” it. Our sick time is just for you, not for when you’re tending sick spouses or kids. Our short-term disability doesn’t kick in until 2 weeks of absence, so sick time covers stuff like recovering from a simple operation, but not longer-term illness. Thus our sick time data represents the time during the work week when people are too sick to work from common complaints, nothing more or less.

Some people get sick more than others. People are more or less able or willing to work when they are sick. Some employees have worked at Atomic for years, some for only weeks. What I find interesting is that when you throw them all together, you find that sick time distributes itself very well according to the natural log function

y = -52 ln(x) + 236

where y is the number of hours of sick time, and x is simply the index of an employee in the sorted list.

A useful model

Here’s where I think what I’ve observed might be useful. Because:

• we have a lot of data (nearly 13 years across 86 individuals),
• our data is tracked very accurately,
• our sick time policy doesn’t distort the data,
• the people of Atomic have a high degree of personal integrity,
• and the natural log function shows up in other places in nature,

I’m going out on a limb and claiming that this function is an accurate predictor of the natural distribution of sick time in groups of people similar to Atomic’s employees. (That group skews male, young, educated, and Caucasian when compared to the population as a whole.)

If my theory is true, then I can also say that the consistency of the data backs up my own experience and belief, which is that Atoms aren’t using sick time inappropriately or with selfish intention. If they were, I wouldn’t see such a high degree of conformance of the data to a natural log model. If cheaters were common, the data wouldn’t fit so neatly to a simple curve.

I realize I’m making a circular argument. I’m deriving what I claim to be a sort of natural law of sick time from a data set, then using the derived curve to claim the data shows consistency with the law.

I’d love to know if other companies with similar employee demographics (and detailed time tracking habits) have data that looks similar. That would help independently confirm the claim I’m making that the natural log curve represents a real phenomenon of illness in people, not just a coincidence.

Assuming I’m on to something, then comparing sick time data to the model might help you to uncover sick time policies or practices that are distorting people’s behavior, such as working when they are sick, or using sick time for something other than being too sick to work.

Who else has data to contribute?

The post Sick time follows a simple formula appeared first on Great Not Big.

      

Related Stories

• How to Avoid the Downsides of Transparency
• Succeeding at Succession – Raising up MPs & Becoming CEO
• Pairing with an assistant to slay the email beast

 

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.

Stimulus

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.

Educating the Grand Rapids market on our design abilities is something we’ve been working on for a while. Our reputation for development skills is well-known; our internal design prowess less so. We’ve also been working hard for many years to improve the gender balance of the company. We lost an opportunity to counter the old image of AO as a group of wicked smart developer dudes.

Response

So that was the stimulus. The interesting thing to me is the reaction that I didn’t have. I didn’t:

• Get angry with our marketing manager for having missed a golden opportunity.
• I didn’t accept her hypothesis that this may be a cultural problem.
• I didn’t call the developer with a WTF? attitude.
• I didn’t tell myself the story that I can’t trust the people I work with.
• I didn’t assume I knew the whole story.

I’m embarrassed to admit that I have reacted this way in similar situations in the past: stimulus, bad response.

What I did instead was:

• Recognized that my marketing manager was upset with herself, and was speaking from a sense of mild guilt and defensiveness.
• Offered empathy for dropping balls when you have too much going on.
• Kindly but confidently rejected the notion that we may have a cultural problem with developers not considering designers as first-class members of teams, or of men minimizing the contributions of women.
• Pointed out this isn’t our last opportunity, and that we should focus on how we can do better in the future.
• Emailed a senior developer on the project and enlisted his help in tackling the hurt feelings directly so they didn’t fester.

Comparing and contrasting the two different reactions makes me squirm as I write them down. It’s so clear how much better one is than the other. Why would I ever react to such a situation so poorly? Could be I’m not a good person, or I have zero emotional intelligence, or I have a character flaw whereby I assume the worst and react angrily by default. Or maybe I just have a stressful, busy job, and like every human I’m programmed with a pretty strong fight/flight instinct. Whatever the root cause, the thing that fascinates me is what happened a couple of hours before this interaction.

Mindfulness

Just a few hours before this interaction I attended an introduction to mindfulness. Allen Weiss, the CEO of the company organizing the marketing conference we were attending, also teaches and studies mindfulness. Coincidentally, I was primed to learn more about this subject by my friend Elissa, and her compelling description of mindfulness. Ironically, I only attended because my marketing manager had registered herself, wanted more sleep, and suggested I take her place.

The one hour introduction included three, short, guided meditations, as well as Allen’s description of his own practice and what mindfulness is all about. I felt pleasantly relaxed, calm, and centered coming out of it.

Here’s how Psychology Today defines mindfulness:

Psychology Today

“Mindfulness is a state of active, open attention on the present. When you’re mindful, you observe your thoughts and feelings from a distance, without judging them good or bad. Instead of letting your life pass you by, mindfulness means living in the moment and awakening to experience.”

I’m certain that a one hour overview isn’t enough to fully understand or master the practice of mindfulness. Allen describes his own mastery in terms of months and years. What excites me is the possibility that my inadvertent experiment points to. Correlation isn’t causation, but it sure seems to me like my brush with mindfulness had a positive impact on how I handled a situation that I might have made worse in the past, and need to deal with regularly.

The post A screwup avoided through a brush with mindfulness appeared first on Great Not Big.

      

Related Stories

• Could you build and run Atomic?
• Everybody likes acknowledgment, leaders too
• Experiments as options on future growth

 

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.

A Simple Model

I made a simple model to think through this question of value. I started from a simple piece work model, i.e. not that of a knowledge worker. This person’s entire value to the company is based on their output, not their knowledge. I doubt there are many jobs left like this in the US, but it’s an interesting case to consider.

In my model, when you change a piece work job to part-time, the output you get is scaled by the fraction of time worked. So for example, output is 50% of full-time if the job is a half-time job. The value exchange is even—half the pay for half the output.

My simple model assumes that pay and benefits are scaled with the fraction of part-time, and ignores overhead expenses like rent, utilities, etc.

The value to a company of a knowledge worker has two components: output and access. The access component represents the value the company gains from being able to access the experience, insights, creativity, cultural contributions, tribal knowledge, historical relationships, perspectives, and accumulated knowledge of the employee.

A naive model for calculating the value of a part-time knowledge worker is to scale both the output and access components of value by the fraction of part-time work. As the spreadsheet shows, that results in a fair exchange of value. I call this a naive model because I don’t believe the access component of value of an employee is scaled by going part-time. If the company maintains a relationship with a valuable, proven employee, the company should be able to continue to take advantage of all the elements of value I label as access.

The third scenario in the spreadsheet shows that in fact the value to the company is actually greater than the scaled pay received by the employee. This is because while the output value scales with hours, access value does not—it is fully retained by the company.

There might be some friction, however, in tapping the access value of a part-time person. I’m thinking of cases when access value is lost because of lack of serendipitous interactions or unscheduable needs. I modeled this with two scenarios. The first is high friction (30% of value lost) and the second is low friction (10% of value lost). In both cases, the company still gets a good deal. The value delivered is greater than the pay.

With output weight at 80% and access weight at 20%, the only part-time scenario in which the company receives less value than it pays for is part-time fractions greater than 75% and high friction. The results aren’t dramatically different if output weight is 90% and access weight is 10%.

Real-world Complexities

Pay is generally easy to scale. Benefits can be difficult, in my experience. Some of our benefits have requirements that make part-time employees ineligible. These make my model too gloomy from the company’s perspective. We also don’t have a mechanism in place for charging different workers varying amounts for benefits, so that makes my model too rosy.

Overhead expenses don’t scale with part-time, and they aren’t charged directly to employees. These make my model too rosy for the company.

A very important consideration is the nature of the work being done by a part-time person. Some knowledge worker jobs might actually require full-time to be effective. With all the electronic communication available today, however, flexible employees can probably succeed part-time in jobs that previously would have required full-time commitment.

My argument for the benefit to the company is based on retaining access to all the knowledge, skills, experience, relationships, etc, of the part-time employee. That’s a much stronger argument, to me at least, if the person has worked for us for years and is shifting to part-time. I think it would be riskier to start a new employee in a part-time mode.

The model

The links below are to Excel and Numbers.app versions of my simple model.

PartTimeWorkModel in Numbers.app

PartTimeWorkModel in Excel (ugly)

The post The Value of Part-Time Knowledge Workers appeared first on Great Not Big.

      

Related Stories

• How to Avoid the Downsides of Transparency
• Guidelines, rules, and consequences– the things I’ve learned
• Sick time follows a simple formula

 

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.

Our value mantras aren’t exhaustive. We expect all Atoms to treat people respectfully, but we don’t have a mantra for that. We expect them (and the company) to be honest, but again, no mantra about honesty. We expect personal responsibility and integrity but lack mantras to that effect. At Atomic, if you think it’s ok to be cruel, or a bigot, you’d be mistaken, and (even though we don’t have a value mantra decrying such behavior) quickly unemployed. Keeping the list of value mantras short seems like an important and useful constraint.

A missing value?

Discussing our vision to someday be a 100 year old company with Mike and Shawn got us thinking about what undergirds that vision, and whether there was something more broadly true about our culture which the vision exemplified. We realized there was — we favor the long term over the short term — and we decided this was an important thing to enshrine in our mantras.

I see us thinking long term when we:

• Do things right, not just expediently
• Experiment with internal governance structures
• Create a broad base of employee ownership
• Build tests for the products we develop
• Decide to buy a building
• Advise clients on maintenance and software product ownership
• Build relationships with people, not just companies
• Hire employees, not contractors, for the vast majority of our work
• Contribute to the communities we live in

When I shared my observations of how Atoms favored the long term, and asked everyone whether they thought that was so important that we should add a value mantra to describe it, the response was positive and unanimous. That didn’t surprise me, given that our values are all observations of existing behavior, not edicts for new behavior. After some online brainstorming we settled on the simplicity and active voice of “think long term” for our new value mantra.

Lisa, our Marketing Manager, asked Atoms how they would define Think Long Term. You can read some of their answers here: Introducing our 6th Value: “Think Long Term”.

Reconsidering “Share the pain”?

When I asked everyone about the possible new value, I posed a second question to the company as well. If we feel it’s important to add a value about long-term thinking, should we consider dropping one to keep the list to five? “Share the pain” was my possible candidate for the chopping block, as it has some negative connotations. As it turned out, there was a strong reaction against dropping “share the pain”. As the person most responsible for cultural maintenance and communication, I was very happy to hear what “share the pain” meant to people, how they felt it was different than the other four values, and why they opposed dropping it.

Here are some of the observations Atoms made during our discussion:

“Share the Pain is an important expression of what it means to be outwardly aware of others and to be empathetic and generous. It requires us to reach outside our own perspective, our own work and our own challenges, to help others.”

“My client’s pain is my pain. Whether it be a design, technical, or personnel problem, I make it my business to help them and their business as if it were my own.”

“…we back each other up in our projects, helping each other and our clients (particularly when we’re working side-by-side with them) to reach our project and professional goals.”

“I think there’s real value to the fact that Share the Pain carries with it the negative connotation of “Pain” because it’s a good reminder that we’re here to work, and that work is not always all roses. I think that can serve as an important counterbalance to an overly optimistic idealism we can develop when working at a place as great as Atomic. But even when harsh reality (Pain) rears its ugly head, we won’t be alone in confronting it. Hard to ask for more than that.”

Preventative maintenance

The performance of really great sports cars isn’t only a matter of what happens at the factory; they require regular, preventative maintenance to keep their edge. Companies need maintenance as well, to last and to perform to a high standard. Culture is owned by the people who live it, but initiating maintenance usually comes down to an individual.

Welcome “think long term”, and long live “share the pain”.

The post Company culture maintenance: Adding a 6th Atomic value appeared first on Great Not Big.

      

Related Stories

• Silly names for important things – the power of naming abstract ideas
• Sharing culture with new employees via a retreat with the founder

 

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.

Conclusion

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.

The post Sustainable pace is a smart long-term strategy appeared first on Great Not Big.

      

Related Stories

• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires
• Embrace and resolve your fear, uncertainty, doubt and anger

 

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.

Value mantras

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

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:

1. Everyone experiences feelings of FUDA from time to time.
2. You’re expected to actively seek to resolve your FUDA.
3. 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?”

Radical Candor

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.

The post Silly names for important things – the power of naming abstract ideas appeared first on Great Not Big.

      

Related Stories

• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires
• Expecting perfect understanding from your writing is a leadership pitfall

 

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.

I organized our trip into five conversational sessions. While I did a little thinking on the topics to cover, I didn’t prepare anything in advance, and I was happy to follow questions and go where the conversation naturally led us. During those sessions I talked about the company’s origins, the first Atoms, what our values mean to us, ownership, Atomic’s “why” and how it’s evolved, our high-level business strategy, what we mean when we talk about Atomic as an extended family, and the responsibilities of an Atom. I shared suggestions on starting a career, my perspective on work/life balance, and what I see in Atomic’s future.

After dinner we had what was one of my favorite experiences of the trip. We hiked up the ski hill to watch the sunset, had some extra adventure climbing something we shouldn’t have, and rested on our backs, in the utter stillness and beauty of a Michigan summer evening, staring up at the sky in total silence, comfortable with each other and just being present in that moment. We closed the evening with a Six Word Stories exercise. I really enjoyed sharing mine, and listening to my young colleagues tell me their stories in exactly six words.

During our trip, I learned what they did and didn’t consider when choosing a company to work for, what their school experience was like, what they appreciated about Atomic and their colleagues, the contrasts they drew with the places their friends worked, how work compares to school, what they struggle with, how they look at longer-term Atoms, how they see themselves in the company’s historical context, and what they hope to be doing in the future. I found out who can dance, and who would never dance. I was surprised to see who shared my tastes in cheap Scotch. I picked up some new music. And I got an awesome glitter tattoo on my hand.

I came back impressed by these newest Atoms, with shared stories and some inside jokes, some really great memories, and pride in knowing I’d helped create something they wanted to be a part of. I was flattered to learn afterwards that the word “cool” had been used in conjunction with my name, and it was fun spending time with people who share my enjoyment of Taylor Swift’s music.

We won’t know for many years whether investments like this Founder’s Retreat pay off, but I’m betting they do. I’ve promised Cell Zero that I’ll come back in 15 years when they are the senior Atoms with the stories to tell about Atomic’s early days, and the “kids” from Cell Fifteen are wondering how they can possibly impact the company the way Rachael, Dan, Andy, and Alex have.

The post Sharing culture with new employees via a retreat with the founder appeared first on Great Not Big.

      

Related Stories

• Silly names for important things – the power of naming abstract ideas
• Company culture maintenance: Adding a 6th Atomic value

 

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:

1. Everyone experiences feelings of FUDA from time to time.
2. Everyone is expected to actively work to resolve their FUDA.
3. 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.

Our expectation of Atoms is that, when experiencing FUDA, they will actively and positively seek to resolve it. In my experience, FUDA that is not ephemeral usually comes from an incomplete or narrow understanding of a situation. In a company, growth makes the situation of people having incomplete information or narrow perspective more common, and thus represents a real challenge to a company culture of close relationships, little hierarchy, broad input, transparency, and collective decision making. It was this negative side effect of growth that drove us to create our agreement on FUDA.

2. Take action

While no one can stop negative thoughts from arising, everyone can choose the actions they take when they do. Gaining more perspective, researching, learning, active introspection, asking questions, discussing with peers, benchmarking other companies, talking with company leaders—these sorts of activities can help resolve FUDA, and are what we expect of all Atoms. It’s ok to have FUDA; it’s not ok to hold on to it.

3. Help others

No one enjoys being in a state of FUDA. Long-standing, unresolved FUDA has corrosive effects on working relationships, and may even be a personal health risk. As a company of people who care about each other, we should all be willing to help our colleagues when they are in a state of FUDA. In addition to be willing to help, we expect people to watch for signs of fellow Atoms struggling with FUDA, and to pro-actively reach out to help them.

Our experience

Giving FUDA a name has helped us talk about a tricky subject. Acknowledging that negative feelings are a natural part of life helps de-escalate conflict. It’s a lot easier to tell someone you have some FUDA you’d like to resolve when you both know that having FUDA is inevitable.

Formulating our stance on FUDA helps Atoms feel that it’s ok to be in a bad place, but to also know they’re responsible for taking action to resolve their feelings. Embrace and resolve.

Unresolvable FUDA is rare, and I believe is almost always due to an irreconcilable mismatch of values or goals. In such cases, I think it’s best to avoid “right/wrong” judgments and move forward with integrity and honesty to pursue separate paths.

We don’t always get it right. I’ve been told something I’ve said generated FUDA in an unspecified group, and that I should do something to fix it. While I strive to not do things that generate FUDA, I can’t fix what’s not mine and I don’t understand. These situations remind me we need to continue to talk about our shared agreement on FUDA.

I’ve seen, and felt, the temptation to not communicate on a controversial or complicated topic in reluctance of the risk of generating FUDA. That challenges our value of acting transparently. People, especially company leaders, need to communicate carefully, but they also need to trust their colleagues to actively work to resolve any FUDA that may be inadvertently created.

Negative thoughts, if harbored and left unresolved, are almost always destructive. A shared agreement about our personal responsibility to actively resolve our FUDA helps us avoid relationship damage and maintain trust with each other.

The post Embrace and resolve your fear, uncertainty, doubt and anger appeared first on Great Not Big.

      

Related Stories

• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires
• Expecting perfect understanding from your writing is a leadership pitfall

 

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.

Everyone needs good budgeting

Our client’s business needs a realistic budget they can count on so they can confidently analyze whether a project is worth doing. Will it provide a reasonable return on the investment in the desired time frame? Tough to answer that question if you don’t know what the costs will be.

Our client, that is the person we work directly with and who approves our invoices, needs a credible budget so they can get approval for the project, or so they can raise funds. Again, you can’t raise capital without having a good idea of what you’re going to spend.

Finally, our teams need a good budget. One of our brand promises is predictability in time and budget. It’s hard to meet an expectation that’s never formalized. No team likes disappointing a client, so a realistic budget is critical for team success. Teams use a budget to force themselves and the client to make choices about feature breadth and polish. In a situation of more ideas than money, a fixed budget forces a healthy discussion around the prioritization of work.

I’ve learned over the years that budgeting isn’t about determining the definitive, proven answer to the question, “How much will my application cost?” Rather, it’s determining a responsible budget for a project and using cost as a constraint on the project. The fundamental question is, “Can the team and client find success within this budget?”

Cost as constraint

Budgeting is one of the most difficult and stressful things for makers and consultancies. More commonly referred to as estimating, it’s often the least favorite aspect of their jobs. Few of us enjoy it or feel confident with it.

It makes sense to me that developers struggle with estimation and budgeting. There are many considerations, some not readily quantified. There are unknowables. Answers are hard to validate (unlike software itself). Like any creative activity, software, and hence the cost of software, is heavily influenced by the people involved. It’s no wonder estimation and budgeting skills aren’t common.

Unscrupulous consultancies will intentionally manipulate estimates to win projects. But even well-intentioned developers may not give budgeting the time and effort it requires and deserves.

Determining the amount of the budget to constrain a project is hugely important, but within a certain range, also somewhat arbitrary.

We like to involve our clients in the decision of setting the budget. Together, we are choosing a constraint, not determining some definitive correct answer to the cost question. We help by doing the thoughtful work to determine a responsible budget range for a project.

An effective software development process supports discovery, learning, feedback, and adaptation. Jointly determining the budget with clients helps them understand that success comes from working together, using budget as a constraint on an inherently open-ended process. The shared goal is to define and build an application that will at least satisfy, if not delight, its intended users, and create a business success for the client.

With the inherent ambiguity around new product development, and the malleability and unconstrained nature of software, treating cost as a constraint is not only vital to project predictability, but also the best product development approach.

How Atomic budgets

We distinguish between budgeting and estimation. Estimation of a feature set is only one consideration for us in determining a responsible project budget.

Feature estimation is a valuable exercise in thinking through the application to be built. It can be a substantial investment of time, but through investigation and conversation with the client, it helps us understand what the client’s goals are, and what should be built. The act of feature estimation lets us bring our own experience and ideas into the conversation. We often influence substantially the nature of the final product.

Estimation involves decomposing the application to be built into high-level features or subsystems. Decomposition, breaking a big thing into small constituent parts, is a powerful method used widely in computer science and project management. For estimation, we use our experience to assign low and high estimates to each feature.

For each feature, we use the spread between low and high estimates as an indication of uncertainty. We compute a buffer for the entire feature set estimation based on those spreads. The buffer places the feature set estimate somewhere between the sums of the low and high estimates of all features. High degrees of uncertainty mean the final estimate is closer to the sum of the highs; lower uncertainty lands you closer to the sum of the lows. This post on buffering describes the details.

Feature estimation isn’t a budget or project plan. Some features that are estimated may in fact never be built. Some important things that eventually are built may be missed. Investing this time is still valuable, even when done at the point of maximum ignorance, for the conversation and understanding it engenders.

Since feature set estimation isn’t sufficient to set a responsible budget, we use many other sources to inform our budgeting process:

• analysis of business needs and goals
• comparable projects we’ve done
• time invested in prior versions of the same application
• team size, composition, and experience
• evaluation of client’s prior software development experience and capabilities
• power and maturity of relevant technologies
• environmental factors such as regulatory requirements and deployment process
• number, diversity and degree of alignment of project stakeholders
• integrations with external systems
• number of technology domains (e.g. web, mobile, desktop, embedded) involved
• migration needs from prior production versions
• criticality to business operations
• likelihood of hidden requirements
• likelihood of emerging requirements
• how well-understood the need and market is by the client

Of course not every source is useful for every project budgeting exercise, but an experienced team draws on many sources of knowledge and insights.

Starting the relationship off right

We often find that our budgeting work helps clients better understand their projects. Investing the time for feature estimation, and considering many different aspects for the budget, helps clients compare proposals from multiple vendors. It also starts the critical task of building trust between the client and the team.

Clients who aren’t themselves experts in software development can find the entire process opaque and intimidating. It’s no surprise they may feel vulnerable to being taken advantage of. Being thorough, transparent, and collaborative in setting the budget helps address their legitimate needs and fears.

It’s said that the best way to predict the future is to invent it. Setting a budget informed by a diligent investigation process, and working with a team that knows how to use budget as an effective constraint, applies this advice to the seemingly perplexing question, “How much will this cost?” The answer becomes easy: “What we budget.”

The post Software project budgeting is more than estimating appeared first on Great Not Big.

       

I write. They read. Some people are confused or upset. They complain. I’m frustrated.

Live through this cycle a few times and it’s tempting to communicate less. I call this temptation the leadership writing pitfall.

Try as I might, it seems my writing is always interpreted in multiple, often conflicting ways. I try really hard to be clear, complete, and unambiguous. Some level of confusion and misinterpretation seems inevitable, regardless of how well-crafted or thoughtful the writing. It can be discouraging.

It’s not just me. I’ve seen, as other people have stepped into leadership roles, the same thing happen to them.

I work with smart, thoughtful people. The audience isn’t the problem. I’m a decent, careful writer, as are my colleagues. I don’t think the author is the problem. I’ve concluded that some level of confusion and misinterpretation is simply inevitable when you’re writing about challenging or complex topics to an audience of 50+ people.

I have felt, and I have seen in my colleagues, a natural but dangerous reaction to this unavoidable misinterpretation. Namely, if my writing is inevitably misinterpreted, and sometimes causes fear, uncertainty, doubt or anger, which I will then need to spend time dealing with, then maybe it’s better, and it’s certainly easier, to not communicate at all.

This is a dangerous reaction because the job of a leader is to set direction and help move the organization accordingly. That requires communication. Less communication means less effective leadership.

I find it helps me avoid this leadership pitfall by reframing the problem.

The right goal for leadership writing

What I’ve concluded is that it shouldn’t be expected, nor is it possible, that my communication is perfectly complete or entirely unambiguous. That’s a standard no one can meet when there are 50+ recipients. It reminds me of the fallacy behind old-school waterfall software development—a perfect spec (complete, unambiguous, accurate, relevant) can’t be created in a vacuum regardless of how much time and effort you put into it. Like with software development, some pre-planning is necessary, but success is achieved through doing, not upfront planning.

I think it’s wrong to think about causing fear, uncertainty, doubt or anger (FUDA) with my communication. FUDA may certainly arise because of what I write, but describing it as having been caused by me means I’m responsible for it. I can’t be responsible for something I don’t know exists, can’t fully understand, and can’t resolve. It’s the responsibility of the individual to resolve their FUDA, not my responsibility to have prevented it.

(This of course doesn’t mean I get a pass and can write hastily, sloppily, or unthoughtfully.)

I think about leadership communication as a contract: I write and do my best to explain; Atoms read and engage to resolve any FUDA they may feel.

Besides fighting the dangerous tendency of communication avoidance, I think this reframing is important for other reasons. If I felt responsible to achieve perfect understanding in every one of my employees, then I’d take too much time pondering and writing, and progress would slow. I’d always feel like I failed, since perfect, uniform understanding is an impossible standard to achieve. If I prepare carefully, write clearly, review and edit before publishing, then I should feel good about my work even if some FUDA arises from it.

Finally, if my goal was perfect understanding in the recipient, I’d be disempowering my employees by removing their responsibility in the communication contract.

Writing to transmit ideas and information between people is a two-way process in which equal responsibility resides in the writer and reader. To riff on Alexander Pope, “To write is human; to understand, divine.”

The post Expecting perfect understanding from your writing is a leadership pitfall appeared first on Great Not Big.

      

Related Stories

• A screwup avoided through a brush with mindfulness
• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires

 

Many companies only promote from within for leadership positions. My own experience confirms the wisdom of this approach. Recently, we found ourselves taking a different route for our Grand Rapids office as we wrestled with the question of how to make it, our largest office, operate smoothly and sustainably.

We have internal leadership talent, but they lack experience in the complex job of Managing Partner. Rushing those people risked spoiling future leaders. Plus, we needed the immediate relief for our office management team that only an experienced person could provide.

The question we faced was: Despite the risk, how do we successfully bring an outsider into a company like ours at a leadership level? Our answer involved an unconventional approach to hiring and onboarding.

Size of the puzzle

Atomic has two offices — the first in Grand Rapids, and a second in Ann Arbor. Each is organized the same way, and offer the same value prop to clients. Each is autonomous, led by a pair of Managing Partners. Both share the services of a thin company layer (finance, accounting, marketing, facilities, benefits admin, etc). Most, but not all, of the six or so people in the company layer work out of Grand Rapids. Currently, we employ a total of 51 people across the company.

Thirty two people in Grand Rapids, soon to become 37, are makers and support staff. Twenty eight of those 32 people report directly to the two Managing Partners in Grand Rapids. Simple math shows we’ve got a structure problem: 14 direct reports is too many. Our Managing Partners are responsible for selling our capacity, keeping makers busy, clients happy, connecting with the community—it’s a very broad role. No surprise then, that the responsibilities which go along with being a people manager have gotten short shrift, historically.

The problem

While we’ve got a promising group of Atoms who are gaining valuable experience for future company leadership roles, it was my judgment that no one was ready for such a role yet. I believed that pushing people who weren’t ready was unlikely to be good for them, and unlikely to provide much relief for our two Managing Partners.

Our “Atomic at scale” challenges in Grand Rapids felt like one of those 15-puzzles — every move we contemplated caused pain somewhere else. We didn’t have the necessary slack in the system to experiment and bring up someone without the right experience. Long-term investments would cause serious short-term pain. We were stuck.

The conclusion I came to was that we needed to add someone with relevant experience. We needed new capacity to move. But bringing someone from the outside into a leadership role at a company so strongly defined by its culture, values, and social bonds is a risky, big deal. In fact, I think it’s safe to say that it’s more likely to fail than succeed. Companies like ours typically promote from within.

Happily, we had an unusual opportunity to hire Jeff Williams, someone I’ve known for a long time, with highly relevant experience in the duties of Managing Partner, who shares our values and was very familiar with our company.

Our hiring process for Jeff was the most thorough we’ve ever used. We applied assessments we use internally, giving us a comparative lens for Jeff’s skills, inclinations, and communication style. We did reference checks with people who worked directly for and with him. We used lunches and dinners for casual, two-way exchange. We paired with him on real work that he’d be doing.

For the final day-long interview sessions, I made sure we had broad and balanced participation and encouraged people to try and answer three questions. Here’s how I framed the assessment I was looking for:

1. Do you think Jeff could represent us well to the outside world?
2. Do you think Jeff shares our values?
3. Is Jeff a person you think you would come to trust, respect, and appreciate after he’s worked at Atomic for some time?

Not surprisingly, we had a range of opinions, and some concerns, from the more than 18 Atoms who participated in the hiring process. In the end, our company leadership team made the decision to extend an offer, and Jeff accepted.

Onboarding

Having gone through a very thorough, broad-based process of assessment and interviewing, our decision to hire Jeff led to another question: How do we bring him in and set everyone up for long-term success?

On the one hand, our Managing Partners could really use some immediate help with their day-to-day responsibilities. On the other, we cared most that Jeff’s tenure work in the long-term, and we recognized the challenges inherent to bringing an experienced outsider into a leadership role.

I framed the problem by asking, what does Jeff not know that long-term Atoms take for granted? What sort of knowledge and experience could we give him that would bring him up-to-speed on all things Atomic? In effect, we sought an onboarding process that converted him from a qualified, experienced, external candidate, to someone as close as possible to a qualified, experienced, internal candidate.

Our onboarding approach is a 50/50 blend of training on sales, and a broad curriculum on all aspects of our business. In the latter, we are involving as many people as possible, allowing Jeff and other Atoms the opportunity to start building relationships through working together. We’re using our pair lunch program to further broaden his exposure to Grand Rapids Atoms.

Our two Managing Partners are leading Jeff’s onboarding. Shawn Crowley is working with Jeff on our sales process and practices, with a strong emphasis on pairing on real sales work. Having a pair on sales has helped Shawn both from a tactical work-share arrangement, as well as the all-important psychological benefit a pair provides. Mike Marsiglia took the broad categories of education that we identified for Jeff and structured an experience akin to how we run product development projects. Jeff’s using the same tools and approach for his broad Atomic education: epics, stories, estimates, Pivotal Tracker, velocity, iterations, and customer reports. I think the indirect learning here is great, and the approach is genius.

Conclusion

We estimate that Jeff’s onboarding will require 3-6 months. That’s a huge investment, but one I feel very good about. Bringing an outside hire into the company at this level came with a cost — we needed to give Jeff the opportunity to catch up on the things he needed to know to succeed in his job. Our “think long-term” value guided showed the way.

Jeff’s experience and highly relevant skills allowed us to take a few numbers out of our structural 15-puzzle. We’ll use our increased ability to maneuver for further experiments in adapting our structure to provide a better employee experience for Grand Rapids Atoms, and create a more sustainable job for Managing Partners.

We’ve always focused on being great and getting better, not on a size or revenue target. Wrestling with the growth that is a consequence of this approach is a recurrent challenge for us. Two months in, I’m feeling optimistic that our onboarding investment, and Jeff’s talents, help us solve that problem for this phase of the company’s life.

The post Succeeding with outside leadership hires appeared first on Great Not Big.

      

Related Stories

• Firing people: feelings, perspectives, and practical advice
• Embrace and resolve your fear, uncertainty, doubt and anger
• Expecting perfect understanding from your writing is a leadership pitfall

 

This is a summary of what I’ve learned about firing people. I’ve had to do that difficult, unpleasant, but occasionally absolutely necessary task 12 times, and have supported other managers doing it an additional 10 times. My experience spans a total of 180 people employed over 15 years. All of these situations were careful decisions made for specific, individual reasons. I have no experience letting someone go for lack of work in the company (“layoffs”).

This is not a post about the process of reaching the conclusion that you need to let someone go. That is a complex topic in and of itself. This post covers what to consider once the decision is made.

I’ve written from the perspective of the manager. It’s organized by stakeholders and events: the manager, the person being let go, preparation, the event itself, clients, and other employees. It’s written in an intentionally “thought-bite” style, meant to inspire further reflection, not justify or explain every point.

Background

A company that never lets anyone go either has a perfect hiring process and employees who never change, or is willing to tolerate and hide problems and leaders who are shirking their responsibility. Letting people go is one of the natural consequences of imperfect hiring (and a motivator, for managers, to take their time and hire carefully).

Being an “at-will employer” means an employee can be fired at any time with no cause or justification necessary. The only exceptions to this rule are for certain well-defined reasons, like racial discrimination or retaliation for claiming harassment. Sounds like it should be easy to let someone go, right? In my opinion, being an at-will employer doesn’t get you off the hook for following a careful, thoughtful process in making the decision, or for implementing it.

Every employee who walks into your office each morning is exercising their own free will and power. They can leave anytime they want. In a software development consultancy, most of them can also get another job easily. They have real power. In my experience, this is often not how unhappy or problematic employees see their situation. They may feel that you have all the power. They may see themselves as powerless or trapped. You, on the other hand, can’t coerce them to work. You don’t own or control them. Your only power, and your responsibility, is to take the difficult action of firing them.

Here are two ways to frame the problem of letting someone go:

1. Bad framing: Right/wrong

For example, “This company policy or expectation is wrong; my behavior is right”. Or, “This policy is right, your behavior is wrong”.

2. Better framing: Misalignment

For example, “The company has needs, expectations, values and standards that aren’t negotiable; you seem to have other needs or values or priorities”. A difference between these two sets doesn’t make one party right and one wrong, just different.

You: The manager

Be confident: you’ve faithfully executed a good process, giving feedback, radical candor, help, and concrete ideas for what needs to improve. You’ve been patient; second and maybe third chances have been extended.

Having to do the unpleasant, difficult task of firing someone contributes to your moral authority to lead an office. Consider that you owe it to everyone else in your office to do the hard but right thing—you are accountable to them for this aspect of your job. No one is irreplaceable. You can deal with short-term pain like project holes and revenue loss. Think long-term.

Remember (but don’t necessarily share) that working at your company is a privilege, not a right. It’s also not the best job for everyone. Let those beliefs give you confidence.

Afterwards, give yourself some time to adjust and recover. It’s a hard thing to do, even when it’s the right thing to do. Cut yourself some slack, find someone to listen; have a beer, be a combination of sad and relieved.

Them: The person being fired

Some people need a push, as they’re unhappy but frozen. For these people, the big moment may come as a relief. They know it’s a bad match, they know they have been underperforming, or causing problems, or unhappy. Some people are just stuck; this goes along with feeling powerless.

Some people may feel dissonance between their own unhappiness and having a good job at a great company. This may be another reason they are stuck: “How could I leave? What if my next employer isn’t as good?”

The person you fire will not remember what you say after you make it clear they are being fired. Shock, concern, humiliation, etc, reduces information retention. This is an extremely personal event for them. Don’t count on them to remember much after this point.

Expect they may claim to be surprised, regardless of what has transpired. Consider that they may genuinely be surprised, and that this is part of their problem. If they don’t express surprise in the meeting, they absolutely will do it at home, in private, and at the bar.

Rejection is hard. Everyone has an ego to protect. Look for opportunities to let them save face without wavering on your decision or plan.

Even with bad actors (sources of negativity, undue or unfair criticism, spreading poison, assuming the worst from every event or decision, etc), remember that they aren’t evil people.

Allow yourself to feel empathy for another human being experiencing something that’s very tough. But don’t let that empathy take you, via misplaced guilt for your decision, into a place where you have to “prove” they are bad, or you had no choice, or it’s their fault. Have your reasons, know your reasons, keep it simple, stand firm, communicate clearly.

The hardest situations are when you’ve come to the conclusion that the person you’re firing genuinely wants to be a good employee, but is either not capable or is held back by other issues; jerks are easier to fire, but less common.

Before the meeting

1. Have a communication plan: who, when, what message, ordering.
2. Determine timing—absolute and relative—of all actions.
3. Decide on practical details in advance: benefits, laptops, software, severance, vacation time, transition, accounts, health insurance, stock, etc. We have a template of all the issues to consider, and some guidelines, but no hard-and-fast policies. Each case should be considered individually.
4. Write an email to the office to send immediately after the meeting. In your communications with others, respect the privacy of the person you let go, but don’t shy away from explaining at a high-level what the cause was and the process that you followed.
5. Write out talking points for the meeting. Keep it simple and short.

Consider sharing the news a few days in advance with a few, carefully chosen, discreet colleagues. It’ll give you confidence about the reception the news is likely to receive. It also may help to have a few people who aren’t surprised as they’ve had time to ponder in advance.

The meeting

You need to take their job, not their dignity. Be resolute in the first, kind in the second. The Crucial Conversation dictum of “start from the heart” is good to keep in mind, but also be very clear and strong on what needs to be done.

Have someone in the room with you. The lead person delivers the message, the second observes and supports. Both should know the plan well.

Favor end-of-day, and when other employees aren’t around. Make it easy for someone to leave without humiliation or drama.

Avoid using the word fired. Prefer words/phrases like separate, let go, you need to leave, time for you to find a job that’s a better match, etc.

Don’t get sucked into arguments over facts and details and events. This isn’t a debate.

Have a printed document for them to take away that summarizes what you’ll do, and what you expect them to do.

Don’t negotiate. Have everything thought through, and drive the conversation, next steps and actions decisively. Should there be something you want to change or reconsider, you can always do that later. Don’t promise anything in the meeting, as it’s an emotional event for you, too.

Use the power of silence. Don’t feel like you need to fill it and therefore talk too much. Allow them to absorb the information, ask questions, then close it down. These meetings are usually short.

If you’re willing to be a reference, make it clear what you’ll say. If you’re not, don’t volunteer anything in this area.

If it helps, and you genuinely feel it, it’s okay to introduce some distance between you as a person and you as manager. As a person, you feel bad about the decision. As a manager, you feel obligated, responsible, and confident. Be careful how you play this.

Prepare for tears. Think through what they mean, how you’ll react. Be thoughtful and have tissues in the room somewhere. Also, consider that the tears may be your own.

Your clients

Clients will have specific, short-term concerns (deadlines, disruption, knowledge loss, ramp-up, etc). They won’t see it as their business or concern about the decision you’re making and the long-term impact.

Don’t do anything that brings into question the quality of work done in the past by the person being fired. (Unless that is in fact the issue, then deal with it honestly and take your lumps to make it right.)

Make it clear that this is a decision you’ve made for the good of the company, and that you’re committed and already working to make sure to hold them harmless. Have your Plan B already figured out before you talk to the client.

Consider a future offer, as part of your project transition plan, to absorb some of the ramp-in time for a new team member. Remind them that new people on projects is often its own good thing (fresh, excited, new perspective, different experience, beginner’s mind).

Experienced clients, or inexperienced clients who reflect on the decision later, will appreciate working with a company that has high standards they enforce and a culture they protect. They’ll also be sympathetic to situations when you’re firing someone for the poison they spread and its impact on the team, office, and project. Everyone knows what that’s like to live with.

Other employees

Expect that other employees will be appreciative, but quiet. They’ve likely seen the same problems you’ve been trying to address. Taking action reaffirms their faith that the company cares about the employee experience, brand, and clients.

Your decision and action shows that there are more important things than billable hours, revenue, and profit; that you are willing to make hard decisions, do hard things.

Tackle the issue of surprise head-on with other employees; if you’re confident the person you let go has no genuine, reasonable claim at being surprised, then make that clear. Other employees want to know that lightning bolts don’t come out of the blue. Your employees have a sense of fairness which the “I was totally surprised!” narrative challenges. Meet this head on, even to the point of discussing the phenomenon and predicting it.

Anticipate social connections within the office and talk with people who were particularly close to the departing person, privately and directly, immediately afterwards. Don’t be afraid of telling them why you’re talking to them: you value and care about them, recognize they have a close friendship, want to give them a chance to talk or ask questions.

If you’ve treated the person you’re firing fairly and respectfully, you won’t lose other employees. People can separate their work and social roles and relationships.

Use the pre-written email to inform the whole office, so everyone gets the same message. Send it very soon after the firing event. Lack of transparency here can be very damaging. Do everything possible so the first knowledge of the event comes from you, not a rumor, or another employee, or social media, or the person you fired.

The next day, address the office as a group, in person, repeating the content of your email, adding appropriate color commentary, allowing yourself to be vulnerable (these things are hard, I feel it’s my obligation to everyone else, not right/wrong, makes me sad, also a little angry that I had to do this, etc). Take questions. Offer to discuss privately. Express confidence that separation is disruptive, but is most often a starting point for a better situations for both parties.

Conclusion

Firing someone is a heavy responsibility. Thinking through the event in advance helps you make it less painful for everyone involved. Smooth, thoughtful execution really matters.

If you’re avoiding the decision, or taking action, remember: you get what you put up with.

Expect that once you’re through it, you’ll criticize yourself for not taking action sooner. You’ll feel like you let a bad situation go too long. You may have. But it’s also easy to say that in hindsight, and never easy or obvious as these situations unfold.

The post Firing people: feelings, perspectives, and practical advice appeared first on Great Not Big.

      

Related Stories

• Succeeding with outside leadership hires
• Embrace and resolve your fear, uncertainty, doubt and anger
• Expecting perfect understanding from your writing is a leadership pitfall

 

Cash is the life blood that runs a business. If it’s mismanaged, it’s highly likely that the company will experience pain. Unfortunately, employees are often surprised by this pain, leading to negative FUDA.

Managing cash flow in a small company is a challenge, requiring financial understanding, discipline, modeling skills, and planning. But sharing and contextualizing cash flow broadly within your organization takes this challenge to the next level. It’s impossible without a lot of data, education, and trust.

Why We Share

At Atomic, we run an open books business. Instead of shielding people from the financial dynamics of the company, we’ve decided to educate them and share data.

It’s starts with a class for new hires called The Economics of AO, reinforced when we share and explain our company results every quarter. This gives employees the big pictures.

A few years ago, we also decided to share cash flow information, but in a way that didn’t overwhelm people. We believe in sharing our cash situation with shareholders for two main reasons:

1. The transparency forces managers to be accountable for cash flow decisions.
2. Shareholders are exposed to the data and are expected to responsibly engage and help if called upon.

How We Share Cash Flow Data

To simplify things, we created a high-level line graph called our Cash/AR (Accounts Receivable) report, which we share with all company shareholders. At the time of the post, about 63% of Atomic employees are shareholders, so the report is widely distributed.

This graph is based on the following simplifying constraints:

• AR will convert to cash at some point in the future. We do good work and do business with honest people. Over our 16 year history, we’ve had very little bad debt.
• We send invoices at a normal cadence (e.g. every 2 weeks). Invoices and their corresponding AR are coupled to time spent not necessarily project deliverables.
• In most cases we have sane payment terms. Our AR converts to cash in a timely fashion.
• The graph only shows what has happened, not what is about to happen. In a non-seasonal business like software design and development consulting, the past tends to predict the future. This certainly does not replace the need to develop more sophisticated one-off future facing models if a future cash fluctuation is anticipated (e.g. a building project, market adjustment, etc.).

Our Cash/AR graph plots three primary components over time (x-axis). Each component is reported in dollars (y-axis). Depending on your cash flow philosophy or need, it may be valuable to plot other components as well (e.g. line of credit, etc.). For simplicity, I’m only going to focus on the major components.

The following shows roughly 2 years of weekly data.

This graph plots three different amounts:

1. Rainy Day Fund Goal (RDF Goal)

Saving for a rainy day is an important aspect of running a responsible business. The art of setting the RDF Goal is unique to each organization. We’ve adjusted our goal over time based on factors like the size of our team, diversity of client base, willingness to leverage our line of credit, etc. We’re currently using an algorithm that adjusts our goal based on real company costs each quarter. You can see these small quarterly adjustments in the graph.

The most important thing to point out is that our goal is the combination of both cash and AR. Cash is very noisy, but our workload is steady. We’ve found that targeting the combination of cash and AR brings consistency to the data, and helps us avoid unnecessary panic.

2.Rainy Day Fund Actual (RDF Actual)

The RDF Actual is the sum of actual cash and AR for a given date. We distribute profit (profit sharing and shareholder distributions) each quarter, and you can see the RDF Actual buildup throughout the quarter and then drop at the end of the quarter in the graph.

The saw-tooth noise throughout the quarter is representing expenses and invoicing cycles.

3. Actual Cash

The actual cash line represents the actual cash in the bank for a given date. The distance between the cash line and RDF Actual line represents the amount of outstanding AR. If actual cash is following the pattern of the RDF Actual then we know that AR isn’t growing or shrinking at an alarming rate.

Analyzing the Graph

The primary components of RDF Goal, RDF Actual, and Actual Cash graphed together over time gives a nice high-level view of the company’s health.

The graph allows you to quickly see and evaluate the following questions:

Are we consuming our rainy day fund?

If the RDF Actual dips below the RDF Goal line the answer is—yes.

The graph also gives you a good context of how much you’re consuming at any given time and how many occurrences you’ve dipped below the RDF Goal line in a given time segment.

What is my current cash on hand?

The cash on hand line shows your current cash and contextualizes it over time.

Is my AR converting to cash in a timely fashion?

The distance between the RDF Actual and the cash on hand line is the current AR.

Assuming your company size didn’t change:

• When the RDF Actual and cash on hand lines start to drift apart then your AR isn’t converting to cash in a timely fashion. You may be in for a short-term cash crunch.
• When the RDF Actual and cash on hand begin to merge together it’s a leading indicator for a potential future cash crunch.

Am I able to hold less cash in the company?

Maybe. We’ve been able to use the graph to quickly review our cash situation over time. This has helped us understand the peaks and valleys of our cash flow and adjust our RDF Goal.

This simple to produce and easy to maintain graph has provide a lot of ongoing value for our organization.

The post Visualizing Cash Flow for Shareholders with a Cash/AR Graph appeared first on Great Not Big.

      

Related Stories

• Succeeding at Succession – Raising up MPs & Becoming CEO
• How to Avoid the Downsides of Transparency
• Sick time follows a simple formula

 

I never suspected I’d come to think matrix management might be a great idea for managing project-based, professional services firms like Atomic.

My undergraduate business classes exposed me to the potential downsides and conflicts related to matrix management. Additionally, throughout my professional career, I’ve observed the pain and frustration matrix management structures impose on new product development efforts. As a result, I’ve held matrix management in such poor regard for so long that I’ve simply equated the structure with bad organizational design.

As an example of the pain matrix management can inflict, let’s walk through a simplified, hypothetical scenario.

Matrix Management Pain

Let’s pretend PayCo, a payroll processing firm, has the following departments: Marketing, Customer Support, IT.

Team members work for a specific department. Each team member strongly associates with their department as it relates to their individual, vocational identity. Consequently, individuals have KPIs and incentives related to their departments.

Marketing

• Is responsible for developing customer insights and driving inbound leads.
• Manages direct mail and digital campaigns.
• Has internal initiatives including new content development and brand identity updates.

Customer Support

• Is responsible for helping clients and client employees navigate provided services.
• Provides live-chat, phone, and email support.
• Has internal initiatives including response time improvement and developing better support documentation.

IT

• Is responsible for keeping business infrastructure and client-facing technology services running and updated.
• Monitors and updates systems for upgrades and works through call tickets for issue support and bug fixes.
• Has internal initiatives including a database system transition and rewriting outdated ACH automation software.

A Special Project → Competing Incentives

PayCo decides to start a new, cross-functional project for developing PayCoGo, a mobile phone app that allows client employees to review their paycheck history. They assign a few team members from each department in a part-time allocation to the PayCoGo team. The team members eagerly meet PayCoGo’s project manager and align on a high-level project plan but now report to two managers and serve two sets of KPIs.

PayCo has doomed PayCoGo to be late, or not gain traction, for factors including:

• Team members assigned to the PayCoGo project have stronger incentives and measures related to their departments.
• Team members have a longer and more career-impacting relationship with their department manager than the PayCoGo project manager.
• The PayCoGo project manager has no insight into the capacity needs or timing of departmental operations or initiatives. It will be nearly impossible to anticipate conflicts or manage capacity and dependencies. Conflicts will slow the project down, and the team members will lose excitement, momentum, and team identity.
• Department managers will view the PayCoGo project as a distraction and change that might put their KPIs and incentives at risk. Department managers may assign the least-skilled team members to PayCoGo or give their employees cover to reduce their involvement in PayCoGo when departmental needs call.

I’ve seen this play out in real life because the departmental-centric, status-quo inertia of matrix organizational structures pulls innovation projects into a gravity well of doom.

So why might a matrix management structure work for a project-based, professional services firm?

Matrix Management with Project-based, Professional Services

Self-managing project teams connected and reporting directly to their client have always been our main organizational abstraction. Last year, adding delivery leads as core members of our product development teams further improved our product quality and the client’s project experience. This aspect of our structure has performed well historically and scales pretty well, since the size of teams doesn’t change as an office grows.

As our largest office has grown, we’ve felt structural pain in the employee support dimension of our organization. This work increases linearly with the number of makers in an office. We want to be sure that Atoms grow in their careers and as individuals through satisfying work, professional development, coaching, and human resources support.

A Possible Next Step

Project team composition and scheduling, sales, and employee support currently all rest on the shoulders of our office Managing Partners. I believe we can better serve clients and Atoms by creating separate management responsibilities around the functional areas of:

• Sales and project staffing
• Individual support of Atoms

Focusing the above responsibilities into separate, functional management groups allows a manager to focus on the unique characteristics of each functional area. For instance:

• Sales and project staffing work is: high importance, short-term focused, high and variable volume, and responsiveness oriented
• Individual support of Atoms is: high importance, long-term focused, bounded in volume based on number of Atoms, and can be mostly pro-actively scheduled

The separation of functional responsibilities helps ensure the short-term focus of client-facing work doesn’t starve the important, long-term work of supporting individual Atoms.

Segregating management responsibilities into focused functional groups also allows for more focused training and development of managers. Some Atoms will naturally enjoy client-facing work and others will prefer helping support their fellow Atoms. Therefore, the separation of responsibilities allows individual managers to focus on developing their strengths.

But doesn’t having two functional management groups impose two managers on any Atom and create conflicts through competing priorities and incentives? After thinking more about the project-centric nature of Atomic’s work, I don’t believe we face the downsides of matrix management I described above.

How Matrix Management Can Work

Several key insights led to me realize why separate functional management groups could work at Atomic:

• Most Atoms work in autonomous project teams, full-time on a single project, for periods of months.
• Teams only work towards KPIs tied to client and project success.
• Atoms focusing on client projects drive business success for both Atomic and our clients. There are no competing incentives.
• Having separate functional management groups does not impose competing KPIs on Atoms. Individual support managers serve the needs of Atoms; they don’t assign them competing priorities. The only priority is the success of the client project.
• Atoms track all of their client and non-client work in Atomic’s time tracking system. Time tracking data is accurate because it directly feeds invoicing and payroll. We can see if any Atoms are working an unsustainable pace or against competing priorities and provide them with support.

Separate, functional management groups could serve Atoms well:

• A group managing sales and project staffing will establish an Atom’s next project and team assignment. Any Atom could work with someone from the sales and staffing group to discuss future work preferences, the need for more team capacity on their current project, or even a desire to rotate from a long-running project.
• The relationship between individual support managers and their Atoms is independent of project assignments, and longer lasting. Atoms could work with their individual support manager on professional development support, annual compensation reviews, workplace interactions, or navigating any benefits or policy.

We haven’t tried organizing around a more formal matrix yet, but we’re strongly considering it. If you have worked in a matrix structure at a project-centric services company similar to what I’ve described, I’d appreciate you sharing your experiences in the comments section.

The post Can Matrix Management Work in a Services Firm? appeared first on Great Not Big.

      

Related Stories

• Visualizing Cash Flow for Shareholders with a Cash/AR Graph
• Succeeding at Succession – Raising up MPs & Becoming CEO
• How to Avoid the Downsides of Transparency

 

We’re approaching a significant milestone in our company initiative to employ more women. When our last Accelerator member joins in mid-July, 25% of Atoms will be women. Four years ago, that number was only 9%. We’ve gone from 1 woman maker to 9, and from 3 to 15 women overall.

We’re still moving toward more balance, but this milestone feels like a good time to celebrate progress and take stock of what got us here.

At First, We Failed

Our recent success comes after an earlier initiative that failed. Back in 2006, when the company was only five years old, I realized how very male Atomic was (one woman working part-time; no women makers), and I said we should change that. As a former professor, I was well aware of the gender imbalance in computer science programs.

That year I created, and Atomic hosted, the first BitCamp program. Inspiring 8th grade girls towards careers in software wasn’t ever going to be a short-term solution to our hiring challenge, but it felt like a good thing to do. SoftwareGR now runs BitCamp, hosting several events a year at many companies.

But while BitCamp was a success, we made very little progress on increasing the number of women we employed. In hindsight, I didn’t do a good job explaining why I believed it was important. I’m not sure I even fully understood why it was important. I got limited buy-in and quite a bit of pushback. Involvement was very limited. I didn’t define or publish our progress. I never stopped feeling the goal was important, but I didn’t do a good job keeping it top-of-mind in the company. I hid behind the stats of our local universities’ low enrollment of women in computer science programs.

What We Did This Time

Making progress has required a considerable investment in time, money, creativity, and effort over the last few years.

1. We changed the conversation.

I believe we were successful in hiring, first and foremost, because we made it a company priority, and got broad support and help. To get that broad support, we:

• Narrowed our goal from “improved diversity” (as that can mean a lot of things) to focus on gender diversity, and explained why.
• Described the business advantages we were seeking (see section below).
• Dedicated an Advisory Board meeting to getting feedback and alignment.
• Distinguished between efforts we made for societal good, and those we made for our immediate benefit.
• Decided how to measure progress (overall % of women as our primary KPI), and started publishing our progress on our website Diversity page.
• Published a series of blog posts on our initiative.
• Regularly shared educational articles and opportunities with the entire company.
• Kept the initiative and our progress visible through standups, company meetings, Slack, and email.

2. We made structural changes.

We also found we had some structural changes to make. By making these changes we freed ourselves from an unnecessary ball-and-chain that would have slowed our progress. Early on, we:

• Revamped and routinized our approach to compensation. Taking away the expectation that employees initiate and make a case for themselves for raises is appreciated by anyone who doesn’t like talking themselves up or negotiating.
• Significantly improved new parent benefits. We want to retain valuable employees and young parents by supporting them when they really need it, at the birth or adoption of a child.
• Changed our operating agreement to allow for part-time shareholders. Atoms looking to combine child raising and career (often, women) shouldn’t be locked out of shareholding through our operating agreement.

3. We changed our language.

• Reviewed and modified our hiring artifacts (ads, job descriptions, web copy) to remove any language that might discourage women from applying.
• Reviewed and improved our diversity statement.
• Updated images on our website to better show our current gender balance.

4. We reached out.

Structural changes and communication wouldn’t have been enough. We needed people engaging and taking action—reaching out to women in the community and encouraging them to join the Atomic team. To that end, we:

• Sponsored and attended conferences focused on women in computing.
• Sponsored and hosted women-in-computing groups and a lecture series.
• Made hiring more women a priority for me, our Managing Partners, and our Accelerator Lead, and invested senior leadership time in strategic recruiting.
• Got broad participation from the company in sponsorship, educational, and recruiting efforts.

How broad was the awareness and participation? I did an anonymous survey of the company and asked two simple questions. 95% of Atoms responded “yes” to the statement, “I am aware Atomic has an initiative to increase the number of women we employ.” When asked to self-evaluate their own involvement in the initiative, 39% responded either “moderate” or “high”.

Why We Care about Gender Diversity

18 months ago, I kicked off the public portion of this project off with a blog post called “Gender Diversity Makes My Company Strong.” Here’s a summary of my reasoning.

Diversity creates better products.

Everyone uses software. It’s easier to relate to and represent people like ourselves. Having both men and women on product teams, therefore, creates better a product for every end user.

Diverse teams are smarter, more creative, and operate differently than homogeneous teams. Gender is not the only dimension of diversity for which this is true, but I believe it applies.

Better products helps our clients succeed, and thus achieves our mission.

Diversity improves company performance.

Companies with more gender balance, and women in leadership perform better on a variety of traditional measures like profitability, revenue growth, etc.

Companies with women in leadership approach risk differently and think about employees differently. Having these differences influence the company makes us stronger.

Homogeneity is a risk to the long-term survival of many things. I believe gender diversity makes us more robust in the face of future challenges, threats, and opportunities.

Diversity improves society.

The under-representation of women in our profession smells like an impingement on liberty, and that’s something bad for all of society.

Onwards!

We’re not done with our initiative to employ more women. It’s still an active company priority. We’re still investing substantial amounts of time, money & energy.

But we’ve made major progress, and I think it should only be getting easier. This year, 3 of 5 members of the Grand Rapids cohort of our developer Accelerator program are women.

Comparing our efforts in 2006, and what we started four years ago, in 2013, I think it’s pretty easy to see why one failed and the other has succeeded. I hope sharing our progress, and how we’ve made it, helps other companies looking to improve their gender balance.

The post A milestone reached in Atomic’s goal to employ more women appeared first on Great Not Big.

      

Related Stories

• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires
• Sustainable pace is a smart long-term strategy

 

Everyone who works at Atomic as a full-time employee has the expectation of colocating with their team in one of our two offices in Michigan. This expectation rubs against a common industry trend toward decentralized teams with members in a diversity of locations.

To many in our industry, expected colocation seems like an antiquated or uninformed requirement to place on an organization. They say that if we didn’t expect colocation:

• It would make hiring so much easier.
• People would be able to get more done from home, free from the interruptions of the workplace.
• It would increase retention because we wouldn’t lose quality makers who want to explore different living situations.
• Our staff wouldn’t lose so much time commuting to a brick-and-mortar location.
• Our company wouldn’t spend so much money on creating and maintaining a physical space.

Going remote is something we’ve considered in the past. But in looking at each of those assertions in the context of the work we do at Atomic, the way in which we’ve chosen to do business, and where we’ve decided to be, the best decision for Atomic, our employees (and owners!) and our clients is to expect colocation.

Hiring

It’s true that opening up your talent pool to the entire world is a tantalizing prospect. I can think of people all over the world whom I’ve known and worked with who I think would be a fantastic match for Atomic Object. Wouldn’t it be great if we could hire the best people and not just the best available people?

Here’s the thing: I would rather have the best team than the best people. And I think teams work best when they are in the same place at the same time. Communication is better. Feeling is better. Efficiency is better. Chemistry can form.

But this takes time. If that team is distributed, the team might not form chemistry at all. If it does, it’ll take a lot of time and effort. Way more than just being in the same place at the same time.

Interruptions

Is working in the office rife with interruptions? Absolutely. Are periods of extended concentration required for the creation of quality custom software? Absolutely. Does that mean that work from a colocated space isn’t adequate for software teams? Nothing could be further from the truth.

Interruptions may or may not add value. I’ll outline a scenario I see play out everyday in our offices. A maker team runs up against a really tough problem they don’t know anything about and set about triaging it. As they discuss it out loud, they are overheard by another maker on another team in an adjacent space. This maker jumps into the conversation and shares some hidden knowledge she had about the problem. This new knowledge ends up saving the first team hours—and sometimes days—of time and de-risks the project.

The adjacent maker was interrupted by something interesting in a discussion that had nothing to do with them. They interrupted another team with new information. That information at that moment added maximum value.

Now let me outline a scenario I’ve seen many times on distributed teams. One team member needs time with the rest of the team to evaluate a design solution. That member requests time from the team via a form of communication. Let’s say that communication medium is Slack. While waiting for a response, that team member is called away by some circumstance at home. Maybe a kettle is boiling over or a child requires attention.

Meanwhile, other team members respond with various times that work for them. As team members chime in, there’s a communication lag because the requester is no longer present. The requester returns to find that the rest of the team has jumped into a webex meeting to plan next week’s sprint. Now the requester won’t even be able to schedule that meeting for another hour. What a headache!

Scheduling a meeting becomes one big repeated interruption. This is a simple piece of communication that should be easily ironed out in less than 60 seconds. It ends up interrupting the entire team multiple times, and very little value is created.

Retention

Over the last 15 years, we’ve seen very few people leave Atomic because they wanted to live in another locale. A great majority of Atoms who have transitioned away from Atomic have done so in search of a different type of work within the tech industry. As retention isn’t really a problem at Atomic, I think this argument is a non-starter.

People who want explore a nomadic life while traveling the world probably aren’t a good fit for a consultancy for all the obvious reasons. We’ve chosen to found offices in attractive areas with a wide variety of different cultural possibilities. Both Ann Arbor and Grand Rapids are appealing to young professionals from a lifestyle standpoint. We think that work and life in these places is very interesting and can be explored for years without boredom setting in. A low turnover rate and growing workforce tell us that this belief is tenable.

Commuting

Long commute times aren’t really an issue singularly solved by colocation; they are a solveable consequence of a lifestyle choice. If you choose to reside far away from your place of work, I’m sure you’ve weighed the pros and cons of the consequences of that move. Maybe a long commute to an excellent job is acceptable. It very well could be that a long commute for an exceptional living situation makes sense. If, for you, commuting is toxic, then take a job that’s closer to home. Working remote isn’t the only solution to a long commute.

It’s also not completely clear that commuting is a problem in every case. We have Atoms who actually enjoy a longer commute as it gives them headspace to listen to podcasts, make phone calls, or spend valuable time with a loved one.

Physical Space

Having a consultancy without a home is a non-starter. Are we supposed to set up for a project kickoff in a Panera? I wouldn’t really look forward to asking the Panera manager if we could wallpaper a booth with butcher paper.

Some consultants work out of co-working spaces. I have to be honest–I think most co-working spaces aren’t nearly as nice the spaces we’ve made available at AO. And I don’t have to share a space with my clients and a bunch of random people.

I’ve led kickoffs with remote parties in the past, and it is astronomically more difficult to get people who aren’t in the room with you to stay focused on the task at hand. It’s also really hard to get complete information from people who aren’t present with you when they may have partial or incomplete information.

Many of the incredibly beneficial collaboration exercises we engage in with our clients require colocation. It seems like a huge adjustment to take that space away from a consultancy, scatter their team across the planet, and then expect to be able to engage with clients on specific projects.

Offices give teams a place to make their own. We recently underwent a workplace reorganization in our Ann Arbor office. Different teams wanted to purpose-build part of our space for their particular project. This resulted in individuals in the team becoming much more engaged in the team dynamic and the way they wanted to collaborate together. Different teams organized themselves according to their needs, optimizing for collaboration and a feeling of togetherness.

Some teams at Atomic elect to decorate their space according to a theme having to do with their project. A connected truck project might have a road-trip themed decoration. A resort management system project might have a tiki-bar theme. This sort of thing unifies our teams and honors our clients.

A physical space gives your brand a place to live together with the most important ambassadors: your team. Creating a space that speaks to the values and feelings your brand should evoke is essential to create a brand-unified team. If the team is distributed, you can still create a unified team. But I bet it would be interesting to sit down and talk with them about what your brand means and how it feels. There’s probably a lot of variance.

Really, maintaining a facility is a question of keeping your priorities straight. People are our most valuable resource at Atomic. Another resource is our space. In Grand Rapids, we bought a property where we have started building lasting equity for our employee owners. The new building also allowed us to re-imagine what a collaborative space custom-made for building software would look like. In Ann Arbor, we gutted our office and renovated it around our needs as a technology company.

In both cases, we prioritized people over facilities. No one took a pay reduction because of these investments in our facilities. Atomic continued to make a healthy profit share contribution to everyone’s 401k accounts. On average, Atomic spends 83% of total expenditure compensating our people. We spend 7% on facilities. Relatively, we feel these expenditures align with good priorities for a company of our type.

We don’t think that the value our company and our clients would get out of vastly reducing that 7% would be worth the extra money. We do think that having a great space in which to work on teams is worth that expenditure. We also think our clients appreciate having a purpose-built locale in which to interface with our teams.

Convenience

I’ll concede this one. Getting together isn’t convenient. Waking up in the morning, following my morning routine and then sitting down at my desk at home for work sounds pretty nice. Very convenient. Maybe I’ll go for a hike near my home with my dogs. At lunch, I can catch an episode of TV. Sounds great. But all that… sounds like a lot of value for me. What about my team members? What about my clients? Is there value in that convenient scenario for them?

It takes effort and dedication to be on a colocated team. At Atomic, we think that a convenient life isn’t something to optimize for. We want to put out the effort to work hard together. We get together every month and every quarter to celebrate together. Isn’t it more fulfilling to do something that hurts a little bit, but is worth doing? I think working together in the same place, at the same time, leads to valuable software products and a meaningful experience as a team member.

I’m curious–what has your experience on distributed and colocated teams been? What’s worked? What hasn’t? What problems have you encountered in both instances?

The post Why colocation? Addressing the objections to having a centralized team appeared first on Great Not Big.

       

Growth challenges the structure of any organization. In my experience, it’s easy to let those changes sneak up on you. As part of our recent work on structure, we’ve decided to adopt the “consultancy matrix” that Shawn Crowley’s written about recently.

One of the early milestones in our recent structure refactoring journey was to identify what I call the architecture of our company. Our architecture is simple, with just four abstractions, and clear relationships between them. But like our vision to be a 100 year old company, it’s proven surprisingly useful in making day-to-day decisions. Just like with software, having the right abstractions and relationships makes implementing a system feel easy and natural.

Abstractions

Here are the four abstractions in our company architecture. We refer to our architecture internally by the acronym ATOC, pronounced “ay-tock”.

Atom

The individuals of Atomic.

Responsible to:

Satisfy our few, basic, expectations. Solve problems for clients, create great products, and/or keep the business running. Seek mastery of their craft. Gradually but continuously improve themselves. Share and live by our six values. Work autonomously and collaboratively. Resolve their Fear, Uncertainty, Doubt, and Anger. Give and receive feedback effectively. Innovate. Help market the company. Think like a consultant.

Team

A group of Atoms with a clear purpose.

Responsible to:

Deliver on our two-sided brand promise: great product for the client, great project experience for the customer. Self-manage. Spend wisely. Be predictable in time and money. Create value. Innovate. Organize work in projects. Collaborate.

Office

A co-located group of Atoms, and the physical space where they work.

Responsible to:

Provide a comfortable, safe, inspiring space for teams. Keep makers busy on client work. Sell our services. Contribute to and engage with the local community. Grow individual Atoms. Socialize.

Company

A service provider to Atoms, Teams, and Offices.

Responsible to:

Tell the company story effectively. Keep the books straight. Manage ownership matters. Select and hold office leadership accountable. Represent the company as a whole. Maintain and communicate vision, mission, and values. Push when and where necessary. Make investments for the future. Manage structure and growth. Define and maintain legal entity, brand promise, service offering, employee benefits, and expectations.

What it Looks Like

Here are a few different ways of representing our architecture graphically. The first is suggest the compositional relationship of the abstractions. The second is inspired by a network protocol stack. Neither is a perfect representation, but both capture some important aspects of the architecture.

Utility of Our Architecture

If our ATOC architecture wasn’t useful to us, it wouldn’t be worth naming, or writing about. Utility means helping us make business decisions, clarifying responsibilities, suggesting possible growth paths, and flagging things that don’t fit. Here are some examples of that utility.

• Scale – Adding offices would appear to allow the company to scale 2-4x without restructuring.
• Brand – Each office conforms to the same brand promise and brand standards, as defined by the Company.
• Accountability – Managing partners in one office neither report to nor are responsible for other offices.
• Hiring – Makers in one office shouldn’t influence or be responsible for hiring makers in another office. Hiring standards and employee expectations should be the same.
• Project Management – Project management is a maker role within the team, not an independent role outside the team.
• Profit Sharing – Profit sharing should be aligned with the autonomy and performance of an office. (This is an example of ATOC pointing out an inconsistency in our legacy structure; we have a centralized profit sharing scheme.)
• Facilities – Facilities management and improvements may be outsourced, but ultimate responsibility lies with Office leadership.
• Budgets – Teams, whether internal or external, manage their own budgets. Work is organized in projects, whenever possible.
• Space – Office headcount is constrained by physical space and office leadership capacity.
• Skills – Reference checks and so-called “soft” skills count as much or more more than technical skills, given our model of highly collaborative teams directly connected to clients.
• People – Atoms are our only tangible asset with the potential for creating future value. We should invest in them accordingly.
• Solo Work – Atoms working alone consistently will feel isolated and culturally misaligned.
• Location of People – Remote workers don’t match the definitions and dynamics of Team and Office.

Like any abstract architecture or taxonomy, there are a few exceptions and corner cases that don’t fit perfectly. We don’t let these small deviations from the model get in the way of the overall value of the model. Our model is powerful both in what it suggests as good decisions, and what it flags as potentially bad decisions.

The post What identifying a company architecture did for us appeared first on Great Not Big.

       

The longer I’m in leadership, the more I become aware of a simple, but harrowing fact: The best leaders in business improvise. A lot. In fact, having a detailed, multi-step, multi-phase plan can be dangerous for any organization.

I do believe that every organization needs a clear vision and mission. And that having specific, measurable key performance indicators are important. But a step-by-step plan for how to get from where you are now to where you want to end up can be the enemy of organizational innovation and change.

A Musical Analogy

To be able to compare and contrast approaches, I’d like to draw on two genres from the world of music.

Classical Music

Classical music is wonderful, but it’s also rigid. The destination of each classical piece is predetermined—we know exactly how it will end. We also know what will happen from start to finish because everything in between is orchestrated. The individual members of an orchestra are highly trained professionals, led by a single conductor who moves them through a written piece of music with a flick of her wrist.

How has classical music evolved or changed over the centuries? Very, very little and very, very slowly. So slowly, in fact, that the different periods in classical music are measured in centuries, not decades. The instruments used are largely unchanged from the ones used hundreds of years ago. I would venture that the genre, as a whole, is backward facing. The names of the past endure while many of us would struggle to name more than three 20th century classical composers, let alone a single 21st century one.

Classical music is beautiful and emotive. It’s incredibly effective for what it is. But is its rigid structure something we should emulate in business?

Jazz Music

Now let’s talk about jazz. It’s fluid. Sometimes, it feels dangerous. We don’t really know where it will end up, and we aren’t sure where it will go in between. Every live performance is witness to wonderful feats of creativity as the music ebbs and flows. The initiative within the group is passed from member to member. Every member of the group is empowered to start something new, change direction or stop at any time.

Jazz lives on the edge of chaos and order, but somehow the genre does not devolve into disarray. Instead it continues to evolve. Many music historians believe that since its inception in the late 19th century, jazz has given rise to multiple new genres of music including rock-and-roll and hip hop. It’s subgenres are measured in years and decades. It is truly a forward-facing, vibrant genre of music.

So when I say that the best leaders improvise, I’m pointing to the difference between classical music and jazz. A multi-phase approach in which everything is clearly defined and carefully scoped is not a signal of imminent success. I don’t think that an organization run by a conductor who only needs a team to fulfill a carefully crafted plan is a long-term model for building a vibrant and innovative culture.

Jazz Principles for Business Innovation

In his book “Jazz Process”, jazz musician and software development manager Adrian Cho puts forth five principles jazz groups employ that translate to organizational leadership. They form a way of working and performing together that leads to creativity, innovation and, ultimately, organizational vibrance.

I’ve seen many of Cho’s principles at work in Atomic. I’d like to suggest a way forward in between the chaos and order highlighted above. As we walk through each principle, let’s remember that the focus of each one is to propel our organization ever forward toward our vision and goal while maintaining organizational life.

1. Have just enough rules.

Rules are essential to the life of any organization or group. Without rules, chaos descends–even in jazz. Typical rules from jazz groups are: “take measured risks,” “make contributions count,” and “stay healthy.”

Nevertheless, too many rules can get in the way of execution and stifle autonomy. Have just enough rules balances confusion and efficiency, allowing a group to maintain order while allowing for smart people to do their jobs well as they see fit.

At Atomic, we have surprisingly few rules. They are succinct, clear and measurable. And they’re not arbitrary; instead, they aim to maintain just enough order to keep Atomic and its members healthy and happy:

• Show up for standup every morning (because we believe working together and being available for one another leads to more efficient, quality work for our teams and clients.
• Work a sustainable pace at a full-time job (because we believe our people are our most valuable resource and that we owe it to our teammates and clients to pull our weight every week).
• Contribute to Atomic Spin every 45 days (because it is one of our best marketing tools).
• Track your time accurately and every day (because it is the lifeblood of our company).
• Take your vacation every year; rest (because this adds to our personal and organizational sustainability).

Following these rules is necessary to avoid organizational chaos. But have more rules than these, and we run the risk of strangling creativity and innovation in our company.

2. Employ top talent.

Custom software and jazz both involve a lot of improvisation. Even though a jazz piece can be composed and follow a certain pattern, there is always a fair amount of latitude for the artists involved to interpret the score as they see fit. As a result, a top jazz ensemble needs to be made up of talented musicians who are not just able to follow the music on the page, but have enough mastery of their craft to be able to diverge from what is on the page. They need to have the individuality and creativity to be able to imagine the spaces between the measures on the printed page. They also need awareness of what’s going on around them in the group. A music teacher of mine once said that “20% of making music is execution. The other 80% is listening.” The members of a jazz group must be tuned in to their team and their audience.

In the same way, custom software usually follows a certain patterns. The problems we solve with software almost always have commonalities. But the problems we solve always require different, custom solutions—even when those differences are subtle. Accordingly, to solve those problems, the members of a custom software team are going to need to possess a certain amount of mastery, individuality, and creativity, enabling them to depart from the common patterns to reach out toward a novel solution. They also need to be aware of changing conditions in their team, with their client, and in the world around them.

At Atomic, we believe that skill mastery can be taught (our Accelerator program is designed to impart mastery over a period of two years). But we don’t believe individuality, creativity, and emotional awareness can be easily imparted. Therefore, we’ve tailored our hiring process around uncovering designers and developers who are unique—who have opinions and are curious about the world around them. They are sensitive to the room.

Throughout the hiring process, we put them in situations where their creativity can shine and they can showcase their own empathy. We also carefully measure the degree of mastery of craft they currently possess so we can gauge what sort of investment we’ll need to make in them to get them where they’ll need to be to perform well as part of our team.

Many have said that our hiring process takes too long or too careful. We disagree. Our hiring process is what it is because we must employ top talent for our client teams. We’re solving very complex problems. A team of individuals who know how to string together a bunch of prepackaged solutions (black boxes) won’t be able to solve those types of problems well. Custom software requires curious, unique individuals who can creatively frame and solve problems. Settling for the former over waiting for the latter just sets us up for pain sooner or later.

3. Put the group first.

Of course, there’s a real danger in only seeking high-performers or “A-Team” players—ego. The potential for strife and a “me first” attitude is very real. Even the most talented virtuoso cannot outperform a team of individuals who have decided to suppress their own ego for the sake of the common good.

Mutual Accountability

In successful jazz groups (and sports and software teams), the members of the whole are accountable to each other, not just to their leaders. At Atomic, I see this prioritization daily. Members of teams share the pain equally with their teammates because they care about them as people. They don’t want to let them down. Often, this type of effort doesn’t come up to the attention of leadership until a post-project retrospective when one team member shows appreciation for another. We don’t go the extra mile for recognition or some misplaced desire to differentiate ourselves from the rest of the group. We do it because we care about the team and don’t want to let them down.

Mutual Responsibility

Another way we put the team first at Atomic is by absorbing mistakes together. Things go wrong in custom software; it’s just a fact of life. We’re solving complex problems and sometimes the best laid plans run awry. When that happens, from managing partner down to the newest designer, we have each others’ backs. We don’t throw anyone under the bus. The team succeeds and takes credit together and the team fails and takes blame together.

The Lure of the Status Quo

One potential pitfall to our team-first approach is the propensity for the collective consciousness of the whole to discourage innovation. Being a cohesive whole is absolutely essential to good teamwork, but it can lead to a feeling of safety in the known and a lack of curiosity. A lack of inquisitiveness and a commitment to the status quo has led to many disasters in recent history (the Space Shuttle Challenger disaster in 1986, the invasion of Iraq in 2003, and the collapse of some of the western world’s largest companies due to rampant fraud to name a few). The signs that could have stopped any of these things from happening were all there for an inquiring mind.

One of the things I appreciate about leadership at Atomic is a purposeful openness to improvisation and experimentation. We often say we’ll try anything that makes sense. If, when tested, the idea has merit, we’ll keep it. This sort of openness to new initiatives is essential to maintain the innovative spirit we are proud of at Atomic. It also keeps our talented individuals engaged and empowered.

4. Build trust and respect.

As human beings, we are all wired in one way or another to work together with other human beings. Within this work relationship, we all have varying levels of trust in those around us. In a highly performant jazz group or on a crack software team, a member has to be able to trust others to do their jobs and respect their ability to perform. The other members of the group have to live up to the trust and respect deposited in them. If not, things quickly break down. Members become nervous and suspicious of one another. The blame game can break out and quickly the group becomes fractured.

Trust through Transparency

One of our value mantras is: “Act Transparently“. We believe its makes sense for everyone—transparency allows us to make smart business decisions in our own interest and those of our clients sooner rather than later because we are aware of changing project circumstances. But I would say that the biggest benefit of our practice of acting transparently lies in the fact that it inspires trust and respect throughout the organization. Want to build trust and respect in your organization? Act Transparently.

Trust through Hard Work

Another way to build trust and respect that I see at work at Atomic often is to understand what the basic expectations of you are in a given situation and then go above and beyond that. Should this server bug be finished by the end of the sprint in a few hours? I’m going to fix this server bug and get some feature work done as well. Does my team need a prototype to be able to validate a feature with a client? Then I’m going to make sure the work I do on that prototype will also be production-ready HTML and CSS that will save my team time. In a jazz group, it’s the basic expectation of a bassist to keep harmony and rhythm for the group. If a bassist isn’t able to meet this basic expectation, the rest of the group will lose trust and respect in the bassist. However, if the bassist can keep rhythm, harmony and fill in gaps with flourishes and the occasional solo–trust and respect in that individual will increase.

Trust through Leadership

As leaders, we can build trust and respect within our organization by acknowledging efforts and results. Never tacitly take credit for something someone else did. Give credit where credit is due. If you don’t, your team’s trust and respect in you will be diminished. They will question whether putting in extra effort is really worth it. If you do acknowledge efforts and results, they will trust and respect you and each other more.

Have you ever noticed that jazz groups have an encouraging performance style? They shout out encouragements to each other throughout a concert. “You got this!” “That’s right!” “Hit it, man!” And, without fail, everyone in the group is introduced at some point in the concert. Even Miles Davis always introduced his band.

5. Commit with passion.

Jazz and custom software exist in a world rife with unknowns and constant change. In this type of atmosphere, it’s essential that members of those teams commit to the common cause with passion. At Atomic, we call this “Giving a Shit“.

A jazz musician who isn’t fully committed to a group or a piece of music falters. Their own lack of confidence in the current context is communicated to other members of the group and indelibly apparent to the audience. The same thing happens to us as software consultants. If we are committed to our project and our team, our confidence transfers to those around us—teammates and clients included. The more senior we become, the more creative confidence we have that no matter what difficulties come, we will be able to see the project through to completion.

Because of my experience and background, I end up mentoring other designers in the craft of workshop facilitation. One thing I always tell people who are hesitant about getting up in front of a group of people to lead them through a discovery workshop is that you are telling these people a story they’ve never been told before. If you have a misstep in front of them, they’ll never know unless you let them know. And you let them know by losing momentum or faltering. But if you passionately commit to everything you do, even the missteps, they can often take you to interesting places you’d never have gotten to otherwise.

As Miles Davis is purported to have said, “There are no mistakes in jazz—only opportunities.” In jazz, an artist is empowered to creatively innovate before a watching audience. The possibilities of a slightly off-key note or a late entrance are high. The same thing happens in custom software. Bugs can be introduced. Mistakes can be made. But be willing to make those mistakes and commit to the task at hand. Your passion for your craft, team, and project will carry you through those moments.

Closing Notes

I’m fortunate to work in an organization where I can see these principles in action on a daily basis. We perform together as if in a jazz ensemble. We’ve got a general idea of where we want to go, but we have freedom to end up in unexpected places along the way. When we started our efforts to become the first 100-year-old software company, I don’t think we thought we’d incorporate design, start a two-year post-college-prep program for CS grads, or even have an office outside Grand Rapids. But the fact is that we’ve maintained openness to improvisation along the way by adhering to the 5 principles outlined here. I’m proud to say that these principles have maintained vibrancy and innovation across the organization over almost 16 years.

The post Jazz and the software company – A choreography of chaos and order appeared first on Great Not Big.

      

Related Stories

• A milestone reached in Atomic’s goal to employee more women
• Firing people: feelings, perspectives, and practical advice
• Succeeding with outside leadership hires

 

Atomic is an intentionally-general software product development consultancy. We’ve found success through technology and client diversity. Instead of focusing on a single industry or technology or client, we concentrate on the aspects of software design and development that cross-cut project success — things like work process, programming, design, testing, project management, toolsmithing, communication, teamwork, and culture. In addition, we intentionally manage how much work we do for any single client.

I believe our client diversity strategy is largely responsible for many good things, including sixteen years of organic growth, consistent profitability, and no layoffs. This post is my analysis of our 2016 clients and the $8.6M in revenue they represented for us. I’ll wrap up with the high-level, long-term financial results I partially attribute to the strategy.

Client Diversity

In 2016 our clients fell into 27 distinct industry classifications. (Note that this is my own scheme, not the SIC code or something more official.)

Revenue by Industry

If you look only at the top (by revenue) classifications you see that 80% of our revenue in 2016 came from seven industries. These top industries change for us year by year, depending on who we happen to work with, but what’s common over the years is the range and roughly even distribution. With roughly 50% of our revenue coming from clients in our home state of Michigan, you can also see our midwestern industrial roots in last year’s client diversity strategy.

Revenue by Client

We tackled the problem of client over-reliance early on. While we’ve never been harmed by doing too much work for a single client, the risk is an obvious one, and I’ve heard plenty of sad stories, even to the point of company destruction.

The chart below shows a histogram of the 57 clients we worked with in 2016, with client name replaced by their industry classification. Our top four clients accounted for 50% of our total revenue. The top 14 accounted for 80% of our revenue. The amount of our capacity we allow to go to any single client is a key part of our client diversity strategy.

The final bar represents 32 clients each less than 1% of our total revenue. While some may be tempted to look at that long right tail of clients and suggest simplifying our lives by chopping it at projects under a certain dollar level, I see something different. Some have been major clients in the past. Some may be major clients in the future. Every one of our clients needs the help we provide. If all 57 of them are happy and finding success with our work, that’s a lot of people saying nice things and a lot of valuable word-of-mouth marketing.

Revenue by Platform

Our generalist approach extends to technologies. While “platform” is a squishy concept, I defined it as follows:

Web

Classic apps intended to be used on desktop browsers

Mobile

Primary user interaction on a smartphone, regardless of underlying tech (native, responsive web, cross platform, etc)

Tablet

Primary user interaction on a tablet, regardless of tech

Desktop

Platform of yore; software that used to ship on CDs

Embedded

The applications all around us that people don’t think about as computers; firmware

IoT

A project with elements of all of these: special purpose devices, sensors, embedded, web and/or mobile

The pie chart below shows how our revenue was distributed by platform, for the clients comprising 80% of our revenue. The shades-of-gray color scheme seemed particularly appropriate given the ambiguous nature of “platform”. (What are Chromebooks? What about responsive web? How about a React Native app? Is Ruby on Arduino embedded?)

The IoT systems we build are particularly vexing. Four of the fourteen clients that comprised 80% of our revenue hired us for IoT projects. Is that a platform now?

The technologies underlying my platform classification scheme are constantly evolving. Embedded was unusually small last year; good thing we employ generalist software developers.

Financial Results

• In sixteen years, we’ve never laid anyone off for lack of billable work. I’m not aware of any other consultancy that can make that claim. We’ve also seen plenty of our clients be forced to downsize at times over the years.
• Our compounded annual growth rate since our first full year of operations (2002) is 22.4%.
• There have been only two years (2009, 2015) when our revenue was slightly down from the previous year.
• Our 2017 revenue will be 21x our 2002 revenue.
• The average of our annual net margin over those 16 years is 24%.

This enviable financial track record stems from getting many things right, and recovering quickly from the many things we got wrong. But if I had to name the most important aspects underlying these results, I’d point to client diversity and our focus on product development over technology.

This strategy is only possible because of the curious, smart, dedicated, flexible people we hire. Success with client diversity means makers who learn new domains quickly — experts at becoming experts, always sharpening their own saw. It means managing partners who can learn a client’s business quickly, formulate a compelling approach to a problem, and determine a responsible project budget. It means marketers who find creative, effective ways of telling our story without a focussed offering or specialization to lean on.

If you’re currently a specialist shop, it may be difficult to follow this strategy. On the other hand, any firm can follow the common-sense advice of avoiding over-reliance on a single client.

The post Client diversity drives good financial results appeared first on Great Not Big.

      

Related Stories

• Jazz and the software company – A choreography of chaos and order
• Visualizing Cash Flow for Shareholders with a Cash/AR Graph
• Thinking Long-Term: Atomic Object’s 100 Year Birthday