BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations The Creative Act: How Staff+ Is More Art Than Science

The Creative Act: How Staff+ Is More Art Than Science

Bookmarks
44:31

Summary

David Grizzanti talks about his path to Staff+ and how he views it as more art than science, looking at the parallels between creating art, creating software, and dealing with organizational dynamics.

Bio

David Grizzanti is a Principal Engineer at The New York Times focused on improving developer productivity by enabling engineering teams to more effectively and efficiently build, test, integrate and deploy software. Previously he was a Distinguished Engineer at Comcast. His areas of interests include improving infrastructure automation, open source communities, and engineering leadership.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Transcript

Grizzanti: My name is Dave Grizzanti. I'm a Principal Engineer at The New York Times. I'm going to be talking about how staff-plus is more like art than science. When you see this word, I want everybody to metaphorically close their eyes and think about a picture what you see, and what you think of when I say the word artist. I'm guessing you thought of something like this, or a person like this painting, maybe singing, creating something, a drawing maybe. You probably didn't think of this, or you probably didn't think of an engineer off the top of your head, or somebody making something mechanical. One of the things I want to do today is challenge that idea. This is a picture I asked DALL·E to create, of an engineer artist, because I was trying to find a picture that would show somebody who is an artist doing engineering, and I was having a tough time. I asked DALL·E to do it. The picture doesn't look all that realistic. I think it shows the point of somebody typing on a keyboard, and has paint all over.

I work in an organization on a team called, delivery engineering, specifically within developer productivity. Within that department we're focused on building an internal developer platform for all engineering at The New York Times. At The Times, our mission is to build the essential subscription bundle for every English-speaking curious person who seeks to understand and engage with the world. This talk is really about staff-plus, staff-plus roles, and my experience in that role. As the title said, how it's more like art than science. I wanted to spend a few minutes going through my background, because I think it's relevant to what I'm going to talk about. I've been in the industry for about 17 years since 2006. Unlike everyone else in the staff-plus track, I don't currently manage people, and I've never managed people. I don't know if it's completely unique. I've been in the industry a while and I've never taken the management plunge. I've been fortunate to work in organizations that have had a substantial career ladder, or at the point when I needed to make a decision, that kind of decision existed for me to continue on the IC track.

What I'm going to discuss is some of the challenges I've had in my role at the various companies. Some of the challenges I think a lot of staff-plus people have, through conversations I've had with friends, or just being at conferences like this, and how I see some of those challenges being shaped by the different companies we've worked at and the roles we've had and how you can overcome them. This is a picture of two different tracks, parallel career paths with a traditional management, one on the left, and one with a split on the right. It's good that companies have this now. Maybe your company has something like this. Audrey talked about a slightly different model of not using progressive titles like this, because so many companies have different versions of it. My last two companies, or the last one and the current one have this, but they're variations on it. My previous company, principal was lower than staff. We didn't even have staff. In some ways, using these exact phrasings don't necessarily help. You may have seen something like this at your job, or maybe you have one of these titles. Within this staff or principal or staff-plus roles, that's really just a title, but it doesn't usually capture what someone's doing day-to-day, or maybe what sub-job they have.

Staff Archetypes

Will Larson's "Staff Engineer" book, came out a few years ago and I think it became a guide for a lot of people in these roles who were looking to grow into it. He defines a few different staff archetypes. I want to go over each of those. They are tech lead, architect, solver, and right-hand. Let me just do a quick definition of these to level set. The tech lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they may partner with two or three managers within a focus area. The architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organizational level of leadership. The solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some may focus on a given area for long periods. Then, lastly, the right-hand extends executives attention, borrowing their scope and authority to operate particularly complex organizations.

Which one are you, something else? Outside of the archetypes, I've found that our roles can be very vague and are often shaped by personal experience and organizational dynamics. If you've been at a company for a long time, and you've grown within that company, you're probably filling a much different role than if you were hired from outside of the company. You don't have organizational context, or historical knowledge of legacy systems. That can play a big part in what you're doing day-to-day. I think my job at Comcast was very different than my job at The Times now, because when I was hired, I'm at the top of the IC track, but I don't know much about The Times or its systems. The problems that I think people are looking for me to solve are things that I can help with that don't need that historical context. I think I have traditionally fallen into the tech lead, architect role. We've level set. I've given the definition of staff-plus, some archetypes.

