Book Review Time: Someone Could Get Hurt

I personally don’t know Drew Magary, but I’ve been a big fan of Drew for quite a while. I read his witty and always awesome articles on Deadspin as fast as he puts them out…follow him on Twitter and of course, since I’m a probably a stone’s throw from where Magary lives I listen to him from time to time on the Sports Reporters, on our local ESPN radio network. Magary never disappoints in any medium, though my preference is to read his articles as they are as vivid as a blue sky night. He says the things that guys like me are thinking...you know in their late 30′s with a wife and a couple of kids…but will only joke amongst the guys, my wife or occasionally a co-worker or two after knocking back a few beers.

When I first heard that Magary was publishing a new book about the challenges and tribulations of being a husband and dad in the 21st century, I immediately signed up on Amazon for a pre-order. I didn’t even have to read a review or a hear Magary pitch his writing online or on the radio.

My kindle version was available about a week ago Thursday, which I immediately pulled down. Heck, I live about 10 miles out of DC. The Caps lost again in the first round. The Wizards perpetually stink. The Nats and O’s were amidst losing streaks. I was pretty much tired of listening about the progress on RG3′s knee. Reading Magary’s book was a no brainer.

Let’s start off with the logistics. It’s a quick read. Since it’s on Kindle, I don’t know the exact paper pages, though if I got off my fat ass and looked on Amazon, I would know that it’s 256 pages of pure humor and bliss. I probably could have read it cover to cover, but let’s face it…like Magary I have 2 kids of my own. So I’m not littered with hours and hours of free time on my hands to read a book un-interuppted. I split my reading across 4 or 5 sessions right before bed and while I was waiting with my pre-schooler for her school to start after dropping off my first grader.

Magary bookends his tales of parenthood with a really serious story about his third child born premature and dealing with a major intestinal issue. I didn’t face the agony of premature childbirth like Magary and his wife went through, but my first daughter spent 2+ days in an incubator under the billyrubin lights. Definitely small potatoes compared to what Magary and his wife went through. In between the chapters there is endless delight and humor about the foibles and challenges that Magary went through in raising his oldest daughter and middle son.

My favorite chapter was definitely the story about his daughter’s first halloween. Magary appropriately labeled the title of the chapter “Slow Guy” mocking a sign he and his wife put up in front of their house to slow traffic down from speeding on his street. As most people would conclude, there’s always an ulterior motive in anything Magary does…so the costume was definitely a cheap, yet funny joke. Kind of reminds me of the time I was in my early 20′s and I thought it would be hilarious to dress up like Warren from There’s Something About Mary. As you could probably guess, most people didn’t find me too funny unless they were obliterated or high. It didn’t hit me that my costume was completely insensitive until the morning after…

I definitely could relate to so many of Magary’s stories. I remember the first time my oldest daughter said a curse word. My wife and I definitely dropped $200+ on the Lice Lady. I fight daily with my youngest about brushing her teeth. I have buckets of toys that my kids have thrown aside like a dirty rag doll. Sadly I miss each passing phase my daughters go through as they get older. It makes me want a 3rd kid from time to time.

Things or stories I wished Magary had written…god knows he’s probably got loads of material about these topics:

Wine Drinking Wives: My wife loves wine. It was definitely not her go to drink before we had kids. That would be a captain and coke, an occasional Cider or a giant swig from a bottle of Champagne. Since having kids the consumption of wine by my wife and nearly every mother of 2+ kids I know makes wine their afternoon delight.

First Kiss: I nearly crashed my car the time my 6 year-old told me she kissed a boy. My immediate response was “where” in hopes of finding out if she kissed him on the lips or some other body part. Her innocent answer was “at school” and the location was the eye brow.

10 Hour Road Trips with Your Wife and Kids in the Mini-Van: The picture below is taken from my recent road trip to Kentucky last Labor Day. This is apparently what they keep in bathrooms and rest stops in West Virginia. I definitely heard banjos…

