Lessons Learned in Engineering & Management

Posted November 11th, 2013 in Observations, Pulse by Greg Bayer
                     

This post was originally published on Medium.

In September 2010, I joined Pulse as the 2nd engineer with the goal of building a backend for what was a small but already very successful mobile app. As Pulse grew, regularly doubling in both user base and team size, we were repeatedly presented with new challenges.

Pulse Team

The challenges that arose in this environment were extremely varied. We tackled scalable distributed systems architecture from the beginning, without allowing ourselves time to slow down. Having launched out of the Stanford d.school, Pulse’s culture was built around an unusual approach. Every team member was encouraged to take part in user experience research and product design. Both our engineering and our management techniques were constantly tested as we grew, and we were forced to improvise and iterate regularly.

Having had this amazing opportunity to learn from many mistakes, as well as from a extraordinary set of peers and mentors, it’s interesting to look back at some of the lessons.

Engineering

Don’t over-engineer. One of the most important lessons I’ve learned at Pulse is to keep it simple. The simpler, the better. This doesn’t mean skipping system architecture/design and diving directly into the code. It’s always worth putting some thought into the architecture of whatever system you are building. Sometimes it can take quite a bit of thought to find a simple solution. But it does mean that if it seems too complicated, it probably is.

When building any system, even a backend platform, start with the minimum viable product and then test (with users) to see if you need more. Repeat this process as many time as necessary, but you’ll be surprised how often the simplest solution is actually what you want. Next steps often take a new direction that couldn’t have been anticipated without testing with users. At Pulse, we never built a system that was too simple. But there were definitely a few that were over-engineered.

Focus on building the core product. In the early days at Pulse we outsourced as much as we could out of necessity (infrastructure, ops, secondary features, frameworks). In the long run, we benefited greatly from this approach, especially outsourcing most of our infrastructure to Google App Engine and Amazon Web Services. With very little infrastructure ops work and the almost no related emergencies to worry about, the team was able to stay focused on the product, even as our systems were required to scale much faster than expected.

Pulse 2011

Similarly, using open source frameworks and libraries was essential to staying focused on the value provided to users. Some of our biggest engineering opportunities came from leveraging recent, freely available engineering advancements to make it possible to build something that used to be hard in a simple way.

For more detail on Pulse’s architecture and engineering approach, see Scaling with the Kindle FireScaling to 10M on AWS and the Pulse Engineering Blog.

Product

Create something unique. Pulse was created by Akshay and Ankit as a Stanford class project. It was simple and solved a very personal pain. It was also well-timed with the release of the first iPad. From the beginning, Pulse tried to differentiate itself by making mobile content reading a delightful experience.

Pulse-on-Kindle-Fire

Competing with slow mobile web pages with tons of distracting chrome around the content, Pulse put the content first. It provided a fast, native experience that worked seamlessly even if the device was disconnected from the internet. It also allowed users to access content very efficiently, without the stressful, inbox-like experience common to RSS readers at the time. Each of these features was relatively simple, but together they created a product that stood out in the market.

Set big goals. Since speed is critical in startups (and in most tech companies), it’s important to focus on approaches that have a chance of getting you to your long term goals and skip ones that don’t. As Pulse grew, we set our sights on building a content platform, not just an app. We wanted users to be able to access the Pulse experience on any device and to connect users with the best content available anywhere.

To that end, we built critical features like user accounts, cross-device syncing, and a rich, personalized catalog where user’s could discover thousands of vetted content sources. We built a platform that allowed users to share and discuss content with each other. We worked hard to build a brand that people recognized for quality and that both business partners and users loved being associated with. We also said no to many small features that would have distracted us from our vision and to other potentially promising directions like building a shopping app on top of the Pulse experience.

Team / Project Management

Balance quality / speed / features. From the beginning, Pulse had an extremely high quality bar. At the same time, we prided ourselves on a very short release cycle. Since those two goals are often at odds, testing features early and “failing fast” was critical. Together with minimizing features, we worked hard to maximize both quality and speed by building an amazing team and keeping them happy and efficient.

Pulse Team

Pulse’s approach was to maximize team member ownership and build a positive, open culture, where communication was rarely an issue. Traditions like Show & Tell and I like / I wish / I wonder, along with the right office space design played a critical role in maintaining this culture.

Collaboration / Mentoring

