For the 1.0 release, I wrote up an insider’s perspective on the entirety of the project.  This time around, I wrote up a post for an internal audience, which ran on EMC’s Intranet site to talk about the process challenges and what we learned while delivering 1.5. So, I figured I’d write a bit here about the comparison between working on 1.0 and working on 1.5.

ProSphere 1.0 was the culmination of years of struggle to figure out how to “replace” ControlCenter.  We were replacing people, product, process — all at the same time as maintaining our revenue stream.  You can go back and read last year’s post if you want to see more of what I mean.  It was a wide open play book at the start, and just making the decision that we were “done” and could ship it was a major milestone.

1.5 didn’t have a wide open play book.  It did have a date, and a place in the overall timeline, and it was a constant fight to keep the feature count low enough to achieve that date.  Teams were rearranged, senior leadership had changed, and suddenly our product was on everyone’s radar.  The product team had to “grow up” fast to get 1.5 done, and I’d be lying if I said there weren’t any growing pains.  But it also totally validated the overall approach we had chosen for ProSphere.

Teams continued to report that they loved the tight-knit, cross-functional collaboration made possible by the Agile/SCRUM process.  Our 2-week iterations kept all interested parties up to date — there was no chance for a team to drift off target.  Our safety net of automated tests kept regressions at bay.  The tools and processes we had laid down in 1.0 allowed us rapid turnaround in 1.5 — it’s easy from “on the ground” to forget how much runway we built during 1.0, and how much effort it saved us in 1.5.

If you’re a ControlCenter customer, go read the official releases about 1.5.  Take a good hard look at that capacity dashboard and the Explore feature.  Think about what value you’re getting from ControlCenter and how hard we’ve worked to bring that value to you in a new product.

Give it a shot.  And let me know how it goes….

This post is from: Dave Talks Shop

ProSphere 1.5 out the door

I like to to think I’ve figured out a few things in my time as a manager, but every day is still a learning experience.  Every time you take on a team member, you learn something new.  You figure out how to adapt to them, what they have to offer, what you need to change to make them most effective. People change, too, so even if your team is static each member of the team is growing.  They have new needs, offer new contributions, interact with their surroundings in new ways.

You can never really rest, as a manager.  You are constantly confronted with change, and the cost of failure is high.  Some will quit, others will remain even though unhappy, draining the will of those around them.

It’s not an easy job.  And “the hard part” is only a fraction of what the company probably expects of you.  You need to know your product, your market, your users, and your technologies.  You need to know your company, your division, your peers, and your office politics.  Somewhere in all that you need to know the dynamics of your team, the individual needs of every team member as well as the combined set of everyone.   You have to juggle the fact that what’s best for your team may not be what’s best for you, you have to weigh the needs of the company versus the needs of your division, weigh your own instincts against those of your senior management.

It’s easy to get overwhelmed.  It’s easy to focus on just the pieces of that puzzle that are easy, or that are screaming for help on any given day.  That’s all many managers do.  It’s understandable.

So, for the new managers in the crowd, I offer my condolences if it’s not what you wanted.  And I hope you get a lot out of the job and share what you learn with everyone around you.  Because we need good managers.  We’ve got too many people filling chairs who would rather be doing something else.

This post is from: Dave Talks Shop

New manager?

But I had a conversation with some colleagues and family over the weekend, and I thought it would be useful to record one piece of information about that day.

I remember many things about that day, sitting here at EMC in Hopkinton.   But one thing that stuck with me over the years is that my manager at the time gave me a hard time about leaving at mid-day to be with my wife, who had been sent home from her work in a high-rise building (if you remember, many high-rise buildings were closed and their employees sent home) and really didn’t feel comfortable being alone.

I’m sure we were working on something really important that day. I’m sure that manager did what they felt was best for the corporation on that day.

I have no idea what I was working on that day.  But I do remember exactly how that interaction felt.  And I remember how absurd that feeling is, in the context of the world-changing events that took place on that day.

It’s a lesson as a manager I carry forward.  I write this not to call out my previous manager but to remind all of us as managers that the world is bigger than our deadlines.

This post is from: Dave Talks Shop

What you remember

The question, of course, is really “is it done enough yet?”.

We finally shipped ProSphere 1.0 at the close of July.  I am not surprising anyone when I say that wasn’t the first release date we had in mind, nor am I surprising anyone when I said we shipped with a backlog of items we wished had made it into 1.0.  But at some point you need to ship it and move on.