Life of an Artist

The idea for this talk came up from a book I read recently called, "The Creative Act: A Way of Being," by Rick Rubin. He's a famous music producer, founding a lot of really popular famous bands with a wide like eclectic mix of music, Beastie Boys, Run DMC, and Metallica. His history of that music has changed over time as he's grown and gotten older. This book is not about music at all, or about his career. It's about being a creative person and what it takes to get into that mindset and be creative. I picked up this book because I was feeling like I was stuck in a rut with just work and not being creative enough and feeling a pull to be more creative. I think engineers, or the traditional engineer struggles with that. We tend to be very tactical, and critical thinkers, which is good, but we don't necessarily let our minds wander and be creative. Between the book and the interviews I've listened to with him, I want to draw on some of the lessons he shared for a more artistic life, that I think we can use to inspire and get better at our jobs.

Let's talk a little bit about the life of an artist. This is a quote from Rick, "To live as an artist is a way of being in the world. A way of perceiving. A practice of paying attention. Refining our sensitivity to tune into the more subtle notes. Looking for what draws us in and what pushes us away. Noticing what feeling tones arise and where they lead." What I want to take away from that, or what I want to talk about is how everyone is a creator. I don't think we think of ourselves as artists, going back to that example I showed earlier with the picture. I want people to put away the idea that you're not creative or a creator. Everything we do in our lives, including writing software is creative, or writing is creative, even if it's documentation. We're not just talking to technicians. Art and engineering are both forms of experimentation. We have to embrace ambiguity, perform discovery, and craft a solution. That could either be to an engineering problem, or it could be to a painting.

Active Listening

The next topic I want to talk about is active listening, or this idea of having a sensitive antenna or transmission. Many of us are just really waiting for our next chance to speak instead of really listening. I find myself having this problem a lot, especially when the pandemic started in 2020 and we were all home doing virtual meetings. It's very easy to be distracted with multitasking.

We definitely have a culture of lots of meetings, and people needing to get work done, at the same time as you're in a meeting. It's hard to just be present and listen. I think being a staff engineer means putting your team and your project first. It's not necessarily about specifically what you're contributing, it's about something bigger. Your role is to help drive progress, help make technical decisions, and keep open lines of communication. Let's talk about how to make this better, make better use of your time, and spend time with your teammates and learn how to listen more. I mentioned this idea of having a more sensitive antenna. This is something that Rick talks about a lot in the book, and living a life of awareness and always being on the lookout for clues. Recently, I was reading "The Staff Engineer's Path," by Tanya Reilly. Her and Rick both talk about this idea of when you're doing something that you've done all the time, it can be easy to be on autopilot and you don't notice things. In Tanya's book she talks about during the pandemic being in the Irish countryside or walking around with friends and how they would be less distracted, and have this more sensitive antenna, and pick up on subtleties outside. Like, "This rock is so pretty, or this tree has these unique qualities." I think we get caught in this rut where we're not paying attention to what's going on behind us, we're just on autopilot. Not really being on the lookout. Rick talks about this idea of improving the sensitivity of your antenna by a few ways. One is meditation. Meditating is one way of increasing your awareness of your surroundings and just being more attune. The other thing is, just being mindful of your surroundings. Quieting your mind and letting signals break through, to live in this constant state of awareness.

Beginner's Mindset

