Photo by Jason Dent on Unsplash

Developer vs. Engineer

Why aren’t they interchangeable?

Do you know the actual difference?

As a result of a talk that I delivered to the NZ SaaS community, on Founder SuperPowers, I was asked to clarify why I thought that developers (working in Enterprises and in Solution Provider businesses) were not suitable to be working as founding engineers in product startups. As it seems, there is a widely held belief across the tech industry that developer and engineer skillsets are transferable no matter what the job is.

Thanks Bruce! I’ve been wanting to write about this for a very long time. So here goes the long answer

C’mon, would YOU assume that a developer (who once built a piece of software on a client project) is qualified to build a new product for a startup company?

Well, you are not alone, just about every tech startup founder that ever got started probably made this assumption without a second thought. After all, isn’t it all just software?

I’m going to tell you why this assumption is flawed at many levels and, in the process, point out why we (as an industry) need to stop making this silly assumption and wake up to the fact that too many startups are hiring under-qualified tech people to help make and grow their business from day one.

But first, I have to define some terms.

It does not matter that much if you agree or disagree with the accuracy of my terms here. I need to have some terms, they need to be simple. Otherwise, the rest of the article will be too confusing to write effectively.

Let’s try to define the differences between a “programmer” writing code in two different contexts, and name them:

Solution Developer (SD) — Works for a services company on projects. Builds a prescribed solution, usually for some launch to some group of users. Works to a plan with time and budget constraints that are governed by some kind of Project Manager that guarantees that the outputs are delivered to a client’s satisfaction. A client (person or company) pays for the work to be done. The client scopes and defines the work to be done (in some format, and for some price tag) and signs off pieces of work when they are delivered as acceptable. When done, the developer gets redeployed to the next project. They predominantly do their work alone but can work in coordination with groups of others like them. They work predominantly in green fields projects and codebases, built from scratch, with whatever the latest and greatest tech trend is on that day. They have high levels of autonomy to make initial technical choices and either start from first principles or consume masses of open-source frameworks and libraries to do all the heavy lifting for them. This is what the vast majority o people who are writing software, are doing today.

Product Engineer (PE)— Works for a tech product company, predominantly on one product. They design, build, maintain, and support a product in-market for a rapidly changing market, for years into the future. They work towards end-user outcomes that they agree are the highest value for their market, now versus later. They always work in cross-functional teams with other disciplines (participating in marketing, user research, product discovery, measuring, DevOps, monitoring, etc.) toward agreed, measurable and demonstratable outcomes in the product, and in the market. They decide (autonomously) when an outcome has been achieved, and, thus, when they can move on to the next piece of work. Works on continuously optimizing, changing, and reshaping (one or more) existing codebases and on optimizing long-term costs. Has high levels of autonomy to make/change ongoing technical choices that affect the product and the market. They rarely get deployed to another product.

Now let’s get into the details, and talk about each of these categories of distinction and how they are different. I want to demonstrate to you that these two roles are, in fact, two different jobs entirely, requiring differing skills, tools, and materials, no matter what many non-technical (or even technical, but non-programmer) people may want to think about them.

TL;DR

In the spirit of the recent claims of AI amazing people with its intelligence, and for those who really can’t be arsed to really understand a topic in any depth, here is the summary of this whole blog post for you, from Notion AI:

Product Engineers and Solution Developers are two distinct roles in the tech industry, requiring different skills, tools, and materials. Product Engineers work for product companies, building and maintaining a product for a changing market, while Solution Developers work for services companies, building a prescribed solution for a specific group of users. Non-technical people often assume that the two roles are interchangeable, but this assumption is flawed. Product Engineers require more mature skills than Solution Developers, and the job interviews for the two roles are also vastly different.

If you are not satisfied with that and want to know more, then read on.

Photo by Anders Jildén on Unsplash

Marketing Presence

If you look at any job board listing tech jobs out there (for example, on Linkedin), you’ll quickly see that no matter what kind of software business the company is, all the jobs share the same job titles. That’s handy, right? Usually, mixing rank and skills area. Such as Junior Developer, Senior Developer, Principle Engineer, Senior SDE, etc, etc.

