Modesty is a Luxury: An interview with Dan Tao

In this interview with Dan Tao, we discuss modesty and other insights on engineering culture. Dan is the Head of Engineering for 

Bitbucket Cloud at Atlassian. As an engineer within a large organization, if you don't celebrate your achievements you run the risk of the larger organization being completely unaware of what you are working on. It's critical for individual contributors to recognize this and proactively take charge of communicating their achievements for the benefit of the organization as a whole.

"It's great to not bring attention to yourself if everyone's already aware of everything you're doing. But nine times out of 10, the vast majority of cases, that's not the case. You need to get out there and talk about the work you're doing." 

Hosted by Alastair Wilkes & Harpreet Singh

• • •

Introducing Dan Tao, Head of Engineering for Bitbucket Cloud

Al: Hi everyone, my name is Al Wilkes, and I work at Launchable as Director of Product Management. Today I'm joined by Harpreet Singh, co-founder and co-CEO of Launchable, along with Dan Tao, who is the Head of Engineering for Bitbucket Cloud at Atlassian.

We thought it would be fun to catch up with Dan to get his thoughts on the current state and challenges around not only software development but also software teams, particularly in larger organizations, as well.

So Dan, welcome. Why don't you kick us off by telling us a little bit about yourself and what you've been working on at Atlassian?

Dan: Sure. I've been with Atlassian for about six years, and I've been on Bitbucket that whole time. I became the Head of Engineering a few months back.

I've been an engineering manager throughout this time, but Head of Engineering is kind of a new role for me. As for what Bitbucket's working on right now, there's a lot of things going on - as I'm sure you both know, since Harpreet and Al both are former coworkers of mine on Bitbucket.

So you guys know there's a lot going on all the time. Probably the biggest thing that I can share it has to do with Bitbucket is part of this large initiative around Atlassian's announcement that they want everyone to move to the cloud. They're actually end-of-life-ing all of their server products, and that includes Bitbucket Server. And so the Bitbucket Cloud team and the Bitbucket Server team are working closely to prepare for a large number of Bitbucket Server customers to move to Bitbucket Cloud.

Casual onlookers might not realize that those are two completely different products. They have the same name, but they're different codebases, different teams, and have had totally different trajectories from their initial conception. So we're working on migration tooling, we're working on implementing features, closing feature gaps with Bitbucket Server and just in general, sort of shifting towards being more of an enterprise kind of focused product. Bitbucket Cloud has its origins as being primarily for developers. It was even kind of targeted toward the open-source community in its early days. There's been quite an evolution of the early product to today where now it's about becoming more enterprise-ready and preparing for customers who have been used to Bitbucket Server. And like I said, building that migration tooling so that it's not this huge task that we're asking them to go and copy all of their data over. We're building a nice set of tooling to help do it for them.

Al: Got it. Got it. And as you said, you stepped into this role fairly recently.

What does a Head of Engineering do? What are they responsible for Atlassian? (Besides talking to us!)

Dan: [Laughs] That's right. Yeah. Mostly just giving interviews to other companies now.

When I interview managers, normally the thing that I tell the candidates who want to become engineering managers is that your primary responsibility is to make sure your team is effective. You know, your output is a high-performing team. As Head of Engineering, my role is to make sure the Bitbucket engineering team as a whole is a high-performing team. I do get involved in the projects on a situational basis, but in general, I'm not.

Day to day, I'm looking at the projects that our teams are building, but also looking at what are the things that are slowing teams down across the board, what is causing frustration for the engineers on the team? Where are the right people not talking to each other?

Where are we not sharing knowledge effectively? And so those are all sort of my main focus. So I don't think that I have a one size fits all answer to what does the Head of Engineering does at Atlassian, but I do think that's the primary goal is to make sure your engineering team or your engineering org has everything they need and is operating effectively.

Harpreet: Got it. All right. So, given you're moving from server to cloud, I believe the timeline is set for doing that. So I guess you must be in a race to provide all this tooling while making sure that your teams are productive and happy and so on. So tell us how that challenge is manifesting itself.

