How to Successfully Collaborate with Software Developers
www.focusedchaos.co
Discover more from Focused Chaos
A weekly newsletter on navigating the chaos of building & investing in startups. Topics include fundraising, building products, analytics and more, leveraging a combination of best practices & instincts.
They take requirements, mock ups and people’s ideas and bring them to life. I’ve been in tech since 1996 and I still get a jolt of amazement when I see new software created.
Building things is cool. And that’s what developers do—they build stuff.
Is the future of software development ruled by GPT (AI) and No Code?
You can’t have a conversation about building software without talking about GPT, AI and no code.
They’re definitely valuable tools for building software. They enable non-developers to build things. And that’s amazing.
But I don’t see GPT, AI or no code completely replacing software developers/engineers. These tools should speed up the development process, allow people (developers and non-developers alike) to test things more quickly, and spawn a ton of smaller products/services in the market by solo entrepreneurs. They can be powerful enablers, but complete replacements seems exaggerated.
As much as I love building things, I don’t want to do it with an AI alone. Or even with no code tools (which I still find too complicated for many things.) Perhaps this is an old school way of thinking, but I don’t imagine myself jamming with an AI at a white board quite the same way I do with a software engineer.
Whether you believe the future of software development is completely automated or not, today we work with developers. And making sure that work is done effectively is challenging.
Recognize that Your Job is to Solve Problems & Create Value
Midjourney prompt: “solving problems”
Today:
Product managers talk to users, scope requirements, prioritize things to build and manage the delivery of new features.
Product designers also talk to users, and then mock up features, bringing requirements to life.
Engineers build what’s defined in the requirements.
I know this is a simplistic view, but a lot of companies operate this way, in effect creating silos between the different groups, which leads to misalignment on what people are trying to accomplish.
Everything I described above is about outputs.
If you ask a developer, “What’s your job?” they might say, “To build what I’m told.” (I’m exaggerating to make a point.) That’s not their job. Their job—as is the case with everyone building stuff—is to solve problems and create value. It’s much harder to define the specific tasks to get there, but the outcome is value creation, not lines of code, features or anything else.
Outcomes > Outputs
If you can get your entire team aligned on outcomes over outputs — solving problems and creating value — instead of the details of the work they’re executing, you have a chance of creating something truly meaningful.
How do you do it?
Don’t Build Through an Assembly Line
When it comes to building products that actually help people, solve problems and create value, linear order taking doesn’t work. A product manager can’t write the requirements, send those to the designer to design, and then send those designs & requirements to a developer to build. In this model you’re just throwing things over the fence to the next person with minimal context. Something will come out the other end of the process, but it’s most likely 💩.
Building products is a team sport.
Soccer is a good analogy. Everyone has a specific role, but it’s fluid and collaborative. A striker will block a shot from going into their net if they have to, even if their job is to score on the opposition. A defender’s job isn’t to score goals, but on occasion they do. There are set plays, but also lots of creativity.
If everyone isn’t aligned and on the same page, the team loses. Teams know they don’t always win, but they need a clear objective to even have a shot at doing so.
So product managers scope things, designers design things and developers build things—but it’s not that simple.
Sidebar: Waterfall versus Agile
Most product managers are familiar with the waterfall and agile methodologies for building software.
The waterfall approach suggests that everything is perfectly defined before it’s built and everything is done sequentially.
Agile methodology is more iterative, but honestly, it’s still fairly linear.
In my experience when people take Agile to its natural or extreme conclusion, it’s basically “mini-Waterfall.” Each sprint is a waterfall that has to be onerously planned, often without the whole team’s involvement.
If you build products in a linear way, you’ll leave developers (and others) with two major questions:
Why are we doing this? When you throw requirements at developers and say, “build this” without context, they will often wonder why. They might say something, but in a lot of organizations their role isn’t to question stuff, it’s to build. So they build. “OK, you want X built, here you go.” They take the input and return the output.
Did we create the expected value? Once a developer is finished creating the output and stuff is released to users/customers, it can be very difficult to tie their work to actual value creation. If the disconnect between the work and the results is significant it can be extremely demoralizing for developers.
Everyone Should Talk to Users, Scope Work & Help Prioritize
In my experience, developers are some of the most creative people out there. They are problem solvers. They occasionally over-engineer things and get “too creative” with their solutions, but they can also find simpler ways of getting things done.
That’s why it’s important that they’re actively engaged in the entire product management & software building process.
1. If you’re interviewing users, invite engineers to join you
They may do little to no talking, but your goal is to help them better understand the end user and build empathy for them. I’ve met quite a few developers that don’t really understand who they’re building solutions for. There’s no way they build the best solutions in that situation. You don’t need engineers on every call, but you can include them occasionally, especially when you’re exploring or trying to validate bigger ideas/opportunities.
This is the same reason why some companies will have everyone, at some point, do a stint in customer support. If you want to really understand what’s going on with users/customers, try answering their inbound inquiries.
I know this takes people away from their primary jobs — every minute an engineer is interviewing a user or responding to customer support questions they’re not writing code — but who cares? Writing code isn’t the job. Solving problems and creating value is the job; and I can guarantee your developers will be better at that once they understand the end user/customer better.
2. Scoping work isn’t the same as determining effort
Many organizations bring developers into the scoping process when it’s time to estimate effort. But the work itself has already been defined. You need to bring developers into scoping much earlier than that.
Scoping work is really about defining the right solution to a problem. It needs to encapsulate:
The problem and who has it
Why the problem matters now / how we know it’s a real problem
The solution and how it will work
A measurement of success (i.e. how will we know if we fixed the problem?)
An experiment plan
When will we ship and the milestones
Developers need to be involved in this scoping process, from a higher level overview of the requirements, into the nitty gritty details.
A lot of this early definition and scoping work should be done through a Product Requirements Document (PRD). There are a variety of templates you can use, but ultimately it’s meant to be a simple document that defines the key criteria above. And it should be a document that everyone contributes to.
A PRD is all about alignment and creative problem solving. And since you want everyone aligned on what you’re doing and why, and everyone (including developers) are there to problem solve, you need everyone participating in the creation of PRDs.
I’ve spoken to some product management people who say, “How can I get developers to read the PRDs?” My answer is as follows:
They shouldn’t be reading them, they should be co-writing them
If they don’t want to participate at that level of scoping, they lose their right to complain about how things are done (i.e. “If you don’t vote, you don’t get to complain.”) Your job (as product manager or founder) is to make them realize how important it is to participate in early scoping exercises.
Sidebar: How long will X take to do?
Don’t treat developers like code monkeys :)
Every product manager or founder, at some point, will complain about how long things take to build. It’s 100% going to happen.
In my experience this is because developers aren’t participating early enough in the process, and therefore haven’t had as much say into what gets built (and why), and aren’t given enough space to creatively problem solve. Without this you end up with a lack of trust between the teams, and once that creeps in, you’re in serious trouble.
Founders, product managers and designers: You need to understand how technology is built. You don’t have to know how to write code, but if you don’t have a decent understanding of what it takes, you’re in a position of questioning everything without much of a leg to stand on.
If developers are involved in scoping the actual solutions and understand users, you can hold them more accountable to their estimates.
You can try to turn scoping into a super rigid process, but I’ve never seen it work. Story points, scrum poker, etc. are painful. You end up spending more time scoping effort than actually doing work. (I’m sure there are a people out there that have figured this out, but it’s not for me.)
Initially, I always double the estimates from engineers and then try to reduce the scope. I’m not going to suggest developers are bad at estimating, but a lot of them are pretty bad at it. 😄
I’m a fan of t-shirt sizing as a way of estimating effort. It’s simple, easier to work with, and everyone understands the basic principle. Even “small, medium, large” may suffice to start (and then you can add x-small and x-large if you’d like.)
Reduce sprint time to increase the number of scoping cycles (practice makes perfect!) and reduce effort. If you find things are going a bit slow, try accelerating into 1 week sprints—it’s very intense, and probably not sustainable, but it forces everyone to keep scope down to a minimum and reflect more frequently on what’s working (and not working.) Two-week sprints are where a lot of people land—if anything takes longer than two weeks to build, break it into smaller pieces so you can ship faster (even if you’re shipping code/stuff that’s not done or accessible by users.)
3. Prioritization = Value / Effort
There are lots of complex ways to prioritize work, but in the end it boils down to expected value creation and effort.
The question you should ask is this:
“What’s the biggest impact we can have with the smallest effort?”
Intercom created a framework called RICE (Reach, Impact, Confidence, Effort), which is quite effective for prioritizing work.
But I would suggest going even simpler, and more specific.
Let’s assume for a moment that you have a strategic product roadmap (more on this in a moment) and for the next month your goal is to increase engagement. You measure engagement through MAU (Monthly Active Users.) You have a laundry list of potential things you can do to increase engagement, but you’re not sure how to prioritize. My suggestion is to do a quick prioritization exercise based on which feature/idea will create the biggest lift in engagement for the least effort. Here’s an example:
In this case, I want to increase MAU by 15%. I’ve got a list of ideas and they’re scored based on “engagement value” (how much I think they’ll drive increased engagement) and effort (which is a rough estimate.) For engagement value you might try “dot voting” (i.e. give everyone a fixed number of “dots” which they can use to vote on which ones they think will create the most value.)
The “target” is a line in the sand that you can use to measure success once the idea/solution/feature is launched.
Prioritizing this way is quick and easy to do, and involves everyone. It should lead to healthy discussions and debates.
Connecting the work done to value creation
Most people want to know if their work is creating actual value. If that’s not the case, and you can’t connect the work they’re doing at the feature level to some type of macro value creation, people will get disenchanted.
We have a tendency to think “building more stuff” is the answer to most problems. And so we shove more and more features into our products hoping it leads to more sales, less churn, etc. But too often we can’t really connect those dots.
You can’t do any of the above work without having some form of strategic roadmap. Too often roadmaps are a list of features to build. This misses the point completely.
A quick list of best practices for product roadmaps:
Focused on goals / outcomes (not features): What are you trying to accomplish? Why? If this isn’t clear to everyone, including developers, you’ll almost certainly build the wrong thing (and it’ll take too long.)
Categorized and organized by themes: Imagine a quarterly roadmap divided by month. Each month is a specific theme (i.e. in my prioritization example above I was focused on “increasing engagement” ← that’s a theme.)
Problems are clearly defined and understood: Your job is to solve problems, so you need to understand them and make sure everyone else on the team does as well. We’re less focused on the precise solutions (i.e. stuff we’ll build) and more focused on making sure we’re strategically headed in the right direction.
Timelines are loose at best: Roadmaps are often divided by month or quarter (although anything beyond 3 months is pretty fuzzy), but any detail beyond that is really meant for sprint planning.
Used as a conversation starter, not as something written in stone: Unfortunately most roadmaps harden very quickly. I’ve made this mistake. You structure everything tightly, lock in due dates and present confidently to the board. But too much shit happens, particularly in early stage startups, to really nail this, or even predict what the world will look like in a few months. As a strategic document, the roadmap isn’t there to define every deliverable on a timeline, it’s meant to create a dialogue amongst everyone (including developers.)
Product managers own the roadmap, but it’s built through collaboration with everyone else.
One benefit of having a theme (or “Name” above) for each portion of the product roadmap is that it allows you to better filter all the feedback you’re getting from everywhere. This is one of the biggest challenges for product managers—taking in all the feedback from every source (i.e. sales, marketing, founders, executives, customers, investors, customer support, etc.) With a theme in place (i.e. “This month we’re focusing only on retention”) you can “ignore” a lot of feedback and keep the team focused.
Now We Sprint
From strategic roadmap → scoping (PRDs) → prioritization → we get to sprint planning and executing.
As I said above, I like 2-week sprints; fast but not too fast, two-week sprints force teams to reduce scope, think in a more experiment-based mindset, and go through the whole process frequently (which should lead to improvements in things like estimating effort.)
A few additional recommendations when it comes to sprints:
Do not mess with engineers during a sprint: Once you’ve committed to the sprint, and everyone is aligned, it’s time to put your heads down and get the work done. Unfortunately engineers are too often interrupted with other things (i.e. Priority bugs! A client request we have to address now! The CEO woke up with a vision for something new!) — all of this takes away from their ability to build.
Don’t over-complicate the sprint process: I mentioned this earlier with respect to estimating effort. There’s already a fair bit of work to do just to figure out what to build, so try and minimize what’s required to actually execute each sprint. Designers and product managers can be working on the next sprint in advance (while still consulting the engineering team.)
Hold developers accountable to delivering: Once a sprint is locked in and you’re committed to not interrupting them, developers need to deliver. If this means they have to work extra in one sprint because they under-estimated, that’s on them. Everyone needs to be accountable for what they commit to doing. Note: If the team is constantly over-committing, you need to look at reducing scope (i.e. recognize they’re over-estimating what they can accomplish.) You’re better off reducing scope than “punishing” the team every sprint with a mad scramble to the end. Find the cadence of delivery that your engineering team can accomplish and balance out there. If this is simply not good enough, that’s a different story.
Run ‘clean up’ sprints: At some point, your engineering team will come to you and say, “We’ve got a lot of tech debt. This system isn’t scalable. We need to clean things up.” Don’t ignore them. Admittedly, in my experience, developers say this quite a bit. Sometimes it’s because they want to experiment with the “latest, greatest” frameworks, but you still need to listen. Burnt out engineers are not useful. And tech debt does lead to problems; bugs, performance issues, etc. At some point the tech debt can get so severe that you’ll hear the most dreaded phrase of all time, “We have to rebuild from scratch.” My suggestion is this: Dedicate 1 sprint every 4 (or 8) sprints to cleaning things up. This means 1 week out of ever 4 or 8 (or 2 weeks out of every 8 or 16 weeks) is focused on nothing but cleaning up the code, refactoring and reducing tech debt. I can almost 100% guarantee you that your engineering team will be happier. And happy engineers solve more problems faster.
Mix up the sprints: You can mix up the sprints by injecting a “clean up” sprint every once in awhile, but you should also balance between major and minor releases. People cannot work at the same clip consistently for long periods of time. Instead of hammering developers with “massive new releases” every sprint, balance this out with smaller upgrades. Some sprints will require extra effort to get done with a higher degree of pressure. The sprint after should be toned down. If you can manage the scope this way (i.e. don’t sprint at 100% every week) you’ll end up getting more value from the engineering team.
Collaboration, ftw
Great software products aren’t built by passing instructions between siloed teams. Aside from the fact that you’re playing a game of broken telephone, you’re also diminishing the significant impact that everyone can have in the process. This is particularly true of developers, who are tucked away in a back room to code.
If you bring developers into the product building process earlier—talking to users, writing requirements, prioritizing, etc.—you have a better chance of building something meaningful and keeping everyone aligned and motivated.
Thanks for reading Focused Chaos! Subscribe for free to receive new posts and support my work.
4 Comments
Share this discussion
How to Successfully Collaborate with Software Developers
How to Successfully Collaborate with Software Developers
Great stuff Ben. Thanks for sharing 👊🏼
Great read, Ben. Thanks for sharing.