Author: David Grizzanti

Transcript

Grizzanti: My name is Dave Grizzanti. I’m going to talk a little bit about documentation and InnerSource. Before I do a more formal intro, just to show a quick example of some of the things I think we deal with very often. Let’s say you started at a new company, and you’re looking to get support for a shared infrastructure platform. John here goes to a Slack channel that he thinks is the right place to ask for help. He says, I’m new to the company, and I’m looking to set up a new app on our shared infra.

I ran over to the docs, but I didn’t find the answer to my question, is this the right place to ask? Another helpful engineer on the support team says, John, yes, this is the right place to ask. What do you need help with? John says he’s looking to set up a custom DNS record for an app he’s launching on the platform. The other engineer says, sure, let me dig a few examples for you. This is a common use case I see a lot. Why this isn’t documented, could be lots of reasons.

Let’s say John is on the team or at the company for a little bit longer, and he wants to ask his team for the app that we have running in production. I’m trying to understand how traffic is routed from the internet through our network to the app. Do we have any diagrams that show that so I can take a look? An engineer on his team says, “I’m not sure we have an exact diagram that shows that, but I drew something for the CTO a few years ago for a presentation. Let me see if I can find those diagrams.” How many of you face similar situations to this or have said these things?

That example about the diagram, I think I’ve said that about three times in the past, maybe not for the CTO. I think these examples are really common in our industry. I see them all the time. I think they show a little bit of a crack in the way that we deal with information sharing and support. A lot of times we handle this with more formal processes, like file a Jira ticket to get support, somebody will take a look at it. That’s not a great way of doing it either. No one wants to file a Jira ticket. I certainly don’t want to do that. Also, I think it discourages people from asking for help, just because there’s too much process in the way.

I’m a Principal Engineer at The New York Times. I focus on developer productivity and platform engineering at the Times. I think a lot about these use cases where people are asking for help for the platforms we’re building, and how to get them to move faster, build more paved paths to let them get to what they want to do, which is build products. Today we’re really talking about building organizational resilience. I’ll weave in some of those ideas as I go through this. Really, I want to talk about how some of these documentation examples and open source concepts can help build resilience for organizations.

Information Availability

I think a lot about developer productivity, like I mentioned, and how to engage with engineers to make their lives easier. Part of this process is making documentation easier to find and understand. I think we just have a sea of information now. We’re overwhelmed with documentation that exists that’s either out of date, or has correct information but not exactly what people are looking for. It’s often easier for somebody to ask just for help on Slack like I showed, or whatever communication tool you might be using, than reading through pages of documentation and trying to find the answer themselves, or piece together a solution from a bunch of different places.

The issue with the Slack approach, I think, is that we often answer the questions but we don’t go back and make that content available for others. It repeats that process over again, like we answer the question, but we don’t take what we answered and make it available for other people. This doesn’t just stop at documentation. It extends to diagrams, like in that example I mentioned, architecture decisions and why systems work the way that they do.

You can also argue that this happens with software too. Large companies have lots of duplicative software across teams that maybe do the same thing. Teams often maybe write something that already exists, because they don’t know that those things exist in the other companies or they’re available for sharing. To sum that all up, I think my thesis is information either isn’t available or discoverable. I’m going to talk a little bit about how maybe we can solve that.

Effects on Organizational Resilience

I want to talk about some of the effects of this bad documentation or information unavailability and the effects on organizational resilience. The first thing is turnover, so folks leaving the company. This is a big one I’ve seen cause harm to teams and disrupt continuity, where a single person or even two people might know how a system works. When they’re gone, or they’re on vacation, somebody asking me for help like that on Slack means that somebody can’t get an answer. This might mean that you can’t move as fast as you want, or you can’t get the help you want until a new person comes up to speed or a new person is hired. The next is onboarding challenges.

I know for myself, because I started at the Times about a year ago, one of the tasks I was given was, can you go through our documentation, try to do this and tell us what’s wrong. Which is interesting, if you like fixing documentation stuff, but some new folks might get frustrated that now they can’t onboard very quickly because they’re in charge of finding the holes in the documentation. You’re putting this burden on them to improve. Either way, it’s not a great experience. Either people can’t get up to speed quickly, or they’re frustrated by the lack of documents.