Shots at the Doctor’s Office: Magary talks about his youngest getting needles poked into his body, which was sad and certainly not intended to be funny. It would have been great to hear a story like the time my wife called me to meet her at the pediatrician’s office. Our oldest, who at the time was 2 had the lead test on her finger. According to my wife it was like a scene from the Exorcist with spinning heads and blood everywhere. Once I arrived at the doctor’s office, it was my job to pin her down. I’m a modest 210 lbs and my daughter may have been 30 lbs at the time. She had superhuman strength that day…

St. Patrick’s Day or Cinco de Mayo: It’s like a right of passage to take your first born to a bar on some amateur drinking holiday like St. Patrick’s Day, Cinco de Mayo or Flag Day. I remember the first time I took my kid I did the obligatory baby bjorn with beer in hand move.

Crazy Art Work Your Kids Bring Home: I can’t tell if this was a death threat from my kid or her finest winter snowman. Either way I might have dozens of skull art like the one below…

Note to Drew…you only get 1 shot I guess at writing a book about parenthood, that is unless you are Bill Cosby and you forgot that you wrote the same book three times before. If by chance you do write another book of similar genre or better yet using the same tone and writing style, you definitely have a reader and supporter in me…

- Steve

Why The Mechanical Turk Just Doesn’t Work

I’m on a tear these days talking about my frustrations with offshoring versus outsourcing. By tear, I mean I wrote one blog a few weeks back so in the natural law of thinking that makes me a pseudo expert of sorts right? Well maybe not an expert, but I do have over 12 years experience working with outsourced teams and about 7 years working with offshore salaried teams. There is no jury to be had. I can pretty much tell you that I’m siding with offshore salaried teams over outsourced contractor teams ten times over. I’ll throw in “Sunday” just for grins. Those who know me often joke that I mix-up figures of expression all of the time, so why not do it in this blog.      

Let me start off by saying I have a problem. I know I have a problem and sadly I and my teammates created the problem. We didn’t mean to create the problem. In fact, we had the best of intentions when we set about our work. No matter how we look at it, we created the problem. 

It all started back in 2006 when my company made a big acquisition. We ended up acquiring our largest competitor at the time. I was given some investment to make use of some outsourced resources from a service provider in India. I won’t use their name, but I’m sure if you look through some of my past blogs you ‘may’ be able to figure it out. We brought on a small team of two engineers. They came to my office in Washington, DC. I even had them sit in my personal office, which at the time was small and uncomfortable. It didn’t have good air ventilation or air conditioning for that matter. It was a room with 4 walls and a white board. That kind of sucked for me, but the two guys were used to rolling power outages and work conditions far worst than a humid DC summer in a stuffy office building. I brought in a fan…everyone was fine.

These guys stayed with me on-site for about 3 months. It was great as each day I really spent my time teaching about Performance Engineering which is by far my absolute favorite topic to teach others and talk about with others. Even though these guys were contractors, I treated them like they were teammates. Heck, they sat next to me for 90 days, how could I not. When the 3 months were over, they went back to India and we continued the working relationship remote. These two guys were great as one stuck on our team for two years and the other stayed with us for 3 years. 

 

Over time we would add team members. I think at one point the team got as big as 7. Today it’s 4 which has pretty much been the sweet spot in terms of what my North American team could manage day to day. Having 7 teammates remote is tough unless you have good leadership. The best leadership we ever got was with those first two teammates. You can tell from that last statement that after year three, everything went downhill. I’ve been thinking a lot about why this outcome of a struggling contractor team has been. The obvious is that these teammates are/were contractors and not officially part of our team. While we try/tried to make them feel as though they are/were part of our team, their solidarity is/was with their own company. They go to their company’s headquarters. They have bosses in India and only points of contact in the states. It’s not like I give them raises or bonuses. I tell them good work or you were awesome today. That’s basically it… I’ve been able to narrow down three reasons in greater detail as to why this model of offshore contracting has been unsuccessful for me and my team. 

