From developer to product lead
Four and half years ago, I joined Electrum, a FinTech startup that builds transaction processing software for banks and retailers. I started out as a junior Java developer. The role came with a steep learning curve for me, since my career up to then had been that of a climate scientist. That's a story for another article, though!
When I joined Electrum, we were a small team of five full-time employees who primarily focussed on consulting and professional services. The company grew quickly and three years later we were up to 25 people. At this point, I found myself in a fairly typical developer role. My job consisted of sticking my head into software problems, shutting out the noise around me to write code, and trying to deliver projects on time. Not to mention that I always provided the vaguest possible response to any question containing the words "time estimate"!
As the company grew, we realised that we needed to move away from being a purely services-driven company. We needed to develop a product strategy so that we could more effectively leverage our outputs into increased value for both us and our customers. This meant dedicating effort towards building a product. So, what exactly is a "product"? Broadly speaking, we see it as consisting of:
- Off-the-shelf solutions that can be rapidly deployed to customers,
- Tools to give our customers a better view of their back-end systems, as well as
- Internal tools to enable our developers to develop and roll out code more rapidly.
Through a series of events, the responsibility of driving this fell on me and I was asked to be the "product guy". I had to take responsibility for ensuring that the company's strategy regarding the product was clearly defined, and that there was a team of developers dedicated to working on core product initiatives. Basically, I needed to focus on defining what Electrum should be building in order to drive its business forward.
Whatever it would take to get there, I needed to figure it out.
The challenges of moving into a leadership role
1. Defining my own role
Before I could even start thinking about working in the new role, I had to overcome my first challenge: I had to define the role itself. Since there was very little formal coordination around a product, there was no precedent for a dedicated product lead to follow. Being part of a young company with a flat hierarchy and a strong emphasis on employee autonomy, it didn't really come as much of a surprise to be told to figure this out on my own. I think, by nature, at any small organisation one learns to be a bit of a generalist and to be flexible enough to dive into a new area when required. That's why I didn't really see it as a case of being thrown into the deep end and being left to flounder (ok, maybe I did a little bit).
I realised I had to shift my mind into research mode to discover what the company needed, and what I should focus on in order to achieve that. I found myself reading articles and books covering anything to do with product ownership, leadership and - dare I say - management. In my role as developer, I was privileged to have been surrounded by great mentors I could aspire to be like, but now there wasn't one single person I could look up to and think: "To be great at this job, I need to be more like them". Although I didn't have a direct mentor to groom me into my new role, the people surrounding me still had a diverse set of expertise and experience that provided me with a great deal of help and advice.
Key learning: Invest time in research and don't overlook the wealth of experience surrounding you. Find out how others have approached the problem, then figure out how these lessons can apply to your organisation.
Since I was filling the role at the same time as trying to define it, I was in a bit of an awkward position of not really knowing how to measure my productivity. As a developer, this is fairly easy to measure because you are building things: you can measure it by features delivered, or some other concrete output. I was now in a very different situation where the outputs were less tangible, which gave me the perception that I was being kept busy without really achieving too much.
I soon realised, however, that my productivity now laid in enhancing the productivity of others. The important metrics for me were now more about the value that the product team could deliver, rather than particular personal outputs. More than anything else, this meant that I needed to build closer connections with those around me. Being in tune with the team's needs and challenges is essential to building a platform for them to perform.
Key learning: As a manager, your productivity is measured by the productivity of your team. Make sure you are in tune with the needs of the team so that you can build a platform on which they can perform.
2. Going from heads-down to heads-up
This next challenge is quite typical for anyone transitioning from a technical to a leadership position: the realisation that I could no longer just put my head down and hammer out code. I needed to skill up on the soft side and be far more engaged with what was happening around me.
A big part of my new role became that of team lead - did someone say "middle management"? This meant I needed to be in tune with the well-being of the team as a whole and also with the individuals in the team. This meant making sure team meetings were productive and engaging, having regular one-on-one meetings as well as just being present to help point a developer in the right direction if they were stuck.
Key learning: Grow your soft skills - yes, even developers have a soft side.
Being responsible for the company's product strategy meant I had to have a very good handle on the needs, wants and ideas of just about all areas of the business - sales, professional services teams, and technical operations.
How this interaction ultimately manifests is through meetings - lots of them. A classic article by Paul Graham expertly sums up the developer and manager's differing views on meetings. While developers value deep work - long periods of undisturbed time during which the mind can delve deeply into a problem - managers require constant interaction and face-to-face engagement. There was a huge shift in mindset that I needed to make to become comfortable with the fact that meetings were now an essential part of my job, not something to be avoided at all costs.
Key learning: Learn to love meetings!
Multitasking and context switching - those evils that hobble productivity - became far more difficult to avoid. As a developer, tasks are typically logically ordered and can be tackled in series, but those that now demanded my attention tended to be smaller, more diverse, and less obvious as to which should come first. It requires considerable discipline to be able to tackle a variety of disparate tasks in an efficient manner. Which leads to the next challenge: prioritisation.
3. What takes precedence?
The main areas of responsibility for me had become leading the product development team, managing the company's strategic product roadmap and managing the backlog of product development tasks. Given that all of these areas require constant attention, I found it quite overwhelming to to figure out where to focus my efforts. One of the core skills of a product lead is the effective prioritisation of features and initiatives - I found that this skill would not only apply to the product backlog, but to my own day-to-day tasks.
The ability to say "no" is often quoted as one of the key skills of a product lead. It seems an easy thing to do, but is in fact incredibly difficult. Probably what makes it so hard, especially in the early stages of taking on a new role, is the desire to be seen as a positive enabler, rather than a blocker of progress.
On a more personal level, when shifting from a developer to a manager mindset, one of the things that is hardest to let go of is the coding. It is something that you have committed so much time and energy to learning, and has become such a huge part of your day-to-day life - how can you just go cold-turkey? On top of this, there is a backlog of stuff that needs to be coded! How can you sit in meetings while there's "real" work to be done?
The reality is, in order to properly focus on my new role, I had to learn to say "no" to coding. The danger of hanging onto it would mean falling back into my comfort zone and not directing my attention to where it is actually needed.
Key learning: Say "no" to tasks that will take your focus away from what your new role requires of you.
Once I had overcome some of the initial challenges of figuring out what my new role required and how I should organise my tasks, I needed to focus on building a team that would deliver value to the company.
4. Delivering value
Developing a product is about investing in strategic value, where the benefits to the bottom line are not usually immediately apparent. In contrast, consulting or professional services projects have rapid financial benefit; the customer has sent through a purchase order for the development of a new integration, and monthly support and maintenance costs have been agreed upon.
To deliver more value, our company had made the decision to invest time in building a core product. It was my job to make sure that we had a team of developers dedicated to this purpose and that value was indeed delivered. The hardest part of this became balancing the priority of core product tasks with those of the professional services side of the business. One has to balance the notion of "the money is not yet on the table, but I assure you it will be" with "the customer is waving a purchase order and wants this delivered tomorrow". When there is a long backlog of customer projects and limited capacity with which to deliver them, one needs a really strong case for assigning developers to initiatives that might not have an immediate payoff.
It was therefore necessary to build trust within the organisation by communicating how the efforts of the product team were aligned with the vision of the company, and would ultimately grow the business. How not to achieve this would be for the team to be an isolated unit with little empathy for the needs of the rest of the company and its customers. An active effort was required to ensure that what we were working on was visible, and that we could demonstrate the value that we generated.
For me, personally, this meant I had to closely engage with all stakeholders to determine what the key product priorities were, and to make sure these could be translated into workable tasks for the team to take on.
Key learning: Make sure the efforts of your team align with the vision and goals of the company.
How successful have I been? Well, it's still early days, so I guess time will have to tell! Nevertheless, this transition has been an amazing learning experience for me as well as a fantastic opportunity to play a pivotal role in a growing company.
Resources
Some resources I found useful:
- Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams
- Things I've learned transitioning from engineer to engineering manager - Gergely Orosz
- On Product Management
- Insights Blog - Silicon Valley Product Group
- Product Talk
- Ken Norton - Google Ventures Partner and Product Manager
.png)
.png)