The next thing is reorgs. For any folks who’ve worked at large companies, this is pretty common. People get moved around. Teams get moved around. Most of the time, what happens is the systems that they supported previously, gets carried around with them. They have this baggage of support, even though they’re on a new team and supposed to be building something new.

Either because they didn’t have the time to document or draw the right things, or they just didn’t have the right practices in place. Then the next thing is outages. In the middle of the night, if you have to call somebody and wake them up to find out how a system works, or you can’t find the right dashboard, or find the right documents, or something like you’re on vacation again, now your outage is going to last longer.

How Can We Improve?

What are some ways that we can improve this? The first thing I want to talk about is documentation. How to create an environment where good documentation practices are encouraged. Ways of making your documentation more discoverable, and teaching people how to approach documentation and maybe how to write technically, in a positive way.

Then the second thing is this concept of InnerSource. This is the idea of doing open source internally. How to create projects that are sustainable, internally. Get more contributors across the company, instead of your main team. Spend less time building the same things, and make happy customers and build trust among engineers.

Documentation

Let’s talk about documentation first. What makes documentation good? By itself, documentation doesn’t necessarily solve a problem. A couple key things, I think, is that it needs to be useful. It needs to be relevant, correct, and up to date, and discoverable. Documentation is not just words. It could be diagrams. It could be information in READMEs. Or it could just be code comments. I think we’ve rode the wave of whether or not code comments are good or bad, or you should write code that’s self-documenting. People don’t need code comments.

Oftentimes, people will write very complex things in software, and they don’t necessarily know where to put the information about it. I think code comments have their own value in this documentation story. Bad documentation often causes more problems than it solves. If you have really long verbose documentation that doesn’t really answer a question, somebody spent all this time writing this, curating it, and if no one’s using it or reading it, is that really any more valuable than not having anything?

The Challenges to Making Good Documentation

Let’s talk about some of the challenges to making “good documentation.” What I found, I think, is that people often want curated and custom answers to questions, going back to that Slack answer I saw before. Either they can’t find the information in docs or they don’t want to read, so they come to ask you a question. This is maybe like a slightly contrived example. I wanted to promote The New York Times cooking app while I could.

Let’s say you were on the Times cooking app and you wanted to make a recipe, and you’re like, “Ok, I’m going to be adventurous. I’ve never made bulgogi before. Let me make this.” I’m looking at the list of ingredients, and I say, I don’t know what gochujang is, I can look this up. I don’t know if anybody’s ever used the cooking app, but reading the notes is a very fun rabbit hole to go down because people ask the strangest questions and also suggest the strangest substitutions. One of the comments I actually saw on here was, what is gochujang? Very fair question. To me, I was like, why would this person ask it in the notes? Why would you not just Google it? I find that people often, they want an expert answer.

Maybe the cooking community has a better interpretation about what this is than Google does. Maybe they don’t trust Google. To me, it hits on like this idea of people wanting someone to give them a specific answer to their question. They don’t necessarily want to look it up or trust somebody else. If you haven’t looked at the notes, or looked at this Instagram account for The New York Times cooking notes, I highly encourage to go take a look.

Another thing is, communication face-to-face, over writing or reading. I’ve been remote. It’s different than in the office. I find people often will DM me and ask me for help with something like, can we jump on a quick call, and let’s talk this over? Maybe that’s ok in the beginning, as long as something comes out of it.

When you’re talking over a problem or situation that’s like in a support nature, and you come up with a solution, that’s not written down anywhere, it’s not even on Slack. That cycle of not producing anything of value afterwards continues. There’s a place for helping people in a one-on-one or talking through a problem. I think oftentimes, if nothing’s produced out of it, or this is your cycle of always answering questions that way, that can become a problem.

The next thing is, writing well takes time and focus. I’m not sure how much this resonates with people. This is what my schedule looks like very often. I don’t know how anybody finds time to focus if your schedule looks like this, especially with the chaotic nature of the meeting blocks. If you ask, I find often that when I see somebody answer a question on Slack, or help someone, I say, can you take that information and go put it up somewhere. Synthesize what they asked, and your response, and put it up on our docs.

