Monthly Archives: August 2014

Why I Blog

From time to time people ask me why I blog. The best way for me to answer this is to give you the quick elevator pitch, as well as refer you to a passage from a blog I wrote back in 2008 below. I started blogging internally and then externally when I realized that there was a potential audience of listeners. It wasn’t just about being heard. When I say listeners, I mean people who were curious about my work, my team’s work or the things that we as a team came across. 

In the early days I used my blog to tell a story about a forensic exercise, a tool evaluation, an idea I had or even some deep intellectual stuff. I wanted a quick and easy way to document my own experiences in a scratchpad. I was really hoping that by me blogging, it would become contagious and others on the team would start blogging.

I was trying to break a bad habit in my engineers. I noticed my engineers treated knowledge sharing as the final exercise in a project. It was kind of like their code commit patterns. Back in the early 2000’s the developers I worked with were really unpredictable in committing code. We would have month long projects and often we would see commits 1x or 2x a week (if that) and then a couple big commits at the end of the project. Documentation would come in the same cadence. Maybe we would see a TOC early in the project. Then all of the content would miraculously show-up a week or two after the final commit (if we were lucky). I constantly felt in the dark about our progress and issues. The only time I really heard from my engineers was when they were about to miss a deadline and needed an extension…or if they wanted to share a success. What I really wanted was for my engineers to show their work as they went along. I wanted their work to be more transparent. Basically, I wanted them to develop some new good habits. 

What I found quickly was that blogging was contagious. Nearly every member of my team took to blogging. Eventually they took to daily commits (some even more extreme…YEAH!!!). At Blackboard, we were considered not only the most transparent team, but often considered the most innovative. Many of our blogs were about experimentation and exploration with new technologies. Because we also shared our thoughts, processes and workflows (we just put them out there for all of Bb to criticize or commend), many teams viewed us as pioneers in thinking. 

As I mentioned earlier, I posted a blog in 2008 about Transparency of Work. I’ve included a passage below from that entry. My thoughts in 2008 haven’t really changed all that much in 6 years. Take a look at the entry. Hopefully, you will start blogging as well.

Old Blog Post

Seven Habits of a Highly Effective Performance Engineer

This is really an extension of #3 Share Your Experience. For this point, I want to share a quick story. In high school, I had a Math teacher named Captain McIsaac. My high school was originally a feeder school for the Naval Academy, Coast Guard Academy and the Merchant Marine. So we had a lot of older teachers who used to be former Navy. Well anyways…Old Cap McIsaac was an interesting guy. He looked like Ted Kennedy’s twin and probably scored the same on most of his breathalyzer tests. He was a terrible Math teacher. Most of us thought he was awesome because he would give us the answers to the questions on our exams during an exam. We never had to show our work. That’s great for kids who cheat off each other. I have to admit…looking back the guy was terrible. He didn’t hold us accountable for our work. It showed in all of my Math classes after Cap’s class. I did well because I love Math, but it takes an awfully long time to break bad habits. You can pick-up a bad habit in seconds, but it takes weeks…sometimes years to break a bad habit.

There’s an important reason for showing your work…actually there are multiple. The number one reason is so that you personally can spend the time reviewing what you did and explaining it to your peers in a visual manner. Don’t worry if you change your ideas…you just write new blogs. The second reason is that we are a global team. Everyone on the team should get the opportunity to learn from other members of the team. It’s a good way to get feedback and share work. The third reason, which is sadly a bit lame is that our days become so busy, that sometimes we need to be able to comment on a blog rather then having a conversation or email thread.


Code is a Team Asset and Not Personal Property


“Code is a team asset, not the personal property. No programmer should ever be allowed to keep their code private.”


I just finished this book this morning. I’ve been reading it the past 5 rides into the office. It’s a quick read and one any manager (new or experienced) should read. If you read my entry about transparency from earlier in the week, you probably get a sense that I’m a firm believer in openness and sharing. High-performing teams more often than not are very open and sharing. They put their thoughts out there in person, as well as in written form. They expose their artifacts, whether it be code or content, to be viewed, critiqued or commended on a continuous basis (daily being the longest cadence). 

Software teams that want to practice Continuous Integration have to think like Osherove suggests about their code. Developers have to be willing to commit often knowing that the code they produce for their product or project is not their own art that they can keep protected on their laptop or even personal Github account (I’ve seen this happen over and over mind you). If they are contributing code to a product or project, then they have to be willing to share and integrate their code ‘as frequent as humanly possible’.

Step 1 is changing perspective. I may have written the code, but the whole team owns it. If for some reason I won the lottery and left the company, the team is still accountable for the quality and functionality of that code. Step 2 is about creating the habit. The habit is to commit early and often. A commitment device that I would recommend is to setup a CI-server like Jenkins or Bamboo. Setup a job that pings our source code tree every 10s to see if something new has been checked in. Have that job do a simple compile. Eventually daisy chain steps like building, unit tests, static analysis, integration tests and eventually acceptance tests. Step 3 is about sharing your CI-server dashboards constantly in your team space and at the forefront of your morning stand-ups.

