The Sniper and the Spotter

Those who are familiar with my background know that I have worn multiple hats over the years as an Engineering Manager (EM) and as a Product Manager (PM). As a result, I often get asked a few questions which are all kind of related:sniper

What do I think of these two roles? Which one do I like better? Do I not miss coding? How do I make sure I am not stepping on the EM’s toes when I am wearing the PM hat ( or vice versa)?

I usually try my best to answer these questions as one-offs and give narrow window into my view of the world on the topic. But most of the times, because of the framing of the questions, I don’t end up providing my entire perspective.

In parallel, over the years, I have seen multiple attempts by various companies and teams to define the roles of EM and PM. More often than not, these tend to be two separate documents independently defining the roles and leaving the interaction between the two roles unaddressed and subject to interpretation. Also the roles are usually defined by describing a laundry list of activities EM and PM are responsible for and expected to conduct.

There is one more observation I have made that I will add here to finish my context for the rest of the post.

What makes interpretation of the EM and PM roles defined in the manner I described above harder in practice is the fact that the EM and PM are usually people with overlapping skills.

The point I am trying to drive is, over the years through these interactions and observing teams struggle to clarify these roles across big organizations, I have realized a need to have something simpler yet powerful and sticky to explain the two roles and the ideal interaction between them. A metaphor, a model, a framework if you will.

Note: The rest of this post is applicable even if you substitute EM title with other similar engineering leader roles like tech lead, lead engineer or architect etc. because the post is about interaction between the engineering leader and the PM discipline.

The Model

I have been thinking about this for a while and have come up with the following model that I think is useful.

EM and PM should act like a  team of  sniper and  spotter respectively.

Think about it. According to Wikipedia in a military Sniper team, “The shooter(s) fires the shot while the spotter(s) assists in observation of targets, atmospheric conditions and handles ancillary tasks as immediate security of their location, communication with other parties; including directing artillery fire and close air support. The spotter detects, observes, and assigns targets and watches for the results of the shot. Also, in conjunction with the shooter, the spotter will accurately make calculations for distance, angle shooting (slant range), mil dot related calculations, correction for atmospheric conditions and leads for moving targets.”

Lets look at the parallels here for the EM as the sniper and the PM as the spotter.

Just like a spotter, the PM should detect the optimal target customer base, observe and document their problems and then inform the shooter about the target customer and the problem worth solving. From then on, just like the sniper and shooter collaborate to make calculations for the shot, the EM and PM collaborate to define product roadmap that will address the target customer. At some point the mission switches over to the execution mode where like the shooter it is the EM who fires the rounds. The spotter’s job in that phase is to observe and report the results of the shots just like a PM reports out customer feedback on the prodcut. You get the idea.

Need more proof? More from Wikipedia: “It is not unusual for the spotter to be equipped with a notepad and a laptop computer specifically for performing these calculations.” Now if that does not sound like a PM then I don’t know what does 🙂

Applying the Model

You can leverage the model in various ways.

You can use the model to create an initial frame in a new team or introduce a new frame to an existing team. The model can help EMs and PMs make sense out of navigating the grey areas of responsibility. Should an EM do a particular task\activity or a PM? You can ask questions like: is the task more about detecting, observing, reporting on the target or is the task more about maneuvering the weapon?

But more importantly, you can use the model to illustrate that EM and PM must operate as a well-cordinated, tight team. They are the co-founders. They don’t jostle for control, they simply complement each other. A great working relationship is critical to their mutual success.

You can also use the model to identify dysfunction in the relationship as well. We all know some shooters who only trust their own spotting and we know some spotters too who love to be in charge of firing the shots as well.

I want to clarify one more thing before we wrap up.

You may ask. What about other disciplines? What about design, QA? Are they not important?  Why are they not part of the model?

My simple answer is of course other disciplines are just as important if not more. The model only addresses EM and PM because of the observation I shared towards the beginning of the post about EM and PM on the team often times having overlapping skills and higher level of  grey areas between their respective responsbilities.

To conclude,  hope you like the model and find it useful. Please share comments or other models if you have found them useful.

On To The Next One

Ren profileIt was September 2003 when I walked in as a new hire at Microsoft in the Visual Studio Team. 13 years later, Microsoft has fulfilled almost all the dreams I had for this phase of my career. So with bittersweet emotions I am saying goodbye to MSFT and moving on to my next adventure.

I thought I would use this post to not just summarize my emotions but also provide my take on where the company is and where I think it is heading. I want to set this up as fuel for the endless Seattle winter cocktail conversations or as things are nowadays endless winter toddler play dates  with little to no cocktails 🙂 If you are curious about my work at MSFT here is my LinkedIin page.

It’s Graduation Day!

