For the past 3 months I have been coding daily. This is something I haven't done for years. Writing software became a hobby since I moved to a product career (except for a few Data Analytics Python and SQL that I used professionally).
Three months ago I became the CTO of the startup I'm co-founding. That came with a lot of coding in infrastructure, backend and frontend.
Reflecting on those 3 months I thought there were a few lessons I would like to share with every product manager and designer - those in a product team that are more distant from coding. After some pruning I ended up with a list 4 lessons I consider the most important (I would love to hear more from you):
Simple things can take a lot of time. Small tweaks can save a lot of time.
There are tons of uncertainties while coding. Estimations are probabilistic.
There are many ways to do the same thing and tradeoffs among them.
Documentation has way more value than you think
If you are an engineer you may find what I say obvious. But remember that some obvious things are not clear for outsiders if they stay under the hood. Opening that up to the team will make for a better communication. Never neglect how communication is super important to a team. I have written about this before.
Let's dig into each of them.
Value has no linear correlation with time when coding
As humans we tend to think linearly. Put more effort and voilà! You have it. Although that's not how it really works.
Simple things can take a lot of time when coding. If you say something like “I'm only ask you to add a button”, then you should probably reconsider the word “only”. Because sometimes adding a button can take months.
I will give an example I faced. We have two frontends for our application: a consumer facing store and an internal backoffice tool. They use the same API (a majestic monolith) with different authorizations. We would like to simplify the authentication process using Firebase for both frontends. Firebase worked really well for the consumer facing app (as it's built for) but the solution didn't play nicely with the requisites and infrastructure of the internal backoffice. We lack some knowledge about the tool in our team too. Something that would take a few days had Firebase worked first trial, ended up consuming more than two weeks. For an early stage startup that's precious time that we don't have.
We decided to try new paths and ended up with a proof of concept with Auth0 that worked like a breeze with the current architecture.
That shows that the reverse is also true: sometimes small tweaks in the solution can save a lot of time. So make sure to talk with the engineers about their struggles. Sometimes we try to dig deeper to solve a problem in a chosen path while the best is to try a new approach. We need to allow this “route change” whenever something stales.
Use statistics to rationalize about the time it takes to build
The example above - and others I could give - shows that there's a lot of uncertainty when coding. That's why most processes and estimations fail in tech. Because it's really hard to reduce this noise.
Instead of forcing developers to give better estimations, the correct question to ask is how the current knowledge of the team is close to the solution. If the team is stepping out of the comfort zone, be aware there's a lot of risk involved and you should either extend the time box allocated for the solution or adding some slack for the team to gain more knowledge on the topic (for instance doing spikes).
My preferred way to dealing with this problem is by reframing the above question:
If there's no real deadline to ship I ask “What's the chance we can deliver this in X weeks?”. Depending on the answer it becomes clear how engineers are seeing the uncertainty and, from a business standpoint, you can set the correct expectations and bet accordingly. By the way, that's the whole idea of betting in the excellent book Shape Up.
Sometimes a deadline needs to be met. So the question flips to “What do we need to achieve this until <date>?” You want to bring the chances as close to 100% as possible. Maybe you need to move resources, leave something else behind, cut corners, remove features.
Notice that I emphasized the word this in the questions above. That's because this is defined by the whole team and has a lot of influence from PMs and designers. So make sure to discuss the solutions considering the time box you have with the whole team in order to increase the chances of success.
Coding is not only about execution
I think the word “engineering” is also misleading. I prefer “coding” or “development”. Engineering implies that there's a project and the engineer will come to execute it in budget and with reliability. In fact coding is half execution half design (not sure what the proportions are, but you get the point).
Building software is a constant balance between several constraints and desires. Many (most) problems have multiple solutions. A developer, at any level, has a ton of small decisions to make when implementing a solution within constraints (time, legacy code, infrastructure). In several companies there's the role of a software architect/designer, but that does not completely split design and implementation. You can implement the same functionality in several ways. Here is an example of 6 different ways to run a simple task in JavaScript.
The role of tech leaders is to make it easier for developers to make those decisions. For instance creating some policies that lead every developer to take the same decision regarding code style (see lint). The whole idea of building the engineering org is to help the tech team to be more confident while taking those decisions faster and reliably according to what the company needs.
Here is the point: what the company needs. Every decision taken has tradeoffs and sometimes the path taken can be misaligned from what the company needs. Hence the need to have a clear product vision and a strong product strategy that is often discussed with and validated by the technical leadership.
Documentation has a lot of value
I want to end with something that is often overlooked: documentation. As I said I have been coding for 3 months and still sometimes I find some piece of software that I don't remember I wrote.
There's a lot of cognitive effort in understanding what I did a month earlier. This is when I feel really happy that my past self had written some lines of comment, a detailed merge request (see best practices here and here) and run some tests.
Sometimes, under the pressure of releasing, documentation is a corner your team is cutting. If that is the case, rethink your approach. Teams are in constant change, new people will need that documentation. But even if that is not the case, remember that developers forget what they have done. Pretty fast.
As a product manager and designer it is a good practice to read pull requests (or merge requests) once in a while. Most of them don't take more than a few minutes to read. You probably won't understand a lot of it. But that is a good way to start a conversation with an engineer in your team.
Talk about documentation in retros. Try to find ways to keep documentation lean and effective as a team.
As I have previously written, it's the product manager job to communicate well with engineers and help on providing a great experience for developers.
Always be curious,
Thanks for reading.