Make sure team members feel ownership. This was a central tenet of our management style at Pulse. We tried to ensure that each team member felt ownership for their tasks, all the way from technical implementation to user experience. The team was encouraged to take ownership in the product direction, system architecture, and the team’s overall success.

We hired new team members who appreciated this approach and regularly communicated ownership by assigning a Directly Responsible Individual (DRI) for every feature. The team was always intimately involved with the product direction through user testing, ideation and prototyping. We encouraged everyone to learn the Stanford d.school’s design thinking process. If someone didn’t feel ownership of the team’s goals, it was very important to find a way to restore this feeling through open communication.

Not everyone is the same. At Pulse we always made time for 1-on-1s and learning more about each other. One of the first painful lessons I learned in my early pre-Pulse years leading engineering teams was to stop assuming everyone was like me. I had to learn to be aware of my own and other people’s social styles. This may sound easy, but there’s a lot to learn. A good social styles class was well worth the investment. Recognizing other social styles is just the beginning. The real challenge is being able to communicate effectively with all types of people and learning how to help others do the same.

Really listen when talking with someone. Beyond awareness of different social styles, it’s important to really listen and to try to see things from the other person’s point of view. If you can’t, ask more questions. Stop thinking about what you’re going to say next. It seems so simple, but it took me a long time to realize that I wasn’t always doing this.

When you clear your mind, listen fully, and ask questions instead of ‘telling’, that’s when people open up. Only after really hearing someone can you know how to help and guide them. Walking or eating during a 1-on-1 can also help people open up and feel more comfortable.

Give more than you take. As a young team, outside relationships with mentors and allies were critical to our success. One of the things I like most about Silicon Valley is the culture of helping others without asking for anything in return. Every time I reached out for help, I found an overwhelmingly positive response.

I still reach out regularly, but I also make time to help others. It’s a virtuous cycle. Help someone and you will start to build a relationship. Care about them and their challenges. Build a team of allies.

Full Pulse Team

As those on the Pulse team know, we’re all still working on these lessons. We continue to make mistakes and hopefully learn from them. As someone who loves learning and growing, I’m thankful for opportunity to be faced with such a steady stream of challenges.

Have you faced similar challenges? Do you have a lesson that could help others in your position? I invite you to share and discuss in the comments below.

 

How To Use a Commuter Check Card to Purchase a Caltrain Monthly Pass

Posted June 27th, 2011 in Observations by Greg Bayer
                     

Warning

Before I start, let me recommend that you don’t try this. The potential savings you gain from using pre-tax Commuter Check cards likely won’t be worth the pain of actually trying to buy something with them. Return the cards to your employer and ask them to enroll in another option for funding your commute costs pre-tax!

Update: The Autoload program via Clipper works great. Instead of buying a pass in person with a commuter check card, you tag on/off once at the beginning of the month to load a new pass.

Goal

Use two Commuter Check cards issued by an employer (each containing $100) to purchase a zone 1-3 monthly Caltrain pass on a Clipper card (for $179).
Continue Reading »

Working Hard With No Regrets

Posted June 2nd, 2011 in Observations by Greg Bayer
                     

Working for a startup usually means putting in more hours than others. Recently, I spent two days on less than 3 hours of sleep in order to push out our new Pulse.me release. This doesn’t seem strange to me and didn’t make me unhappy. In fact, it was one of the most exciting and fun things I’ve done in a while. However, after mentioning it to some friends, I realized not everyone understands why it can be good to spend so much time “working” to build something you believe in.

Upon hearing about my sleep deprived state, my friend sent me a link to the top 5 regrets people make on their deathbed along with the comment “you might need this.”  I appreciated the link and enjoyed the reminder to live life to the fullest, especially with regards to keeping in touch with friends and loved ones. I also realized that my friend didn’t understand that for me the long hours I put in are all about fulfilling my dreams of creating new technology and impacting the world in a positive way. According the article, not chasing after dreams is people’s #1 regret.

Continue Reading »

Cashing in on People’s Financial Inexperience

Posted October 7th, 2010 in Observations by Greg Bayer
                     

Payday Loans

There has been a lot of coverage in the news lately about payday loans and check cashing services. They routinely take advantage of people in hard financial times, charging them interest and fees up to 300% per year. Because of the predatory nature of these services, there has been a strong push for legal oversite.

But these types of predatory practices are much more widespread than one might think. Consider credit cards. The way a credit card company makes a lot of money is when someone can not afford to pay off what they charge and must maintain a balance for an extended period.

Large car manufacturers are also in the game.   Continue Reading »