When you find out that what you’ve shared into the world, something you’ve poured your heart into, is not recognized by those who you thought will be thankful for it, it isn’t really worthwhile to antagonize them. You’re just crying over spilled milk. Sure, cry, but please ask why you made the thing in the first place and give yourself an honest answer. Why was the thing important? Is it truly for your audience or for yourself? Did they actually tell you to create the thing, or was it an initiative? Why aren’t you satisfied with what you’ve done? Was it a requirement that they use the thing you’ve built too? Is it necessary to be recognized? Isn’t it enough to know that you made something of value at least for yourself?
And if you’ve made the thing you did for consumption and it wasn’t consumed by the people you think would, maybe the thing isn’t as valuable as you think it is. Listen to your audience, to their comments, and, perhaps, to their silence. Understand their wants and needs. Talk to them. Maybe something significant is missing.
Everyday, prepare a very specific question (or a task) interesting enough to warrant research for an answer within several hours without distraction. Sometimes for learning, sometimes for fun, hopefully most days for both. Everyday there must be an adventure to immerse in, albeit small, something to be curious for.
Here’s an always challenging question: how are great software development teams formed? Managers, scrum masters, we all struggle to create continuous progress within our groups. And we know that there’s lots of factors in why that is – communication, skills, individual quirks. Sandy Mamoli and David Mole tells us that self-selection is the answer, and their book, Creating Great Teams (How Self-Selection Lets People Excel), provides us with the details.
Here are some notes from the book:
- Fundamentally, two factors determine whether a group will forge itself into a team: 1) Do these people want to work on this problem? 2) Do these people want to work with each other? Neither a computer program nor a manager can answer these questions. Only the employees who will do the work can.
- Self-selection is a facilitated process of letting people self-organize into small, cross-functional teams. Based on the belief that people are at their happiest and most productive if they can choose what they work on and who they work with, we think it’s the fastest and most efficient way to form stable teams.
- The best motivators are autonomy, mastery, and purpose. Autonomy provides employees with freedom over some or all of the four main aspects of work: when they do it, how they do it, who they do it with, and what they do. Mastery encourages employees to become better at a subject or task that matters to them and allows for continuous learning. Purpose gives people an opportunity to fulfill their natural desire to contribute to a cause greater and more enduring than themselves.
- No one chooses to work on more than one team or project. Time and again organizations fall into the trap of optimizing resources rather than focusing on outcomes. People often believe that multitasking, having people work across several projects, and focusing on resource utilization are the keys to success, when in reality they’re not.
- People communicate face to face. There are barely any discussions about process or how to communicate. Team members just talk and coordinate and collaborate as needed. Things are much faster that way.
- In the spirit of letting people control their way of working, we never mandate whether a squad should run scrum, kanban, their own special creation, or a traditional way of working. Following Daniel Pink’s principles of motivation, one of the key forms of autonomy is being in control of your processes. Giving people autonomy over who they work with should be extended by letting them choose how they work together.
- There are two agile practices we believe should remain mandatory: retrospectives and physical story walls (if you are co-located).
- It’s fair to say that sometimes employees don’t want to work with each other. And that’s okay. People know whether they’re going to gel in a squad with a particular person, and if not, it makes sense they would choose not to work with him or her. Self-selection, unlike management selection, allows them to make that choice.
Elisabeth Hendrickson’s book “There’s Always A Duck” has been around for a number of years but I have only been able to read it recently. Now I know what she meant about ducks. They’re literally about ducks, but also about people too. People are different, and yet we share similarities. We experience things, we communicate with each other, and we learn and get better because of those experiences. Her book tells us stories of her adventures and the lessons she’s discovered along the way, and it was nice to have had a glimpse of what she saw and felt with her encounters with software project teams and everyone involved.
- The vast majority of programmers I have met are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They work hard to make sure they are implementing the right features and writing solid code.
- The next time you’re tempted to think of your programmers as idiots, incompetents, or quality hostile, remember that no matter what else they may be, they’re people first. Even if it seems like they’re hostile or incapable, it is far more likely that they are having a very human reaction to a particularly bad situation.
- And before you blame someone else for a mistake, remember the last time you made one. I’ve made some real whopper mistakes in my time. We all have, whether or not we choose to admit them or even remember them. It may be that some programmers don’t care about users, but it’s more likely that bugs are honest mistakes made under difficult circumstances.
- Even when we are speaking the same language and about the same thing, it’s hard enough to communicate.
- The point wasn’t to catch every possible error. What seems to go wrong most often? What errors are difficult to see at first glance, and thus require concentration to prevent? What causes the most damage when it happens?
- Janet doesn’t know anything about the ins and outs of creating software. She probably doesn’t want to know. She just wants to serve her customers well. And this software is not helping. Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don’t see is Janet’s pain. The feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they’ll detect catastrophic problems that cause servers to go down. But they won’t see the little things that cause long queues at the front desk of the hotel.
- Testers naturally notice details. Not only do we notice, but we think about what we noticed, we attempt to interpret our observations to explain why things might be that way, we ask others if they noticed, we question our assumptions, and we poke and prod at things to see if our understanding is correct. We use our observations to inform us, and in doing so discover underlying causes and effects we otherwise might miss.
- I sometimes fall into the trap of thinking that the first problem I see must be THE problem that needs to be solved. Perhaps the problem I spotted is indeed worth correcting, but I almost never manage to spot the true critical issue at first glance.
- Both fear and excitement stem not from observable reality but rather from speculation. We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us. We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking. We are speculating that we knew what the users actually wanted in the first place. We are speculating that the tests we decided not to run wouldn’t have found anything interesting. We are speculating that the tests we did run told us something useful. None of it is real until it is in the hands of actual users. The experience those users report is reality. Everything else is speculation.
- It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact. In short, frequent delivery means we live in reality, not probability.
- Hire the right people. If that means keeping a critical position on the team open longer than anticipated, so be it. It’s better to have an under- staffed team of highly motivated, talented, skilled people than a fully staffed but ineffective team. Remember that hiring mistakes often take only a few minutes to make, and months of wasted time to undo.
- Listen. There are always signs when a project is in trouble: missed milestones, recurrent attitude problems, general confusion about the project. Sometimes these signs indicate a dysfunctional team, sometimes they’re just normal bumps along the road, and sometimes they are early warning signs of major problems. The only way to tell the difference is to listen carefully to what the team members have to say.
- The best way to get people to accept change is to make it more fun, and more rewarding, to do things the new way.
- Choose a path that takes you in the direction you want to go. Don’t choose a path simply because it takes you away from the swamp you want to avoid.
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
“Tools of Titans” is Timothy Ferriss‘ latest book, compiling lessons he has learned from interviewing over 200 world-class performers in his ‘The Tim Ferriss Show’ podcast. It is massive, and the number of takeaways he’s given away in the book is as plenty as it’s size. Like his “The 4-Hour Workweek” title, several of the ideas in it got me thinking deeper into how I’m living my own life, asking myself which projects and goals actually matter. Plus there’s bonus notes on other interesting things, like physical exercises that provide bang for the buck and the profound effects of using psychedelics in healthy doses.
Some favorite lessons:
- The quality of your questions determines the quality of your life.
- Do your kids remember you for being the best dad? Not the dad who gave them everything, but will they be able to tell you anything one day? Will they able to call you out of the blue, any day, no matter what? Are you the first person they want to ask for advice?
- If you don’t do something well, don’t do it unless you want to spend the time to improve it.
- Accept that quality long-term results require quality long-term focus. No emotion. No drama. No beating yourself up over small bumps in the road. Learn to enjoy and appreciate the process. This is especially important because you are going to spend far more time on the actual journey than with those all too brief moments of triumph at the end.
- It’s not what you know, it’s what you do consistently.
- When you’re thinking of how to make your business bigger, it’s tempting to try to think all the big thoughts, the world-changing, massive-action plans. But please know that it’s often the tiny details that really thrill someone enough to make them tell all their friends about you.
- If this were the only thing I accomplished today, would I be satisfied with my day? Will moving this forward make all the other to-dos unimportant or easier to knock off later?
- You can sacrifice quality for a great story.
- People who have plenty of good ideas, if they’re telling you the truth, will say they have even more bad ideas. So the goal isn’t to get good ideas; the goal is to get bad ideas. Because once you get enough bad ideas, then some good ones have to show up.
- The way you teach your kids to solve interesting problems is to give them interesting problems to solve. And then, don’t criticize them when they fail. Because kids aren’t stupid. If they get in trouble every time they try to solve an interesting problem, they’ll just go back to getting an A by memorizing what’s in the textbook.
- Commit, within financial reason, to action instead of theory. Learn to confront the challenges of the real world, rather than resort to the protective womb of academia. You can control most of the risks, and you can’t imagine the rewards.
- Choose projects and habits that, even if they result in “failures” in the eyes of the outside world, give you transferable skills or relationships.
- For anything important, you don’t find time. It’s only real if it’s on the calendar.
- When deciding whether to commit to something, if I feel anything less than “Wow! That would be amazing! Absolutely! Hell yeah!”—then my answer is no. When you say no to most things, you leave room in your life to really throw yourself completely into that rare thing that makes you say, “HELL YEAH!”
- Great creative work isn’t possible if you’re trying to piece together 30 minutes here and 45 minutes there. Large, uninterrupted blocks of time—3 to 5 hours minimum—create the space needed to find and connect the dots. And one block per week isn’t enough. There has to be enough slack in the system for multi-day, CPU-intensive synthesis. For me, this means at least 3 to 4 mornings per week where I am in “maker” mode until at least 1 p.m.
- Don’t try to please anyone but yourself. The second you start doing it for an audience, you’ve lost the long game because creating something that is rewarding and sustainable over the long run requires, most of all, keeping yourself excited about it. Trying to predict what an audience will] be interested in and kind of pretzeling yourself to fit those expectations, you soon begin to begrudge it and become embittered—and it begins to show in the work. It always, always shows in the work when you resent it.
- You can’t blame your boss for not giving you the support you need. Plenty of people will say, ‘It’s my boss’s fault.’ No, it’s actually your fault because you haven’t educated him, you haven’t influenced him, you haven’t explained to him in a manner he understands why you need this support that you need. That’s extreme ownership. Own it all.
- The world is this continually unfolding set of possibilities and opportunities, and the tricky thing about life is, on the one hand having the courage to enter into things that are unfamiliar, but also having the wisdom to stop exploring when you’ve found something worth sticking around for. That is true of a place, of a person, of a vocation. Balancing those two things—the courage of exploring and the commitment to staying—and getting the ratio right is very hard.
- Any great idea that’s significant, that’s worth doing, for him, will last about 5 years, from the time he thinks of it, to the time he stops thinking about it. And if you think of it in terms of 5-year projects, you can count those off on a couple hands, even if you’re young.
- The way you do anything is the way you do everything.
- To blame someone for not understanding you fully is deeply unfair because, first of all, we don’t understand ourselves, and even if we do understand ourselves, we have such a hard time communicating ourselves to other people. Therefore, to be furious and enraged and bitter that people don’t get all of who we are is a really a cruel piece of immaturity.
- It’s better to be in an expanding world and not quite in exactly the right field, than to be in a contracting world where peoples’ worst behavior comes out.
- In any situation in life, you only have three options. You always have three options. You can change it, you can accept it, or you can leave it. What is not a good option is to sit around wishing you would change it but not changing it, wishing you would leave it but not leaving it, and not accepting it. It’s that struggle, that aversion, that is responsible for most of our misery.
- Perhaps I didn’t need to keep grinding and building? Perhaps I needed more time and mobility, not more income? This made me think that maybe, just maybe, I could afford to be happy and not just “successful.”
Last week I told our technical writer, a music expert, a video games enthusiast, a good father to his young daughter, and a loving husband to his wife, that I could build him a small tool that could quickly update a master file of local translations, so he could focus his precious time on more important matters other than the job of laboriously cross-referencing and manually updating such a document. That was a passing comment while some of us were suddenly randomly discussing the process of how he was currently maintaining the file. However, the passing comment also felt like a pitch to a software development project that had some sort of value to a very specific customer, and an easy one at that. It was a fascinating experience; it makes you think about how caring for the well-being of someone is very much a part of building software of value, and that good software connects people for the better.
Let’s see how that tool works out this week.