Today I have a slightly different team; a few people have changed responsibilities to allow the teams to better meet the needs of our next release.  And while I work to integrate that new team together, I also stew over a laundry list of requirements and enhancements to our product for the next release.  Resolving priority conflicts, providing gross estimates, learning new areas of the product, and making sure nothing slips through the cracks — it’s a busy time.

It’s a totally different kind of busy than when trying to release a product — but it’s just as important.  The context shift is jarring, but the quality of the work done today will impact our working lives for the coming months, and have a direct impact on the satisfaction of our customers with the next version of this product.

This is, of course, the job we all signed up for.  It’s an exciting time.

This post is from: Dave Talks Shop

Ship it, move on!

Fifteen years later, I’m writing about a new big splash for EMC in the SRM space – ProSphere 1.0. I’ll stop you right here and tell you that you need to go read Chuck’s post on the product. I can’t out-do his deep-dive into the industry angles and why it’s such a big deal, so I won’t even try.

What I will tell you is why working on this product was so different from any other product I’ve touched at EMC, and why I’m so proud to be able to announce it here. Just like fifteen years ago, it was a chance to take a look at everything “wrong” while also still looking in new directions at the same time the industry is making another scale leap with Cloud environments. This has been some of the hardest work I’ve done here at EMC. But seeing it get out the door is making it all worth it.

EMC ControlCenter has a decade-plus roller-coaster history.  It’s been through some challenging times, on many fronts, but we’ve never stopped trying to improve it for our customers.  We often talked about things we’d like to do differently, given the chance.  By the middle of 2008, a vision for the future was firming up – and we had a name for it.  “SRM 7,”  reflecting our goal to avoid “growing” ControlCenter to a new major version after 6.x.

We handed out T-shirts with a stylized “7” inside a diamond shape (which might evoke a certain superhero).  The (perhaps dangerous) implication?  SRM 7 was going to fly in and save the day.  We were all a bit skeptical.  But today we’re announcing the first shipping release of that product – ProSphere 1.0.

Why do I think it’s such a big deal?

We didn’t rebuild ControlCenter

Early on, we faced a critical decision – do we rebuild ControlCenter piece by piece, or do we build a new solution from the ground up?  We knew part of the issue with ControlCenter was feature creep.  We wanted to focus on critical customer use cases and build the application that could do those, and resist the temptation to build a giant unwieldy Swiss Army Knife.  That philosophy bled into everything.  We didn’t build a giant infrastructure that could address all our needs; we architected an extensible solution and implemented enough of it to get us through the use cases we were attacking.  We avoided writing “just in case” code to support possible future features.  We didn’t build what we could reuse.  We knew we couldn’t ever finish this in time if we wrote it all from scratch, so we pulled in proven components from other shipping EMC products and integrated them.

Further than that, we didn’t want to be the single best interface for every deep use case – we knew you wanted to use the right tools for those jobs.  So we made a plan — find those tools, link to them, launch them in context, and make your sign-in transparent – and in the process eliminate thousands of lines of code which need to be tested, debugged, upgraded, and so on.  It’s a win on every front.

You’re never going to have a “lean” piece of software to do the giant job of managing the storage for your entire enterprise.  But ProSphere is downright svelte compared to ControlCenter, and we intend to keep it that way.

It was ok to look outside

Another shift we made in ProSphere was to look outside our traditional sources of software components.  We didn’t want to write, maintain, and test unneeded software.  We didn’t want to architect and design unneeded components.  We pulled in open source software, we used open standards, and we got creative.  It was a learning curve for the development team, but in the end we have a product that communicates using known web technologies and patterns, and which we hope will serve as the foundation for an open, extensible management solution.

This extends deep into the product’s DNA, not just a superficial claim about what our APIs look like.  Eliminating traditional agents, using HTTP to communicate between our machines, going to a virtual appliance model, using industry-standard system monitoring  … all these things make the system higher quality and more extensible with less code to carry.

We got Agile

One of our early decisions was to abandon the waterfall software method we had more or less down to a science in ControlCenter, and replace it with an enterprise-scale Agile development approach.  In my personal opinion, two excellent things came out of that decision: we “forced” our development managers to take ownership of use cases within the product, and we created cross-functional (development, quality engineering, documentation, product management, user experience design) teams to tackle those use cases in close collaboration with each other.  In my fifteen years of software development, this is the closest cooperation I’ve seen between functions on a project team of this scale.

We built a safety net

