agile, Career, Product Management, Project

Changing the process from within

Would you agree with the statement below?

If you disagree with how something is done, you should give the process a try and drive changes from within.

Give yourself some time to think before reading the example below.

I was given an opportunity to drive some works that are normally done by Lead Developers/Team Leaders/Tech Leaders etc. I initially rejected it because I didn’t agree with that specific process. It is a discovery process where the engineer lays out options, considers the pros and cons, considers the use cases, proposes a solution, and gets a written agreement from the interested parties. Let’s dissect this process with a real example.

Example: Cross-account Kafka applications in AWS

  • Goal Summary: Source data from an application database in one AWS account to a MSK Kafka Cluster in another account.
  • Options: There are a few layers of decisions to be made. The publishing technologies could be custom publisher, Kafka Connect, generic in-house publisher. Then there is the cross account networking challenges. A proxy, direct connection, clone the DB etc. And then there are language choice, data flow design etc.
  • Decision: Kafka Connect with Network Proxy
  • Decision Maker/Interested Parties/Influencers: Product Manager from team A/Team B, C and X/ Team O, P and Q

This is an extremely over simplified version of the process. It took the team a month to finalise the proposal from trying out different options, to coordinating with different teams and many many discussions. But here is my interpretation of this process: we have a big challenge in front of us and we want to build some certainty before we step too deep into one direction. We also want to get an agreement between the teams that are involved, either in building them, might be using them, or potential maintenance team.

Why I disagree with this process

Retrospectively, I think I am too much of a purist when it comes to software development process. I have this ideal state of how Agile teams should be operating. Trust me, we are an Agile organisation but it is difficult to convey what that means nowadays.

First of all, the process is a waterfall in disguise. If it sounds familiar to you, the documentation that it produces, the contract model, the desire to be certain; they are very similar to the classic software specifications. For the record, there is nothing wrong about waterfall because it is still a great model for certain types of softwares. However, this process is so much leaner than a standard waterfall process. The document is in Git Issue and it was created with the understanding that things will change down the road.

Secondly, the reality is often not as good as the idea set out to be. The structure of the process is such that a single person or two mull the problem for a long period of time before presenting to the stakeholders. Although others are encouraged to challenge and be critical about the options and decision, there are a couple of problems. One being that not everyone will be on the same page or same level of technical understanding of the problem to challenge properly. Often people will just shrug it out and agree with whatever is decided. And then there is the biases of the individuals that will influence the decision.

And then there are two common outcomes at the end of the implementation of the decision. Teams tend to stick to the plan even if the road is bumpy and might not fit perfectly. This is sometimes accompanied with comments like “but we agreed to”, “we have invested in the decision”, and perhaps “the other teams are expecting this to be X”. The second outcome is that it changes and changes and the decision is not relevant anymore but the documentation and comms never really get updated. Although it is a preferred outcome nevertheless, why spend the time in the process anyway?

An iterative approach

Not sure if it s specific to Scrum or maybe it has a specific name to it, but let’s call it Agile for the simplicity sake. We know that the idea of Agile is to build small, try it out, showcase, learn and adapt to changes. Too many buzzwords, let’s use the same example above and see how we can iterate through it.

First we need to break the problem down into smaller more manageable problems. We can do this during refinement where the whole team will be there. Product Managers will focus on representing the customers and work with team to see what values can be delivered in the next week or two. There is no right answer for sure but the first goal can be to build a cross-account connection to first allow us and others to build applications outside of the cluster account. Let’s set that as a goal. The team discuss the options and agree to try on one.

A week of the team getting their hands dirty in the implementations, does it work? can we present something to the customers? If it works, that is great and move on to the next challenge. If it doesn’t, we learn and inform the next decision. A few iterations later, we have a living system that is not necessarily done or perfect but it is delivering value also we know that we are satisfying the requirements because we keep in touch with our customers.