Most of the time, they don’t do it, or they do something and the result is not super helpful. Often, it’s because I think, again, we’re just too busy to find blocks of time where you can focus a lot. This may not be the case for all engineers. I think I found that in a remote culture, a lot of times, a lot of these blocks are dedicated one-on-ones that people have with people, or just meetings that are recurring, to check in on status. Everybody needs these meetings to feel like they’re connecting with their team, and it doesn’t necessarily help with the focus time.

Solutions to Documentation Challenges

A few solutions. We really need to get better at communicating asynchronously. I think the idea of communicating more but less frequently, is something that I’ve been trying to do more of. Meaning, put out more information, but don’t feel like you need to talk with somebody every day. I came across this quote in this law the other day that I thought was interesting, which is the idea is if you can write down the problem clearly, then your issue is half solved. It’s referred to as Kidlin’s Law.

The idea is like writing down a problem, getting it out of your head helps clarify and work through your thoughts. To me, it’s like rubberducking in programming. Like, if you jump to your first thought, or thinking about something on the surface, and throw on an idea, oftentimes, it’ll die on the vine. I’ve seen this happen with important conversations I’ve had with colleagues recently, where we want to make some big technical decision and they haven’t really fully formed their thoughts around how they want to solve it. They will propose it in a meeting.

Like, I want to use Helm charts for Kubernetes versus some other tool, which is very controversial, but they haven’t really figured out why they wanted to use it. They may have just read a blog post about using this to solve some problem. The mass or the group will throw a bunch of negative opinions at them. Then they feel discouraged and back away from it.

Where I’ve been trying to encourage people to say, ok, take a day or two days. Write down what you think the problem space is, what your solution to that is, and then share that out with people. Let them comment asynchronously, let them take time to digest it, and then we’ll go over it with everyone. Taking the time to think through and write down your problems before you introduce them to people.

The next thing is, teach and encourage a culture of writing. This is something that I started doing in my last role, which is this idea of, people have different writing styles, all that doesn’t necessarily lend itself well to technical writing. Google has these technical writing courses, that they teach technical writing, and some of it is grammar. Some of it is just how to write in a way that’s verbose enough, but clear when you need a particular technical point.

Like, don’t write in passive voice, write in active voice. They run one or two classes that you can join. They also give you the materials if you’d like to run them internally. I joined one of them maybe two years ago, and there was like 60 people on the class, so it wasn’t all that productive with that many people. We took the information and ran a few sessions internally, which were successful. I wasn’t there long enough to continue doing that. It’s something that I’ve thought about bringing it back to the Times.

The next is, make it discoverable. I had this at a job, 15 years ago. It’s a Google Search Appliance. It’s something that you could buy from Google and stick in your data center. It would essentially make a Google search engine of all your documentation internally. Unfortunately, they killed the product at some point. I think that this issue of searchability of information in companies is a huge issue. I’ve never seen a great solution for it.

A few things that I’ve seen recently, and some things that we’re doing at the Times now, that are some alternatives, that other people are familiar with these tools. I’ll go through them and talk about pros and cons. Backstage is an open source developer portal that was originally written by Spotify. It’s now a CNCF project. They have this concept of TechDocs.

You can bundle all your MkDoc sites into Backstage and then search them within the Backstage portal. If you happen to have a bunch of MkDoc sites that are all spread across your company, you can put them into Backstage and make all the docs searchable. That works well for MkDocs, maybe not so well for other things. At least technical documentation is all searchable in one spot.

Google Cloud Search is actually really valuable if you’re using a Google suite of tools. That’s what I use most often now. They even have a plugin thing that you can integrate, I think with MkDocs to make some of the MkDoc sites searchable as well. Hermes is a project by HashiCorp that gives you a nice interface over the top of Google Docs, that also makes them more searchable, which is nice.