The first and obvious is the difficulty to find good leadership to run the team’s day to day operations on the ground. The most talented resources who can do this are identified and hand-picked very early on by these large professional services companies. They become good candidates for on-shore work because they have good presence and can represent the company better. I could be totally off-base on this comment as I’m really only basing this conclusion on about five teammates I’ve had over the years that left our team in an offshore capacity to find work onshore. I am pretty confident that a sample size of five is pretty strong statistically so I’ll stand by my argument.

Second is that I’ve found that many of my contractors took a position in consulting because they wanted the diversity of changing projects. That’s not what I want or need from my consultants. I need a consultant who’s going to stick with my team for many years and advance their career and pay on our team. I need someone who doesn’t get bored after two months on a project. Financially it’s still more cost effective for me to have this kind of model because I can cut overhead costs and still have a team member that can stay long with us. That doesn’t happen in this world of outsourced and offshore contractors. You really are lucky to have someone stick around for a year. If you are really lucky you can keep someone around for 18 months. If someone stayed longer than 18 months it has a negative affect on their resume and future job prospects. It’s like a budding young wannabe NBA start who hasn’t declared for the draft by the age of 4. By 5 years-old you over the hill. So you better declare for the draft by the time you know how to tie your shoes before you become stale and old. That’s the same deal here in this part of the world in the land of consulting. 

The third problem is something that me and my team created. Many years ago we started this automation project we called Fusion. We put a front-end UI on it called Galileo. It’s been a huge asset for our team. Maybe one day we might even open source the code and give this stuff away for free. As we were building this, I remember one of my DC engineers joked and named it “Automaton” to reflect how it could potentially make all of our teammates into robots. Awkwardly, I think he felt like it would open up the doors for us to replace staff with robots. That was never its intention. The intention was to make our business processes more reliable, timely and predictable. Most importantly it was designed to make our team scale without having to make loads of investment in resources.

 

 Galileo has been an incredibly successful project for my team. I am very proud of it and the team that has spent years building, maintaining and promoting the platform to others at my company. What has happened with my outsourced contractors is that they lost their way of contributing to the team in a meaningful sense. They used to be adequate performance engineers. They used to spend time digging into issues. They used to do more work sadly. With Galileo, the team has had a propensity to become push button operators. When Galileo has a problem they stop working like a bunch of office workers when the Internet is down. They have turned themselves into Mechanical Turks. 

“Bummer…looks like the Internet is down. Let’s go to Starbucks, get some coffee and smoke a couple of cigarettes before Phil in IT resets the switch and we have to get back to work!”

 

I’m not talking about Amazon’s Mechanical Turk program when I talk about my contractor team. Heck if I used Amazon it would be a whole heck cheaper, but all I would get are fake twitter feeds, email spam and blog comments. The term Mechanical Turk came out of the late 18th century in Europe. Someone had invented a fake chess-playing machine to impress some royalty in Austria. It was all an elaborate hoax based on a human chess player inside of the machine making moves via magnets. The robot itself was a lifeless puppet that would make the moves required by a master chess player hiding in the box. 

I’m not saying Galileo has become a hoax. It’s not at all. I am saying that the team (our contractors) who primarily interact with it have become mechanical turks in their own right pushing buttons and watching spinning wheels and status pages as they wait for tasks to complete. They completely lost their priorities. The whole vision behind Galileo was that it would do all of the repeatable, brute force work in an automated fashion. It would do all of the work that the contractors had historically performed years back. It would create “opportunities” for the team to become better chefs in our kitchen. They could assemble Galileo templates like recipes and do some cooking. While the cooking was happening, they could do more analysis of performance issues. Unfortunately that never materialized. Rather than becoming better performance engineers, our contractors turned themselves into pushbutton operators. They knew how to do one thing well, run a test. It didn’t matter that the machine was running it for them. 

