Care where it counts

I care a lot. I always assumed my frustration or disappointment at work was because I cared too much. Friends and family always told me that I had to learn to care less. “Leave work at work” was the sage advice I was given again and again. Since you, kind reader, may not know me, allow me to explain: I cannot leave work at work. Work is a part of my life and I can’t stop living a part of my life just because the clock has struck six. I care deeply about the people in my life and our time spent together, even if it’s at work. So, I can’t possibly care less. But I can focus on caring about the right thing.

Luck and great recruiters have allowed me to work with some of the most talented developers, business analysts, architects, and system administrators in the world. They have all proved to me that there are brilliant people who can do their jobs better than I ever could. But through their eyes, I have learned that I do what I do better than they can. In fact, they rely on me doing a great job so that they can do theirs.

Because I started as a developer and because of my management training, I’ve wasted a lot of time worried about the how. I, like many other young managers, felt as though the best way to make sure my project got done on time, on budget, and with high quality was to control all the details. As my teams grew and especially as I began to manage multiple teams, it became clear that my detail-control methodology does not scale. To make sure that I can grow as a manager and to make sure that I give my company the most value I can provide, I’ve really started to dig out of the implementation.

Here’s what I’ve learned for those we are looking to do the same: it’s hard to let go. Those who relied on you to fill in the details will take time to adjust to filling in their own blanks. Know that you will not make the switch flawlessly; you will leave things out of both the details and the greater picture. My advice to get through the setbacks: with each mistake, determine where your care and effort could have been better placed to prevent it. Continuous improvement is the name of the game. Keep the big picture in mind; the light at the end of the tunnel will slowly get bigger. Once you feel the warmth of the light, you will never look back.

Stop managing and start helping

Last week, I read an old blog post on As Chris Daily said, people need to “let go of the perception that they are in charge. In reality, you were never in charge, but you told everyone you were.” His words sat with me while I did my usual routine in trying to shepherd code from development to release. I paid attention to how much time I spent “micro-managing.” It was too much.

So, today I stepped back officially from my “managing” of the team. After only their second sprint it was obvious that they don’t need me to manage them; they manage themselves. I should be spending my time helping them get work done, not supervising or making their decisions.

Next week I’m going to be doing more of MY job (not theirs). My job is to coach. I am excited to coach with such a talented and devoted team.

Building cross functional teams

Scrum is a style of Agile software development that has become very popular. However, like its namesake in Rugby, the development methodology depends on the ideal that the team is at its greatest power when it moves ahead together as a unit: a scrum.

“Scrum relies on a self-organizing, cross-functional team. … The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.” (Mountain Goat Software)

It’s a hard transition for some organizations to assemble a team that can operate in a scrum. If you are lucky, the management has already decided upon Scrum and is ready to assemble a cross-functional team. However, if that is not the case, it will be up to you, my fellow agilist, to advocate. The concept of Scrum is generally not enough to convince someone new to the ideals. More often than not, the first team includes only application developers. It takes time to get buy-in that the team really does need a database guy AND a solutions architect AND a QA person.

I’ve found the best way to bring everyone into alignment is to carefully warn about the possible side effects of not having a cross functional team, continue to work as hard as possible, and see how it goes. What seems to happen is that the team begins to feel the void where a function is missing. Let the team decide what it needs. I always recommend having the outcomes/goals of your retrospective posted and available for all, including the leadership of the company, to see. If one of the outcomes of the team’s discussions is the need for a more cross-functional team or an additional team member, use that information to bring it to the management’s attention.

Letting the team decide what it needs is important in all changes. Only the team knows what it needs and what it’s comfortable changing. The team will determine the right mix of functions to create the perfect cross-functional team.

Just getting it done is getting me down

I am demanding.

I want work to be done perfectly every time. I expect everyone to have the same attention to detail and follow through as me. Guess what? It’s frustrating and the frustration doesn’t yield better results. Even worse, the frustration is mine alone and doesn’t help anyone (specifically the person I’m frustrated with) improve.