GitHub code search has gotten a lot better, if you’re storing all your documentation in READMEs. Then something I’ve looked up and not used a ton is Elastic Workplace Search. I think this is a pay feature. If you’re an Elastic user, you can plug in all these external sources, and then make it searchable, and Elasticsearch will index it for you. A couple of things to solve this searchability problem. What I’ve seen at most companies is they’re all using slightly different flavors of all of Google Docs, Markdown, things in GitHub, so it’s not perfect. If you can focus on one documentation type, it can be really valuable.

The next is, create the right incentives. This is something my boss said to me the other day when I was complaining about trying to get folks to write stuff down, is that we don’t often have the good incentive structure to write documentation or to write stuff down. The incentive is to push out code or help users. If you help them get something done, or ship a product, like that’s the success story. Not, I’ll go back so the next time somebody doesn’t need to ask the question.

I think we need to reward people for working on this stuff, just like working on coder solutions. Smruti mentioned in her talk on platform engineering about this book, by Kathy Sierra called “Badass.” The quote from her talk, and from the book is about making better photographers not a better camera. That idea really stuck with me because we oftentimes think about making our platforms better or good enough so people don’t have to ask questions. It should be really easy to use they don’t have to ask questions. I think we’re building such complex things that that’s not often the easiest path. I think our goal should be to give users as much information as knowledge to make them power users of the platforms. Making information digestible and curated in a way that helps them learn.

The next is, understand and learn how folks like to work. I think getting to know each other really at a personal level helps. There’s lots of different ways to do that. Especially in a remote culture, it’s challenging. I think you need to be intentional about building connections and trust with remote people. Oftentimes, we ask people to do things like, why didn’t you just write this down? Or why didn’t you do that? Some folks may feel intimidated about writing large documents.

They need more focus time. I just think understanding that relationship between people and between your coworkers is important. I think practicing empathy in that space is especially important. One of the things my manager did at a previous employer, was we did this team norms and stories, where we got all in the conference room for a few hours, and people went through what’s your best and worst day, not personally, but at work.

Someone said my perfect day is, “I go into Jira, and there’s a ticket I can pick up, and it has all the tasks I need to do. I can pick it up and work on it, and then I can move it to done.” I don’t want to think about all the complexities of like, what I need to do, I just want to be given the list and I want to work on it.

Someone else may be like, “I want more ambiguous requirements. I’d like to like design this myself, and then work on it.” I think until you get that information out of people, it’s hard to assume how you should approach things with people. As a manager, you might be getting frustrated like, why isn’t this engineer working on what I asked them to do? Maybe the way that they like to work is not something that you understand. I think being open and honest, and just discussing how people like to work is important to having a successful and productive team.

Then give the time and space for creating. Maybe you have dedicated time for reading and review, dedicated focus slots for writing, and writing meetings. That sounds counterintuitive. A few times we’ve done this like, let’s just schedule a block of time to block it out. We’ll put our cameras off and turn our mics off, and we’ll just sit there and read this document and then comment on it. I’ve done that a lot recently for proposals that we’ve been writing for standards at the Times, where we have a scheduled block of time, and we’ll review some of the documents that have been written, to take back comments. Being online, being on the meeting allows us to just go off mute quickly and ask a question if we need to, otherwise, we’re not talking back and forth.

Lastly, let’s talk about just agreeing on approach, to writing and formulating some of these documents. Don’t worry too much at first about formal patterns and diagramming tools. I think people sometimes get hung up on like, what’s the right format. You spend two days searching on Google for the perfect template, or whatever you’re going to use.

Reminds me of the story somebody talked about, where they spent three weeks finding the perfect computer to work on and the perfect editor to use. You can spend too much time overthinking what’s the right thing. Don’t worry too much about formality, just clear and simple documents and design should be your goal. If you do want to decide on a style or a format, RFCs and ADRs are a good format to choose. They have structure to them. Most of the time you can find a lot of information online about companies that follow these approaches.

If you struggle for where to start, and you want something to use, these are a good basis. This is an example of an ADR template that a colleague of mine at the Times, Indu, proposed for her team to start using. It’s not super complicated, just a question to decide on, what’s the context, what’s the recommended decision, supporting arguments, those sorts of things? Just gives you a place to start and a place to write down your thoughts, so you’re not just staring at a blank Google Doc and being like, how do I ever write down this long document? Especially if you’ve never done one before.