Give it a try…See what happens. 

Transparency…Training…Setting Expectations

I’ve been reading The Hard Things About Hard Things the past few days by Ben Horowitz. Half-way through there is an interesting chapter called “Why Startups Should Train Their People”. The chapter is essentially a replay of a blog Horowitz wrote that talks about Good Product Managers Bad Product Managers. You can see the story here. Personally, I think the chapter should be renamed to “Why All Companies Should Train Their People…Continuously!”

Thoughts About His Blog First…

As technologists, I think we take for granted the training of our engineers and scientists. We see training as an ‘exercise’ that is done during the initial phase of on-boarding an employee to a team or a new job. Rarely is it seen as a continuous exercise. Most engineer organizations miss it big time during the on-boarding phase as well. They may spend a fair amount of time training new hires to learn the corporate policies, processes and norms. A little bit of time is spent training the engineer to get going, but mainly from an access and peripheral perspective.

Most technical managers take for granted that training is something that should be part of a continuous exercise. Just because a software developer may have years of working with an IDE (Integrated Development Environment), a source code repository like Git or SVN and a defect tracking system like JIRA or TFS, doesn’t necessarily mean that they are good to go with simply a wiki document on how to get started. The good technical managers go through the experience together with their developers to make sure they are on the right course and that the little intricacies (rarely documented) are small bumps in the road to get started and be productive.

Training is more than just getting a development environment up and running. It’s about setting a standard and defining expectations around performance and commitment to one’s craft. It’s about sharing the norms of the team culture, demonstrating them first hand and then working as a team to highlight mastery or achievement of those norms. For example, if the norm of the team is to commit code daily and the value is for transparency of work and a dedication to a quality pipeline, then what should be trained are both the norm and the value to the new team member. I call that out, because often teams will bring on new developers and have several norms in place that are poorly communicated to the new team member.

I remember that when I was more focused on Performance Engineering, the first thing I had a new team member to my team or software engineer to our development organization do was read my blog on habits good performance engineers exhibited. It was only the start of training for being on my team. I felt it was my responsibility to training all of my managers. I didn’t train all of the engineers, but every manager had to spend a fair amount of time with me so that we were really clear on expectations, as well as setting the standard that I wanted my managers to uphold.

This isn’t a one-time thing either. I felt it was important that I continuously learn and share my experiences with my team. For example, we value good engineers not just because they write elegant, reusable code, fix bugs timely and share their work. We consider them good because their constantly evolving and learning through experiences outside of their daily assignments. They are working on Open Source projects, learning new languages and collaborating with industry peers. We call them good because they are growing. The same holds true for good managers. They don’t do a set of tasks real well and repeatedly do them well. They learn about new things, technology, practice, process, etc…they experiment, share and incorporate. 

About the Article

I think anyone can replace the role or “Product Manager” with any job they want to insert. It could be “Budget Analyst” or “Software Architect” or “Release Engineer”. It really doesn’t matter from my perspective. What matters is the forethought about the beliefs Horowitz feels make up a good versus bad product manager from his own ideology lens. I don’t necessarily agree with every statement that Horowitz writes, but I do agree with the thoughts that expectations should be set. Managers and team members cannot just share the “expected” norms to a new team member without sharing the norms that detract from the team’s culture and success in the role. Being able to share both positive and negative norms are critical to establishing a stage of transparency for the team.

Ben Horowitz: Good Product Manager…Bad Product Manager

Good Product Manager/Bad Product Manager

Courtesy of Ben Horowitz

Good product managers know the market, the product, the product line and
the competition extremely well and operate from a strong basis of
knowledge and confidence. A good product manager is the CEO of the
product.  A good product manager takes full responsibility and measures
themselves in terms of the success of the product. The are responsible
for right product/right time and all that entails. A good product
manager  knows the context going in (the company, our revenue funding,
competition, etc.), and they take responsibility for devising and
executing a winning plan (no excuses).

Bad product managers have lots of excuses. Not enough funding, the
engineering manager is an idiot, Microsoft has 10 times as many engineers
working on it, I'm overworked, I don't get enough direction. Barksdale
doesn't make these kinds of excuses and neither should the CEO of a

Good product managers don't get all of their time sucked up by the
various organizations that must work together to deliver right product
right time. They don't take all the product team minutes, they don't
project manage the various functions, they are not gophers for
engineering. They are not part of the product team; they manage the
product team. Engineering teams don't consider Good Product Managers a
"marketing resource." Good product managers are the marketing counterpart
of the engineering manager. Good product managers crisply define the
target, the "what" (as opposed to the how) and manage the delivery of the
"what." Bad product managers feel best about themselves when they figure
out "how". Good product managers communicate crisply to engineering in
writing as well as verbally. Good product managers don't give direction
informally. Good product managers gather information informally.

Good product managers create leveragable collateral, FAQs, presentations,
white papers. Bad product managers complain that they spend all day
answering questions for the sales force and are swamped. Good product
managers anticipate the serious product flaws and build real solutions.
Bad product managers put out fires all day. Good product managers take
written positions on important issues (competitive silver bullets, tough
architectural choices, tough product decisions, markets to attack or
yield). Bad product managers voice their opinion verbally and lament that
the "powers that be" won't let it happen. Once bad product managers fail,
they point out that they predicted they would fail.

Good product managers focus the team on revenue and customers. Bad
product managers focus team on how many features Microsoft is building.
Good product managers define good products that can be executed with a
strong effort. Bad product managers define good products that can't be
executed or let engineering build whatever they want (i.e. solve the
hardest problem).

Good product managers think in terms of delivering superior value to the
market place during inbound planning and achieving market share and
revenue goals during outbound. Bad product managers get very confused
about the differences amongst delivering value, matching competitive
features, pricing, and ubiquity. Good product managers decompose
problems. Bad product managers combine all problems into one.

Good product managers think about the story they want written by the
press. Bad product managers think about covering every feature and being
really technically accurate with the press. Good product managers ask the
press questions. Bad product managers answer any press question. Good
product managers assume press and analyst people are really smart. Bad
product managers assume that press and analysts are dumb because they
don't understand the difference between "push" and "simulated push."

Good product managers err on the side of clarity vs. explaining the
obvious. Bad product managers never explain the obvious. Good product
managers define their job and their success. Bad product managers
constantly want to be told what to do.

Good product managers send their status reports in on time every week,
because they are disciplined. Bad product managers forget to send in
their status reports on time, because they don't value discipline.


Who Are Your Tech Role Models

This is kind of a fan-boy post and I’m hoping I get some discussion or follow-up blogs from my colleagues. I would like to use this blog to talk about a few my role models in technology. I encourage anyone who comes across this blog to put their list out there for themselves. For my list, I’m going to cover four of the technologists I look up to for guidance and direction. I consider them my north star of technology. All have a background in software performance. Each are engineers at heart. They have built product, systems and architectures. 

Tech Role Model #1: Cary Millsap

My list is not in any particular order by the way. If I did order it, I would probably put Cary #1 anyway. I first read Cary’s book Optimizing Oracle Performance in the fall of 2003. I was about to leave my job as a Performance Engineer at Manugistics to take on a new job as the Director of Performance Engineering at Blackboard. I think I read Cary’s book cover to cover 3 times over the course of a 10 day period. His methodology, which he calls Method-R (also the name of a company he created) was the most pragmatic and practical approach to performance forensic analysis any other engineer had presented in last 10 years. I followed Cary’s career from Hotsos to Method-R to Enkitec to Accenture. 

I attended multiply Hotsos Symposiums and even hosted Cary for a week long consulting engagement with my team. If I had to sum up why Cary has influenced me in a sentence or less, well it really comes down to the paper Cary wrote called Thinking Clearly About Performance. In a little less than 15 pages, he’s able to distill my entire career of beliefs and practices about software performance. 

Tech Role Model #2: Steve Souders

I first met Steve Souders formerly of the Yahoo Exceptional Performance team in 2008 at the first Velocity Conference. He was the public face of YSlow and one of the first engineers that I had the experience with in the industry looking at performance from a cognitive experience. In my early years of performance engineering, I had been focused on the throughput and processing times of algorithms. When I moved to Blackboard, my attention shifted from server and database to a complete full-stack including the client. Steve and his team really distilled front-end performance first. He was a true pioneer.

I’ve met Steve many times at various conferences. We have exchanged a couple of emails over the years as well. Like Cary, he appreciates his community of followers and welcomes the attention. The good thing is that he doesn’t seek or crave the attention. He takes it in stride. These days, Steve is no longer with Yahoo or Google. He’s moved onto Fastly as their Chief Performance Officer. The fact that a company has a Chief Performance Officer is a testament to Steve. 

Tech Role Model #3: Adrian Cockcroft

Adrian Cockcroft was one of my earliest performance engineering heroes. He worked at Sun Microsystems back in the late 90’s and early 2000’s in various roles. Back in 2002, I worked on a competitive benchmark with him and the Performance Engineering team at Sun. I was a like a kid in a candy shop. Looking back I probably didn’t appreciate the opportunity I was granted and the access I had to him. Like Steve and Cary, what makes Adrian special is not some insane degree of intelligence. Though Adrian is ridiculously smart. Rather, it’s pragmatic and practical thinking. Performance Engineering is an engineering discipline based on decomposition of time, demand and inertia. Smart, critical thinkers succeed.