Time to step back and look at the problem. As Chris Daily said, people need to “let go of the perception that they are in charge. In reality, you were never in charge, but you told everyone you were.” This is incredibly important because we were raised in a world where bosses told you what to do. It’s not unusual for people to come to me and ask questions like “How should I do this?” or “What exactly do you want?”. These questions are the root of why I’m often disappointed with the final product. If I decide the how, what stake does the person doing the task have? He won’t have any ownership and by using the prescribed solution can easily implement without much thought.  But I want him to think! I want him to come up with different solutions, talk to his peers, make decisions that the team can agree on, and own the solution.

Instead of answering with how, I am trying to enable the team to decide by itself. I am stopping myself before answering, counting to ten, collecting my thoughts, and framing my response as an agile coach. I hope to find myself answering how with a suggestion to sit and talk the problem through with the business owner and team. I hope to find myself less frustrated and more productive.


The bottleneck of false import

I have only been at my current organization one year, but somehow I am already the definitive source for information. I am no technical expert, but find myself making technical decisions. I care so much about getting the job done (both well and on time) that I weigh in on technical decisions just to expedite.
Here’s the problem: with every new system and each project, more information is in my head and I become even more relied upon. But I am still one person with only so many waking hours, two ears, one mouth, and one tired brain. I have become a bottleneck without meaning to. No matter how much I decide or how many people rely on me to “be in charge,” projects aren’t getting done better or faster.
The solution: use all the knowledge I have of Scrum development and being an agile coach to forge a new path.
Turns out moving from the guy who knows everything to the agile coach ain’t easy. At this point, it’s equally changing my internal behavior as much as teaching others to adjust to my new external behavior.
I turned a meeting that was “standup” by name into a real scrum stand up. We answered the three questions, we tried to move conversations into follow ups; it was beautiful. Not perfect but beautiful.
Here’s how we did it: I acted as the Scrum Master. I told everyone the rules and enforced them. I tried to assist by recording the blockers so the speaker felt he could safely move on to the next person and his blocker would soon be addressed. The team did the rest. For now, I’ll setup the follow up meetings. One change at a time. Tomorrow we’ll do it again and hopefully it will be easier. By next week, I will try to have encouraged everyone enough that they setup the meetings and resolve their own blockers as a team.

Development Tools

Developers do the work. It’s just the truth. I can coach and teach but I don’t make the product go. It’s a frustrating a rewarding thing to be the coach. But it also means that I have the responsibility to get the team whatever they need to get the job done. Today I want to talk about tools.

My developers often complain that their computers are slow. When I have confronted the people in a position to change this, they make sure everyone’s anemic machine has 8GB of RAM and a few gigs of empty storage and declare the problem solved. But I sit with the developers while they work. They spend, literally an hour a day waiting. They wait for code to compile, they wait for IIS to start, they wait for programs to stop crashing, for solutions to close and open. In general, the machines waste their time and the developers know this. Almost every developer I know has a great system at home. It’s his baby and what he will measure his work machine against. When the work machine fails this comparison miserably, the developer understands that the company doesn’t appreciate and value his skills and time as much as he does.

If we consider for a moment that each person on a team of 20 developers is billing us roughly $150/hr, then each day we spend at a minimum of $3,000 paying them to wait and get frustrated. This figure is typical back-of-the-napkin math and is lacking detail a specificity, but in general it’s accurate.


What can $3,000 buy? A pretty great workstation that would stop the waiting for one person. So, in 20 days, you could “break even” on buying the whole team new machines to cut the wait time. This seems like a no-brainer. Not only would productivity go up, but the team will understand that they are important and investing in them is something that the company does willingly and  frequently. You want your dentist to have the best tools when he works on your mouth; I want my developers to have the best tools when they work on my projects. As I said above, they are the ones who do the work. They are the heart and soul of the IT department and should be treated with the import they deserve.