You Can’t Have it Both Ways: Offshoring Can’t Be Done via Outsourcing Companies

So the title of this blog most likely yields a giant “no kidding” response from my loyal readership, which is totally expected. A few of my teams work with an offshore consulting company. I won’t mention them by name, but I will say that they are big enough and global enough that most people in and out of the tech circle know who they are. Like most offshore companies they have their marketing propaganda that breaks down their value by industry vertical, area of specialization and global presence. They gloat about their amazing “Centers of Excellence” which differentiate themselves from their competitors. News flash…nearly every global consulting firm touts a Center of Excellence, which is code for “Sometimes we show customers a room with computers, monitors and white boards. This room is where all of the magic and innovation of INSERT MAJOR SKILL HERE happens.” Of course we all know that these CoE’s are just marketing fronts that really don’t exist.

Today I read an email from one of our contacts of this offshore service provider informing me of not one, but two team members who are “moving on to greener pastures”. This has been a theme for us now for roughly two years. Back when the economy was tanking in 2007/2008 we agreed to expand our investment in this firm. We made it clear that we were not outsourcing an entire responsibility, but rather extending our team through third-party team members overseas. The service provider wanted our business and made it clear that they would be able to help us find and retain talent. We agreed that we would do our part to invest in the skill set and agree to incrementally increase compensation. If at any point we were at risk of losing a team member, the 3rd party would do its part to shadow resources and seamlessly replace the team member who left via attrition.

Well as I said, the last two years haven’t been anything like the first four years. We have had more folks come in and out of the team that in the previous four years combined. In this particular part of the world, job jumping has returned to Silicon Valley like conditions in 1998/1999. We are lucky if we see a teammate come on-board for 8 months without either the threat of leaving or actually picking up and leaving. For a while I thought it was us that was the problem. I thought it was our work. I thought it was compensation issues. I thought it was quality of work life balance. For the most part I know that we do our part to address what we can control: the type of work, conditions of work and the opportunities for learning. We have little control over compensation, though we push our 3rd party service provider to address promotions and role leveling on a frequent enough basis that I am confident we influence each team members position and standing in their organization.

Don’t get me wrong…we have had issues ourselves. Forces above me have influenced contract pricing. We have fought rate increases and expenses. The folks on our business side definitely see the relationship as pure outsourcing (professional services) and not offshoring. They are right to do so as this 3rd party company deals with all of the headaches that I and my company don’t have to deal with these headaches.

The lesson here is that you can’t have it both ways. You really can’t use an outsourcing company to act as your offshore team, no matter how each of you spin it to the other. As the recipient of the service, you have to maintain a vested financial interest in your offshore team. You have to be able to directly influence the culture of the organization and not just the team. You have to be able to influence the quality of work/life balance and conditions of work. While controlling the type of work and norms of the team is important, it’s not the same unless you can also influence the organization. Probably the most important point is that your own organization has to view your team members who reside offshore as colleagues and teammates of the company. Just because they live in an another country with a different economic system doesn’t mean they should be inclined to a constant pay rate and salary.

Getting Face to Face with Culture

Five days a week I get up and prepare for 8+ hours in the office. I check my phone within seconds of my alarm going off. By the time I’ve brushed my teeth, ate my breakfast and gotten dressed for the day, I’ve likely responded to 5 emails and maybe 2 or 3 text messages. Shamefully, I’ll admit to looking at my phone during my drive. I rationalize it by only looking at the phone while at a stop light. Nobody’s perfect, so I’d be lying if I said I didn’t check it mid-drive. 

At work, even when in my office, I may look at my phone 150 times and not realize it. I’m always connected…always responding…always keeping busy. Saturday/Sunday are supposed to be family days. The same routine. I try to make as best use of the time as I can. When I do my household chores like mowing the lawn, weeding, mulching, painting, powerwashing, etc…I often listen to one of my favorite podcasts like Freakonomics Radio or the Ship Show. When I’m not playing with my kids, hanging out on the porch with my wife or playing golf, my absolute favorite past time now, you can find me on my Kindle or IPad reading Twitter feeds, TechCrunch articles or books on my active reading list. Usually I’m reading things that are relevant to work or golf or my kids. I’m using this time more wisely. Instead of doing work on the weekends and nights, I’m thinking about work opportunities and improvements during these times so I can be more effective when I’M ON at work, rather than making work always BE ON.
 