Some basic steps. Get together with your team, brainstorm and approach. Maybe do some whiteboarding. Write up the document, whatever format you choose. Consider tradeoffs. Then, circulate to engineers. I think one of the also common things I see is that people are afraid to share the document before it’s perfect. I think circulating it, and getting feedback early and often is important. If you find yourself wanting some more formal approach to this, I’ve seen a mix of these things work.

At the Times, we have this thing called the Architecture Review Board. That’s not like an ivory tower architects’ person, it’s a rotating mix of engineers throughout the company, that changes every year. Whenever an RFC or an ADR is written, teams will send them to this review board, and they’ll give feedback as a more slice of engineers across the company. It’s not a mandate.

You don’t have to go to them before you launch something. It’s more of a nice to spread the information around with everybody to get some feedback before a decision is made. Sometimes they can catch things that you wouldn’t normally see, or you might get feedback from another part of the company that you may not know anything about. Especially in the platform space that I’m coming from, it’s valuable in case you’re not really paying attention to something that might affect them.

InnerSource

Let’s wrap up on documentation and talk about InnerSource, which is the second topic, which focuses more on software sharing, and a bit on documentation within the scope of these projects. What is InnerSource? InnerSource is internal open source. It’s the use of open source best practices and the establishment of an open source culture within your organization. You can still develop proprietary software, but you’re opening up work between developers and teams internally.

I think the key idea with InnerSource is it can help break down silos, and accelerate innovation with a transparent culture, like open source. Saying, just do open source in your company, is not necessarily easy or quick. It’s definitely a journey. You need to transform to a more internal sharing economy, respecting corporate culture and values, and internal organizational constraints.

The idea is to drive towards openness and transparency across teams. I think an easy one is, use a single version control system, and everyone should have read to all repositories, which I think is a common practice in some orgs. I’ve seen that in previous companies that’s not always true. There shouldn’t be a reason why you’re hiding code from internal engineers. Make sure everybody at least has read.

Benefits of InnerSource

A couple areas, I think, where InnerSource can help. If you manage to get this up and running, you can definitely develop software faster by having more folks helping you, even if it’s just one person from an outside team, who has ideas on a shared library or shared tooling. Improving documentation. The onboarding example I mentioned a while ago, if you don’t have a lot of new engineers starting out on your team, if you have new people coming in often that want to contribute or want to help, they’re constantly looking at your documentation, looking at your contributor guide, they can help improve docs for themselves, and also for the wider company.

Reuse code across teams. Maybe you have people rewriting the same tools across the company that do the same things, especially in large organizations, so build a common set of shared libraries that multiple people can contribute to. This also builds trusts and improves collaboration: engineers knowing each other across teams, helping each other, those sorts of things. I’ve seen the develop software faster and the reusing be really useful with maybe internal APIs or internal platforms with supporting tools.

We had a pretty successful DNS tool at my last company, where we had lots of people from outside the team build libraries, and also like Terraform modules, those sorts of things, that weren’t developed by the core team, they were developed by developers that were using the APIs. It was an example of developing software faster and helping this trust among engineers.

How Does InnerSource Improve Resilience?

How does this help with resilience? I think from an employee turnover perspective, you don’t only have one person that understands how the software works, or even one team, because you have people from across the company contributing to it. Maybe they can help take over. They can move teams, if you have staffing issues.

Helps with onboarding time, because of the documentation that I mentioned earlier. Also, with more people contributing, there’s just more activities, so I think new people coming on can get started quicker. Then the same thing with reorgs. If you have teams moving, if software is getting handed off to different teams or moved around, the more people that understand how things work and are contributing, the quicker you can get started.

InnerSource Commons – Patterns

InnerSource Commons was founded in 2015, and is a nonprofit. It’s the world’s largest community of InnerSource practitioners. They’re dedicated to championing this idea of InnerSource and building a community around it. I’ve been working with them over the last few years, and contributing to this thing they call patterns. I want to go over a couple patterns that I think are valuable and can give you an idea into how to get started with maybe promoting InnerSource inside your company.