To the uninitiated hiring manager, it would not matter whether the job they are hiring for was project work inside an Enterprise IT department or an established software business, or the next tech startup. There is little distinction being made (by the reader) in the titles being used. They all sound roughly the same unless the hiring manager knows intimately the intended differences, and can tell them apart.

Yes, there are trends in titles, and yes, some of the employers do, in fact know the difference in titles they are advertising for, and some of those writing the adverts are trying to be very specific about it — for a good reason. But that distinction is lost to many in the market. Most of the Enterprise jobs and the startup jobs seem very confused and mixed up about what they are looking for. Conflation is common in this job marketplace.

Why is there not a clear understanding of the distinction being made between an engineer and a developer, and a programmer?

I would love to talk about that distinction here, I have my opinions on that. But I’d rather get into why the conflation exists at all.

If you haven't spent a good few years (decades even) programming professionally (in whatever job), you are simply ill-equipped to know the difference between engineering a long-lived piece of software, and just writing functional code [that works] on software projects. But that does not stop non-technical founders or (low-experienced) technical founders from hiring these people into completely different roles, often inappropriately.

There are two problems. The first is that anyone who has been anywhere near tech (for example, in tech Sales, or Marketing) and not in an actual programming role, thinks that they know tech people well enough from just being around these people. Secondly, those folks may know enough that the tools and practices, and processes may all look similar enough, and conclude that “well, it is all just software” at the end of the day, and therefore the differences are irrelevant.

Thus, they conclude that not only are the differences in job context irrelevant, but they’ve also concluded that the actual job is just a commodity role, and thus one developer is no different than another engineer, and therefore, the people in the job are interchangeable. This is all just how some people simplify the complex world around them.

But it is wrong, nonetheless. A Joiner is not the same person as a Carpenter, an Airline Pilot is not the same as a Military Fighter Pilot, and a Lawyer is not the same as a Barrister. Even though they all appear to have similar names, use the same tools, work with similar materials, and use similar tools and processes. They both work in wildly different commercial settings, use different materials, use different processes, have different standards, and they optimize their work completely differently. It is not the same job and, in most cases, not even the same skillset.

Any programmer who has been both a solution developer (SD) doing project work (say: in a services company), AND has also been a product engineer (PE) in a successful product company (at scale), knows intimately the difference between the jobs. Those who haven't crossed over professions just don’t know this. Especially those SDs who have never worked in a successful product company product team.

For everyone else (non-programmers), the difference can easily be seen in the differences between job interviews, between a services company and a product company. Services companies just choose bright-eyed, capable and enthusiastic problem-solvers. Product companies want much, much more mature skills, and thus the interview loops are wildly different.

Photo by Oktay Yildiz on Unsplash

Outlook

So, in what ways are the two roles actually different, with respect to looking to the future?

Well, fundamentally, SDs are hired into a temporary contract to get a specific job done. The business model they work in (a services provider model) was designed to address a market of consumers (clients) that assume that software development is a commodity, and, thus, that its outputs can be bought at a pre-determined price and reliably scheduled to deliver something of prescribed value. These clients don’t really know about or care about the quality of the thing being built, nor care about supporting the thing they ask to be built, beyond it being delivered. They just want something built, that works, that does something they predicted that it would, so they can declare victory on having that thing — as soon as possible. It is a project to them in every sense of the word.

Much like you can design and build a new home from scratch, have it built to a plan and budget, by some arbitrary skilled workforce, and be ready to move in, as soon as it is built.

I’ve written at length about this flawed mental model for building software things a hundred times in the past. Pick any one of these titles for starters. But, regardless, it is a profitable business model for solution providers that many can make a living from, and even thrive.

Fundamentally, product engineers (PEs) are hired to guarantee that an efficient and durable product is built, and refined, and keeps delivering a high-quality service for a very long period of time, efficiently and effectively. Long enough, and frequently enough, to earn back the expensive cost of doing that, collected from buyers to pay for its creation and support for its entire lifetime. Those paying for it (the buyers) have no say in how it gets built or maintained, or even what it does! If what it does is worth paying for, they buy it. They are certainly not paying the entire cost of making and maintaining it, only some minuscule proportion of it (maybe 1000th of it or a trillionth of that total cost!).

