I’ve had a few discussions recently about that critical relationship between the product management team & the engineering team. Now, it’s fair to say that sometimes this relationship is too close, in the sense that PMs spend all their time with engineering and almost none with marketing, sales, CS etc (not to mention users!). But we can all agree that this relationship is absolutely crucial to building effective, scalable products.
There have been a few comments that have stuck with me and I wanted to reply to a few of them with my thoughts. To paraphrase…
This guy, maybe he’s not a 10x but he gets it done and we just have to work around him
Obviously 10x, 100x, 1000x developers do exist out there. The kind of people that seem to have an answer for everything, can solve any problem, rustle up new MVPs in 10 seconds flat. These people sound great, and sometimes they are great, but they can also completely disruptive if…
• They have their own ways of working & refuse to meet anyone in the middle
• They have strong opinions strongly held and refuse to be budged because of personal preference
• They write stuff fast, don’t test or document anything, don’t share knowledge and become a silo
• They eventually leave the company and no one can work out how anything they did works
Now, to be clear, I’m no saying all of these people are like this but I’m also definitely not saying none of these people are like this. For me, a true 10x (100x etc) developer is one who collaborates, shares knowledge & truly contributes to the team. After all, great software is written by great teams.
Engineers need to know that they’re working on things that are valuable
It’s fair to say that engineers in many companies get a bad deal - they’re thrown requirements over the wall with little to no context, expected to deliver too many things all at once, with no clear idea about what happens once they’ve delivered the things. In many companies, engineering is still seen as a factory resource where people are just constantly typing and code comes out the back for the grownups to go and sell.
Don’t be one of these companies.
We have to see engineering as a key strategic partner in our product development, not a production line. We need to get engineers involved as early as possible to help to understand why they are building what they’re building, and also give them feedback after products are released. Get them some customer quotes, or even on a call with an early adopter so they can see how they’re changing people’s lives.
More than anything, any engineering team that thinks that it’s not working on the most important stuff doesn’t trust the product team and you need to work on that.
Engineers don’t like to write stuff that gets thrown away
This goes back to that production line mentality; the idea that the only measure of an engineer’s time is the number of lines of code that they write. And, in many cases, this is probably the reality for engineers working in such conditions.
Don’t get me wrong, it’s never fun to give up on something that seemed promising but didn’t work out. That new feature or product line didn’t land? It’s a shame, but it happens. We can soften the blow by working small and ensuring:
• We learned something along the way to improve future decision-making
• We learned something new about how we can (or can’t!) use technology to serve our needs
What I’m not saying is that we should leave loads of rubbish cluttering up the code base - when I say “thrown away” I mean let’s just get rid of stuff we don’t need anymore and focus on the essential.