This is a mind map tree of all the patterns that they support and a couple categories that they fit into, so begin, adopt, grow, and scale. The idea is that you can start at begin, and travel down depending on where you are in this journey. I’ll talk about a few of them across the four categories. Let’s say you want to get started, but applying open source practices doesn’t work in your company when maybe some folks are lacking an open source background.

The pattern that they have for that is called documenting guiding principles. The idea with documenting guiding principles is it provides clarity on purpose and principles to users. Why does the organization want to adopt InnerSource? Which InnerSource principles will help address these challenges?

The next one is, new contributors have a hard time figuring out who maintains the project, what to work on, or how to contribute. The pattern there is standard based documentation. This is the idea, which you’ve probably seen a lot in open source projects. It addresses the need for clear documentation, so maybe a README, contributing guide.

In the open source world, that also includes things like licenses, which may be applicable internally for you as well. It enables a more self-service process for new contributors. They’re not pinging you on Slack and asking you, “I want to fix this bug, is this the right way to go about building the application?” I’ve seen this example, actually fairly recently. We’ve collected a couple people across our platform engineering org to help work on a few things, and it took them two to three weeks to add a feature that was very basic, because they didn’t know how to test what they were working on.

Not just unit tests, but test it as the integration point across systems. I met with them. We worked through it. We improved some of the documentation. Then they opened the PR and the team that wrote the app changed the way something worked, so now all their tests weren’t working anymore. I didn’t know that either. I had to go back and ask them. They didn’t update the documentation. I think just being in this habit of maintaining your contributing guide, even if you’re the only team working on it. If someone else wants to contribute, or another team member in a sister or a brother team wants to contribute, it’s valuable to keep this stuff up to date.

Next is, teams may hesitate to adopt a project, if they’re unsure of its maturity. I think this is a pretty standard thing in the open source world where if you go look at a popular open source project, most of the time they have release notes, they have an available binary that you can download, or brew install, or whatever. I think internally, we don’t often publish standard artifacts. This pattern is a standard release process, which is publishing release notes and usable artifacts.

These practices show dedication to the project. It demonstrates commitment to sustainable software, and increases confidence when you’re publishing a quality product. For internal maybe like CLIs or binaries, oftentimes, if the team uses them, they’ll just build it themselves locally and have it on their machine. They don’t make it available for other people to install easily, or like publish the release on their internal GitHub. I think if you want other people to be able to use it easily, you need to make it available and also show them that you push out releases every month and are publishing release notes, so they know what to expect.

The next is, thank outside contributors for their time and effort. This is, praise participants. I’m not sure how common this is in open source. I feel like I’ve had mixed reactions to this for people. The idea is that, it feels good for people to be recognized, even if it’s something silly. Sending somebody a thank you note, sending them stickers if it’s an open source project.

I think increased recognition is an avenue to influence and growth. I think if you thank people, they’ll be more likely to contribute a second time. They’ll feel good about making something better, versus their contribution just being ignored. I think everybody likes swag. It’s a valuable thing to give away. Having projects internally in your company, think about branding them. This is something I’ve been trying to bring to the company I’m at now where we had a project that had a name, and we were having an onsite at the company where we were going to be talking about the project.

I said, we really should print stickers and give them out when people come to the talk. They’re like, we don’t have a logo. I was like, let’s just make up something on Photoshop, and then print it out and send it to them. We did that. Then people took the stickers and put them on their water bottles, and the name becomes more synonymous with the project, because people have this little token.

Next thing is, potential contributors cannot easily discover projects that interest them. This is the idea of having an InnerSource portal. This could be like a website you build yourself. It could be tags you use on GitHub. It’s just this idea that you want to make the projects discoverable in some central place. Backstage has a plugin called bazaar that is an attempt to make this InnerSource portal idea.

You can list all the projects in maybe your GitHub repository that meet some qualifications for InnerSource, whether they’re ones that you’re trying to promote, or that have a good contributor guide or whatever. Some curated list, that you’re telling people, so they’re not just trying to figure it out themselves by wandering around GitHub.