Not that it has anything to do with it, but if the buyers don’t like what the product does, or how it does it, they can simply spend their money elsewhere. It is vitally important to understand the difference between engineering a desirable product that works for people so that they will buy it and use it, versus just constructing someone’s unique creation tailored to their preferences on a contract.

Now. The two contexts (described above) make all the actual differences between the job that an SD performs and the job that a PE performs.

Let’s break it all down for you

Photo by Bud Helisson on Unsplash

Short Term versus Long Term

An SD will be working on a given software project, for let’s say, between ~6 months and ~18 months. After which the project is over, and they get moved on to the next project, by their employer. The software they built for a client will be delivered and then taken over by another party, usually someone at the company of the client, or sometimes managed by different people that the client also hires. The SD may be involved to some small degree in fixing any high-impact bugs that may come up within a short period of time after the delivery of the project, but this is not common. Usually, some “lucky” other person gets assigned to that kind of maintenance after the project is delivered, while the now “more-experienced” SD gets sold onto another project to do it all over again somewhere else, now more important to their employer.

On the flip side, a PE has no such luxury, their work is never done, and they are not going anywhere. Whatever they build is what they end up maintaining and supporting for the next ~5-10 years or so (should they stay that long in the job).

The first point here is that whatever thing the SD created, is going to be supported and maintained by some other group of people. Not by the SD themselves. They have moved on to the next cool project. This means that the SD never gets to see the future outcomes that they create (whether they are good or bad or both), and will/may never know how effective their hard work was, in the real world, and with the test of time. And frankly, they get the luxury of not caring about any of that. It is creative freedom.

The PE, on the other hand, gets to see if whatever they make actually works on a market of real customers, and they have to live with whatever design choices they make forever. Most of the time, that future is exactly what they designed for. Whereas the SD is not designing their solution for any future at all, except for the short-term goal of making the software work now, to gain sign-off, and thus permission to move on after.

The second point to make here is that the SD, more often than not, gets to start the project from scratch, from day one. Something we call “Green Fields,” where they have unspoiled pastures to shape any way that they want to. Whereas, unless the PE was there from the start, this is rarely the case for them. They generally work in the “Brown Fields” that have already been worked by others before them, and they have to live with past choices made by others, which tend to be far more restrictive for them.

Now, another key thing to understand here, is that the SD rarely ever works in teams of others that collaborate and work together on the same code (same components), and thus they never have to do extra work to make sure that their handiwork aligns with other people’s handiwork. More often than not, SDs work on their own stuff. They just do whatever they want, the way they like it, without having to worry about what others think of it. This is a big deal because, unlike other industries, different people do things in different ways in software, and it’s only working in teams when programmers have to agree on doing things in a unified way. The SDs don't always have to do that, whereas this is just the way it has always been for the PEs.

Photo by Brook Anderson on Unsplash

The Bleeding Edge

Since SDs are often creating a new thing from scratch on day one (every year or so), they get to decide and define far more of the technical constraints of the system they are building. They simply have to at that point. They get to make some pretty key decisions at the start of the project, which can be very hard to reverse later. We will call these dependencies. Dependencies on their tech stacks, their deployment technologies, the tools they use, and their software dependencies (libraries and frameworks) that they reuse.

Incidentally, one of the massive advantages of being an SD for an extended period of time (~10 years) is that you learn quite rapidly what does and does not work in industry, since you get to start over and over again on each project. You get to apply what you’ve learned from the past, by building the same kind of thing over and over again, and you learn rapidly how to do it better each time, and even guard against common mistakes in the future. It is in fact a great way to learn about how to apply lots of tech in a relatively short period of time. PEs don’t actually get as much exposure as SDs to trying new things out in industry, certainly not over and over again.