The next thing is beginner's mindset. This is the idea of approaching problems as if you have no knowledge or experience in a given area. I think years spent gaining experience and honing your craft can often act counterintuitively. It will limit the scope of your imagination, creativity, and focus. A few examples of this, I'm sure everyone's heard of the beginner's luck analogy. I've played board games a lot. I've played board games with friends, where I think I'm the expert and should be winning, and then a friend comes over and plays, he's never played before, and they win. They beat everybody at the game. You're like, how did you do this? I think the idea of somebody coming in with a fresh perspective, not necessarily with all the historical context, can often see through some of the complexities and look at it with fresh eyes and sometimes a better outcome. I think within our discipline within engineering, there's a common problem with the second system effect, where the tendency of small, elegant, and successful systems to be succeeded by over-engineered systems that are bloated due to inflated expectations and overconfidence of the engineers. The confidence from the first system's success leads to start a more complex one that maybe is beyond the abilities of the engineer. Unconsciously the developer's mind is full of additions that may not have been there in the first project, and will cause this bloating and unnecessary complexity. In the beginner's mind, there are many possibilities, but in the expert's, there are a few. I think, when we become experts, we have such a narrow scope of how we see problem solving that it kind of blinds us a bit. Over years of deliberate practice and execution, we gradually notice recurring patterns which our minds unconsciously form into shortcuts, rules of thumb, and best practices. In time, these mental cheat codes can hew ever-deepening grooves into what was once a wide-open pasture, walling us into fixed mindsets. Developing a beginner's mindset is all about freeing ourselves from this preconceived notion of expectations about what should happen next. By doing so, we reduce the risk of stress or disappointment. This mindset often helps artists unblock creativity, start fresh, and develop new ideas, get outside of their own heads. It can also help engineers and less creative types as well.

Improving/Avoiding Traps

Next, let's talk about a few ways to avoid the common traps and hone our beginner's mindset. Ask questions and listen. What if our assumptions are wrong despite the best evidence at hand? What if solutions drawn from our past are no longer relevant? It goes back to that idea of attuning your antenna and listening more. The next thing is, go slower. We tend to operate on autopilot in areas where we have the most knowledge and experience. This can take us out of the optimal discovery process and cause us to miss steps. Consider answers as more middle ground, and dogmatic absolutism is the opposite of an open-minded curiosity. Avoid pre-judgment. Can you really know how something will work out if you're too focused on how you believe things should work? Detach from expert mode. Attachment to expert identity, traps us into offering answers before crafting questions. One of the other ways is work with a beginner, whether that's someone new to the field, or someone who's been in the field for a while, but maybe doesn't have expertise in the area you're working with. I think practicing exercises or digging into problems with somebody who's a beginner can oftentimes break you out of that mindset. Starting a new job at a new company is also a great way of doing that, because you come in and you don't know anything so you're forced to think backwards. Not that I'm saying everybody should start a new job every few years, but it's a good way to give you a different perspective.

Writer's Block

The next topic is writer's block, or just getting stuck on a problem. Architecture, staffing issues, team dynamics, artists commonly face these challenges, writer's block, or whatever painters would call writer's block. You often hear of artists wanting a muse. I don't know if we have muses in software engineering. I think we can change up our environments to stir up ideas. Let's talk about a few ways to get around this form of writer's block that I think are similar to artists. For me, I often feel overwhelmed by how large tasks can seem at first, so I like this idea of taking small steps. This talk, for instance, was like, I have this idea of riffing on this art book, and that was it. I was like, how do I get from there to talking for 45 minutes? For me, I break that up into more manageable chunks and force myself to schedule it into my day. For this talk, what I did was I'm going to write 5 minutes of content every day for the next 5 days. If I did that, then I'll have 25 minutes by the end of the week. That actually worked out really well, just spit out as much stuff as you can on a piece of paper. I think for writers, this is often a suggested paradigm for writing. As you're writing, don't try to write and edit at the same time, because that can make you feel stuck and get put in this loop. Just focus on one thing, write as much as you can, and come back and edit it later. I think taking these small steps toward a larger goal can give you a sense of accomplishment each day and make the larger tasks seem less overwhelming. The next thing is, change your environment and eliminate distractions. This picture really resonated with me when I was looking it up, because I definitely found myself back in 2020, when I was working from home, being like, I need as many monitors as I can, I need an iPad over here. I've gone the complete opposite of that in the last year and a half, and I have one monitor in front of me and a keyboard. Least amount of distractions possible. I think even working from home, if you don't have a dedicated space, or even if you do, there's a lot of distractions, like chores, your kids coming up, your pets. I think trying to eliminate some of those is very helpful when you need to focus and break out of whatever you might be being stuck with. I mentioned this picture resonated with me because the person is looking at their phone while also looking at their computer.