This process does not guarantee the perfect solution at the end either. But what I value most here is the learning. Although we might have to do more actual work than the previous process, we do it as a team and we also learn how to adapt. In the Evolutionary Architecture principle, it is about supporting change and not about making the perfect decision. By involving in the change process, we learn how to change better.

We also build a team with thinkers and decision makers, and not just builders. I believe software development is a creative process and it often is not enough to just build things, but also to create things.

What do you think now

So we were here because my manager thinks that I should give the process a try to be able to understand the value from the inside and also drive changes if needed to. Do you agree?

For me, I am in a protest. I think that the process is against my ideals and I would not just do it so I can progress in the career ladder. This is definitely not looking good for my career progression but hey! it is about the journey, not just the destinations. I am enjoying my role and I am still learning and growing where I am as a senior developer. Although we know that there are pressure in climbing the ladder (perhaps a story for another time), I am not in a hurry to get anywhere just yet.

Standard
Career, Product Management

Why a Software Engineer might not get that Product Management role

Interviewing is a skill. Often you might think that you checked all the boxes from the job description but still ended up failing miserably in the interviews. There could be a few reasons that you failed like you suck at answering interview questions, you are not actually qualified, or you might have prepared it incorrectly.

Suck at answering product management interview questions

Interviewing requires practice and preparation. Maybe you can still get away with it if the last time you interviewed was 4 years ago and you are applying for the similar role. However, applying for a new role is pretty much starting from scratch without a lot of past experience to carry you. You won’t have the day to day examples to present and you don’t have experience interviewing for that specific role.

Even if you were given the list of questions before the interviews to prepare, you might not actually answer it well. Let’s take “How do you manage competing priorities?”. The answer could be “to understand the value and cost of each piece of work and visualise it in a roadmap. You can use tools like RICE, Kano model, Value vs Efforts to help with estimating your projects”. All of these are “correct” answers, but what interviewers really want to know if you have done any of those yourselves. Without a real experience in Product Management, it’s almost impossible.

One can try to draw examples from engineer’s day to day. For example, you can talk about Sprint Planning and how you estimate works, visualise it and make decision based on the key criteria. For example, if something requires a few hours but will save the developers hours of manual task every week, that’s a quick win and should be done as soon as possible. While a big task that bring smaller values can wait.

You might not be qualified for the role

You don’t always know what is required by the job even if it has a very detailed job description. Every interviewers has their expectation of the role and it doesn’t have to be the same as the job description. And I think interview is not only a great way for a company to get the right person for the team but also for the candidate to clarify the exact role description.

Nevertheless, you might walk into the interview and realised that you are not qualified for the role. Just like a software engineering role where every team needs different skillset. For example, one might be looking for a higher tier senior engineer who can upskill very quickly and start coaching others. You might be a senior developer with very strong technical skill but not really invested in coaching skill and that’s just not a good fit. You are still a great developer for the right team, but just not for this team.

Preparing it the right way

As a software engineer, interviews are mostly technical. You know how to code, how to draw system diagrams, how AWS works. How well you perform in your interview depends on your experience and being prepared with good examples. You might be asked to explain a system, for example. And you would refamiliarize yourself with one of your systems and even draw a diagram from memory one or twice. Product management interviews are a lot more functional. How do you manage stakeholders, how do you sell the product, how do you manage senior managers, what is your vision.

On hindsight and after listening to one of the interview tips from Modern Product Management podcast, I learned that I should have role-played the role before the interview. The gist was to know as much as you can about the team and product, plan out the 30/60/90 days, map out the stakeholders, make some showcase materials and just working on the product. This will help put you in that role and be able to answer the questions more from a first-hand experience rather than basing on nothing. It is also a big bonus to show that you have done a lot of work to know their company.

The we vs the I

We often look for great team players when it comes to software engineers. And we are trained to almost exclusively use “we” instead of “I”. It becomes very important when interviewing for a product management role to know when to use “I” and when to use “we”.

