Last month, I quit my job at Datadog after working there for a little over 3 years.

I learned a lot while I was there – a lot of how you should do things, and of course a bit about how you probably should not do things – and I wanted to take a minute to write some of it down, while it’s all still fresh in my mind.

And so, in no particular order:

Software

• Developers are most effective when they’re familiar with many systems, not just one or two. This way, they can reason about how a change will affect the entire stack (very important during incidents), and their time can easily be reallocated to different areas of the product to speed up important projects. Don’t let this happen to 5% of developers by accident (for example, just the ones who have been around for a long time) – make it happen, with rotational programs, etc!

• Automation (e.g. continuous deployment) can cause as many problems at it solves. A human implicitly does a bunch of checks and fail-fasts that you only think to program a computer to do after it causes an outage. Only automate a process when it’s obvious to everyone involved that the manual way cannot possibly work anymore – manual processes can even be quite pleasant if you invest a little in tooling!

• Keep the dev cycle near-instantaneous. Tech like feature flags and microservices can allow developers to write, test, and safely deploy many discrete changes within a single day, which is not only productive, but also much more fun for everyone involved.

Projects

• Take advantage of the recency bias. It doesn’t always have to be a bad thing – there will never be a time you’re more motivated to solve a hairy latent problem than “right after it causes an outage”. It feels great to get it fixed right then, instead of making a ticket that will sit in a backlog, forever waiting for the next sprint.

• Prefer projects with small organizational scopes. If the person who cares about the work and the person doing the work are different people, you’re opening the door to a host of communication breakdowns, motivation issues, and differences in vision. Not every project can be done start-to-finish by a single person or team, but the ones that can often finish faster, have better outcomes, and are more gratifying for the people working on it.

• Check in often, with everybody, about a project’s perceived value. Related to the above, if no one cares about the work, the project is just going to take two years to finish and be a big disappointment in the end anyway. Either there is a lot of value in the project (in which case it’s important that everyone working on it sees it and agrees), or there isn’t (in which case – might be time to ask “do we still want to do this”).

• Don’t measure proxies. Don’t measure number of cores allocated or number of lambda invocations if what you’re trying to decrease is cost. Measure cost! This way, not only is it easy for everyone to remember the thing that actually matters, but it also gives the people working on the problem the greatest flexibility in how they choose to solve it.

• Allowing developer autonomy will make or break a project. Find smart people, entrust them with a problem (not a solution), and just let them do what they decide they need to do. Will they still generate an RFC or create a kanban board? Maybe – but they’ll do it because they see it has value in helping them reach the best solution, not because they’re forced to, and the difference in the quality of that RFC or the attention paid to that kanban will be night and day. People over process!

People

• Metrics are for software, not people. Questions like “how are the developers feeling” can’t be boiled down into a 30-question survey, as much as the folks at CultureAmp want you to believe they can. These problems are inherently qualitative, not quantitative, and while surveys have their place, they at best can only show places you need to dig further.

• Everybody wins when people can just manage themselves. In some ways, managers act as bandaids – they fill in gaps around prioritization or communication, and ICs can “just focus on the work”. But those are both core parts of “the work”, and trying to outsource them can lead to inefficiency or a steep loss in company connectedness. Create an environment where people can be trusted and empowered to own every part of their job, and hire folks who want to work in an environment like that.

• Intrinsics play only a small role in human potential. A “10x developer” in one situation will be an underperformer in another, depending on the type of work being done, the team dynamic, the balance of interrupt vs focused time – the list goes on. Almost everyone has the potential to do amazing work when they are set up for success.