The next thing was, go for a walk. Again, change your environment. For me, I try to do this at least once a day. I don't have this nice of a nature to walk around with, but getting up and going outside. I try not to take my phone with me or look at it. One thing I've found very helpful is if I'm just walking, and I think of ideas, I'll just write it down real quick on my phone and then put it away. I've thought about even taking a pen and paper with me so I'm not using my phone to get distracted by Slack. I think going for a walk and just stepping away from work for 20 minutes, 30 minutes, gets you out of that mindset and can really help generate ideas, on the problem you're contemplating or just other things you might need to think about. Then the last one, which is maybe a little bit more severe. Cal Newport wrote this book called, "Deep Work." In the book, he tells the story about an author who was having trouble getting his book done, so he booked a round trip business class ticket to Tokyo. He wrote during the whole flight to Tokyo. Then he got on and wrote the whole way back. When he got back, he had his finished book. The reason that this story resonated with me is that at the time a couple years ago, when I would fly, I would actually have that feeling like, I'm free of distractions. No one can call me, can't do anything, this is the perfect time to read or get work done. It's interesting that flying usually is not a relaxing experience, but being in that environment where you're almost forced to sit there, you can't leave, no one can call you. It's a great way to force yourself to focus. I've been trying to find ways of like, how do I get myself into this same mode of how I would feel on a plane, but being at my house without spending lots of money? The other idea with this plane ride was that if you make a big financial investment in doing something, you're also more likely to force yourself to do the work. Because not only are you stuck on a plane, but you spent a lot of money to fly there just to write the book. By playing with these ideas of making a commitment or changing up your environment to unblock yourself.

The next one is alternative mediums. This is a little harder, I think, in the last couple years with being remote and not having whiteboards. Another trick I think I like to use for myself or with teams is just to change the way you're talking about a problem, whether it's like write it down versus talking out loud, or just draw a picture. That could be an architecture diagram, but it could also be a flowchart or anything that gets out of the problem of people talking past each other with using words. Languages can be different between different cultures, different dialects in different languages. Drawing sometimes breaks away from those problems, and clear a better path. Oftentimes too, I think drawing with somebody else, or even myself is similar to like rubber ducking in programming, or rubber ducking in general where you're just using the other person to lay out your idea. Then it helps you get the ideas flowing, even if you don't care what they say. Maybe you find somebody that you tell them like, "I don't want any feedback on this idea. I just want you to sit there and let me draw this out, to listen to what I'm doing." Then lastly, is be an anthropologist. A funny story of this picture. I was trying to find a picture of an anthropologist online, which is very hard. It had to be Creative Commons or something I could use. I had a picture of archaeologists, which is a very different field, but I was going to try to make it work. Then I was traveling last week, and I saw this sign on a building. I was like, I'm going to take a picture of this and use in my talk. Another area I often see folks struggling with is when they start at a new job, or even if they've been in a job for a long time, not necessarily understanding organizational dynamics and culture. I think this is one area where if you think like an anthropologist does of like studying social behavior of current and previous civilizations, and apply that to your company or your job, it can help you break through some of those problems. It takes work, but meeting people in different parts of the company, or reading historical documentation about old documents that the company has done, or put out will help you understand motivations, whether they be cultural or business-oriented things. I've taken on this task for myself to meet as many different people as I can and study the company to help me understand what they've done. I've found that when talking with more junior engineers, or folks that I've mentored in the past is that this is something that they've always been like, "How do you know so much about x thing that this other team is doing? No one told me what's going on." I've often said to them, here's a good way of learning some of this stuff. Seek some of this information out yourself or chat with somebody you meet who's in a different team, it'll give you a good perspective on what's going on without the company or in the company. That wraps up, I think, some of the art topics.