For majority of the questions, it’s about what you do. So I’ll say that prepare to use “I”s more to show that what exactly that you did to achieve those goals. Often it’s just the product manager that’s talking to different groups of customers and juggle between their request, the team might not know about them until it’s at the top of the product backlog. So is managing the senior stakeholders, your team don’t usually go with you to those meetings. So take the pride and own your stories.

And there will be times to use “we” and it’s important to know when. For example, it is important that you give your team the credit when it comes to building a successful product. You might also need to tell a story of how you sell the dreams to your team, how you collaborated with other roles in your company like the engineers, designers, delivery managers, team leaders etc. Although product management can be a lonely role, you are still a part of a team.

Standard
Career, Product Management

A developer applied for a product manager role

I am a software developer. Throughout my career I have been that person who is technically capable but truly shine in the leadership skills. I champion Agile processes in every team I have been to, manages stakeholders well through proper expectation managements, and a great mentor. So seeing how I excel more on my soft skills than my technical skills, I thought product management is a perfect role for me.

I don’t think that was a wrong assumption. I still believe that I will be an excellent product manager. Nevertheless, I failed miserably on my second attempt at the role. So here are some wisdom to share on the cost of my hindsight.

Expectation of the role

Product management in general is about being the representation of the customers and the market. But every role is different even if they have the same title. The role I applied for had some expectations that I wasn’t expecting and might even disagree. But nevertheless as the discipline evolves, these responsibilities get more standardised among companies.

The biggest unexpected element for me was that a product manager is expected to be a visionary. I mean, it sounded like an obvious responsibility but I wasn’t expecting it to be a character trait rather than a process. Part of the interview conversation was to see if I had a vision for the team. In a deeper sense, it was a test to see how much I understood the domain, the market for this domain and if I can propose a plan. This presented a challenge for me because I didn’t know that being a visionary was a big part of product management. I came in with the expectation that a vision is made not born. I thought that it is created through a process of understanding the users, understanding the needs and the wants, defining the problems and with the creativity of the team to produce a goal. But coming in with a solid vision can be a big winner during an interview.

Next is about saying no. Product managers often jokes about saying no more than saying yes. My approach was about data driven and being diplomatic with stakeholders. But I felt that there were an expectation of a more assertive approach. As a developer I like to discuss things. Every disagreement is a conversation. And most of the leadership training talks about influencing through understanding what the other parties want and build a solution. But in a role like product manager where you can be constantly asked for things and everyone want it now, the answer that senior managers want to hear more is probably “no”. Just “no”.

Selling the product is another key aspect that I didn’t do well. The question I was asked was how to get buy-ins from investors or senior managers who haven’t heard of certain technology (Kafka) or don’t understand why they want to invest in your team. Expectation here is to be able to show how you can manage senior stakeholders. As I haven’t done much of those in my career it was difficult to draw from experience. But one way to approach is to use tools like Lean Canvas. The key here seems to be about being high level and show the value of what you are trying to achieve. You also need to be able to zoom out using the language that different group of people can understand. For example, senior managers might not understand or need to understand the intricate detail of your solution, but they are more interested in why you want to build it, how much it’s gonna cost, and how much money it’s gonna make. And doing all of these with enough data to back them up and to convince the stakeholders.

So what is next?

Failing an interview puts you in a weird place. I was really grateful that the hiring manager was someone I knew and worked with before, and they gave a very honest feedback after the interview. However, it was also very brutal. I definitely felt horrible afterward and ashamed for a long while. They were great feedback nonetheless and it opened my perspective more into this role. So moving forward is important but I’m still on the fence if I want to pursue this career path.

And even when you are at a great place where you feel supported, have a good feeling about where you are heading in your career, and getting a lot of great feedback on your current role; failing really put your failures on loudspeaker. It was really hard to not feel like an imposter, that everything is not as good as it was, or maybe you are not good enough. This is all a normal emotion and it’s important to acknowledge them. It is also very important to be kind to yourself. Imagine if you have a friend who have just failed an interview and feel like the most useless person in the world. What would you say to that friend? Can you treat yourself like treating someone you love who is going through a tough time?

Standard