Create participatory systems throughout your software lifecycle. This goes back to that RFC idea I mentioned before, but cross-team decisions through RFCs is important. Again, don’t focus too much on the format. Publishing these kinds of standardized format documents out in the open through that Architecture Review Board, or just through some engineering email list allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all parties. People see that you’re going to build this new tool or make changes to the platform. It’s not a surprise to them when it happens, because this document’s been circulated more widely.

Key Themes

Some key themes that I mentioned here is, documentation needs to be accurate and discoverable. Find what styles and formats work for you through trial and error. Don’t assume that if somebody else is doing one thing it’s going to work for you. Make the time and tools available to contribute successfully. The incentives I mentioned before, just giving people the time to focus and write tough stuff down.

Build a culture of InnerSource for key projects and platforms, and follow some of the prescribed patterns that I mentioned. The community is always looking for new patterns, and also new companies to sign on to patterns they have. It’s important for them to see examples in the wild of these patterns in practice.

Takeaways

Discover how your team likes to work. That idea of sharing and going through what people’s ideals day is, I think is a good way to understand what people want out of their work environment. Make dedicated time and space for reading and writing. Investigate the patterns I mentioned.

Questions and Answers

Participant 1: On the topic of InnerSource, it strikes me that monorepos get at some of the same sorts of things. Can you talk about how monorepos and InnerSource might or might not be able to do that?

Grizzanti: The Times has a few monorepos. The news app I think is a monorepo. I think it does help with some of the information fracturing across repos. Like all the code is in one spot, you might only have one README, one place to put a Dockerfile or a Makefile to do builds. I don’t think InnerSource has a pattern on monorepos.

That’s actually an interesting thing to chat with them about. I do think it has pros and cons. I’ve seen some of their build pipelines are a little gnarly, because they’re trying to like, if you check something into this directory, how does that affect the build pipeline? I think from centralizing all the information in one spot, that can definitely be helpful.

Participant 2: Can you go through maybe a few more practical ways to get time and space made to be able to do much more, for instance, communications?

Grizzanti: I think there’s two aspects there. From a personal perspective, you can block off your calendar. Whether or not that works super well for everyone in every organization is organizational dependent. I think also, you need to think about like, when do you work well on those sites of things? Being introspective about like, am I better in the morning, am I better at night? Where would I prefer to focus time, and advocating for that.

Some organizations, we toy with this idea of having a focus day where there’s no meetings. It was on Fridays, which I think is probably the worst day to do it. Because I feel like at the end of the week, people were like, I don’t want to spend all day working on documentation on a Friday. That may not be successful. Maybe you just want to wrap up your week and get a bunch of other stuff done. For me, the best time to do it is in the morning. Luckily, even though The New York Times is based in New York, I work with mostly West Coast people, so I don’t have any meetings until like 12:00 or 1:00.

Most of the time in the morning, that works really well for me. That doesn’t work well for everyone, though. I think there’s a balance of like doing the blocked calendar thing, and also figuring out what times work for you and advocating with management. We can’t just expect people to be able to spend all this time reading huge documents that we’re putting out, commenting on them and writing their own if we’re in meetings all the time. I know we’ve been talking a lot about making more space for that, trying to cancel more meetings, doing stuff more asynchronously.

I really like Cal Newport’s book, “Deep Work.” Also, there’s another one called, The Death of Email. He talks all about how tools like Slack, and just the constant connectedness is ruining our ability to focus. He goes into a bunch of styles for folks to do more focus work, and figuring out what works for you. Like investing time and money into something may help you focus because you’re being more intentional about it.

He tells a story in the book where somebody was trying to write a book and he never had any time, so he bought a flight from New York to Japan, and then got off the plane and then flew back. All he did on the plane was write. It was really useful for him because he couldn’t do anything else. He spent all this time and money doing it, so he felt the need to focus. Obviously, that’s a little impractical for most people. Maybe you need a different place to go to write instead of just being at your desk. Toy with those ideas and figure out what works for you.

Participant 3: In my organization, [inaudible 00:43:19] we have many country sections, many viewpoints to diagrams, many [inaudible 00:43:29] spread across many different systems. I was wondering if you have any tips or suggestions for how to organize that, and encourage other people to keep them organized?