So where am I going with this blog? I’ve realized that I’m changing. The old Steve wouldn’t stop working. I wouldn’t stop to smell the roses from time to time to ask questions like “Are we having fun?”, “Are we improving?”, “Are we learning?” and most importantly “Are we providing value to our customers?”.

I’ve changed my behavior outside of work, sans email and texts, which I know I have to fix. Sometimes I put my phone on the floor of the passenger side so I don’t check email while driving. I still can answer calls thanks to bluetooth, but I’m a lot safer as well as those around me are safer because of it. I’ve realized I’ve had to change my behavior at work. I wanted to share a few of those things I’ve been doing…

First, I’ve realized that I’ve got a laptop, which means I’m portable. I’ve got the ability to work where ever…whenever. I try to work an hour a day somewhere other than my desk, but hopefully around others. It makes me wish that we didn’t have desks or offices, but rather big rooms with large communal tables. If only we had bean bag chairs and nooks built into the walls. Second, I’ve got to break bread with my teammates more. This week alone, I’ve eaten twice (it’s only Wednesday) with teammates. It’s a great feeling to get away from the desk to do this.

Third, if you ever have had a meeting with a pen, sticky notes and a wall…it’s quite engaging. I’ve had more meetings in the last 2 months with sticky notes, than the last 10 years combined. There truly is a power of stickies. Many of those meeting which might have been scheduled for 30 minutes went longer than scheduled. The key thing was that we didn’t look at the clock. We met until we were done being productive. Early on, I’ve had meetings that went 90 minutes over. Now I’m observing we are getting so productive, we finish meetings early.

The fourth and fifth points are of similar context. I find myself looking outside of my teams for new ideas. This includes other teams at my company, as well as talking with more technologists outside of my company. I’m more interested in picking someone’s brain face to face, rather than just reading an article or two and picking my own brain. Many of these conversations are mutualistic…it’s not just about me asking them questions, but sharing my own stories for them. The fifth point is I’m trying to get more people inside of my teams to share their own ideas. We try to have more ad hoc chats and idea sessions. We go for more walks one on one. We spend more time as groups at the board. We use stickies as I noted above.

All of these things are tackling culture head on, or at least I think they are trying to shape the culture of my teams and my organization. I’ve realized that culture isn’t about t-shirts, laptop stickers, happy hours…ping pong table (though we have one and enjoy playing). It’s not about some forced event where half of us are forced to share our thoughts and the other half sit quietly in the back…Culture is about who we are and how we want to act. It’s about our norms and values.

A Tester or an Engineer…It Shouldn’t Be an Either/Or

It’s 10:30pm on a Monday night. I just got off a skype call with a candidate for a position on one of my teams. The position is for a performance engineer. If you know me, it’s rare for me to hire someone on my performance team that has spent time as a performance engineer in the past. Maybe I’m a little biased, but nearly every candidate I’ve run across over the years that’s been a so-called performance engineer was really a performance tester in wolves clothing. 

Maybe I shouldn’t be so tough on other performance engineers. This candidate was another wolf in sheep’s clothing. His resume said performance engineer, but it read performance tester. I should have gone with my instinct and passed on the candidate.

So why am I being so hard on other performance engineers who really are performance testers? It’s not like I don’t see a place in the software and technology world. I do…I just have higher expectations. I think you should too…