Staff-Plus Challenges

Let's talk about some of the challenges I think engineering side with staff-plus, and maybe how we can use some of these artistic references to help us do our jobs better. Leading without authority I think is something that we often talk about in our industry, especially as individual contributors that are not in management positions, and don't necessarily have what we traditionally consider authority. You want someone in your team and another team to work on something with you or for you, or you want even other engineers within a team that you may be leading, but not necessarily from a traditional management perspective. How do you get them to work with you? There's a book by Keith Ferrazzi, called "Leading Without Authority," that's very popular. It touches on lots of different topics within this arena. One of the things he talks about is co-elevation, which I'll build on. Really, this idea of just relying on other people within the company, other folks that you know, to get things done without the traditional hard or soft power differences. Being like, soft power is the ability that you can co-opt rather than coerce. Coercion is not necessarily the best way to get people to do things for you. It's not going to gain you any favors. You really want to build relationships with people and work together. This idea of co-elevation that Keith talks about is a more mission-driven approach to collaborative problem solving, through fluid partnerships and self-organizing teams. When we co-elevate with or more of our teammates, we turn them into friends or peers. How to establish relationships in order to build these self-organizing teams and co-elevate. We talked earlier about this idea of anthropology, being an anthropologist, to learn the inner workings of your organizations and various teams. Use the exercise, use meeting people to build those relationships with different folks across the org, build trust and credibility with them. I found through my last couple jobs that being approachable, and just being friendly is actually amazing for building these relationships. I think some people got to put off some of that friendliness, but showing people that you're approachable and willing to work with them, and not putting your foot down with different ideas can really help. When you're doing these, talking with people, doing these interviews, you should develop a set of questions you can use to ask folks during the time you have with them. This will help set the tone for the interaction. Keep it light to make it not seem like an interview. Your goal here is to listen, not talk, be an active listener.

Next, I want to go over what some of those questions would be or how to frame this interview. The three sections are get context, solicit feedback, and ask for advice. Within the context section, you could ask things like, tell me about yourself. What do you do for the team or the company? What does a typical day look like for you? From the feedback side, what works really well for you or your team? What's most frustrating? Then some advice. What did you learn as you were coming up to speed at the company or recently on a project? Are there any pitfalls I should be aware of? If you use these set of questions to establish your relationships, keep the ones you think you got valuable answers for. Stay in touch with those people every few months or so, and keep the relationship active. It can also help as you're approaching these questions or approaching these interviews, to have a beginner's mindset. Don't go into them with any preconceived notions based on the person's role, or position in the company. Somebody who may be in a more junior position will have just as much to say, as somebody who may be a VP. Keep the perspective of roles really matter, out of the equation.

The next thing, building on this topic of leading without authority, is establishing solid relationships with your peers, not just necessarily people who you would look up to that are in a higher position from you. If you happen to be in an organization that doesn't have a lot of other folks in your same role, this may be a little bit of a struggle. You may be in a big company that has a lot of staff, or staff-plus engineers, or you may be in a company where you're the only one. Some ways to do this is look outside of your immediate team, as you're doing those interviews, or just meeting people on whatever chat app you use. The next thing is look outside your company. There's a popular leadership Slack channel called Rands, that you can find other people from lots of other companies there. I've chatted with a lot of other staff engineers from other companies. It's a great way to learn what they're doing and some of the challenges that they have, not necessarily meeting people in-person or coming to conferences. I'd encourage people to maintain and nurture those relationships with the people that you've met. I have a peer group that I meet with regularly, who now work across various companies. It's a great resource for bouncing ideas off of, keeping yourself up to date with challenges that other companies are facing and not just being so insular with the company you're in now. Going back to the anthropology idea, this exercise, the interviews and maintaining these relationships. I've met lots of other friends doing this and stayed in touch with people both professionally and personally. Even after you've both left your companies or jumped two or three times, I think this can be really helpful.