Grizzanti: I think we have similar problems. I think the diagramming for us is a bigger problem, because everyone uses a slightly different format, it’s at a slightly different level or scale. This doesn’t help with discoverability, but I’ve recently been trying to encourage people to use the C4 diagramming style. It’s like, this idea that whenever you’re drawing something, there’s four levels.

The example he uses is Google Maps, you’re looking at it from the continent view, or you’re looking at it from the country view, to the state view, to a specific road. At least that gives people a common like, these are the levels I should aim for to keep the formats common. I don’t think there’s a great way to search for diagrams, though. At least I haven’t found anything to make discoverability of diagrams be easy unless you put them all in one place. I think the easiest place to probably host those is in the GitHub repos where the tools are also present.

As long as they have common formats, they may have common endings, and you can use code search to find those things. I think storing them in the tools that you’re drawing them in, and keeping them there only, and producing PNGs or JPEGs, and putting them on a wiki doesn’t really help. I think keeping the original sources and the copies of them with the source code repositories, is probably the best thing that I’ve seen, because at least then when you’re looking at the actual repository, the diagrams are cohosted with them.

Participant 4: I’m curious about one of the earlier points you had, that people are looking for curated specific answers. That is something that I see fairly often. I think it’s almost like a cultural thing. I’m wondering if you have any tips for dealing with that.

Grizzanti: What we’ve tried to do is when people ask questions that we know are documented, to encourage them to go look at the documentation, like not RTFM. Don’t be mean about it. Like, “We have this documented on this place, go read it.” One thing I’ve seen work well is using Slack bots to try to understand what people are asking, and then point them at the docs. That requires a lot of investment, though, and it’s per team.

I think encouraging the people who are answering the questions to understand that this issue exists, and if you just answer the people’s questions every time, then they’re going to keep coming back and asking over again. If you look at their questions, point them at the docs, or after you answer it, write the documentation up and then point the next person back at that. I think that’s the best we can do at least for now. I don’t think this problem is unique to our industry either. I do think that a lot of people are just used to getting curated answers to things, the cooking app being the example.

Participant 5: I was just wondering if you had any recommendations for keeping code [inaudible 00:47:13]. Then, also, if you’ve had any success with tools that generate documentation, like Javadocs, or Doxygen, or something like that?

Grizzanti: There was a movement around continuous documentation, which is this idea of keeping your docs with your code and treating them like source code so that they’re updated when the code is updated. Whether that’s like, you have some CI that runs with your code that says like, did you update the documentation, or reminders?

I think is really the best process we can do. I think that’s also very cultural, to just stay top of mind of like, “Ok, I changed something. Do I need to check if the documentation should be updated, or the diagram should be updated?” Most likely if you’re changing something, there’s likely something that needs to be updated somewhere. Just seeing that often in pull requests can build that culture.

I’ve seen that work for APIs, like Swagger, and Javadocs, and Godocs. I feel like oftentimes, people just to get around the Go complaining, you just put one line at the top of the functional. It’s a balance. The self-generating stuff is useful. A lot of times, it’s just boilerplate and it may not tell you all the complexities of the stuff you’re writing. I think that’s also just when you’re doing pull requests, reviewing, make sure people are actually documenting what’s happening, if it’s valuable.

I was talking to a former colleague about Ruby. I remember when I was writing Ruby 10 years ago, rubocop was very militant about keeping your functions very short, having certain number of lines. I think that’s something that we don’t often check. Really long functions that have no documentation are not good. If you keep them like four or five lines, maybe they’re self-documenting enough that you don’t need a lot of code comments.

Participant 6: [inaudible 00:49:33]

Grizzanti: I did think of one other tactic I’ve used in the past to improve documentation is to do documentation sprints. We did that recently when we were launching the GA of our platform. Maybe every couple months, maybe once a quarter, you say like, we’re not going to work on any features for the next two weeks. We’re just going to work on improving docs. Maybe once a quarter is too much, maybe it’s not often enough, but being intentional about fixing that, and improving it and making it better is valuable.

See more presentations with transcripts

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

Subscribe on:

Apple Podcasts
Google Podcasts
Soundcloud
Spotify
Overcast
Podcast Feed

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.