I like my performance engineers to have a passion for reverse engineering. I want them to logically explain the execution of code from top-to-bottom. They should be able to explain the efficiency of one method call, routine, execution plan, etc…over another. They should have a passion for forensics and not just the show CSI. Forensics from a software performance perspective is about using quantitative approaches to measuring performance and scalability. It’s about balancing “Fuzzy Forensics” with more “Transparent Forensics”.

By “Fuzzy Forensics” I’m referring to data that can be used in an abstract fashion for correlation purposes. An example of a “Fuzzy Forensic” piece of data might be the output of a performance counter against the CPU or the GC output from a JVM log. The data can help narrow down the window of time, a resource constraint, a hotspot in the architecture or a bottleneck, but it can’t provide the depth of explanation to achieve root cause on a performance issue. That’s where “Transparent Forensics” comes into play…A good example of this might be Call Stack Tree, Heap Dump, SQL Trace, etc…The cost to obtain “Fuzzy Forensic” data is far less expensive than “Transparent Forensic” data. 

Back to my point…a lot of folks who call themselves performance engineers aren’t even thinking about forensics. The thought of measuring performance is foreign. I keep hearing this horrible broken record that measuring is done by the tool, whether that be LoadRunner, JMeter, SilkPerformer, SOASTA, Grinder, etc…That’s simply not the case. 

So why do I care? Here’s the thing…in all my years as developer and system engineer, I’ve been passionate about performance. I’ve been a practitioner of performance engineering for nearly my entire professional career. I perk up when I meet other performance engineers. Every now and then I get really frustrated when I meet someone who enjoys the various aspects of performance engineering, but doesn’t take it further. If anything, it’s a greater frustration with humanity for not being willing to challenge themselves to be omniscient in their field. 

It makes me think of this analogy of sorts. A bunch of kids are part of a high school track and field team. It’s a new program to the school and none have any prior experience with the sport. The school doesn’t have a lot of money so the kids mainly practice their events on a grassy field behind the school. The kids have a lot of success practicing. Some of the kids are separating themselves as the truly talented team members. While others are simply improving day by day with personal bests in their events.

After several weeks of steady improvement they go to their first meet against a series of local teams. It’s an invitational of sorts. All of their meets are away as they have no facilities to host a meet.

The kids show up to their first meet and step on the track at the stadium. Nearly all of the kids are in awe. They hadn’t seen a track so nice. Remember they were used to practicing on a grass field behind the school. The first race was a total disaster. Only 1 person scored a single point, the one shot-putter. 

The kids who were considered fast by their teammates, finished last behind every other runner from the other schools. None were prepared for the terrain. None were prepared for the technology. The kids left the meet pretty discouraged.

The next day in practice, one of the kids suggested that they consider running on the pavement instead of the grass. Another team member suggested that they go to another public school on the weekends to practice. Another member suggested that they change their uniforms from t-shirts, shorts and jogging shoes to more aerodynamic outfits.

These were the kids that picked up on the visual clues around them at the meet. Some of the kids didn’t buy the hype. They wanted to continue practicing on the grassy field. They wanted to  wear their normal uniforms. They didn’t want to practice on the weekends. These were the kids who didn’t grow all that much.

The next meet yielded better results. Rather than being embarrassed with only 1 point, the team scored 20 points. They even had a contestant finish in the top-2 for their event. The talent wasn’t any worst. In fact, it was the same teams from the previous meet, just at a different location. The kids who picked up on the visual clues were the contributors to the team’s success. 

The difference from 1 point to 20 points was learning was happening. The kids who were scoring points understood that the environmental conditions they practiced against were very different from the environmental conditions they raced. They had to be both visually aware and perceptively aware. Essentially they had to do more than just adapt. They had to evolve. They had to be able to reason. They had to survive. They had to trust their own instincts and observations. Most importantly they had to change.

I think this is one of the greatest threats facing performance engineers today. The good performance engineers realize that they have to constantly learn. They have to challenge their process, not in a confrontational manner, but in a socratic manner. 

The really good performance engineers get better with each day.

Book Review of the Phoenix Project