PEs rarely ever get to start something new from scratch. It can happen, of course, (eg. if you are there from day one of a startup or a new product), but it is far less common for PEs to be in this position. PEs are usually already constrained by what other software is already going on around them, in other codebases of their product, or in other products of their company, which all will have some policies and standards applied to them (at some level).

But SDs are generally able to start with whatever they fancy (albeit, sometimes, they may be constrained by their client’s environments and needs). Thus, an SD is almost always going to be selecting the latest and greatest technology known to them, at the time they start a new project. If they are up to speed on the latest trends, then it is those trends that they will follow and apply to their new thing, since they have full control over it. No matter if those trends are yet unproven, nascent, or poorly supported. If it’s cool, and it’s something the SD wants to try out (and the client has no constraints stopping them), they are going to convince everyone (who bothers to ask them) that they are best to make that selection in the name of tech progress, (and secretly, and selfishly in the name of fun and learning new things). You can usually predict what an SD is going to use, by looking at the latest conference they may have attended, or the books and blogs they are reading.

We call this behavior “Living on the Bleeding Edge” of technology. The upsides can be few and far between, but the downsides can be considerable and damaging in the future.

The thing about the Bleeding Edge stuff is that it may be so new, that it’s unproven by the masses, and often not battle-hardened enough to survive whatever application it is being used for by the SD, and the test of time. But the “cool factor” makes it so much more desirable to try. Furthermore, since its not-broadly been adopted yet (by the masses), the support and maintenance (and tooling) for it are likely not to be that great either. Since the ecosystem around it has not matured yet. Thus, when an SD takes a hard dependency on that thing in their new system, as their foundation, they are only considering that it works for them long enough to get the project delivered. Certainly, not how to migrate off of that thing in 1-3 years' time, when it may have been made obsolete. So, it’s not an immediate risk to them, and thus not part of the design they are working towards to get the project done and delivered. It becomes someone else’s problem to clean up that mess. Never mind, they did an excellent job of delivering what was asked for, right?

PEs are necessarily far more considerate of these choices because they have to live with them in 1–3 years' time. To the point that they will refuse to take dependencies on any other people’s whizz-bang bleeding-edge stuff because they already know that they have to support upgrading it and fixing it, and replacing it in the future. Especially if the O.G. authors of that bleeding-edge stuff, either do not want to change it, or they later abandon their pet project at some point in the future, because they took a job at Twitter — happens more often than you might think! PEs are hardened to this kind of risk, whereas SDs have the luxury of being cavalier about it. PEs have other strategies to deal with it that SDs have not had to develop skills for yet. In the context of where PEs operate, this SD behavior is a source of backlash for their maverick approaches.

Photo by Fauzan Saari on Unsplash

The 2.0 Rewrite

There is a joke in our industry that only veterans are qualified to make tongue-in-cheek, and that is to suggest: making the “2.0 version” of something.

Specifically, in programming, the reference is to the much-idolized: “2.0 rewrite”.

If a newcomer or newbie is heard making this suggestion, it simply is not funny, it is considered dangerous, and it is quickly corrected behind the scenes.

The 2.0 rewrite notion is the idea that you can make up for all the mistakes of the past that had been made, and fix them by having another go at it in the newer, shinier 2.0 version. Where a dangerous underlying assumption is made, you won’t make the same mistakes again in the future that caused the rewrite in the first place. But the real truth is that for this to be even remotely true (in the future), you need to have already understood deeply what the causes of the previous mistakes were (in the past), AND you now need to be able to avoid making them again in the future, with some mitigation. It is a fallacy in most of the contexts in which it is thought to succeed.

The idea of the 2.0 rewrite is SO DAMN potent for the uninitiated that they will go to huge lengths to suggest and insist that this is what MUST be done to fix the world around them, rather than doing the hard work of actually fixing the world around them— that they probably had a large hand in creating. Much like the idea of wanting to colonize another planet and start again, rather than fixing the mess we created on our own planet. Thinking that this new approach will be different somehow from the old approach, and automatically prevent it from happening again.

