Making Time for a Side Project Using a Commitment Device

My team is getting used to my style and attitude about work. One core value I believe in is making time for other work (that’s relevant to one’s career) outside of the normal velocity of a sprint to accomplish additional learning or work. If you have a chance, take a look at my presentation about PTOn which is about applying a commitment device (ie: scheduling of time for Paid Time On) to ensure that the work is accounted for and is not disruptive to a team’s work velocity.  

A really good friend of mine (David Hafley) sent me this article today which is directly in line with my presentation about PTOn (Paid Time On). Teams (and individuals) need time to work through a work problem (project of role) or a problem that could yield incredible inspiration (project of passion). The challenge that I see with software development (engineering teams in general) is that teams focus on scheduling every ounce of time imaginable. If the team has 12 months in a year and they follow a 1 month velocity, then they have 12 units. The same applies to a 2-week velocity in which the team works off a 26 unit schedule. What I’m really getting at is that software teams tend to build utilization models that account for work and vacation. Occasionally, these work models account for training or an off-site. You get my point which is teams tend to over-schedule their team members like they are a bunch of Carbon Based Units.

CBLF meaning - what does CBLF stand for?

If you read the article closely, you will see it emphasizes creating “personal time” which I personally find difficult. I have a wife, kids, hobbies, etc…I will agree that finding personal time is important, but in the same grain, I would suggest that in the 40+ hours we spend at work (some 60+), we need to “find work time” for learning. 


Balancing Testing versus Measurement

One of the advantages of having a SAAS application is the ability to capture true production telemetry. This telemetry consists of functional and non-functional (performance and security) data points. These data points can be and should be optimized for use by our team to make us a more informed development team about the quality of our product. This by no means implies that live production metrics should be leveraged 100% in lieu of testing. There should be a balance of testing and measurement.


I covered my testing philosophy in one of my earliest blogs in which I stressed and advocated for the need for robust build/test pipelines complete with quality inspection (unit, static, integration and acceptance). This pipeline is nothing original or unique that I’m proposing. The pipeline is a component of Continuous Integration in which developers commit early and often. The pipeline grows in complexity and maturity in an iterative fashion with each day as the team’s commits becomes a robust product or module ready for deployment. Consider this early phase more of an incubation phase in which the product is nothing more than executable code, but not deployable ore useable. When code is being incubated, teams should be placing more emphasis on testing and evaluation. This testing is more Unit and API, not acceptance testing.


If the product is ready for acceptance testing, then the product is ready for a deployment (synthetic or production). If the product is deployed, then it should be measured with deep telemetry (dynamic analysis) such as RUM (Real User Measurement), APM (Application Performance Management) and ASM (Application Security Management). Artifacts such as log files and live telemetry from component systems (Queuing Systems, Ephemeral Caches, RDBMS and Non-Relational Structures) should be captured and used. Why…Because the data is there. Why ignore passive data that can be analyzed, captured and organized in an automated fashion?

I can’t really explain why the data often gets ignored. It simply does because so many development organizations focus on the discrete activities of testing. They often fail to capture the more meaningful data that comes from embedded telemetry into the development process. That same telemetry data that can be captured in the testing process can be captured from live production systems. It’s like a golden egg that gets laid every day. The team has to take advantage of this goldmine of data.


I had the chance to talk with Badri Sridharan from LinkedIn about a year ago. Badri and I both ran Performance Engineering practices in our careers. We were exchanging perspectives on the current and future of Performance Engineering. During the call, Badri shared insight into a system called EKG that the Development and Operations teams introduced at LinkedIn. The blog was written by the Operations team, so it shows a lot of infrastructure data points visually. If you look toward the bottom of the blog, you will see the reference to exception counts and a “variety of other metrics”. Those other metrics as Badri explained are functional verification data points. Teams at LinkedIn can get live production data for their Canary and A/B deployments before they promote code throughout the whole system

EKG compares exception counts, network usage, CPU usage, GC performance, service call fanout, and a variety of other metrics between the canary and the control groups, helping to quickly identify any potential issues in the new code.

I’m still learning what telemetry exists in our systems right now. I’m eager to hear from all of our teams about what data is captured, where it is stored, how it’s made actionable and how the data is brought back into the development process. 

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. 

It’s Not Goodbye, but See You Later…

I’ve never been one for goodbyes over the years, so I will leave you with a blog of hope that one day we will see each other again. We might be working together away from Blackboard or maybe one day I will come back. I just don’t know…What I do know is that for this blog I’m going to cover some parting words that hopefully will resonate with my reading audience. I’m hoping it will ignite some kind of spark and make an impact on the future.


When I started the Performance Engineering team in the fall of 2003, I set out on a mission to make Blackboard the fastest performing, most scalable e-Learning software platform in the world. I wanted us to be the benchmark in the software space, where companies look at us lovingly in the distance with deep admiration and respect. That leads me to my first major point…


1) Set high expectations for yourself and your teammates…Do what you can to achieve them.


There were a lot of things I wanted to accomplish when I came to Blackboard, but the one thing I knew I didn’t want was to fail. I came here in my late twenties. I was a mere child in terms of professional experience. I was being entrusted to build a multi-million dollar team for a $100 million dollar company that wanted to go public and become a $1 billion dollar company.


Our CEO, Michael Chasen had high expectations for me, therefore I needed to set higher expectations for myself and the team I was building. Setting expectations is really about setting goals and then being transparent about those goals. Achieving expectations is about being both strategic and operational at the same time.

You don’t have to have 20+ years of experience to be successful in any venture. You have to be smart, committed and resilient. The smarts come from planning, researching and my personal favorite, continuous learning from experience. The commitment is about execution to plan, as well as a willingness to re-plan after learned mistakes. The resilience is about perseverance when times are challenging.


2) Every day is a benchmark


I wrote a blog back in June of 2007 to my team about the importance of seizing the moment. Unfortunately, the blog was internal and I never posted it. I was half correct with the blog. The part I nailed was the part that insisted every day is a chance to start over. Every day is a chance for a new beginning.


I missed an essential part which looking back could have and should have fundamentally changed our team’s purpose. It was an aha moment that if I could do it all over again, I would totally have done it differently.


The focus of that blog was about testing and benchmarking. In 2007, we were a very good testing and benchmarking organization. Some in the industry might have said we were one of the best given our maturity, practice and tooling. We should have looked at all of that production data real-time and built an analytics engine that studied live system data. That was the real data we needed more than anything. I’m not talking volumetric sampling. I’m talking APM (Application Performance Measurement).


We should have built the collection tools and engine to process the data. That would have been disruptive. It would have been game changing. We didn’t and as a result we failed to reset expectations and learn from our past experiences.


3) We cannot change the cards we are dealt…we can change how we play the hand


I don’t know the original author of this quote. The context for me is hearing it back in 2008 watching a YouTub clip of Randy Pausch giving his famous Last Lecture. I think I watched that lecture a dozen times. I bought the book and read it over and over as well.


That quote has been in my head constantly for the last few months as I’ve been deciding whether to leave Blackboard or stick around. I’ve thought about it in the context of my 11 years here. I realized over and over again me and my teammates were dealt blow after blow. Some of those blows were good…some were bad. Rarely did anything we as a group planned happen in a natural order. More often than not we found ourselves treading water or playing a defensive game of ping pong.


We got through it all. The way we got through it all was being adaptive and willing to change our plan.


Blackboard will hopefully outlive me for many decades to come. The folks who are a part of the future, will hopefully adapt like me and my colleagues adapted over the years. Looking back, that’s what made this place so special. There was a simpatico ebb and flow to change on the fly. Hopefully the people and the company won’t forget that going forward.


– Steve Feldman

Blackboard (2003 – 2014)