Moving from Server to Cloud

Dan: Yeah. So, Atlassian gave a pretty long advanced notice to customers. They're not shutting off their server products tomorrow. So we do have time concerns, but, as you're alluding to, just as equally just as large concern is team burnout.

We're not trying to get our teams to work long hours and just get it done, nor are we trying to rush anything, because that's not good for our customers either. I think the primary method we're using to make sure we're on track is just prioritizing, very ruthlessly and very regularly, about what is the sort of top things that need to get done.

For the migration tooling I mentioned, we have an early access program. The teams working on those features are reaching out and working closely with a small group of customers who have expressed interest. They want to try it out even if not all the bells and whistles are in place; they just want to help get this tooling to a place that it needs to be where it's ready for all customers.

So, prioritizing and making sure that we are not going to reach a point where Bitbucket Server is now at its end of life and Bitbucket Cloud isn't really covering the main bases that it needs to cover. I think that we're in good shape there.

Also, the whole time I've been at Atlassian one of the company's values is "Don't fuck the customer." So even when we've communicated to customers and try to do our best to make sure everybody has the notice, they have the support and resources that they need, and they're informed, I've still seen it happen where a customer somehow wasn't ready or missed the memo or whatever it is. Atlassian always works with them. We don't want to just sort of turn a blind eye and say, "sorry, we gave you advanced notice. Now you're on your own." So I fully expect that we're going to do that this time around as well.

Harpreet: I was actually coming in from a different angle. Having worked at Atlassian for a short while, when I talk to people, I now hear the adulation of people for Atlassian and what the engineering practices are and how they tackle the challenges. So, as you were talking about this, I was thinking that this would be an interesting series of blogs in terms of how you've managed to take a huge set of customers from server to the cloud and driven that through these timelines and how you made these trade-offs.

I'm sure lots of people would be really interested in hearing that because that's effectively the challenge that most people that we talk to have. They are on some old code bases they're trying to move to the cloud. They're moving from monolith to microservices. Some timeline has been roughly set up for them because that's how they're trying to react. And then it's just blocking and tackling throughout the journey to that point.

Dan: Yeah, no, I totally agree. And I hope we are going to put out a series of blog posts.

I'll take that as an action item to make sure somebody's name is attached to that. Cause. I think the point you're making is to not do it in darkness but to share the story with our customers as we're working through it, which I agree would be very valuable.

Philosophy and Software Development: Modesty fits in

Al: Speaking of, I think that's a good segue to talking about your blog.

Dan has, in my view, an excellent blog about philosophy and software development combined called philosopherdeveloper.com. You've been writing there for a number of years now, and you recently posted a blog about the concept of modesty being a luxury.

I was wondering if we could spend a little time talking about that. So, what's the central idea, and what kind of prompted you to write this blog? We thought it was really interesting.

Dan: Yeah. The central idea is that part of the responsibility of an engineer or the responsibility of anyone in an organization is to communicate what they're doing.

If you write a bunch of code, and nobody knows that you wrote it, and it doesn't go anywhere that anyone sees any of the effects of you having written it... It's sort of like if a tree falls in the forest and no one's there, did it really make a sound? So, writing code as a software engineer, it's easy to think "that's my job," but no, your job is not to add text to a text document, it's to make changes to software. And then you have some ownership of the impact that those changes have, whether it's on other teams that collaborate on the same code base, whether it's on the customers, whether it's on other Atlassian teams or other teams at your company.

So that's part of your job. That's part of what you need to be doing to contribute to the success of your organization. But I've found that there's a lot of reluctance to share, and I think it's because people conflate the notion of communicating or sharing your work with the notion of bragging or boasting about yourself or trying to call attention to yourself. And because we view this concept of modesty, or of humility, we hold that up on a pedestal as a really good trait that we all want to have.

So the point of the post is to try to encourage people to separate those two things to the extent that you can, and to basically say that if you're avoiding communicating what you're doing because of modesty because you don't want to call attention to yourself, I call it a luxury because you can't afford that.