I want to talk about mentorship a little bit. I think most people think of mentorship as, I would like to find a mentor who can teach me something, or I can learn from. Or I should be mentoring people that I can teach stuff to, or I can give wisdom to. Usually those relationships are, I want somebody who's older than me or wiser, or who is in a position higher than me, or I want to mentor someone who is in a lower position than me or who is younger than me. I think one of the things that I've benefited from is this idea of peer mentorship. Finding somebody who's in the same position as you, title, maybe the same age as you, but has a completely different background than you, or just a different approach to the job. I think this is an often-ignored aspect of mentoring. Companies mostly have formal mentorship programs, where they're matching you with someone who's higher position or matching you with somebody who's lower for you to be a mentor to. I think sometimes this traditional approach skips over that peer mentoring aspect. A few areas where I think that having this peer mentor can help is someone who complements your skill set. Maybe there's an area where you think you struggle with a lot that you can find somebody else who's in a similar position with you, and establish this peer mentoring where they'll complement either within the company to work on a project or just another way to do rubber ducking. Someone you can rubber duck with to throw ideas at and work on interesting projects with or someone you could just honestly commiserate with on shared struggles. If you want to vent about something you're dealing with at work, sometimes somebody who may have similar struggles in another company, or in a slightly different role within your company can be useful. You don't have to worry about it messing up any formal mentorship relationships you have.

Next topic is impostor syndrome. I just wanted to touch on a little bit because I think it's something that comes up a lot in our industry. I myself have faced this many times. I think starting at a new company is especially a challenge with this because you're coming in as this high position as a staff-plus. I've had this happen to me where people say, you're our new principal engineer, I can't wait to see the things that you work on in the next couple months. That's very nerve-racking as somebody who's like, ok, now I need to make sure that I'm living up to expectations. Artists can often feel impostor syndrome as well. They're looking at all these famous artists out there within history, or comparing themselves to those, how can I possibly create something that would be as good as that? Despite outward success, and a set of successful work, you still feel like a fraud. I think these feelings are natural, and many people have them, so take a little bit of comfort in that. Allowing yourself to fail and feel uncomfortable and exposed to the challenge, you can overcome self-doubt, and this feeling by being open and authentic, and sharing your experience with others. A few of the ways I think I deal with this, where I found useful for other folks is just be open and authentic. Let go off perfectionism. No one's perfect. Cultivate a bit of self-compassion, and share in each other's failures. You often only see someone's successes, but know in the background that they've had setbacks too. Rejected conference proposals, articles. Find a colleague that you can do this with and celebrate successes with your team. Make sure you're celebrating wins.

We talked about impostor syndrome just now, but there's also this idea of just generally embracing discomfort. I think that's an important aspect of growth. Artists like us suffer rejection quite often. You need to know that you're good, you're good at what you do, your creation is worthwhile, and you'll grow from this experience. Oftentimes, I think we want to just look at the headline. The story is not the headline. We miss out on nuance and depth and taking the easy path. For me, embracing discomfort is all about facing challenges you don't like, not taking the easy path or doing the easy items off your to-do list. Tackle the hard problems, don't snack. Will Larson has a really good article on his blog about snacking, and doing only the easy tasks and never taking on the hard challenges. Oftentimes, the hard things are the things that might result in failure, or worse, some humiliation. No one likes humiliation. Hopefully you work in an environment that embraces failure. We need to be comfortable putting ourselves out there with our solutions, like artists do, taking criticism and using it to improve. Don't try something just because you might think you'll fail. There's a lot of cliches about failing, learning. At the core of it, many of them are true. We learn from mistakes, big and small. Make time to try the hard things, get your hands dirty, and put your creations out in the world. Part of embracing this work and discomfort is making time for it. Let's talk a little bit about that in the next section.