Let’s get the emotions out-of-the-way first. The best way I can describe the feeling is the one of graduation and gratitude. This company is one of the oldest and one of the finest institutions in the tech industry. One of the things the company is great at is nurturing college hires and help transform them to thorough professionals. I found a lot of great mentorship and opportunities to develop new skills. MSFT supported my education goals and my transitions across disciplines. My family thrived with MSFT’s support.

So it is with all my heart I say thank you to Microsoft and thanks to all my managers, my sponsors, my amazing peers and my directs over the years!

State of the Union

During the last decade the company has had to navigate through some rough waters. With that backdrop as I keep running into current and former MSFT employees and folks working at other companies at social events I see a few themes in how people in the Seattle area view\rate the company. Some of the arguments can be intense and polarizing. Typical criticism of the company involve themes like : MSFT does not innovate, it is hard to get things done at the company, not agile enough, delays due to lack of consensus across big divisions etc. IMO some of these views ignore key context and often are supported by apple-orange comparisons.

I will try to offer my view of things here and shine light on some nuances.

Spoiler alert: In a typical MSFT fashion I will try to offer a more balanced view and even in more typical MSFT fashion I will do that by offering praise first (and loads of it) 🙂
The company is doing well. The state of the union is stronger than it has ever been and not just because the stock has nearly doubled in last 2-3 years. Satya has brought strong leadership and brought about many a transformations. The company has rightly retreated to focusing on what it is great at – being a platform company selling to enterprises with cloud and productivity as big pillars. Gone are the days of intra-team feuds and rewarding hero performers. The culture is well on its way of transforming and becoming more and more collaborative, customer focused and data driven.

The story of an Apple and an Orange

While many people know about and appreciate these transformations, one aspect that MSFT does not get enough credit for is how amazing and successful it is at selling to enterprises. In the consumer tech world, the success stories often involve tech that offers a creative solution but often times also defines a problem in a way that customers had not imagined before. Successful products often have wow factors.

Things are different in the enterprise world. In the enterprise world the game is about solving naturally occurring business problems in a way that offers the best economic value to all parties involved. It is more about things like  data warehouses with infinite scale in the cloud than about driverless cars or space rockets. In the enterprise world you don’t try to move as fast as you can.
You move at a pace that is just right for your enterprise customers (yes there is something as moving too fast or building software that is too smart in enterprise world). Due to these and other factors innovation can feel more incremental than earth shattering and that is perfectly OK. There are no jaw dropping launches, high-profile secretive press events and that is fine too.

To be honest I would like to offer a deeper dive into enterprise software and what makes MSFT so great at it and better than its competitors but not only will it be a bit off topic it will also leave very little for the cocktail conversations I am trying to ignite 🙂 So I will rely on just some of the facets I hinted above and conveniently jump to the following conclusion.

MSFT gets enterprise customers like no other company does.  MSFT is set to dominate enterprise software including cloud and productivity for a long time to come. 
Another pattern I see when people talk about some of the inefficiencies, slow progress and  coming out of MSFT are comparisons between MSFT and much smaller companies. In my opinion this is another one of those apple-orange comparisons like the consumer tech to enterprise software one . Big organizations inherently work differently compared to small organizations whether it is tech companies, government, sports bodies or charities. From talking to people around the Seattle area a lot of issues people identify with Microsoft are similar problems Google and Amazon also face and are problems arising from sheer size of these organizations and scale of the business they operate in. I am not saying one should tolerate inefficiencies I am just saying the comparisons should be between equals otherwise you are chasing a dynamic that is never going to materialize in a big company setting. An 18-wheeler is not going to handle like a roadster around the curves but it can sure haul a lot more stuff.

So could the fruit ripen more

Alright so now I am primed to offer my view on what I think are challenges unique to MSFT. Continuing on the theme of comparing MSFT to the appropriate peers like Google and Amazon there is one challenge that I think MSFT faces more than the likes of Google, Amazon and Facebook do. MSFT has been in existence far longer than these companies. By the time these companies came into existence MSFT already had its share of ups and downs. What that means is that there are folks at MSFT who have perfected their own personal template for success long before the modern (post 1999) era. At times these templates can be at odds with the transformations happening in the industry and at MSFT. Some folks are able to evolve their personal templates for success, others are slow to warm up and that creates impedance mismatch which eventually slows progress.

Another area where I think MSFT’s competitors have historically done better than MSFT are acquisitions. While MSFT is traditionally best at strategic collaborations and partnerships, acquisitions have always been an Achilles heel for the company. Although recent smaller acquisitions like Xamarin give me hope, the price MSFT paid for LinkedIn still feels astronomical.

Could this be Satya’s aQuantive moment? I hope not.
So those are some of my views on where MSFT’s at and where it is going. I wish all my colleagues at MSFT good luck and looking forward to lots of great stuff coming out of MSFT.

