I’ve spent my first few weeks at Swarmia listening in on a lot of customer calls, and talking to many other software companies myself. It’s been a good reminder that every company’s productivity journey is different.

Whenever I’m talking to a new company about their productivity challenges, there are two questions I like to ask:

• How did you get here?
• Where do you want to go from here?

With a little probing, the answers to these questions help me build a mental map of the company’s size, age, and culture, and how each of these factors will influence what comes next:

• The size of a company heavily informs the types of productivity challenges it will face. Even when headcount growth is effectively flat, productivity challenges tend to grow as your codebase grows.
• Without intention or intervention, the age of a company is likely to be inversely related to its ability to adopt new technologies broadly, including off-the-shelf developer productivity solutions. On the other hand, the earlier you become productivity-aware, the easier it will be to change and adapt accordingly.
• The culture of a company defines the scope of available solutions for driving productivity improvements: Does the problem need to be solved solely within engineering, or are you willing (and able) to examine non-engineering solutions? Is there a framework for making long-term technical investments?

If you’re starting out on a productivity journey, ask yourself these two questions, and then consider how your company’s size, age, and culture will inform how you think about the problem and the path you take from here.

Question 1: How did you get here?

There are plenty of “origin stories” for a company’s decision to invest in sustaining and improving the effectiveness of their engineering organization. Sometimes it’s a simple conversation among leaders: “Is it just me, or did we used to ship things faster?” Sometimes, it’s driven by painful failure: “We missed most of our OKRs last half, and product and engineering are pointing fingers at each other.” And sometimes, it’s driven by curiosity about the opportunity — “I’ve heard of SPACE and DORA, and I think they could help us” — more than an acute or targeted need.

Each of these origin stories — and every other story that eventually leads a person like you to read a post like this — has a unique motivation. How the problem is stated tells you a lot about what underlying issues you’re likely to find when you start digging into the problem. It’s relatively easy to adopt a tool when you can operate with curiosity and a mindset of continuous improvement, and much harder when you are trying to solve an acute problem within the constraints of a company’s current size, age, and culture.

In the examples above, two of the stories clearly lend themselves to tooling: “It seems like we used to ship things faster” and “I think DORA/SPACE could help us.” In the third story, about a product vs eng blame game, a tool can certainly help quantify the problem and help you hypothesize solutions, but it’s going to be harder for a tool to prescribe context-aware remedies.

If you’re at the point of feeling like developer productivity/experience/effectiveness is A Thing You Should Care About, it’s good to ask yourself a few questions to prepare for the conversation that’s ahead:

• Why is this important? “We have a goal to improve productivity” is an answer, but not a great one. What’s motivating the company to spend time on this topic? How did it beat out other goals? How high up does the goal go?
• Why is this important now? Development teams can always be more productive, but suddenly now is the time you’re paying attention. What changed?
• What have you tried so far? How did you decide you needed to do something else?
• What metrics are you tracking today? Where are they falling short? How are they changing over time?

Question 2: Where do you want to go from here?

You know where you are and how you got here — now what? Again, size, age, and culture come into play. As you consider your path forward, the particular nature of your company will point to useful guardrails and dangerous sinkholes.

Smaller companies may still need to nail down delivery fundamentals, while larger companies may consider forming dedicated teams to standardize, automate, and speed up development processes. At companies with 100+ engineers, it takes effort just to sustain the same amount of productivity: Even if the engineering headcount isn’t growing, the codebase is, and quickly. As a company grows, its investment in productivity needs to grow too; the later that investment starts, the more debt there will be to pay down. At a certain eng org size — bigger than you are, probably, but smaller than you think, perhaps — you may need a team dedicated simply to keeping things running smoothly as you accumulate LOCs every day.

A company’s trajectory is shaped by what the tech world looked like when the company was making pivotal tech decisions. The earlier those decisions happened, the less tech had been commodified. The more time that has passed since those decisions, the more likely it is that those decisions have since been layered with alterations and customizations. A build vs. buy debate doesn’t have an obvious winner when you’re dealing with bespoke systems; on the other hand, the earlier you add observability to your engineering workflows, the more likely you are to have that information when you need it, even as your company evolves.

A company’s culture determines the likely pace, breadth, and permanence of improvement. Companies that highly value team autonomy will face different challenges than companies that have standardized on tooling and centralized processes. The depth of trust between leadership and individual contributors will influence how readily those individual contributors embrace productivity efforts, and the company’s engineering ladder will play a big part in who raises their hand to do the work. When you’re thinking about how to drive change, don’t pick fights with the culture: use it to your advantage whenever you can, and reshape it (gently) only when you must.

Answering these questions will deepen your understanding of how each of these three factors will come into play:

• What would “better” look like? Your engineering effectiveness investment proposal was approved, it’s two years later, and everything is better. You can’t believe you used to spend time doing … what? What has changed? Thinking back to current reality, what’s kept you from making these changes now?
• Who benefits when we achieve “better”? This is a trick question, because the answer is “everyone” — from product to sales to customer support to engineering to users. Still: Where will you find reliable allies and champions for more effective delivery — even if it comes at some near-term cost, like slower delivery of bug fixes and new features?
• What kinds of potential changes are in scope? Does The Business think of this as an engineering problem, or a business problem, or both? What is the scope of the most senior person who will sponsor necessary change, even if it has a near-term cost? Who will warm up to the cause after a couple of success stories?
• What are the biggest obstacles you expect? This is not the time for rosy optimism: talk openly, now, with anyone who wants to pitch in, about what’s going to be hard. Maybe two different eng organizations aren’t aligned on what’s important; maybe you expect the CEO to defer to product priorities instead. Maybe everyone’s on the same page but you worry that procurement is going to take three months. There are lots of ways this sort of effort can go sideways: anticipate the ones you can.

So now what?

Every company takes a unique path to arrive at the start of their productivity journey, and the path they follow after that will be unique too. There is plenty to learn from what others are doing, and plenty we can standardize on as an industry, but the way to improve your particular situation will be unique to the size, age, and culture in which you’re operating.

You can use the big questions above — How did you get here? and Where do you want to go from here – to orient yourself at a high level to some of the challenges you’re likely to face. Then, the lower-level questions can help you start to chart a path forward. I wish there was a single silver bullet, but after “get visibility into your current process,” so much will depend on the details of what you find.

If you’re trying to get a productivity initiative under way at a company of 100+ engineers, we should chat. I’d love to learn about your goals and challenges and help you find a path forward — drop me a note at rebecca@swarmia.com and let’s talk more.