I think many of us are obsessed with this idea of time management and squeezing every last second out of the day to be productive. I read another book recently by Oliver Burkeman, it's called, "Four Thousand Weeks." I thought it was going to be about time management, but it wasn't really so much about time management, as it was a philosophical look at how much time we have in our lives. The title, "Four Thousand Weeks" is the amount of weeks you would live if you live to be 80, which is a little scary that you only have 4000 weeks, or might. This book really gets at the core of how we should value our time, and worry less about trying to squeeze every last minute out of the day to be productive. In some ways, our obsession about productivity is making us more miserable. Just take comfort in the fact that your to-do list will never be done. We think if we just finished this project, this presentation, then we'll be done. Like I think I said to myself this week, "After this talk is done, then I can relax," which is not true. You're never done. There's a chapter in the book that discusses learning patience, by staring at a painting for three hours. This was an assignment that a teacher gave to students where they had to go sit in an art museum and just look at a painting for three hours. This may seem like torture, but the lesson here is to force students to learn patience. We want everything immediately. Why would I spend three hours looking at a painting? That's so unproductive. We need to give ourselves time to think, to daydream, to use the skills I discussed earlier, learning to be an active listener. Make time for unplanned work in your day. Most of us wake up with the to-do list. We jump on meetings. We immediately start working. Try to set aside some time where you have nothing planned. In this unplanned time, think of a problem you may have been trying to solve recently. Maybe you go for a walk, change up your environment. Anything that would help you get out of the trappings of your reasonable day.

Inception to Creation

Let's wrap up some of these ideas and lessons into a format we can use to embrace and grow our creativity. There this idea that Rick, going back to the book, talks about, which is this idea of taking your ideas from inception to creation through four steps. The first is seeds. This is where you collect as many ideas as you can. You open up your attention to the world. Let inspiration in the world around you collect these seeds that you can plant later. The job here is not to judge the ideas or think too much about them, it's just to collect them so you can reflect later. The next is experimentation. This is where you play with some of the high potential seeds, exploring them in whatever ways you can. You can imagine so you can start seeing which ones have potential life. You're not doing any editing here, just a lot of experimental play to see where you may focus your attention later. Your level of excitement over time is a good metric for selecting what seeds to focus on and take them to the next area. The next is crafting. This is the phase when you have ideated, experimented freely, and you have a clear sense of direction. You may find yourself rotating back to the experimentation phase as you begin to refine your ideas, learning more information that helps direct your art. While you're executing in the stage, you're still open and adaptive to the many possibilities of your work. Then lastly is completion. This is the final phase, one that can be supported by a deadline to help bring your art to the world. This may be more about refining, than it is to complete, which means that is the best you can make it. It's less about discovery and building as those are for earlier stages. It's helpful not to extend the stage for too long, because you may lose a sense of connection to the work.

Key Takeaways and Themes

The headline is not the story. We don't pay enough attention. I'm sure a lot of us look at news articles online, I do this all the time, and you don't read past the headline. We miss nuance and depth when we live on the surface. Discipline is not a lack of freedom, it's a harmonious relationship with time. Managing your schedule and daily habits well is a necessary component to freeing up practical and creative capacity to make great art. It seems counterintuitive to make time, to have free thinking time. It's good to make that part of your day. Make time in your day to not work on something specific, let yourself daydream. Everyone is a creator. Become a better listener. Try to cultivate beginner's mindset, and increase the sensitivity of your antenna. Don't try to micromanage every aspect of your day. Set aside one to two hours in the morning or afternoon. Block off your calendars if you can, at least twice a week for unplanned work. I know that sounds ironic, planning for unplanned work, but trust me, it's worth it, whenever you think you'll be least distracted, if it's the morning, midday, afternoon. Second is build new relationships. Try to meet at least one new person in your company once a month. Join or start some form of peer mentoring program. Maybe use a coffee or a Slack bot to meet new people. At my last job I had a goal of meeting every distinguished engineer at the company over the course of the year. I left before I achieved that, but it was a good goal to have. Then last is working on improving your active listening. Make your antenna more sensitive. Meditation is not for everyone, but find something that works for you: walks, quiet time. Commit to spending 30 minutes a few times a week exploring this space to improve.

 

See more presentations with transcripts

 

Recorded at:

May 02, 2024

BT