You know, luxuries are things that are great if you can afford them, but you shouldn't be buying them if you don't have the resources or the means to actually to buy them. And to me, modesty is the same way. It's great to not bring attention to yourself if everyone's already aware of everything you're doing. But nine times out of 10, the vast majority of cases, that's not the case. You need to get out there and talk about the work you're doing, make sure the right people are informed, make sure customers are informed if it touches customers. And this doesn't mean bragging; it doesn't mean showboating or anything like that.

But to the extent that you're concerned as a person that it might come across that way, you sorta need to get over that because it's something you need to do. That's the central idea.

I wrote it because, for example, I've seen many cases of engineers who work on a really gnarly bug. They discover something really valuable, something really good for the whole team to know about. But they just quietly fix the bug and kind of go about their day. But you just gleaned some super important and valuable information that you didn't share with the team! Or a team delivers a really high-impact project, but they don't actually promote it within the organization.

Or there's other versions of this. You do write a blog post, you do share something, but then you just post it quietly in the Slack channel, and you don't make sure that it's broadcast and pushed out to the right people. As the person who was responsible for writing this thing up, you find yourself sort of recoiling, fearing being perceived as attention-seeking, or demanding "Hey, everybody read this!" You're like, "Oh, I don't want to be rude. I don't want to make people think that I'm telling them they have to spend time to read this thing."

But again, it's important. People should be aware of what you're doing. And I think within an engineering org, or any sort of organization, part of that is even if there isn't an immediate reason that somebody needs to know what you did, there can be the aspect of "how is your team perceived?"

You want to bring energy and positivity and you want people to have these good connotations when they think about your team, because they're like, "Oh, that's the team that did X, Y, and Z." As opposed to "I've never heard of that team before, I don't know what they do. I sort of assuming that they're maybe expendable, or I assume that maybe they could be repurposed to work on something else."

There is a little bit of politics in there, but I think primarily it just goes back to the original premise that communication is an important part of our jobs. It's really key to an organization functioning effectively. It was about that desire, "I want to be modest." I'm sort of oversimplifying of course, but the idea of modesty, meaning like you just don't call attention to anything you do because other people will just notice. Very few people, if any, are in that camp.

At a large company, I think the only person who's maybe in that boat is the CEO. People are watching the CEO, and they want to know what the CEO is thinking and doing and saying. Maybe the CEO can kind of afford to be "modest," but most people, not so much.

Harpreet: This line of thought reminds me of this author Austin Kleon who has written this book "Show Your Work." One of the most lasting impacts on me and the central idea is very similar, where he comes from the angle that everybody out there is building their tribes, and ideas are what excites people.

And people don't like finished work. They like to see other humans building things, struggling with things, and learning the lessons from it. And once they see somebody putting that out there, it engages the other humans to the point that they can reach out and engage with the author.

And that's where all the magic of collaborating really happens. So your point about how somebody fixed a gnarly bug and gained this tremendous insight; if that's not written out there, nobody else knows. They don't know that if they had a problem like this, and they need to come to you and engage with you.

It's a huge missed opportunity. Isn't it?

Dan: I think it's very much relevant. And that example, by the way, I have direct firsthand experience with that. In my early days as a software developer, I remember being relatively junior, but I really enjoyed writing code, and I would sometimes write maybe like a little helper library or something like that.

And in my mind, I was like, "This is really valuable, what I've done. I wrote this helper library, and now in the future, we can use this, and it'll make life easier in all these different scenarios." But I never considered that nobody knows that I wrote that. Nobody's going to just stumble across that and say, "Oh, that's great, I'll use that."

And so I think a lot of engineers make similar mistakes of thinking that the job is done when the code is written. When actually if nobody knows about it, and if nobody understands how it's supposed to be used, the work is unfinished. And like you said, Harpreet, it's a missed opportunity.

How Fear and Perception can Stunt Communication

Al: Do you have any specific guidance or tips for people who recognize this problem and then want to fix it?