On to the next one

And with that circling back to myself. Happy to have been part of this great company and done my little bit. I am excited to announce that I will be joining as the Director of Product Management at Bellevue based Apptio. My charter will be to help evolve Apptio’s  customer base and core platform that powers all of its SaaS applications. I am on to the next one!

Cue in Jay-Z:

I’m on to the next one
On to the next one
On to the next one
On to the next one
On to the next one
On to the next one
On to the next one

Hold up, freeze

Somebody bring me back some money please.

Engineering leader’s survival guide series: Have you found your rhythm?

This post is part of my blog series: A survival guide for software engineering leaders.Ren profile

In this post I will talk about establishing a rhythm of business early and evolving it. I will be honest. This is a bit of a dry topic compared to some of my upcoming posts but this is important and one of the first things you should look to put in order. Hence I feel compelled to cover it even if it is dry. I hope some of the Dos and Donts at the end are more fun read.

I have to start this post by defining what I mean by rhythm of business. Rhythm of business for me is the scaffolding the team uses to organize itself and includes but is not limited to: various team huddles, email groups, release cadence for the product, business reviews with stakeholders etc.

Why is establishing a rhythm of business important?

In the world of a v1 product often there are tons of unknowns: product direction, funding uncertainties, relationships within the team that are still forming etc.

There are always lots of ideas and opinions flying around often times diverging substantially.

A well known rhythm of business can be the light weight scaffolding the team needs to to tackle the uncertainties in an effective way. It can become the one constant the team can count on.

On the flip side if the rhythm of business itself is yet another uncertainty added to the list above it can lead to chaos and meltdowns because the team spends cycles trying to establish the rhythm while grappling with other problems.

How do you go about establishing the early rhythm?

1. Be deliberate about establishing the initial rhythm and evolving it as you go. Just by taking the time to think about discuss what the different options could be you are likely to end up with something more thought out than leaving it completely (or partially) to chance.

2. Start as light weight as possible. Add more structure, rigor as you go. Nothing kills early progress on a v1 product as processes that are too heavy weight.

3. Create a proposal yourself first but review, refine it with the team upfront. Build consensus. Strong disagreements over daily, weekly rhythm can be very disruptive and affect collaboration.

4. Last but not the least, find ways to make it fun for the team! More on that below.

No really. What should an engg leader do?

Ahh so you are like me. Theory is nor for you. You are all about the tangible and not the abstract 🙂 For you here are things I have done (or avoided) that have worked for me.

1. Do leverage daily standups. Enough said!

2. Do leverage parking lots for daily standups:

We all know how this goes. Someone goes on an on about the complexities he\she has uncovered and by the time that person crosses the 60 second mark the phones start to come out of the pockets, the eyes start to wander and before you know it everyone thinks the standups are a huge waste of time. Don’t let this happen to your team! There is an easy way to make sure the useful discussions happen with the right folks without making everyone start hating the daily standup. It is called the parking lot list.

3. Do demo Fridays every week and do them with beer:

I can’t emphasize this enough.

If there was one thing I were to point out that worked like a charm every time for all of my products it is demo fridays with beer.

I can write a post just discussing demo fridays (and I might do just that at some point).

In products I led we would take turn in the team bringing beer and munchies on fridays, go around the room asking folks to show anything they are working on. Anything was fair game. You are a backend dev and have a new API that spits out some JSON. Show it to the team! You are a UX guy and you revved the landing page. Show it and get feedback! You are a designer and want to show the latest mocks. Put them up there!

It is beautiful when your backend dev, UX dev and designers connect and start talking about integration all on their own without you having to be the go between.

Some of you are probably wondering if this is same as sprintly demos and retrospective. Yes it is similar but with some important differences.

First, I have seen teams get too caught up in formalities of the sprintly demos and retrospectives.

They get too worked up, become too technical about their velocities, burn- down charts, estimate accuracy, planning processes and somewhere, somehow along the way they forget to bond and have fun as team.

While those are certainly useful and have their time and place they are more suitable for relatively mature teams. In a startup environment an overemphasis on those can backfire.

Note my emphasis on beer above. It is no joke. There is no better way to bond in a startup team than over food and drinks.

Secondly I don’t think it is productive to do sprints shorter than 2 weeks. 2 weeks is a good start for sprintly planning but it is too long to go between fun team huddles and demos.

So to recap, plan for 2 weeks but do demos every friday.

4. Do huddle with other leaders before business reviews.

This one is small but important. In a startup setting it important to make tangible progress but it is even more important to effectively showcase the progress being made. So do think about how often you have the all up business reviews and build in a huddle with relevant folks just before the review for a dry run. You don’t want to sell your awesome team short.