Back in February I wrote a blog about how Amazon recommended the Phoenix Project about five minutes before I walked into Mike McGarr‘s office only to realize he was reading the book himself. I ended up reading the book, now twice cover-to-cover and I’m ready to share my thoughts…

I don’t know if I’ve ever really given a book review in the past. I know over the year’s I’ve recommended books like Seth Godin’s The Dip, Malcolm Gladwell’s Outliers and Blink, as well as Chip and Dan Heath’s Made to Stick or any of the Patrick Lencioni books, though my favorite was Three Signs of a Miserable Job. What I’ve come to realize is that I like books that are relevant to career, survival, instinct, etc…that are presented as stories. The stories can take different formats. Patrick Lencioni and Gene Kim (Phoenix) tell their stories as fictional narratives with underlying business messages. Gladwell, Heath and Godin tell non-fictional, mini-stories about real people to relay their points. I’ve come to conclude I like both styles. I’ve also come to conclude that I don’t like books that read like college text books. None of the books above read like a boring text book 

Why You Should Read This Book

Let’s cut to the chase…I think you should read this book because it’s a riveting story that 99.99999% of all people not living under a rock can relate to. You don’t have to be in technology, manufacturing, business, etc…to find a kinship with the characters and storyline of the book. If you are reading my blog, most likely you are some form of technologist, whether that be a software developer or engineer. So this story will resonate like no other. You will find yourself associating character’s with real people from your own life experiences. I found myself chuckling over and over as I realized that I experienced or am experiencing (present day) many of the same challenges that the protagonist, Bill Morris and his team were facing.

I also took a lot of notes and performed a lot of reflection. I quickly realized that over time I managed to become quite complacent with my own work and the work of my team. I had a lot of in-flight work. I had no controls in place with regards to accepting work. Priorities were managed by who screamed the loudest. I kept asking myself, how in the world did we ever get any work done?

What I Learned from the Book

There are a ton of underlying themes and messages in the book. I took a few key points away from the book. These points ranged from knowing the origins of my work, controls of work being accepted or rejected, the flight/progress of work, prioritization of work, continuous improvement (kaizen) and the relevance of practice of work (kata). I’ll cover the three most important below.

Origins of Work
Work needs to be better categorized from where it’s coming. Work that comes from a customer or key stakeholder has different controls than let’s say a self-created initiative. The author’s call-out four types of work: Business, IT Operations, Changes and Unplanned work. It’s that fourth type of work (unplanned) which is the silent killer to a team. In my own work scenario, I’ve narrowed down work to three types: External (Client), Internal (infrastructure) and Unplanned.

Controls of Work
I’ve never gone so far to create a process for work to be accepted or rejected. I’ve definitely rejected work in the past, but never a formal process. What I didn’t realize that by not having a formal process for accepting work, it creates a high-degree of chaos in terms of a backlog of work. The stuff just keeps piling up until it gets done. When work piles up, priorities get mucked.

Work in Progress
The biggest take-away thus far for me has been an interest in learning about Kanban. All of my teams are using a Kanban tool, essentially a board that visualizes work, queues up tasks and acts as a pull-based approach in which we pull work in to the group. This comes as a result of the controls of work being put in place. We can visualize our actual WIP (Work in Progress). We have awareness of unplanned work (which takes a long time as it requires 100% transparency). We can help each other prioritize the work of the team.

What I’m Reading Next

I have two books that I’m actively reading. The first is The Goal by Eli Goldratt which is eerily similar in genre to this book. Goldratt’s Theory of Constraints is referenced constantly throughout the book. The second is Kanban: Successful Evolutionary Change for Your Technology Business which is more of a HowTo on Kanban.

Samurai is Good but TDA May be Better

This morning Mesfin sent over 3 thread dumps from his Performance Investigation of our Continuous Environment. I was having a hard time getting the Samurai web site to come-up. So I did a quick check to see if anyone had an alternative I could run on my laptop. I came across this project called TDA.