Angelique Jenney is the Director of Family Violence Services for Child Development Institute, a multi-service child and family agency in Toronto, and is an Assistant Professor at the University of Toronto. Angelique has over 19 years experience engaging both victims and perpetrators of family violence in intervention and prevention services within the violence against women and children’s mental health sectors.
The estimates. Good gravy, people, the estimates. Is there anything more terrifying in this business than when you have to go on record saying how long it’s going to take to do a thing that (frequently) you’ve never done before? Estimates, after all, are the logical result of a series of questions that raise more questions. “How much will this cost?” leads to “What is it we’re doing?” which is followed by “How long will it take?”
And no matter how risky it may seem to come up with answers to this last question, it’s an expected part of the client services business. How else would our prospective clients know what they’re going to have to pay us? Without this knowledge, they’d likely never take the leap and agree to become actual clients. (Which, as you may know, is kind of important to this whole thing we do.)
Likewise, without good estimates, we can’t schedule our time. We wouldn’t know when projects end and when new ones can begin. Kind of crucial, right?
So why does estimating incite such raging fear in our hearts?The problem of accuracy
Quick show of hands: who thinks they’re really good at creating consistently accurate estimates? Yep, that’s what I thought.
The quality of an estimate stems primarily from how closely it represents reality. There are several challenges to creating accurate estimates.
My experience is that most estimates (particularly those that are written with less experience to back up their assumptions) come from a place of optimism. We imagine doing a series of tasks in the best possible circumstances. We ignore unknowns, and all the resultant extra work that may arise from them.
Sadly, this is rarely representative of the world we live in, and leads to underestimating.
On the other hand, perhaps we’ve had a very difficult experience with a similar task. Perhaps it was due to circumstances that, though they were truly miserable, are unlikely to be repeated. In that case, our historical anxiety comes rushing to the fore and unrealistically colors our expectations, causing us to estimate far too high.
Or—as is often the case with unique and complex problems—if we have very little experience to draw on, we may simply take a shot in the dark. Have we estimated too high? Too low? Who could possibly know?
There are, thank goodness, a few things we can do to alleviate these problems. So let’s look at two possible ways to go about it, which I’ll refer to as “scope to time” and “time to scope.”Scope to time
The scope to time conversion is a pretty standard, traditional estimating exercise. Given some fixed scope of features and deliverables, how long will it take to perform each task? For websites, we try to understand scope-defining things like:
- How many templates are we designing?
- How many rounds of design revisions?
- What are the development features (e.g. is there a newsletter sign-up, a t-shirt purchasing system, integration with a fulfillment house API, etc.)?
- What are the limits of browser testing (e.g. IE6, IE7, IE8)?
Once we think we understand all the things we’ll have to do, we try to make up numbers that represent how long it will take to do each thing. But before making a calculation (or guess), we must first think about what kind of timescale we want to work with.That timescale tho
Timescales are lenses through which we can look at a task. I’ve found that which lens we choose can have a profound effect on our estimations.
Consider a task such as creating an element collage for a new client. We could potentially estimate time in terms of minutes, hours, days, weeks, months, or even years. Let’s take the extremes first. How many minutes does it take? I don’t know. Lots. How many years? I don’t know. Some small fraction, I guess. OK, how many hours? 10? 15 maybe? 8? Those all sound kind of right. Days? Well, 2 to 3 sounds good.
But 2 to 3 days at 6 hours each is 12 to 18 hours. Which is higher than 10 to 15. So which is right? My hunch is that when we think about an hour, we’re not looking at the right scale. Because the difference between a good hour and a bad hour can be wildly different. I’ve had an hour where I’ve accomplished almost nothing tangible. I tried things that failed; I got stumped on some problem to which an answer revealed itself only later; I was maybe just in a bad mental space at that time. I’ve had other hours where I’ve had great insights, closed ticket after ticket, made a huge dent in a project. The thing is that every day is made up of some of both of these hours. So when I think about what I can get done in a certain timescale, I remember that a day or a week is made of good and bad hours, and what that averages out to. What can I do in an hour? Somewhere between very little and a lot. In a day? A reasonable chunk of a thing.
On the other hand, at very large timescales—say months or years—my brain starts telling me that the chunk of time is approaching infinity. What can I do in a year? Everything! Which of course is not true, and is in fact a very dangerous assumption to make. Even very big numbers have an end. And to find those ends, we need to ratchet down our timescale.
This is why, in general, I find the middle timescales (days and weeks) the best for conceptualizing how much we can get done. Questions like “How many days will it take to build out a feature?” or “How many wireframes can I complete in a week?” tend to get me on the right path.
In addition to that, experience can help a lot. The more work we complete in our careers, the more data we potentially have to check our assumptions.Condemned to repeat it
So we think it takes two to three days to make an element collage. Great! But is this our first time at the rodeo? If we’ve done element collages before, and—here’s the kicker—if we’ve accurately tracked our time in the past, we can compare this estimate to our record of the actual hours we spent the last time.
This is why I encourage a policy of tracking time spent on tasks. You can make a habit of running a timer (at Bearded, we use Harvest, but there are others, such as Freshbooks and TimeTracker), and switching that timer with every task switch. The motto is ABT—Always Be Tracking.
Now if we think our mental model of how long it takes to do a thing is way off, we can confirm our hunch by looking at historical numbers, and correct that mental model for the future. It can keep us from under- or overestimating the same thing over and over again. Which is nice.Delta delta delta
Another way to check our assumptions, especially in larger groups, is to compare independent estimates done by multiple people. Seth Brown, COO of Lullabot, explains how he employs this approach:
Typically we try to work either on a retainer or an hourly basis, however clients often need to have an understanding of what the retainer length might end up being. We tend to decompose projects into bite-sized chunks, first epics, and then tasks, and then estimate those with a group of developers on our team. Each developer does a blind estimate for each task and then we compare everyone’s guesstimates. If the “delta” between each developer’s guess is large we discuss assumptions, ask questions if we have to, and then re-estimate.
This approach can certainly minimize risk. If two independent people think a task is easy or hard, it’s more likely to be the truth. And if they disagree, then a deeper discussion will likely lead to a better definition of scope.Things fitting into things
Some tasks scale up or down with the scale of the project. Project management and meetings are perfect examples. For instance, when we estimate an hourly project at Bearded, we like to add 15 percent for project management to the grand total estimate. That way, more project scope results in more hours to manage that scope. Seems reasonable, man.Time to scope
Defining scope and converting that to an amount of time is one way to do things. But you can also go the other way, and there are some very good reasons you might want do that.Constraints are your friend
When was the last time a client showed up on your doorstep with infinite weeks and infinite budget to complete a project? Usually at least one of these constraints is in place. Great! So if they only have eight weeks before some event requires the delivery of some solution, then that’s what you have to work with. You know how many people-hours you can devote in those eight weeks, and that time constraint determines the maximum effort and cost. The next question is: What’s the most valuable way for everyone to spend their time during that timeframe?
Likewise if they have a budget of $100,000, just divide that by the team’s weekly rate and you know the maximum number of weeks they can afford. Then it’s time to answer that same question: How can we best spend our time to maximize value for that client?Talk it through
Not surprisingly, this often becomes a conversation. Though sometimes a client is reluctant to divulge their budget (often out of the belief that a vendor is just trying to get the biggest number possible out of them), I find that telling them our weekly rate up front engenders some initial trust. At that point the mechanics of our cost are exposed, and we’re simply trying to figure out—together—how many weeks of our time they feel comfortable paying for.It’s all about trust
In these scenarios, the scope and work products tend to be more open-ended. We’ll have a prioritized list of things to work on, and we’ll work our way down it—with the understanding that the list may change as we gain more knowledge and new facts present themselves throughout the project. Again, we’re always focused on maximizing our value to the client, so if something more important has appeared, we won’t just keep plugging away at a task because that’s what the contract has bound us to.
This approach tends to bring us closer to an agile process, where our ship date is fixed, but the work product and deliverables are variable. This approach requires a certain amount of trust and empathy on both sides. Everyone needs to understand that none of us can guarantee exactly what’s going to be delivered at the end of the engagement. It may be scary, but this uncertainty is tempered by a different kind of increased control on the client side: they can continue to reprioritize and redirect us throughout the project, without negotiating change orders.
That isn’t to say we rush into these projects with no plan. Far from it. But we admit that our plans are imperfect and subject to change. Frequently we begin these projects with a research phase to define the rest of the project (or perhaps to define a second phase).
The big question in this kind of arrangement, then, isn’t “Will we ship that thing on time?” Rather, it’s “Is the work we’re doing worth more than the money our client is spending on us?” If the answer is yes, then the value is clear, and the details about the exact work product or deliverables become less important. If the answer is no, then it’s likely a bad match and you should shift your focus, or they should look for another vendor.Easing the pain
It’s not just in estimating scope that we encounter trouble. As Woody Allen famously said, “If you want to make God laugh, tell him about your plans.” No matter how we go about making estimates of things, it’s rarely foolproof.
So what else can we do to ease the pain of estimating?Plan for the fan to be hit
For one thing, we can plan for what to do when things go worse than we imagined. In my experience, people who build things (web things included) are often optimists. Why else would we agree to dive into the unknown again and again with each project?
Paul Ford’s epic article for Bloomberg, “What Is Code,” sums up the problem of estimation optimism fairly well:
You ask the universal framing question: “Did you cost these options?”
He gives you a number and a date. You know in your soul that the number is half of what it should be and that the project will go a year over schedule.
Clearly, we must plan for when things go less than ideally.
In hourly projects, we borrowed an idea from our friends at Sparkbox and include a 20 percent contingency budget on every project. The contingency budget is a line item like everything else, but we never track time against it. It just balances out against overages from other line items. It covers our butts when things take longer than expected.
Likewise on weekly projects, it often makes sense to not densely pack every week of the schedule. Having a penultimate week on the project that’s focused on things like “polish” or “fit and finish” can keep you out of trouble when something goes awry. And if everything goes smoothly, great! When could you not use an extra week to tighten the screws, refine UIs and interactions, test on a few more devices, or create documentation for the client team and—heck—your future self?Reaching across the aisle
Something that makes almost any project better—regardless of process or format—is good, open client communication. Why not extend this approach to the estimating process?
Says Ben Callahan, president of Sparkbox:
Lately we’ve been experimenting with an idea called “Collaborative Pricing.” It typically starts with an email from a potential customer where they’re answering a few key questions about budget, timeline, and scope. Our next step is to clarify any major questions we have based on the information we’ve been given. Then we’ll quickly put together a Google Spreadsheet that breaks down the work in a way we believe is reasonable given our current understanding… The idea is that we can work with our clients to find a budget, scope, and timeline that is mutually beneficial. We use Google Spreadsheets because it allows real-time collaboration but is also intuitive for anyone familiar with Excel or Numbers. The most helpful part of estimating in this way is that it makes the very first interaction we have with our customer one of collaboration.
Sounds pretty great, right? It encourages our clients to start prioritizing their resources (us) from the beginning. Do they want to pour extra hours into one feature instead of another? Do they want to cut something that doesn’t seem worth it, so they can add more budget to another area? Can they take a section or set of tasks off our plate (for instance, usability testing recruiting or QA) because they can assign internal resources to cover it?
Exposing the machinery of an estimate helps to demystify the process. It sets up a more collaborative relationship from the beginning, discourages adversarial behavior, and builds trust. These, my friends, are things of which a good client relationship is made.Yeah great but how much does it cost?
Just as there is no single good way to set pricing, there is no single good way to estimate. You’ll need to do some trial and error to see what works for you, your communication style, your design and development process, and your clients.
The web is always changing and so, it seems, is everything else in our industry. So don’t be afraid to experiment and try new things. If all goes well, you’ll have plenty of opportunities to try again, and refine your estimating process with each project. You may also find that as your organization grows, what worked before no longer does, and that a new approach is suddenly more suited to you.
And oh hey, I’ll be damned if that doesn’t segue us quite neatly into the final installment in this series, where we’ll investigate how scale affects our web businesses. See you then!
Everyone wants beautiful homepages. It doesn’t matter who’s running the organization, what industry they’re in, what design trend is hot, or what CMS is being used. A homepage is the front door to an organization, and organizations want homepages that reflect their sparkling missions and content.
Obviously this is where we, the web professionals, come in. We identify patterns in a company’s content and design. We build an ordered system to manage the site, with content stored in structured fields and cross-referenced by neatly stacked taxonomic containers. We build drool-worthy designs into pretty template patterns, into which a CMS can automagically flow that content. Relax, humans! The computer robots have got this.
And, of course, the robots drive homepage content, too. A common type of homepage—which I see a lot in my work with nonprofit organizations, but can be found in any industry—is a mix of somewhat static, explanatory content, with dynamic chunks populated by the most recently published content from a CMS. When these organizations are on tight budgets, often without a lot of staff and resources, it seems like a good idea to code the static parts and automate the dynamic parts. That way, staff doesn’t have to fuss with edits, updates, or technical interfaces, and the organization can focus on doing important work helping people. Homepage: done.
Until the request inevitably comes: the board of directors needs a slider because they want a way to highlight more than one post at a time. Furthermore, they need each slide to be able to feature a blog post OR a donate page OR an about page OR their gift catalog. And it’s important to the executive director that all static blurbs be wordsmithed especially for the homepage, and the blurbs may need to be tweaked during peak fundraising months. My easy homepage publishing system just left the building.Maybe the robots shouldn’t win
After having this conversation about 242 times, I’ve realized that the homepage is almost always a giant exception to the rest of the ordered system for a reason. It’s the most human page on the site, where the potential helpfulness of computer robots collides with the messy reality of humans.
The homepage is a company’s elevator pitch that must telegraph an organization’s priorities and values as succinctly as possible. The fundraising department, program staff, and board members may feel anxious about ensuring their interests are visible on this valuable real estate. These internal forces, or the politics of partner organizations or funders, will affect what is presented on a homepage, even if it may not be the most logical choice for content, design, or structure.
Instead of wishing for (the ever-elusive) Total & Complete Control, it’s more useful to accept this human foible. Rather than fighting it, let’s build something specific to handle this exception better, in a way that’s least likely to break down the road.Of blobs and chunks
Here’s a homepage I am currently rebuilding for Small Can Be Big, a non-profit project of the marketing agency Boathouse. Small Can Be Big works with Boston-area partner charities to help keep local families from slipping into homelessness. Let’s break it down:
- Hero area: the organization wants to be able to put anything they want here. This content and its design are unique to the homepage.
- “How it Works”: three quick points about the organization’s process. These are also unique to the homepage.
- “How it Makes a Difference”: A list of brief highlights about the organization’s impact. Blurbs very similar to these live on an “Impact” landing page of the site, and could be pulled in automatically. The content admin, however, needs to be able to wordsmith these blurbs specifically for the homepage, so they are unique.
- A newsletter subscribe form: this form may get used elsewhere on the site, so it will be stored in a sitewide-accessible block or a widget and then displayed on the homepage and on other pages as needed.
- The latest blog post: This will be automatically populated.
- A custom call to action with supporting content, just for the homepage.
So, we’ve got one sitewide, global element here (the subscribe form), and one systematized, auto-populating region (the latest blog post). How do we let this organization custom-craft the other pieces of this page?
One way to approach this is to create this page in a single body field, and give the client a WYSIWYG with which to maintain it. This offers the ultimate flexibility. But as anyone who’s written a goodly amount of HTML knows, giving content admins a big WYSIWYG blob can lead to broken code, elements that aren’t accessible or semantic, failures in the responsiveness of the page, and content that doesn’t fit within the constraints of the design. This can quickly lead to a schlocky-looking (that’s a technical term) homepage.
A better approach is to break the page up into little custom WYSIWYG chunks (blocks, panes, or custom text widgets). You assemble them on the homepage via whatever best methods your CMS offers, and the client maintains each and every little snippet in its own block.
The advantage is that the homepage gets broken down into components, reinforcing—at least somewhat—the separation of the content from its layout and design. For example, the “How it Makes a Difference” chunk might be built as four separate blocks or custom text widgets, floating next to each other:
The downside is more complicated management over time: the containers holding these chunks are generic tools, wired together in a front-end display. Each chunk may be maintained at a different URL. Specific help text can be tricky to include. And lots of small bits in the backend can be difficult for content admins to track, especially if there aren’t editorial guidelines and a strong governance plan in place. Eventually, the quality of the homepage, and the site, can start to degrade.Let’s embrace the exception!
What I’ve been increasingly doing is making a content type that exists for one purpose: to serve as a structured form for homepage content entry and maintenance. This can feel weird from an information architecture perspective. Content types are generally reserved for pieces of content that share common attributes, implying that there is more than one instance of that content. As one of my colleagues said the first time I suggested this: “A whole content type for one piece of content?! That’s not what content types are for!”
But here’s exactly when we need to check back in with the goals of building CMS content structures in the first place: robots are here to serve humans, not the other way around. If this exception is needed, let’s embrace it rather than fight it. A single form to edit all of the custom content on the homepage can make things easier on the content admin, and helps enforce design cohesion and content consistency.
In breaking down the content type for the Small Can Be Big homepage, I looked for logical content and design patterns so I could group fields in a helpful way. For example, the three “How it Works” blurbs are there to inform donors about how their contributions work:
It’s logical for this sort of element to live on a homepage, and it will likely always be needed for this site. So I built it as a list of three items, and called it exactly what it is: How it Works. In the CMS, it looks like this:
I included help text about what HTML goes into each field, and some sample content. If the homepage changes in the future, these fields can be tweaked, or deleted and replaced with something else. But if the content structure remains the same, the design and/or layout can easily change to restyle this same three-item list. Either way, this setup is flexible.The homepage edit form is your oyster
How you break down a homepage into a content type is dependent on the kind of content and design you’re working with. In the Small Can Be Big example, I’ve broken the form itself into the different content and design areas of the homepage: the lead feature (hero) section, the impact section, etc. This makes the form a lot less overwhelming to edit.
The breakdown is also dependent on your client’s staff resources. In my example, the client has a dedicated technical person on staff to edit homepage content. We collaborated with the content admins throughout the development process; we know the homepage content admin knows HTML well, and when we asked him what editing tools he wanted, he requested no WYSIWYG. I wrote help text to remind him of the HTML elements that are allowed and expected in the field (if he tried to put messier HTML in there, it’d get stripped out by the CMS), and provided him with a quick inline example or reminder of the content that should go there.
For a less technically savvy admin, I might make more fields, rather than fewer. Fields could be made to hold icons, images, and alt text. I could put WYSIWYG editors on each of the text fields, customized for the expected markup. Alternatively, I could make every element its own field: image fields with clear, descriptive help text for the icons, and plain text fields for the H3 headers and paragraph blurbs. I would then output those values into customized HTML templates, giving me complete control of the markup around the content.
The homepage edit form is a fantastic opportunity to add helpful UI elements for content administrators. It’s also a very good idea to add a general help text block, like I did in the example, linking off to the site documentation. You could also link here to the site’s style guide, if it has one, or add voice and tone notes.
Of course, how far you can take this is also a function of your project budget and timeline. If possible, it’s wise to build time into ongoing project budgets for regular adjustments to these customizations, to ensure they continue to be helpful for content admins in everyday use. But even adding a little structure and help text can go a long way.Let the humans win
My job is to map messy human communications onto computer systems to help make it easier for people to manage those communications. That means that I need to balance the boolean realm of computer code with the far more ambiguous needs of organizational communications. By creating a structured exception for the very human homepage, I can better ensure the consistency I crave as a developer while giving content admins the flexibility they need.
Adding more logic and structure to homepage editing has another benefit as well: it encourages people to evaluate the meaning of their homepage content, making them plain old better. Rather than concentrating solely on visual “wow!”, and putting up icons and copy “because it just needs a little something there,” a structured edit form can force people to inventory what’s there, and identify that “little something’s” purpose. This encourages conversation around the role of the homepage, and keeps it from becoming a pretty parking lot subject to the whims of the boardroom.
The homepage exception is just one example of the many kinds of accommodations that human beings need in the coded, structured systems we build for them. It’s our job to adapt computer systems to their needs, not the other way around. If we don’t, then our robot overlords have won. If we expect, plan for, and even celebrate these messy, human exceptions to our logical systems, we get closer to making a web that works for both people and machines.
If you work on the web, you’ve likely seen heated emotional outbursts in the office. When someone barks at you because their business process must change or you’ve presented a concept that doesn’t match their mental framework, it’s easy to take their words personally and get agitated. But people have a right to experience emotions. They might not always cope in healthy ways (and you don’t always have to accept the resulting behavior), but it’s part of our job to hear them out.
During my time managing content strategy at a university, I witnessed tears and frustration over font colors, training requirements, form fields, and access levels. It took me years of studying human behavior to realize it was my responsibility to accept the emotions. I could no longer chalk it up to people “not getting the web” or “not seeing the big picture.” Those excuses weren’t getting me anywhere when furious folks showed up in my office unannounced. And those excuses weren’t fair. I needed to be a better partner.
So how do we turn challenging outbursts into productive conversation?Look for the signs and pick your strategy
Validating emotions isn’t a glorified psychological process. It’s about being a real, authentic human being who empathizes with another’s emotional state. And, guess what, that’s damn hard.
Instead of releasing a defensive remark, refocus and try to understand what’s fueling the outburst. Psychiatrist Dan Siegel believes that by naming our emotions we have a shot at removing ourselves from their grasp. I’m certainly no psychiatrist, but after years of watching humans build web products together, I’ve noticed most people get wound up over four core issues:
If we look for signs that indicate what’s behind fierce comments, we can attempt to defuse and move forward.Calming insecurity
Working on the web involves a lot of change. We test new technologies, try out different processes, take on diverse clients, and integrate new best practices. It’s easy to feel a few steps behind. Anyone who provides direct support knows what it’s like when people experience something new and unfamiliar.
“I NEED THIS FIXED NOW.”
“I DON’T KNOW WHAT’S GOING ON!”
“I KEEP TRYING THAT AND IT’S NOT WORKING. THIS IS BROKEN.”
Perhaps a CMS user is struggling to make updates. Maybe a sales rep is trying to pull a new analytics report for a client. If not handled well, these emails are followed up by phone calls or drive-by office visits. In my experience, they can even lead to high-level meetings with angry department heads voicing concerns about how the web team doesn’t care.
These hectic reactions often indicate that people feel insecure. They’re a step or two outside their day-to-day domain and they don’t feel confident. Ultimately, they’re experiencing fear of the unknown. And fear releases adrenaline bombs launching us into fight-or-flight mode, which is why we love scaring ourselves and why people get hot and hung-up.
Witnessing this type of response is our cue to scan the context to identify what’s driving the insecurity. Did we move to a new CMS and now a colleague is struggling to relearn their job? Is a marketing specialist preparing quickly for a meeting and they’ve forgotten how to pull the right report? When we read through their emotions, we can identify their basic needs, and then:
Avoid blame. Steer the conversation away from what they’re doing wrong or what they don’t understand. Instead, let them know you’re happy to help and together you can make it happen.
Tailor language to make people feel comfortable. Using insider jargon is the fastest way to make someone outside our field feel even more insecure. Instead, see the conversation as an opportunity to help colleagues or clients boost their confidence.
Give away your knowledge. Beyond simply making a fix or giving a brief explanation, try digging up a few resources to help someone understand your field even better. I worked with a designer who’d respectfully send me links to articles after we worked through heated challenges. Instead of protecting his expert knowledge, he’d direct me right to his source so I could feel more confident in the future.Addressing the fight for freedom
No one likes being told they can’t do something. But web work, be it enterprise content management, development, or design, involves lots of saying no. Workflows dictate who can and can’t publish pages. Browsers and devices constrain our key strokes. Content templates confine layout flexibility. Like I said, lots of no. And inevitably our saying no is going to stir up opposition.
In enterprise contexts, we sometimes encounter those who push back because they want more personal independence. In my higher ed days, I came across professors and department staff who refused to attend CMS training or neglected our architecture standards. They openly challenged these governance practices because they wanted to manage their sites without conforming to institutional process.
In agency environments, enforcing well-intentioned web standards can make others feel like they’ve failed. When we say no to requests that come from our sales or client reps, their frustration with our restrictions is less about personal freedom and more about wanting to deliver. They don’t want to let the client down so they’ll insist it’s absolutely necessary.
When it comes to freedom issues, we can start by asking questions like:
- What are you trying to accomplish?
- How do our restrictions keep you from doing your job?
- What alternatives do we have?
Then, we need to pop open the hood to show them exactly what we’re up against. If a client rep makes a last-minute request to add a content chunk that will change the functionality of an entire template, we can bring up the CMS, show them how the template works, and outline what their change would entail. Or, if a renegade web editor repeatedly breaks basic usability best practices, we can call a meeting, walk through examples of the user experience we’d like to create (and avoid), and brainstorm other ways to meet their goals.
It’s respectful to offer our full knowledge and shoot for shared understanding instead of hiding behind the technical veil. Also, don’t be afraid to change your mind. If you understand their motivations, logic, and rationale, you might decide to adjust your processes or tactics. That’s okay. You don’t always need to defend your ground as the expert.Affirming the identity-seeker
Some of the most delicate emotional responses we run into surface when people experience identity issues. A new hire wants to solidify their role. A new team lead wants to redirect the project because of their years of experience. A company goes through rebranding and longtime writers have to find a new voice.
“Well, I’ve used Drupal for over 10 years. I don’t understand why that wasn’t the obvious choice.”
“Of course I know QR codes. I’ve used them. That’s why we need a QR code.”
“That’s something my strategy team does. It’s not your job.”
Working as a contractor and consultant, I prepare myself to hear these types of comments from those trying to reposition when I join a team. I don’t blame them. They simply want to be seen as a valuable contributor. So do I.
Instead of shooting them down by defending my expertise, I reinforce their identity by inviting them to share their knowledge and experience. A helpful phrase is Kristina Halvorson’s “tell me more about that” line:
“We’re glad you’re on this team. We need your expertise. Tell me more about what you know.”
“Sounds good. Tell me more about how a QR code will help us drive traffic.”
Affirming others by asking them to share their experience doesn’t mean you need to go along with their ideas. But it helps you calm their defensive posture, not look like an opponent, and move the conversation to productive ground.Restoring value and worth
Emotions don’t always manifest in loud declarations or snippy emails. Sometimes people just check out. At the university, I noticed a once oppositional stakeholder had grown silent. But just because I no longer heard his clamoring didn’t mean everything was cool. He had disengaged and wasn’t keeping his site up to date, to the detriment of his users. I realized it was our failure because we hadn’t been listening to him.
Withdrawal usually happens when people don’t feel heard, repeatedly. Maybe in a large organization, a department head’s project keeps getting shoved to the end of the queue, so they give up. Or maybe a junior developer feels overshadowed by seniority. They’re not chiming in because they believe it doesn’t matter.
The good news is we can boost worth with seemingly simple things like listening and letting people be themselves. Margaret Wheatley, known for her organic approach to organizational behavior, believes it’s more about being present than formulaic strategies:We spend so much time in complex group processes focused on team building, problem-solving, effective communications, etc. But what happens when we forget about technique and just try to be present for each other? Have you experienced what happens in you and others when we really listen to each other?
So what’s the takeaway? We need to make an intentional effort to be present and recognize people as we go about our daily bustle. How do we do it?
Invitations. Draw others into your conversations. If a developer seems quiet in a meeting, ask for their opinion (even if it’s not about development). If you’re working on a new approval workflow, grab coffee with one of your more challenging web contributors and ask them how a process change could make their job easier.
Specific praise and appreciation. In their book How the Way We Talk Can Change the Way We Work, researchers Robert Kegan and Lisa Laskow Lahey advise us to put more power in our compliments if we want people to know their worth. Instead of saying:
“Thanks, Greg! You’re doing great work.”
Take a few seconds to think about why Greg’s work is great. And then tell him directly:
“Thanks, Greg! I like the way you programmed that content type. It’s smart development. I think it will make maintenance a lot easier for our client. And I appreciated the way you advocated for that in our meeting.”
Access. If you work in large systems, offering a clear, reliable support channel provides all stakeholders with equal access to be heard. Or holding open meetups can give your web colleagues regular face time and an avenue for bringing up concerns.
Ultimately, listening and recognizing others takes time, and in the fast-moving chaos of web development, strategy, or production, we don’t have the cycles to acknowledge someone who’s not asking for our immediate attention. So we need to get intentional about being present.See the common sense above the struggle
These arguments might seem like common sense. And honestly, they are. It’s easy to step back objectively when we’re not under the gun. But, at our core, we’re not logical beings. We get swept in and stir things up. It’s difficult to stay levelheaded.
So when strong emotional reactions spike, we have to do our best to accept them and not make it personal. Only from a non-defensive stance can we accurately assess what’s triggering the reaction. If we can pinpoint the issue, be it security, freedom, identity, or worth, we have a chance to turn the conversation around. So next time someone barks, temper your hackles, draw a deep breath, and be present.
At the beginning of this year, I switched my full-time focus in a pretty sizable way. I jumped from an environment where I had at least a bit of expertise and its associated advantages, into one where I had little to no foothold.
Switching roles usually means adjusting to a new environment, new coworkers, and new problems to solve—things you might work through in a matter of weeks. But there I was, two, then three months in, and still feeling unadjusted.
What I hadn’t realized was that jumping into a completely different side of the industry is disorienting. The new environment was similar enough to the old one that it still triggered my muscle memory, which was largely irrelevant for new tasks. There were only a few skills I could rely on during the transition—the basic workflow, programming principles, and methods of collaboration and feedback were all the same, but that didn’t always help with things like deploying applications to devices natively, or making decisions about how best to implement a platform-specific SDK.
One of the biggest advantages of having expertise is understanding and implementing best practices, but they were often the biggest hindrance in learning something new. Applying best practices to a new area of focus from a related-yet-foreign area of expertise was destructive.
This was most noticeable in the software architecture decisions I faced. Coming from the world of programming on the web, both server and client side, my mind defaulted to certain patterns of communication between pieces of an application—specifically notifications and callbacks. When sketching out a plan for a feature build, I would sometimes forget about the delegate pattern, which is a pretty heavily-relied upon pattern in Cocoa. In a lot of cases, that was the best fit for the feature in front of me, but my mind was trained otherwise.
The other reason knowing best practices was destructive when learning something new: I was constantly focused on making sure what I built adhered to those patterns. That forced me to focus on optimizing a system before I’d even built or understood it. I was prematurely applying structure to something that I wasn’t quite sure even worked yet.
I had to get back into beginner mode: make whatever it was I was building actually work, before deliberating on how it should be built. It sounds like an obvious thing, but it takes concentration to restrain yourself like that. The sad irony here is that I should’ve known this from the start. A few months ago I wrote about relying on intelligence rather than knowledge, and that’s how we should operate when learning new skills.