Engineering

Ecosystem Engineering

August 17, 2017 Leave a Comment

“An ecosystem engineer is any organism that creates, significantly modifies, maintains or destroys a habitat”

— Wikipedia

When you are working on platforms, you have the needs of the producers, consumers, and the market itself. As the market, or platform owner, your job is to make sure that the ecosystem as a whole is healthy.

One key is to not get too greedy at the platform layer, as Bill Gates put it:

“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”

This is somewhat common sense, but why do we often do such a poor job of taking care of our ecosystems?

One reason is that it is a hard, complex slog. When you are building something new you have a lovely green field and pivoting doesn’t have the number of side effects. You don’t have as many dependencies to manage, so you can run fast and break things. You have built a lean product team with top notch engineers who are cranking through their sprints like Usain Bolt.

Then something happens. The success of the work slowly changes the game, and before you know it you may be in a situation where the team members don’t really know it has changed! The incentive structures in the company may have been setup to reward the wrong things.

For example, as an engineer, the way to get promoted is to tackle harder and more complex problems, delivering fantastic solutions, in record and reliable time. You level up by showing how your craft has improved. This may be utterly at odds with the needs of the day.

Let’s look at a real world example. The Web is too slow and this causes a major drag to the ecosystem health, resulting in the current epidemic. If you are an engineer on a browser team, you will be working on more and more complex technical solutions to either:

Taking the existing content, speed it up in the browser. Incredible work has been done here, and it gets harder and harder (and more complex). Compare older browsers and how they blitted pixels to the screen vs. the complex GPU architecture that is in there now.
Build new standards and implementations that have faster paths. This is geological time, and a ton of work too…… and the solution isn’t enough, you need adoption.

If your core metrics are based on browser metrics, these are the paths you will take. However, if your core metrics are around the speed of the Web at large, which includes other browsers, then your point of view may change. Your investigation occurs at another layer and you may end up with totally different conclusions.

For example, WordPress is a huge percentage of the Web, including new content. This may have you conclude that helping make WordPress faster (better AMP support, service workers, etc etc) will actually generate a truly massive impact on the perceived performance of the Web at large, and it may also cause a competitive push with other CMSes. We see this happen again and again. For example, Flipkart being the “Google Maps of PWA” drove a lot of mindshare in India on investing in performance, especially from the eCommerce vertical. But this work is far from sexy. Many engineers would rather NIH yet another amazing CMS versus go in and make WordPress better.

Engineering teams are naturally working on the next feature / version of the platform. Take something like iOS or Android. Their yearly drumbeat is intense. I get to see this first hand by witnessing the mammoth effort that the Android team takes on. As we tick to the N+1 version, it is natural to focus on solutions there, but the ecosystem lags behind.

This is why work such as the Android Support Library came from Chris Banes, an engineer in Android DevRel. If you are talking to developers everyday, you are living in the real world constraints of today.

It is critical that we line up the outcomes at the ecosystem level, allowing you to really wrestle with the problems that you face at scale. It is important to look at all the tools at your disposal to enact the painful, necessary change. You need to think through all of the carrots and sticks. This kind of engineering effort deals with much outside of the scope of code. Psychology, and economics, can be front and center.

This is when other functions come in. Is the full go to market team in line with the same metrics? E.g. BD, Marketing, Sales? When everything is aligned magic happens, however often I see this break down due to us wanting to break down the problem into small chunks. If we aren’t tying everything together we end up with small product teams that are focused on their product, versus the ecosystem. The goals revolve around adoption. Everyone is pushing their shiny thing.

As I continue to see this pattern, I keep realizing that we need more ecosystem engineering, and we need to change the incentives to truly allow “Product Excellence”.

NOTE: There are some teams that I have seen that go above and beyond here. One great example here is Rick Byers and his team, and their maniacal dedication to bring predictability to the platform.

Tech writers are underrated

July 19, 2017 Leave a Comment

I have long seen the Bay Area (and tech industry in general) hold up the engineers, or the designers, as the heroes of Silicon Valley. There is the mythology of Steve and Steve in a garage, or Jonny Ive in a pristine design lab, creating the future.

In my own experience I have seen how important all of the roles are to making sure a product, and a company, is successful.

I highlighted project managers and QA engineers in the past, and today I want to speak about tech writers. Being back at Google I have once again gotten the opportunity to work with incredibly experienced tech writers, and I want to tell the tale of two (hypothetical ones): Robin and Pat.

First up is Pat

Great tech writing requires an immense understanding of the engineering product, as well as knowledge of the range of developers (or others!) who will be using it. The writer is the bridge between the product and the engineers knowledge who built it, and the end user developers. Pat takes the time to build the relationship with both sides and go deep with the product and its goals before getting to work. By embedding with the product team, and devrel experts, she immerses in this information, and is also able to help define the product.

By working with the product team she is able to get the insights and deep knowledge, but the understanding is that the audience is not the internal team, so the job at hand is to educate and help the external developers.

Too much documentation happens at the end of the production line “and now, can you writeup some docs?” This can be natural. You don’t want to waste time redoing docs while the product is undergoing massive iteration, but by having Pat there from the beginning gives the opportunity for the information to iterate and tweak, and then it can be deeply baked at the end. Pat is very strong when it comes to information architecture and taking massive amounts of information and prioritizing and shaping it based on what is really needed.

Many tech writing teams from various past lives felt stuck in the 1990s. Their process fit a “and now we need to write the manual” type style. Books are great, but not only are they not the way that many dev learn, but they have limitations. These days, for technical products, you can bring together a slew of tools:

Being able to play with the products live can be an amazing learning tool, and we all know that most people learn best by doing
Video, and various widgets (including tools, playgrounds, etc) can be embedded and composed with written content
Customization for the developer (e.g. show the sample API client usage using JavaScript vs. Python).