Last, but most certainly not least, this product has the most aggressive safety net I’ve encountered.  Every day, thousands of automated tests run against the system in various forms – unit tests against the code, integration tests against the REST interfaces, automated UI tests against the finished product in a test environment (deployed automatically after every finished build), and even more automated UI tests against the finished product in a “real” environment.  Individual developers had access to a simple web-based tool to deploy a build, patch it, and run a suite of hundreds of automated regressions against it prior to delivery – all from their desks, without ever seeing an installation screen.

We combined this with static analysis tools constantly analyzing the source trees to check for bugs, security lapses, stylistic violations, and undesirable complexity, with web-based dashboards for everyone to see.  Finally, there’s a dedicated team doing manual run-throughs of customer use cases in a variety of real-world environments.  You take all that and combine it with an organizational mandate not to tolerate technical debt, not to tolerate little bugs accumulating in the system, and you’ve got a team that understands what quality means and has an extremely low rate of regressions.

Part of what took us so long was building all that scaffolding, and changing the culture of our development and test organizations to get us here.  And now that it’s built (not that it’s ever “done!”), it will pay for itself for years to come.

In conclusion

I’ve been involved on this product for about three years now … the same amount of time I’ve been a father.  And like any Proud Papa, I can’t wait to show off.

We built a solid foundation – a highly deployable, serviceable, and usable application – and concentrated our efforts on a small, tight family of use cases using that foundation.  We’re already working on what’s next.  I think we’ve changed the game here.  I’m proud to be a part of that.  I was just one manager, with one small team, working on little bits and pieces of this giant project.  I’m grateful to my team for consistently seeing the big picture and working nonstop to get us there.  I can’t begin to explain how proud I am of the work they did.

It hasn’t been easy; a lot of blood, sweat, and tears are flowing in the hallways.  But nothing worth achieving is easy, and there are a lot of smiles today as we finally take the wraps off this.

ProSphere 1.0 is just the first step.  It’s your turn now.  Check it out.  Tell us what we’re doing right, what we’re doing wrong.  Help us take this to the next level.  I promise I’ll listen and do my part to make sure your voice is heard.

This post is from: Dave Talks Shop

Introducing ProSphere

One of them was something I learned from Steve Todd, way back in the day — always excel at your day job before you do anything else at work.  Doing a great job in your primary responsibilities is what gives you the freedom to explore secondary responsibilities.

I’ve been eyeball-deep in work on EMC’s next offering for Storage Resource Management (what you may have heard referred to as “SRM7″).  Never mind my days, it’s consumed my nights as well!  So I’ve let this blog get a bit rusty.

There are some other rules I’ve set for myself, and it’s cool to see that the “social” folks at EMC have codified some of those rules into a little video that people here actually get training credit for watching.  It’s short and sweet, and I was pleasantly surprised.

This post is from: Dave Talks Shop

Rules for blogging here

Which axis is most important?

• You could say that the people are the most important. Without them, you can’t produce your product.
• You could argue that the product is most important.  Without it, you can’t employ your people.
• You could argue that the process is the most important.  Without it, people are ineffective.

The truth is your organization and your employees need you to focus at different axes at different times.  Effective managers can operate comfortably on a variety of axes.  Of course, we’re all naturally going to gravitate towards the axes that make us the most comfortable, or where we feel most effective.  It’s part of managing your own career to figure out how to get into roles and surround yourself with the right people so you can focus on the axes where you are most effective, without the organization paying the price.

It might be your first instinct, when hiring someone, to pick someone who values the same skills you value.  You’re a strong process guy, and you’ve just interviewed a candidate who feels just as strongly about process as you.  Congratulations!  But if neither of you are good with people, your team is lagging.  Nobody is focusing on an axis which is at times the most important one.

Likewise, it’s vital when thinking about your own career to think about how your management views these axes of concern.  You may have incredible technical instincts, but if your manager dedicates most of his time to thinking about Process and People, your strength on the Technical axis might escape his notice, even if you’re helping make sure his organization is well-rounded.  You may have to take some extra time to make sure he’s aware of your contribution in that area.  When people talk about how hard it is to do self appraisals, I think of issues like this — just talking about how cool you are can be difficult, sure, but the real challenge is figuring out how to spin the fact that you’re great at something your manager doesn’t seem to care about (while suppressing the fact that you aren’t so great at something your manager clearly does care about).

Over the years I’ve enjoyed the mental exercise of thinking about these various axes of concern and modeling them at their extreme both in my own life and those around me.  Some mental games to play:

• If you replaced your entire team with code-producing computer algorithms, and your job was simply managing the business priorities to figure out what those algorithms produced according to schedule, would you be happier?  Would you feel like you could finally do your job?
• If every artifact your team produced was immediately thrown in the trash and nobody cared what they did, would you be happier?  Would you feel like you could finally do your job?

When you find yourself too strongly aligned to a single axis, it’s probably time to take a look at your surroundings and make sure you are still operating effectively.  Whenever the structure of your organization changes, rethink your alignment on the axes.  Don’t be blind to a sudden shift in priority at the senior management level, for example.

This post is from: Dave Talks Shop

Areas of concern

Good luck to any applicants!

This post is from: Dave Talks Shop

Cool job opportunity at EMC

I don’t know yet if I’ll be there, but I can tell you what will be there — a handful of sessions describing the new storage resource product that’s been occupying all my time of late.  There’s even a hands-on!

I can’t yet tell you the product’s marketing name (pesky lawyers), but we’ve been calling it “SRM 7″ internally for a while now, and we’re wrapping up the first round of beta sites and pushing full speed ahead for a coming general availability release.

If you’re a ControlCenter customer and want to see what’s coming soon, make sure to sign up for any/all of the “Beyond ControlCenter” sessions listed in the EMC World course catalog.  Tell them Dave sent you .

This post is from: Dave Talks Shop

Beyond ControlCenter

This isn’t a post about software development, though.  Instead, I’m sharing how iterative development has changed my approach to performance reviews.

One of the goals of the iterative model is that at any time, the Business can decide it’s time to release the software, and you have something usable ready for them.  In other words, you approach every long task by breaking it into smaller tasks, each of which has as its output a piece of software with business value.  You do not take on a feature that takes six months to write; you break it into features which take (say) one month each to write, and do them in priority order.  In doing so, you might actually have to break it into eight (or ten!) features, and not six, but those extra months of “lost time” are considered a good investment by the Business, because of the increased flexibility you give them in releasing the product at any time.

So when faced with a pile of performance reviews to write, I tried to approach it the same way.  My first goal was to reach a point where I could, if my management required me to, “release” the reviews (minimum business value).  Then, I took on activities which would increase the value of those reviews to everyone involved.

Before I could do this, I needed to identify the stakeholders in the process — the customers.  The most obvious customer is the employee being reviewed.  The next in line is probably my own management chain (who in turn represent the corporation, eventually).  Finally, I am my own customer here.  Done.

Next up was defining the outcome of my initial iteration.  I decided on the performance ratings (the “grade” at the end).  While this may seem backwards, many managers will tell you this is how they work in reality (if not in theory).  Why start here?  It’s the bare minimum to achieve the business goal of the performance review.  The minimum business value my customers can get from my deliverable is a performance rating.  If I don’t have that, I don’t really have a review.

So, I studied the requirements, refreshed my memory, aligned my measurements with those of my peers, and entered performance ratings for my entire team.

Iteration complete!  It feels good to know I’ve got a piece of deliverable value ready to fall back on.  But clearly I have no intention of calling this a review.  I planned out my next few iterations.  Here’s the rough plan I settled on:

• Define the major accomplishments for each person
• Identify the core strengths for each person
• Identify the development opportunities for each person
• Compare my version of their accomplishments to theirs, as identified on their self-appraisals, and adjust
• Fill in details on their accomplishments
• Fill in details on their strengths
• Fill in details on development opportunities
• Fill in other textual fields in review
• Compare each review with self-appraisal, look for major gaps and issues, and adjust
• Refactor each review as needed

At each point, I am performing the task for all my team members.  The result is, I hope, a set of reviews which have the same level of detail and attention given them.  It will avoid the problem where one person’s review gets a week’s worth of time, and another person gets an afternoon’s, because I ran out of time.  If I run out of time, everyone’s review is short-changed (but they still have something valuable).

It’s still in progress, but I think I like this approach. It’s keeping the entire process fresh for me as I approach each team member, and keeps me from getting overwhelmed with any one person’s review.

(You might notice two points in the process where I review the self-appraisal.  I am fairly strict about this; I review it once to make sure I didn’t forget something critical they worked on, and a second time to see how my appraisal and theirs differs.  I will usually make changes after that second review, but I do not conduct it until I have a “done” review written.  It’s harder, but I think the review is better, this way….)

As a techie-manager, how do you handle “releasing” the product of a performance review?

This post is from: Dave Talks Shop

Iterative development of performance reviews