I know that one of the problems that I've had over time is the "blank page" problem, being very intimidated by the prospect of a blank blog post that I need to fill in or whatever it is. I know one of the tactics that you've adopted in the past is the idea of a 60-minute block post. Right? You just spend an hour on it and then it's done. I guess that's more to encourage getting this thing done and getting it out there, but it still kind of works for me.

So I'm wondering if you have any other tips for engineers or other team members who recognize this and would like to communicate while also still being modest.

Dan: The general advice is to think about the thing that's keeping you from sharing something. If you think about what it is, often it's some form of fear. I want to you to think about the thing you're afraid of and think about whether it is really that bad. Fear might be things like: What if I'm wrong? What if I share out a thing, and I kind of got some of the details wrong, and that's going to make me look dumb? Or everything's fine, and I actually feel good about this, but I'm afraid I'm going to be perceived as bragging. It's generally some sort of fear that might be holding you back.

I think when you sort of actually think very concretely about it and you try to put yourself in that mindset, at least for me, what often happens is I realize, "Eh, it's really not a big deal." The thing I was afraid of it's really not anything that should prevent me from doing this. So if I'm wrong, how bad is that? I'm not going to be fired. Are people going to make fun of me? Probably not. You know, I might feel a little embarrassed, right? That's not a big deal. That's something I can get over. And frankly, it's probably a good thing because then I'll learn something from it. Whereas if I don't share it, just because I'm afraid I might be wrong, then I'm like giving up that opportunity to actually learn that I was wrong.

Similarly with being perceived a certain way. Like I said, I've been at this company for six years, but I have so many relationships with people I work with. If one blog post is going to change somebody's mind and suddenly they're going to think, "Oh, Dan is full of himself," then something's very wrong. I think realistically it's one tiny data point in a large set for everyone in terms of who you are.

And even if there were some reality to that fear, the information is still important. If I believe that the information is important for people to know, I can't let that little bit of fear prevent me from sharing it.

So those are the things that I would encourage everybody to think about.

As far as the practical tips, you already named one of them: time boxing. Sometimes you find yourself spending half a day or a full day writing something up, and what I want you to think about is the curve of the value of the content you've captured at the halfway point versus the 75% point versus when you finally decide this is ready.

You probably already captured a huge percentage of the value halfway through or 25% of the way through. Even when you just had bullet points just capturing your basic ideas, you probably already conveyed a lot of the value of what you were trying to say.

That's the premise of my 60-minute blog post idea: I just need to put a stop to this. I could easily spend six hours working on this thing and trying to get the words exactly right, but me trying to get the words exactly right isn't making a huge difference in terms of the amount of information that's being conveyed to the reader and how much value they're getting out of it. They might be slightly more impressed with how articulate I was, or I might be able to edit it down a little bit and cut out some of the noise, which could save readers a bit of time and make the message a little bit clearer.

But what is a much greater risk than things being a little unclear or the words not being exactly perfect is that the thing takes so long that I get demoralized. I completely give up on it. And then I've wasted even more time, and I didn't even convey the information that I needed to.

So one tip is to just time box and recognize that perfect is the enemy of the good. I don't want to spend half a week writing something that I've already got the information in a good state after an hour or two. I can share that out.

The other one is a reminder that things get easier with practice. At this point, I actually can write something that I feel pretty good about in about an hour normally and share it out. But it's not because I'm just exceptionally gifted, it's because I've done it so many times.

Probably the first thing I wrote in an hour was garbage, and then the next thing I wrote an hour was a little better. At this point, I've done it so many times that it's easier.

If you think of it as "I'm always going to be doing subpar work. I'm always going to be sort of under-delivering, and I'm not going to be proud of the work I've done," that can be really debilitating belief. But if you recognize, "Oh, I'm actually just going to get better and better at it. By forcing myself to do this, I'm actually I'm investing in the long-term impact I'm going to have, because a year from now, this will probably just be something I can knock out in an hour versus if I weren't to go through this exercise. It would always take me a week, and it would always be such a struggle. And half the time I wouldn't do it at all because I couldn't afford to spare a week on it."