When it comes to software, in most contexts where a “2.0 rewrite” is invoked by the same people who created the 1.0 version, the reasons (for the creation of the flawed 1.0 in the first place) are too poorly understood to begin with. Thus, the only inevitable outcome of the 2.0 rewrite is to create a disaster with the 2.0 rewrite, and eventually, the suggestion of a 3.0 rewrite, and so on, into the future.

In 30 years, I’ve never seen the 2.0 rewrite strategy work in any business, as described. Rewrites can absolutely happen, though, but it’s often performed by a different party than the party that created the 1.0 mess, and they succeeded for reasons that accounted for the original causes.

Ironically, and conveniently for this article, SDs creating something that could not be properly supported or maintained in the future (which is super common), often creates a candidate for the 2.0 rewrite solution. But to succeed here, the rewrites need to be done by veteran PEs with a long-term view to supporting the new version.

Furthermore, in the product context where PEs work, no early-stage business could ever afford the capital to rewrite their product, for two reasons.

1. Justifying the capital outlay for a full rewrite of your product that is already in the market is extremely hard to get past finance and their boards. Why rewrite it, when it’s already generating revenue for the business? Why not just persists and do the hard yards with it, and just hollow it out in place, a piece at a time, instead?
2. Having a version 1.0 of your product and a version 2.0 of your product in the market for your customers at the same time requires many, many more people in your business to do both things at the same time — the complexity is off the charts. Usually, requiring the same people to support version 1.0, more people to build and support version 2.0, and even more people to manage and synchronize both of the products in the market, and the migrations from one to another. None of whom any business can afford either. Never mind the issues and costs of sharing data, poor designs, and services between them.

At the end of the day, whilst you may have heard rare stories of this happening, and succeeding, (by the skin of their teeth), it won’t be at the costs in time and capital that were anticipated. I can also bet that none of those projects accounted for the “opportunity cost” that was also lost in the process as well. Too many businesses that have done this, have failed as a result.

In a nutshell, the 2.0 rewrite is never gonna happen in the startup/scaleup world, no matter how romantic or enthusiastic your engineering team members are about it.

Notwithstanding that, a rewrite (of any kind) shouldn’t be happening in startups/scaleups in the first 5–10 years of their life anyways!

Until perhaps, they reach massive scale, where replatforming may be a reality for them. But at that point they probably have the capital to correct their designs.

In order to avoid that stuff, the PEs in those startups/scaleups need to be skilled and disciplined enough (in the first place), so they can avoid creating a thing that requires a rewrite. They do this by applying skilled techniques, practices, and disciplines as they proceed from day one.

The SDs of codebases that have to be re-written (a few years from now) may have inadvertently made that happen through a lack of knowledge and experience of how to build systems that can be evolved and scaled in the future. In the services world, SDs are simply not playing the long game, and therefore they don’t need to apply these critical long-term engineering skills, even if they were to have them. In fact, they may well be considered to be inefficient (and not cost-effective) at delivering what they are being paid to actually do.

Photo by Malcolm Lightbody on Unsplash

Rigor and Disciplines

The developer skills and disciplines that a PE is required to have to engineer a long-lived product (let’s say for the next decade or two) are vastly more rigorous, disciplined and specialized than those that we find in SDs who are building “point solutions”. Especially, if those PEs are working in startups.

In early-stage startups. There are at least 3 key things that PEs need to prioritize, and apply with more rigorous disciplines, than SDs need to on projects.

1. Maintainability — The codebase that is built from the start is going to look nothing like the codebase that they will be working on in a year or more’s time, and it will be significantly different in 1–3 years' time also. Thus it will need to have a structured and robust enough architecture that can change and be re-shaped easily. Prioritizing high cohesion and low coupling.
2. Collaboration — More and more PEs are going to be touching the same codebase over time as teams expand as a result of getting more funding and the company scaling up. Things in the codebase need to be far better structured and in-order when more hands are working with it together. Otherwise, it can quickly become chaos, because new contributors to the codebase will resort to their own individual habits if there are no established standards, patterns, and conventions to adopt for everyone. Staying consistent is even more crucial.
3. Scalability — At some point in the startup’s immediate future (maybe a year or two down the track), the business itself will need to be scaled up, in terms of the number of users using the product — by design. The codebase and its deployment model will need to be able to scaled-out to match market demands. To do that, the codebase will likely need to be optimized in certain areas and corners of it, and it will certainly need to be split apart and deployed into many more pieces than it originally was.