Another huge difference is that the entry point, and path, is so much more dynamic. Many developers are ending up on your content based on a problem they are having:

Ugh I can’t do X
[X] <= search for answers
End up in a doc, potentially very deep into the docs.

The default case isn’t “I want to go visit the home page of the documentation today!”, and Pat knows that all too well.

Next up is Robin

Robin is an empathic educator. Robin loves to code and build things, going as deep as possible on not only the product, but also the competition and ecosystem.

This gives Robin a ton of context on where to delve deep. If we aren’t consciously shaping the documentation experience, then it is easy to default to equal weight on small docs in the small. In the real world every API and method is not equal, and there are tasks that developers want to accomplish that don’t line up directly to documenting code.

As Robin looks at what the developer is trying to accomplish, and both feels individual pain and witnessing the community, a slew of solutions come up. Robin is able to drive change to the developer product/platform itself this way, is able to envision new tools or fix existing ones, and the result of the work tends to be in less verbiage yet more solutions.

When working ideally, the tech writers work hand in hand with their other devrel counter parts to drive this change. Together, they prioritize the work and how best to attack the needs of the diversity of developers that use, or may use, their products.

Doing it all with style

Context is varied throughout our tools, but consistency is important too. To that end the writers and editors have built a style guide for developer documentation. This is a living document that works as a collection of best practices and contract for how documentation can work best.

This is really important work as developers naturally bounce around through various documentation and use a variety of developer products. If we can do a better job here, a developer that jumps between docs on Firebase and Android will be able to intuit a lot along that way, versus having the feeling like these words are vastly different, and having to learn the cultural norms of the docset. I am happy to see the style guide public, as we see more and more projects in open source, and the community cares more and more about documentation. If someone wants to jump in to help with TensorFlow or AMP docs, they can easily see where the writing team is coming from.

Educator

It has been really exciting to see the tech writers in our DevRel team really take on the role of educator. They care deeply about developer success, akin to the other roles. This is something that ties us all together.

We want developers to be successful, so they can build experiences that enable people in the world. This is what gets me out of bed in the morning, having the platform to help in a small way.

Developers know how important docs are, and tech writers now have a massive impact there and much beyond.

And, I want to say thank you to the tech writers who help this mission, every day.

Others in the series:

Project managers are underrated
QA engineers are underrated.

“My engineers want to code at night! Oh no!” Oh yes!

September 4, 2015 Leave a Comment

I was talking to someone who was concerned about one of the engineers on his team. This chap was writing a lot of code on the side for a hobby project, and it didn’t feel right to this manager. After listening in to the group for awhile I had to insert myself and ask some questions:

Is he performing his job to a satisfactory level?

In the information age it is hard to measure impact based on the number of hours. At some point the engineering manager has to set the expectations for the engineers job performance. This typically happens already, where it is clear how to meet expectations, exceed them, and more. Putting in the effort to clearly define these levels gives you the tools you need to be much more loosely coupled on items such as time input.

If the engineer is at least meeting the expectations of their role, you shouldn’t be too concerned about what else is going on, but there is always the opportunity to talk about what it means to get to the other levels. At some point the employee may take the trade off to do more in their personal life at the expense of being a role model (not that time is the only way to become a role model).

Measuring the impact that a person has on your business is hard. There are so many complex variables at work, with a myriad of side effects. There is the notion of individual contribution, and also the leverage that you get with the team. A great leader has a huge leverage effect beyond himself, and that is true for any employee.

If he instead spent the same time on a hobby very different to work, how would that make you feel?

The manager didn’t like the engineer writing code on the side, but why? Why does it sometimes make people feel weird if they use the skills they have at work for a hobby, when if they spent the same amount of time on a very different hobby it wouldn’t feel as weird?

If the engineer was cranking away putting hours and hours into becoming a scratch golfer, how would you feel differently?

In some ways you should feel very excited that an engineer on your team loves software so much that he continues to explore it “off hours”. The passion is a great sign that they enjoy their craft beyond a pay check. Understanding the motivations is of course key. The context is what matters here. What are they working on? Is part of the hobby project a way to explore different tech stacks? A different domain? There is a good chance that this “free time” work is a gift. The engineer is growing and you are getting the benefits of that growth, while he is with you.

Is he being paid for work on the side?

It can feel different when someone is hacking on a fun open source side project vs. a paid gig. The incentives are different. On the one hand the golden rule of “as long as they are doing their job” can be applied, but it is still a warning sign. Do they feel they need the money and don’t like what they are doing other than the pay check? Or, is the pay check a happy side effect of working on something genuinely interesting?

When money is changing hands there is another person in the equation: whoever is paying them. If it is consulting work, someone is managing that work. If they are selling an app on an app store, there are customers. When this happens loyalties can be split, so the salient point is “where is the primary focus?” When shit hits the fan and you need this guy, is he around?

In the 24/7 world that we live in, when is it OK to work on this vs. that. Chances are you have had people work for you at all hours of the day. In fact, it may be that some of your engineers work best coding at night, so you should let them do that at times for their day job!

Expectations

As with seemingly so many things in life, it probably all comes down to expectations. You should be able to have an honest transparent ongoing conversion between engineer and manager. You also need to be fair across your work force. You may have some fear that the engineer will leave to work on this hobby, or get another job due to the open source work, but is the alternative of trying to capture someone better?

If you can find a passionate engineer that is creative and wants to explore his craft no matter what, you should probably consider yourself very lucky. If not, what kind of culture are you creating? Whatever you do: don’t just tell them they can’t be creative and put them in a box. If you want obedient fulfillment workers, this is one way to start down that path.

As one of my kids often remarks: “Are you FORCING me?”