Harpreet: As you were saying this, I was trying to put this into my journey in software. I spent a decade and a half in open source prior to Launchable and Atlassian.

And one of the projects we actually moved from closed source to open source. In the first, maybe six months to a year after doing that, managers had this concern to the team like, "why is this kind of conversation internal?" Like, you're sending a chat. Why is this internal, you're writing a blog? Why is this internal? And it was really going to your point that if you're throwing these small bits out there all the time, you lose the fear. Not to have that finished product, as you were saying, because really people are interested in ideas.

So if I sort of munge all of this together, it feels like there's lots to be learned from open source developers. Right? Because in that corridor, you cannot be quiet. You have to really shout from the rooftops for people to listen to your ideas. And for that to happen, you need to constantly keep putting these ideas out there and these bite-size ideas and let people munch on those.

Dan: I totally agree with that. I think I think there is a lot to be learned from open source. At the same time. I would want devs who may have dabbled in that area not to be intimidated. There are some big, high-profile, open-source projects out there that, if you look at their repositories, their documentation, things like that, everything seems really top-notch. They might have processes locked down, contributing guidelines, every commit has to follow this format, here's our system for triaging issues, et cetera. And it can seem really buttoned up and sort of like, "Oh, that's the bar of quality I'm supposed to meet."

But what you don't normally realize is if you're looking at an open-source project that's widely used, it didn't get that way overnight. Go look at the first couple of commits. Look at the early days of that project; they were probably figuring things out. Again, they got to where they are through practice. Through doing it over and over again, through dealing with issues from the community, dealing with contributions from the community, establishing guidelines, establishing rules, and such.

It got to the point where it probably looks really perfect in some cases. But firstly, it's not perfect. There's still issues with it. And secondly, it took a lot of reps to get to that state.

Al: Yeah. We're talking a lot about the act of writing and communicating through writing. I think that comes naturally to the Launchable team, as we're a distributed team. And also, I know Atlassian, which is a distributed team... we both use Confluence a lot. That's a practice that we brought over from Atlassian, so I think we already have a strong muscle in written communication inside companies.

But it's something that I think a lot of teams getting to grips with after a year of a lot of teams working distributed for the first time due to the pandemic. So hopefully this kind of way of communicating and way of working is becoming more normal and people are becoming more comfortable with it after a while doing this.

Dan: Yeah, I hope so. I mean, for sure at Atlassian there's a strong writing culture.

There's also, as I'm sure there are with many organizations, a lot of folks who love to just meet over Zoom, give a presentation, something like that. I think the immediate benefits of meeting with people in real-time, synchronously, are hard to compete with. You know you get everybody on the same page in 30 or 60 minutes.

But it's so not durable. That is the problem. I find many recordings of meetings, but people rarely go back and watch them. They're also not really searchable. They're not really discoverable. You can't quickly find that part of the conversation where they talk about X. You have to watch the video from start to finish.

With writing it can be a struggle to shift from one to the other because when you write something it feels like a time investment, you know? And if I share it around, how do I know that people really get the meaning? And what if they have questions? I'm not there to answer their questions in real-time.

But you can answer the questions, just not in real-time. They can comment on the page, and you can respond to their comments. And I think it's far more durable.

I find things that are written down pay dividends over a long period of time. I'll still reference stuff I wrote five years ago or someone on the team wrote five years ago. Sometimes when someone comes along and asks, "Why did we do X?" And I'll say, "good question. Here's a page written back in 2015 that gives you some of the context and explains it."

I think if it were something where the team sat down and had a quick meeting and discussed it five years ago the context would just get lost. It becomes tribal knowledge.

Al: So shifting gears a little bit... At launchable we're all about helping people deliver with speed and quality.

And Atlassian is very well respected in this regard, delivering high-quality products that customers really love. So we'd love to get some insight into kind of the "mojo" of the engineering team there at Bitbucket, and also at Atlassian more generally. What are some of the principles and practices that lead to such beloved products?

Dan: Yeah, engineering team mojo. Well, some of it's top-secret, so I can't share it with you, but I think one of the shifts that we've been making for a little while, but especially over the past year, which I'm really excited about is continuous delivery.

I can give you a very specific example. The Bitbucket team used to batch up our changes and we would generally release them - I think when I started it might've been once a week. It was really infrequent. Devs were merging changes, and then they were getting deployed to a staging environment. We would validate them in that environment and let them "soak." We deployed to a prod environment for customers once a week, and then we eventually moved to once a day. But even deploying once a day, sometimes you're talking about changes contributed by 20 different developers.

So what we've done over the past year has moved to a continuous delivery model where every single change that's pushed to the main branch of a repository is prepared to be deployed for production. All the tests and all the post-deployment verification checks are run against it. We validate that it can be deployed to prod.

We've also democratized it so any engineer on the team can promote that change to production. There are at least two goals with this.

One is giving devs more ownership over their changes reaching production. The old model where you batch it up and do it once a week or once a day takes a bit of control away from developers and it makes them feel a little bit apathetic towards it: "I'm going to merge my change and then sometime in the future it'll reach production. I don't know when I don't necessarily know exactly how to check." The more senior engineers on the team knew how to check, but it was tribal knowledge.

This new continuous delivery model means that it's up to you when you merge your code, and you are in charge of validating it in the staging environment and promoting it to prod. It's really great in that it gives ownership to devs who then can respond if their changes create any issues. They can roll back pretty easily.

The other thing is it just massively reduced reduces risk. It used to be that if we were to deploy, especially if deploys had been delayed for a day or two, and then we got a prod deploy out and then there was some sort of issue, the team was really resistant to rolling back since it would roll back three days worth of changes.

That was obviously a problem. With the new model, the paradigm is if anything goes wrong, rolling back should just be the absolute first thing you try. And it's not this fraught decision: my one change that I just pushed out caused an issue, so I'm going to roll it back. I'm not affecting anybody else. The surface area is very small. The sort of scope is very well understood by me.

So that's a specific thing that we've done, and what I'd like to see us do more of is the general model of "trust, but verify," where you don't put tons of barriers in place for people to get things done.

You try to remove as many barriers as you can because it turns out a lot of those barriers actually increase risk. But you still need the ability to audit and sort of figure out what caused a problem if there is a problem and respond to it very quickly. So similarly we've had a lot of conversations about other types of merge checks or code review policies or things like that we should be putting in place or building into Bitbucket.

I think that's kind of the underlying theme for me. We don't want to be just making it harder and harder and harder to get code promoted to production. We actually want to make it as easy as possible. Everything that we add in terms of features should be about empowering teams to get visibility into what is causing an error. What sort of changes went into a particular deployment? How can you quickly identify the right person who should be notified if, if their change caused an issue? Those kinds of things. And similarly, thinking of code review not as a series of gates that developers have to push through but more as a knowledge-sharing opportunity.

Code review is about getting the work that was done by one engineer into the head of two or three other engineers and getting a bunch of people to collaborate and try to make that code as good as it can be. Improve the quality of the code that's being pushed out rather than preventing subpar code from getting pushed out.

Al: That's great. That's great to hear.

Harpreet: So, tying this back to your modesty and luxury idea, you were talking about helping people understand if they broke stuff and getting that feedback back to them and getting code reviews into the heads of people.

So in terms of helping people understand if they broke something, what are some of the communication things that you've done there? Is that just something coming in from Slack or is this more like a daily review meeting?

Templates on Pull Requests

Dan: That's a great question. Even though we have had Bitbucket Pipelines for many years, the Bitbucket team was using Bamboo internally for deployments for quite some time. And honestly, a huge change has just been moving to pipelines for our deployments within Bitbucket itself, without leaving the product. This is the product where devs go to view their code. It's where they push their code. It's where they review one another's code. And it's now where we deploy our code.

If something goes wrong with the deployment, you can view it directly in pipelines. You can look at the commits that were in that deployment, and each one is associated with an author. And every commit is also part of one or more pull requests, which have reviewers. So you can identify the group of engineers who might know something about something going wrong very quickly.

There was also a process that we were doing for a little while that we've graduated from. It was a process where every single change before going out to production went through an operational readiness meeting. There were a few representatives on the team who had that level of operational maturity and knowledge where they could talk through a change that a developer or a team was putting out. They could make sure we considered everything. Have we considered logging volumes? Have we considered database query volumes? Have we considered the impact on the support team? What if something goes wrong with this, does our support team know how to respond to issues in this area? Those kinds of things.

It was a good sort of check-in, but it was a gate it was preventing changes from going out. We brought all these things into consideration, and we've graduated from that process. Part of that was trying to streamline many of those things as best we could. So for example, Bitbucket has a default pull requests descriptions feature that we use internally, too.

We made a template of what every pull request should have, like some information related to the rollout plan, risk mitigation, support, impact, and operational impact. We have a template now that has a heading for each one of those categories. We're encouraging devs from the beginning, or at least from the pull request phase, to think through those things rather than have to present their changes in a meeting and then have someone tell them, "Oh, you didn't really think through support impact. So you should probably go back and revisit this."

In tandem with that, we use Slack very heavily. When a deployment goes out, you can look at the pull requests. You can find the commit that might've been causing an issue. You can look at the pull request, and that pull request should have this filled-in template where the dev already put some thought into what to do. If this goes wrong, things like that.

In many cases, they'll have links to runbooks and things that they've written. So it's good that you can identify the engineer responsible, but you can also sometimes even quickly identify "Oh this change that caused an issue. We actually already have a runbook that covers what to do in that case."

We also make heavy use of feature flags on Bitbucket. So nine times out of 10, the answer is: "Turn off this feature flag." We thought it was safe to turn on, but if anything comes up though, here's the one to turn off, here's a link directly to it. And you can flip it off until morning hours in the US when an engineer can look at it.

So that's not really one single answer to your question, Harpreet, but, hopefully, that gives some visibility into the many ways we try to communicate these changes and make sure people are thinking through the changes they're making.

X as Code

Al: That's great. That's great. So just wrapping up here, just one last question. I'm wondering if there are any interesting trends that you're in the software teams world that you're looking out for and maybe interested to adopt or try out of the next couple of years.

Dan: Yeah. Well, this is kind of a big one, so it's not really a technology trend so much. With the DevOps movement, if you want to call it that, a big part of DevOps was config as code and infrastructure as code. I think that "X as code", as a trend is only going to continue until it sort of consumes everything.

And by that, I mean the reasons that teams have discovered the value of treating more things as code than just software is that the tooling we have around version control is so robust and so applicable to so many other areas that don't even realize how valuable it is. That it's only going to increase more.

So things like policies as code, documentation as code, ownership, group memberships responsibilities as code... I think all of these things have a future.

And the reason is with code, using tools like Bitbucket, you have an artifact that captures the way things are. And when people want to make changes to that artifact, they can propose their changes. Those changes can be reviewed, they can be refined, and then they can be committed. And then they're immutable. The new artifact is immutable, it has a label and you can't change it. Right?

This offers so much concrete control over the kinds of things that we want to have concrete control over, like policies. Whereas I think it's common that a company might have a page somewhere that describes our policy about X. And if someone wants to make a change to it, they just make a change to it. But what you don't have is visibility into the change. Who did they discuss the change with? What were the considerations that went into it? What was the back and forth? Was it officially approved by anybody in particular? That might all be captured somewhere, but not in really a really rigorous way.

I think infrastructure as code, security policies as code, that's just the beginning. I would love for Bitbucket to broaden its scope and become the place where more and more teams, not just software teams, start capturing their artifacts in code.

Al: Perfect. Yeah, that's awesome. I love that line of thinking!

Well, that about does it for us today. Really appreciate the time and thoughts, Dan, and look forward to catching up again sometime in the future!

Dan: Thanks for having me!