The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:
- Reusing good software is easy; it is what allows you to build good things quickly;
- Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
- The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.
Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:
- Start as simple as possible;
- Seek out problems and iterate; and
- Hire the best engineers you can.
Monday, February 1st, 2021
Sunday, November 22nd, 2020
Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!
Saturday, September 26th, 2020
Thursday, July 25th, 2019
The story of Jack Garman and the 1202 alarm—as covered in episode two of the 13 Minutes To The Moon podcast.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
Monday, June 3rd, 2019
I got a preview copy of this book and, my oh my, it is superb!
If your job involves dealing with humans (or if it might involve dealing with humans in the future), you’ll definitely want to read this.
Tuesday, July 10th, 2018
I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
Sunday, June 24th, 2018
A really excellent piece from Derek on the history of community management online.
You have to decide what your platform is for and what it’s not for. And, yeah, that means deciding who it’s for and who it’s not for (hint: it’s not bots, nor nazis). That’s not a job you can outsource. The tech won’t do it for you. Not just because it’s your job, but because outsourcing it won’t work. It never does.
Monday, May 21st, 2018
Some ideas on the best of use of time in sprint zero of an agile project.
- Understand your context
- Identify risks
- Understand the business process
- Get testing infrastructure
- Understand quality attributes
- Get to know the people
- Prepare an initial product backlog
- Build a walking skeleton/spike
- Build a learning backlog
Saturday, May 19th, 2018
Agile itself provides us with the ability and opportunity to correct course, it allows us to steer, but it does nothing as such to help us steer correctly.
This observation about (some) agile projects is worryingly familiar:
I was suddenly seized by a horrible thought: what if this new-found agility was used, not teleologically to approach the right outcome over the course of a project, but simply to enshrine the right of middle management to change their minds, to provide a methodological license for arbitrary management? At least under a Waterfall regime they had to apologise when they departed from the plan. With Agile they are allowed, in principle, to make as many changes of direction as they like. But what if Agile was used merely as a license to justify keeping the team in the office night after night in a never-ending saga of rapidly accumulating requirements and dizzying changes of direction? And what if the talk of developer ‘agility’ was just a way of softening up developers for a life of methodologically sanctioned pliability? In short, what if Agile turned out to be worse than Waterfall?
Tuesday, April 3rd, 2018
Navigating Team Friction by Lara Hogan
Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.
Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:
- Forming. The group is coming together. There is excitement.
- Storming. This is when we start to see some friction. This is necessary.
- Norming. Things start to iron themselves out.
- Performing. Now you’re in the flow state and you’re shipping.
So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.
An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.
The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.
Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.
We have six core needs that are open to being threatened (leading to an amygdala hijacking):
- Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
- Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
- Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
- Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
- Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
- Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.
Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?
We value those needs differently. Knowing your core needs is valuable.
Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.
We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:
- Doubt. People double-down on the status quo; they question the decision.
- Avoidance. Avoiding the problem; too busy to help with the situation.
- Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
- Bonding. Finding someone else who is also threatened and grouping together.
- Escape-route. Avoiding the threat by leaving the company.
All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.
Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:
- What do you think folks are liking or disliking about this so far?
- I wanted to get your take on X. What might go wrong? What do you think might be good about it?
- What feels most upsetting about this?
You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.
This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.
Listen with compassion, kindness, and awareness.
- Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
- Elevate the conversation. Meet transparency with responsibility.
- Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
- Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!
This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.
Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.
We can get better at giving and receiving feedback.
Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.
|General||Specific and Actionable|
The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).
observation + impact + question/request
Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.
Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.
Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.
You’ll start to notice when your amygdala or pre-frontal cortex is taking over.
Talking one-on-one is the best way to avoid team friction.
Retrospectives are a great way of normalising of talking about Hard Things and team friction.
It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.
Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.
What if you disagree with what management says? The absence of trust is at the centre of most friction.
|Commit||Mature and Transparent||Easiest|
|Don’t Commit||Acceptable but Tough||Bad Things|
Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.
But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.
Remember, storming is natural. You are now well-equipped to weather that storm.
Tuesday, February 27th, 2018
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
Monday, January 1st, 2018
A great round-up of Leading Design—one of the best events I attended in 2017.
Wednesday, July 5th, 2017
A series of posts on the decisions and trade-offs involved in being a tech lead:
I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.
Monday, May 1st, 2017
Dealing with Technical & Design Debt - Breakfast Session - Agile Swap Shop (Brighton, England) | Meetup
If you’re a project manager anywhere near Brighton, put this event in your calendar for the morning of May 30th.
Friday, January 17th, 2014
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.
Monday, October 22nd, 2012
Mark gets to the heart of the issue with making responsive designs work with legacy Content Management Systems …or, more accurately, Web Publishing Tools. There’s a difference. A very important difference.
Monday, January 2nd, 2012
Mashing up Angry Birds and spreadsheets to better visualise project time-tracking.
Friday, April 16th, 2010
The companion website to Kevin Hoffman's IA Summit talk, this is a hugely valuable resource for an often-overlooked part of the design process: the kick-off meeting.
Sunday, December 4th, 2005
This series of cartoon panels is funny because it's true.