For all these reasons (and others) that PEs are explicitly designing for, they also need to construct, organize, and maintain codebases very differently than SDs working on short-term projects.

You might think that SDs would know all about this stuff, would have those skills developed already, and would be applying them also. And be qualified to apply these skills when they need to. But the truth is that these skills are hard-earned over the years from doing this stuff over and over again, screwing things up, and constantly improving and remediating them. These are not easily taught skills, nor are they skills that every developer or engineer learns in the course of their normal careers. SDs can legitimately avoid them their entire career.

Without these developed skills onboard early in your startup (from day one), your founding developers (likely, inexperienced in this specific skillset) are likely to create a codebase that cannot manage complexity well enough into the future. Within a year or two, that codebase is going to make whoever is working on it slow down considerably as time moves on and as more and more features and functionality are added to it. The natural and unavoidable increase in complexity of the software (as it scales) with the startup (as it scales) produces codebases (and databases) that are impossibly hard to modularize and scale out later when needed. The famed big-ball-of-mud has been born, and the 2.0 rewrite fix is just around the corner. Just when it is least wanted or needed for the startup business, trying to scale. This has killed and continues to kill, numerous startups detracting their precious resources from accelerating to meet their market demand for service and reliable high-quality.

To avoid this inevitable fate for most startup teams. Experienced PEs have a few tricks and disciplines up their sleeves that must be applied rigorously from day one.

1. Rigorous automated testing — For PEs, having a comprehensive automated test suite is absolutely crucial to being able to move fast and remain moving fast, far into the future. Without this, any change to any code in the future will be avoided and seen as too risky since there is no way to manage regressions that WILL occur all over the place, causing more painful support work for the PEs and the business. SDs don't need to worry about this aspect of their short-term projects, thus, to optimize time and cost, and effort, they don't invest in doing it.
2. Rigorous architectural patterns — These are patterns and structures of the codebase that spell out where things go and what they should look like on disk, how they are named, how they interact, and the general shape of the code and components in it. Layering, directory structures, naming conventions, coding standards, and base frameworks are all laid down early on so that everyone writing code in the codebase can be consistent about it. Critical for teams of people working on codebases. None of this structure is set in concrete, and things change every week, so it has to be able to evolve over time, and thus be structured in a way it can evolve consistently across the codebase. SDs, again, don’t need to worry about this stuff so much, since they are playing the short-term game again, and they often work by themselves in isolation from others. Where the code is structured and organized just for their own needs. Who else needs to know about these things but them?
3. Modular-monolithic architectures — This is a monolithic codebase (at the start) that is also highly modular and de-coupled from day one, that can, in the future, be deployed in whatever topology suits the business as it scales (typically moving towards micro-services). There are significant issues with any small teams building microservices but there are massive benefits to starting with a monolith. However, the trouble starts if the monolith cannot be scaled-out as the business grows. To mitigate against that, it must remain modular, not just in the code, but also in the databases, and in any shared services. Sharing data schemas between logical domains is thus forbidden, and the goal is NOT to share all possible reusable code. This takes practiced skills to achieve this, architectural patterns like “Ports and Adapters” combined with layers and domain specificity, are commonly used together to divide the components into horizontal technology layers and vertical domains at the same time. Connected by adapters that can change when the components are deployed into separate hosts. SDs rarely ever learn to apply these techniques, since they are considered overkill and too much work in their context, to get projects over the line within tight budgets.

The above 3 areas are crucial for PEs to apply, but not essential for SDs to apply in their respective contexts.

Photo by Felix Mittermeier on Unsplash

Strategic Thinking

Unbeknown to most, if not all, inexperienced people programming professionally, there is a set of skills that need to be developed in order to mature in this industry. We don't often describe them with the word “strategic,” but that’s exactly what they are.

Many programmers assume these kinds of things are “managerial” in nature, and thus not important to them because they seem out of reach of their remit, and unrelated to coding. They fail to understand what being strategic is trying to achieve.

Strategy is a tough word to define in a tech and programming context, and that’s part of the reason most programmers don’t understand the meaning of the word. However, the good news is that some programmers eventually get to the point where they are doing plenty of strategic thinking in the course of their daily programming work (if they stick the job out long enough).

These skills make the real difference between junior and principal programmers in either SD or PE contexts.

Interesting side note: in the main, across the industry, we don't see too many Principal-level SDs working in services companies, who are still doing the front-line job of programming. It is well known that services, as a profession, is a “young person’s game” for a reason, because of the relentless exhausting pace, and energy needed to stay resilient to stress created by these kinds of clients and their deadlines. After several years of it (maybe 5~10 years), it generally leaves the player yearning for more fruitful and meaningful work, than just living off the excitement and mastery of being a project mercenary. What is interesting however, is where do they go after that stint? Do they stay on the tools? do they burn out, and never go back, or do they move into other kinds of roles and different kind of work? Certainly, a few of them move to product contexts to become PEs and continue their craft more sustainably, getting down and dirty on expanding their skills.

Strategic work answers a few simple questions, like: “How will we win?”, “Where will we play next?” and “How will we know when we have won?”. It focuses on the direction and the big-picture outcomes of the work, which make all the difference in the market.

The answers to these questions are less important than doing the work to answer the questions themselves, in the first place. The real issue is that someone, somewhere, needs to be focused on asking and answering these questions, to maintain focus and direction. This is necessary strategic work for PEs, not necessarily for SDs.

The truth is that SDs do little, if any, of this kind of work beyond the start of the project they work on. Where they know so little about the future. They generally do it all upfront, then they just get focused on the details of the delivery for the remainder of the project. In addition, project work generally rushes to the deadline at the end, where there is now little time or resources to revise these questions and answers, and thus this thinking is rarely ever revisted.

Getting busy on all the details of delivery (in operational work) is the #1 reason that strategic work gets forgotten about, no matter what context you are working in.

Strategic work for PEs in a product context involves the following kinds of activities:

1. Measuring Effectiveness— After building something (new feature, fixing a bug, enhancement, etc), then looking at whether the thing that was built is effective at delivering the value that was assumed that thing would generate in the market for end-users. For example, if we added a feature to a product, do the end-users actually use it at the right times for the intended goals they are working towards? Were they able to discover the new feature, in their normal flows? Do they actually use it, and how often? Do they keep using it? are they getting through the user journey for which this feature helps them achieve their goals? These are all strategic focuses. SDs just about always assume that the feature they have been told to build, is there for some critical reason, and end-users must “need” it. The strategic thinking was already done for them upfront, so there was no need to verify what they are doing will be effective.
2. Validation & Innovation — Before building the next thing, qualifying that this thing (the solution option) is the best solution option to select “first” to address the problem being presented. Not just the first idea that came to mind, as is all too common. Then, finding actual evidence up front (from the market) that this option could and would support the hypothesis that this thing will make a difference (versus other solution options) that we must have. This kind of strategic work is not necessary for SDs, who are again being fed requirements that are just presumed to have all that figured out already.

In the product context, these questions are answered by counting measurable “product outcomes.” For example, we might ask: “what do we do next?”, to: “increase the onboarding success rate of our software”, “how to reduce churn”, or “how to increase retention.” The answers to these questions are easily measured by measuring end-users taking action with the actual software. Typically, either in the data of the things that they create with the software, or from tracking their activity using the software.

These questions are rarely if ever, asked by SDs in a project context.

Photo by Hannah Busing on Unsplash

Teamwork

Most SDs are sold and incentivized as individual resources working on projects. Even though they may work with other SDs on the same project, and even on the same codebase, they will find clever ways to isolate their creations from each other. Working on different components, different features, or different parts of the system, and working from different physical locations. They believe (right or wrong) that there are efficiencies to be had in dividing the work and doing it all in parallel individually, knowing that they have to integrate it at some point in the future. This rarely goes as smoothly as expected and often creates checkpoints, and causes significant integration problems at these points in time.

This is far from what we call teamwork. Even though programmers (in general) have a preference to work in isolation, PEs generally have to work in tighter, and more coordinated teams because they work cross-functionally with other disciplines (eg. designers, user researchers, UX, marketing, product management, etc), and they intentionally coordinate their work to integrate more frequently with all those parties, delivering whole pieces together to focus on creating measurable outcomes in a market. They are not driven by feature lists, and deadlines like SDs generally are.

The outputs from these two contexts and the differences between their processes are wildly different because the inputs to the different processes are wildly different. Different inputs equal different outputs. That is obvious to most people, but only when they think about it.

Photo by HiveBoxx on Unsplash

Transitioning Between Roles

Now, for every point that I have made above, you can, no doubt, think of examples where people and organizations are exceptions to the descriptions given. No surprise there. There are heaps and heaps of software companies (more than you could possibly know about) today executing product development processes really poorly, and often with poorly qualified people without the right skillsets. There is massive variance across the software industry, and there are companies doing things that are quite damaging to their business, given the context they are in.

Mainly, I assert, because (i) the leaders of those companies either do not understand the software industry and product development well enough, or (ii) they are poorly qualified to lead product development teams in the required practices and processes appropriate for their context, or (iii) the people they inadvertent hire are not skilled in the context they are actually working in. You wouldn’t believe how many of these software companies are led by people with either no experience working in software companies, or with no experience in product development. Two key areas of skill and experience that are critical to their actual future business.

SD to PE

Generally speaking, transitioning an SD from a project context into being a PE in a product context normally requires significant uplift in their skills, disciplines and attitude, as they need to learn to work more effectively in teams, apply more rigorous disciplines, and apply more strategic thinking to their work towards outcomes with others.

These skills are not strictly required in an SDs context, doing project work. But even so, the good news is that some of these skills ARE being applied by some very diligent SDs in an project context, which is cool, and that does make it easier for those people to have an easier transition into the PE context, should they make that transition.

PE to SD

What about those transitioning from a PE context to an SD context? That also happens, of course too. Well, apart from getting exposure to more green fields work and the luxuries and excitement that this provides, PEs may get a little frustrated with the lack of rigor and disciplines around them.

In some cases, some of the rigor and disciplines that have been learned as being necessary to the PE job, then get applied to this new SD project context. They may be considered a little too excessive and over the top for the project context, and that can be challenging for both the ex-PE and the company that hired them.

In Summary

The main takeaway here is that: an SD working as a lone-wolf in a services company, in a project context, is not doing the same job, nor do they have to develop the same skills that a PE necessarily has, working in a product context making long-lived products in teams.

Despite the fact that they both use the same languages, tools, frameworks, and technologies, and also use the same (sounding) processes and practices. They are vastly different jobs, requiring different skills, practices, disciplines, and accountabilities.

This distinction may only be recognizable to those who know this industry intimately and possibly to only those who have worked for extended periods of time in both services and product contexts.

But as we know, in this industry, there are many non-technical or inexperienced technical people who think that these jobs are conveniently interchangeable. They simply lack experience in a wider perspective.

I conclude that there are far too many product startups who staff themselves with SDs straight out from the project context, instead of with experienced PEs who are skilled in the product context. Probably, because those who brought them into the company don't know enough about the differences or don’t know how to find and hire the people they actually need. Likely, it is either a lack of experience, or it's an economic pre-mature optimization that drives that behavior.

SDs don't know that they should apply these new PE skills in this context, and thus don’t develop them. Then, as their startup grows, to the point where they had needed these skills (to have already been applied), the startup business starts to suffer, introducing impediments (due to “the big ball of mud”) that simply should not be an issue at that stage of the business. This is a crying shame since it is predictable and avoidable.

Can a product context onboard SDs? Well, it is possible, but I’d say only if those SDs are shown the ropes by experienced PEs who know how to teach and show them the ropes effectively, and that there are enough PEs such that those practices are the norm rather than the exception.