Letting your engineers choose what to build
(or, how to build more, better, faster)
Over the last 6 months we’ve dramatically changed how we manage our engineering team here at SketchDeck. We’ve switched from me and my co-founder setting weekly product priorities, to letting each engineer decide what they want to build. It’s lead to faster product development, higher quality software and better product design. In this article I’ll share our experience changing over, its benefits and its challenges.
SketchDeck is a graphic design service, powered by a sophisticated online platform. We’ve clients and designers all around the world collaborating through our software. I’m David, one of the founders and the CTO/Product Manager.
Product management in the early days…
In the start it was just me and my co-founder Chris. We both designed slides and replied to customers, we chatted about our ideas and I wrote software. It was all quite simple.
As our design volume grew, we hired our first engineer. He and I helped field the chaos: chatting with our designers, helping out clients, writing software, fixing things that broke.
My co-founder, first engineer and I would informally get together and discuss what we should do next. We’d then build it, hear directly from the designers and clients using the software, and make adjustments based on feedback.
Growth breaks things
As we grew we took on a larger engineering team. The new team members asked us what they should work on. Each week we’d all get-together and discuss the week’s product priorities — largely driven by me and my co-founder. We’d settle on some priorities, then allocate each engineer part of the work.
Whilst this organisational process seemed simple and benign, things didn’t run smoothly. Things were taking a long time to get released. We’d bemoan that the engineers didn’t “get” the clients and designers. Buggy software found its way out to production. We had a growing snag list (minor bugs and awkwardnesses).
I tried to fix these issues with process. I hoped that by making development a simple process it would be faster and more reliable. I required our engineers to include test plans in their pull requests. We required senior engineers to break each feature proposal down into all its components and sum up all the time required to build it. Spreadsheets started to appear.
Turning our little startup team into a bureaucracy was a bad move. It made our product development slower. Our engineers were now more distant from responsibility and reality — as a result they still didn’t “get” our clients and their product design choices were worse. Managing all of this took a lot of my time, my weekly code-writing volume was halved
YC: “You’re doing it wrong”
Around this time we had a meeting with Michael Siebel, the president of Y Combinator. He quickly admonished me for how I was running the tech team. “I wrote a blog article about this…” he lamented.
I had read the article, but never felt its process would work for us. The article describes getting the whole engineering team together and having everyone propose what to build that coming week. I’d tried this, but the meeting defaulted back to my co-founder and I making all the suggestions.
Talking with Micheal I realized the big thing we were missing: having our engineers interact directly with our users. We needed our engineers to feel their users’ pain, hear their suggestions and to turn those into suggestions.
With this insight I returned to the office to totally change how our team worked. Our new process is as follows (it’s a slightly slimmed down version of Michael’s process, with some extra details we found important):
The engineer led product process
- All engineers deal directly with users. They answer support tickets, get on the phone with users, visit users. This is vital to make the next parts work. We allocate engineers to particular user groups (e.g. clients, project managers, designers, sales etc.)
- Each engineer’s goal is to improve the company’s metrics connected to their users. For example, to increase retention of customers, to increase feedback scores, to reduce support tickets, etc.
- Engineers decide what they want to build. Michael described it as “if they come up with the idea, get it approved and work on it, your process gets an A+”
- Weekly there is a sprint meeting where the past week’s progress is discussed, then each engineer proposes what they will work on over the next week. The group approves the proposals (or sometimes debates them with alternate data / customer experiences / ideas about priority and return on investment / visions for the platform’s future design). Engineers are held to the deadlines they set for their own work.
- Weekly there is a metrics standup where we review the company metrics and priorities. Those responsible for each metric explain if they’re on target and what their next steps are.
Transitioning to the new process
Our team was really supportive of making this change. Their openness to doing something new and willingness to wait and see the potential benefits were greatly appreciated and helped make this a success.
We had a couple of challenges, all of which were overcome. Initially, for our junior engineer, it was hard to make product proposals as he hadn’t yet spent time with our users. To remedy this we offered him our own suggestions and introduced him to users he could talk with. Over time he built up experience and was then able to make good product proposals.
Secondly, it’s harder to track if the team are on target or not — everyone is in a constant cycle of technical and user discovery, and as we learn our plans change. Sometimes features we think will be small turn out to be much bigger. To combat this I regularly check-in with our team, asking what their goal for the day is. Then, we quickly assess if their current plan’s effort-to-reward (i.e. ROI) seems appropriate, and if it doesn’t, suggest a small adjustment to the plan.
Finally, there is a risk with this process that you lose product design quality. This could happen in two ways: the UX of individual components could be worse as the engineer designing them lacks a background in UX design. Secondly, the overall platform could lack coherency as its different pieces are designed by different people. We’ve combatted this by having UX review be required on all features, just like code review. Engineers receive code and UX feedback on their work before it’s released. Also, as product manager, I share sketches of how the platform could look in the future and help guide everyone towards a shared vision.
The benefits of adopting the new process
“I was initially hesitant to move to engineering led product prioritization. I thought our product would become disjointed without top down prioritization. This did not happen.
Instead I’ve seen two big improvements: First, the team is more motivated — people are working on what they believe is most important. Second, the features we build are better. The engineer understands the problem in more detail, and iterates with the user to ensure that it solves the problem they have. Overall this has been a great change for SketchDeck, and we have a better product as a result.”
— Chris, CEO & Co-founder
After making this change, I immediately noticed how much more time I had to code, as I no longer had to spend so much time project managing. Thanks to the new process I doubled my code-writing volume:
The next benefit was that our snag list began to shrink after being backlogged for half a year. In the old process, it was too much work to prioritize tiny fixes, so we didn’t get to them. Now, as engineers bumped into snags they’d fix them, then carry on what they were doing:
Our engineers’ technical and product decisions improved:
“A major benefit is in the responsibility that an engineer feels towards the success of his output. After several cycles of claiming to understand a users pain, and advocating a solution, one tends to become very honest about the real effects of features being developed. The more direct the feedback loop from real users, the better” — Kris, Senior Engineer
Instead of somewhat grand and circuitous technical plans, engineers opted for quick fixes and tactical hustles. We still work on architecture projects, but are more considerate of their big cost.
Thanks to the process our users are happier. We frequently turn their feedback into new features and improvements. For example, I spent the last month answering clients’ questions about billing, then built a dashboard based on the experience. Within a day of launching it we got glowing feedback:
“This is is a great add-on to your platform! All the charges finally make sense!”
“I just checked it out and love it! That’s what we needed for sooooo long!”
By giving our engineers more autonomy their work is more fulfilling and they have more opportunities to learn and develop:
“Having the ability to direct what I am working on inspires me to consider how my changes effect our platform as a whole. I’ve come to better understand the needs of different users and I feel more connected to my work” — Nick, Engineer
Finally, we develop interfaces and ideas that we never would have before. Since we’ve multiplied our user facing eyes and ears, we collect more ideas and viewpoints, and build more considerate designs. As a company we “hear” our users more.
The final verdict
It took us a while to discover this process, but we’re really glad for it now. I’d recommend taking Michael’s grading test for your engineers (They decide and build for themselves: A+, you write a feature a spreadsheet and put names against rows: D-) and consider making some of the changes outlined above.
If you want to choose what to build, and want to directly improve the lives of marketers and designers, we’re hiring engineers to help build SketchDeck!