5. Do commit to a release cadence early and actually stick to it.

Even for super early alpha phase you want to be clear about a few things right from the beginning. How often are you going to put out new versions of your app? How often are you going to push your service bits to PROD? How are you going to separate your dev, PROD environments? How are you going to version things, manage back compat?

Manage your limited preview alpha community the way you would manage your paying customers post release.

When you try to treat your alpha customers as you would treat them post release you will come across foundational pieces your product needs and you will get ahead of the curve in getting those baked in.

So those are a few things come to my mind as Dos, Donts when you are thinking through your rhythm of business. Hope this gives you enough food for thought and motivation for figuring out your rhythm of business early in the game.

A survival guide for software engineering leaders

I am starting a series of blog posts sharing my hard learned lessons working as a software engineering leader on high visibility, make or break startup projects.

First things first. My creds for the topic:Ren profile

I have successfully launched 3 v1 products over last 3-4 years as an engg leader, the last one of them being – the Microsoft Band Apps for Windows Phone, iOS, Android. You can check more details on my linkedin profile. For each of these products I was one of the first engineers as well as leader on the team. I hand-picked developers and grew each team as the product evolved. By the time I was on my 3rd v1 product I had developed a template for organizing, managing v1 products and teams. As I look back at some of the patterns and practices I think sharing them and learning from others experiences on the topic will be a fun and valuable experience.

So what is life like for engg leaders these days and why do they need a survival guide?

The supply and demand for good engg leaders is heavily skewed with demand for experienced engg leaders far outstripping the supply. So it is true good engg leaders do have lots of great products, companies to choose from. However life is anything but smooth for engg leaders these days. Here are some of the reasons:

1. Product cycles have dramatically shortened and are getting even shorter.

With the help of rich cloud, mobile platforms, plethora of OSS lego blocks, tons of troubleshooting on internet software products that used to take years can now be launched within months at high scale.

Few missteps here and there, few team issues here and there and you are already behind schedule. This has reduced the margin for error substantially for the engg leaders.

2. Customers demand a great user experience

Thanks to the great Steve Jobs customers now expect a sleek user experience even if you are building an app that calls you a cab! You have designed the perfect product with all the right features, a scalable, fast backend but have a poor nav model? Too bad. Your competitor can easily eat your lunch by differentiating on simpler, more intuitive UX.

This means engg leaders need to constantly aspire for and balance best in breed user experience with functionality, features and performance. It also means engg leaders need to learn how to leverage the value designers bring to the product.

3. You need to be deliberate about bringing good leadership

See the above comment on supply and demand? Well it applies to all your developers too. They have tons of options and will stay with you only if they love working with you, the team environment you create and on your product. A lot of it comes down to your leadership skills.

Often time engg leaders overindex on being the technical experts in their domain and undervalue or worse are sometimes unaware of leadership basics.

There are more challenges but by and large this is the trifecta of themes that makes it challenging to launch great products on time for engg leaders.

What’s the engg leader to do? What resources are out there?

One of the closest and the most relevant thing is agile development patterns and the material on the topic: the scrums, the kanbans, the lean startup methodology etc.

While these are super useful they often address only one or two dimensions of the challenges as I described above in isolation and are also mostly written from the team, company perspective rather than from the perspective of the engg leader.

I think that is a crucial difference. Secondly, these do not boil down to simple, practical, battle tested tips, dos and donts for engg managers that they can apply to a wide variety of teams, products regardless of what spectrum they fall in their adoption of agile methodologies.

There is tons of great material on leadership but by and large besides Steve Jobs’s biography I don’t see engg leaders discuss\reference a whole lot of it  and I hope to contribute towards changing that 🙂

What can you expect from this series?

For each post I will pick up a topic\problem engg leaders typically encounter and some proactive ways, practical ways they can tackle the issue. I will provide simple dos and donts with anecdotes from my personal experience handling similar situations. Occasionally I will point to material I have found useful on the topic especially for leadership.

To make this more concrete here are the few next posts that I am considering. If you have a topic you want to see me cover hit me up.

1. Establishing a rhythm of business for the team

2. Leadership basics for engg leaders

3. Negotiations basics for engg leaders

4. How to decide on technical bets?

5. Effectively working with designers and product managers

6. Hiring

Continue reading

Welcome to Fast Times in Tech!

I am a technologist, fitness enthusiast, software engg leader and a father. I have led several products from start to launch at Microsoft. I am an alumn of UW Foster school of business. You will typically see me blend business and tech speak.

You will see me blog about a variety topics related to my background all set in the backdrop of the fast times we live in with Tech. I hope to keep the ton light, entertaining and above all positive. I believe we tend to attract the same energy towards ourselves as we project outwards to the world.

Here are my channels: