Minimally Invasive Management

January 25, 2015 § Leave a comment

One of the greatest compliments that can be paid to an author is that they establish a common vocabulary for concepts everyone understands. I’ve heard the word “servant leader” used from time to time, but to me it fails to capture the nuance of leading technical and creative folks in our industry. Here’s to Minimally Invasive Management, a term I plan to overuse immediately.

You’ve heard of software as a service? This is management as a service. Managers serve the people doing the work. And nobody is more important in an organization than the people doing the work.

In this brave new world, management’s role should be to remove the impediments in front of the people doing the work so that they can do it well – and so they can be satisfied, rewarded and motivated in their work.

via Randy Komisar, HBR

Free to Grow: Transparency driven Accountability

April 25, 2013 § Leave a comment

What motivates you?

There’s an old saying, “Hard work isn’t easy. It’s hard.” The pace of business and the changing market landscape makes that statement as true today as it’s ever been. Working amidst complexity, struggling to achieve ever-higher productivity goals, and operating within razor-thin margins are common realities in many industries. With all of these challenges, it’s easy to ask, “is it worth it?”
The science of motivation has grown tremendously in recent years, and it’s a good thing too because Millenials and GenY employees seem to have a pretty different set of expectations about the role of work in their lives than their parents. Research by Daniel Pink and others are increasingly showing that internal values, not external rewards, are the primary drivers of passion and success. Specifically, Pink refers to “Autonomy, Mastery and Purpose” as three principles that drive motivation to perform. The freedom to choose what we work on, the opportunity to improve, and an understanding of how what we do matters are all far more successful at producing results than money or titles.
Now, that puts business leaders in a tough spot; we want happy employees and we want a healthy bottom line. Is there a solution that lets us provide autonomy to our teams, and still achieve our business goals? I think there is.
df20021001
We’re in a competitive industry, and technology moves at a blistering pace. I’ve seen my engineering team triple in size in the last two years! Our company culture values freedom, innovation and a challenger mindset. These values become more precious but also more difficult to preserve as we grow. For that reason, we need a context for freedom, a set of parameters that dictate what we should and shouldn’t do. We need to understand the boundaries that, if followed, will help us win. This is our strategy.
 
A well defined strategy is the context for freedom.
 
When you have a company strategy that everyone (and I mean everyone) understands, you can begin to draw a mental picture that allows each person in the company to make micro-decisions aligned with success. You do that by creating line of sight between every day activity and the results. It’s convenient to visualize this in three layers:

  1. A crystal clear strategy

  2. Established metrics (Key Indicators) that demonstrate the success of the strategy.

  3. Tactical processes designed to improve Key Indicators

 

I like the maxim, “You are what you measure.” I’ve seen engineering teams wrapped around the axle of code coverage metrics, or obsessed over velocity or burn-down rates. When we put a number in front of our team, we know they’re going to try to hit it. That’s why it’s so critical that we use wisdom when establishing the metrics which will govern our business. We should focus on metrics that directly map to our strategy, and drop the ones that don’t. We should be confident that the improvement of our Key Indicators equates with improvement in our overall business outlook. Then we can empower our teams to drive towards those Key Indicators, however they choose. We should establish the what, not the how.
 
Employees with an understanding of the strategy, and a grasp of the Key Indicators that drive it, are in an excellent position to develop good processes. This is the day-to-day blocking and tackling that must be done to generate results, and this is where freedom pays the greatest dividends in terms of motivation and performance. Modern work management tools let us provide this to our teams and still preserve a high degree of accountability, because we can see both their activities and outcomes. As business leaders we need to understand what’s happening, but stay the hell out of the way (that includes asking for status updates).
 
Transparent Accountability is the beating heart of successful, modern businesses. Strategic alignment provides a context for freedom for individuals, and Key Indicators set the bar. The processes your team establishes and follows should drive those Key Indicators, and you’ll know they are because you have visibility into what they do.
 

aligned-with-goals

Selling to the Enterprise, a Product Dev Dilemma

September 22, 2012 § Leave a comment

I recently read an excellent article by Paul Graham that defines a startup (as distinct from any other new business) as the combination of two key attributes:

  1. It must make something lots of people want
  2. There must be a way to reach those people

Most businesses can do one of those things, but not both together. Software and the distribution medium of the web has opened up all kinds of possibilities for achieving both goals, which is why another key indicator for a startup is rate of growth.

The common unit of success for any startup, then, is the growth of the user base. This presents a problem for a business geared at selling to the enterprise: although the unit of growth is the user, the acquisition of users is done at the level of the corporate account. This creates conflicts all through the product development process. Building sexy and easy-to-use is great for the user, but they’re not the ones buying your software. Building rich business value will help you win accounts, but lack of adoption by the end-user within the business will doom you when it comes time to renew.

Because if this internal tension, I believe anyone doing product development geared at selling to the enterprise must consider one of two growth models:

  1. Design to maximize number of accounts sold
  2. Design to maximize number of licenses per account

You achieve growth in model one by selling to as many companies as possible. You accept as a ground rule that you will probably not achieve rapid growth by going wall-to-wall within any corporation that buys. As a product designer, you should focus your efforts on deep solutions for specific verticals (Marketing groups, Help Desk, HR). This focus allows you to solve the problems better than one-size-fits-all solutions that could be sold to a larger audience within a single company. You’ll win more accounts than Model Two, but with fewer seats sold per account.

In Model Two you grow by selling as many possible licenses into each account. The trade-off for going with Model Two will be that you must provide a solution that is either one-size-fits-all or extremely customizable. It must work across a huge variety of professional disciplines. Wall-to-wall adoption of a product across an enterprise is rare, and must typically focus on common problem-sets to all workers. Examples here include collaboration, management and productivity-enhancement tools. Selling a tool like this requires a value-proposition that makes sense to Senior Executives, and the adaptability of the product will likely mean that compromises must be made on ease of use for specific verticals. As a designer, you should solve problems in the most generic way possible, with an emphasis on strategic problems in the business rather than tactical ones.

So, what does this have to do with Continuous Delivery? In any start-up you must build a system that allows you iterate on concepts as fast as possible so that you eliminate designs that don’t lead to growth. If you are selling to the enterprise the importance of Continuous Delivery in your system will depend on which of the two models you choose. If you’re shooting for selling the maximum number of accounts, you can iterate on look-and-feel, and on solving the most common problem sets of your targeted verticals. This can happen rapidly because your have more total accounts to work with. If your ambition is to grow by deal size, your iterations will probably be longer because you will have fewer over-all deals to test your strategy against.

I think if you’re building enterprise software, deciding on one of these two paths to growth is key to focusing the Product Development process enough to iterate into a successful solution.

 

Agile 2.0 and the Continuous Delivery Mindset

June 22, 2012 § Leave a comment

Today’s Agile is not “agile” enough. This was the message I took away from the Agile Roots conference in Salt Lake City this week, where topics around Continuous Delivery and returning to the foundational principles of Agile weaved into many presentations. As I observe trends in our industry as well as the tech sector as a whole, it becomes more clear all the time that even established businesses now operate in an environment of extreme uncertainty. Prescriptive methodologies that drive long cycle times simply cannot keep up with the pace of change in an increasingly services-oriented world.

Image

Continuous Delivery provides the technical foundation for a software development lifecycle that can respond to this pace of change. I remember a few years ago when AtTask first adopted Scrum, and started shipping code every month. We thought it remarkable that we could deliver working software at such a rapid pace! How quickly things change–it’s not uncommon for development to ship code into production several times a day! Examples include IMVU, Etsy, and Flickr and many others. Even in large scale organizations like Facebook, a daily deployment is now possible through robust automated testing and clever use of virtualized infrastructure. As I’ve described in other posts, AtTask has adopted a rich CI pipeline, which includes many of these features and now facilitates daily deployments. We have the technology to react to change at the pace the market demands… but do we have have the professional will?
An “Agile Mindset” can be demonstrated by adoption of the agile values in the decision making process of an organization. Agile teaches us to focus on delivering value over adherence to a plan, and to focus on results over process. Ironically, Scrum as it’s most commonly practiced is a heavy weight process in itself, and while it can help enforce agile principles, there are many examples of companies who keep to the pomp and ceremony of Scrum, but gain little value from the flexibility it affords to the product development process.
One of the Agile Roots keynotes this morning was given by Dr. Israel Gat (@agile_exec) on the subject of Agile 2.0. The thesis is that converging market trends require a re-assessment of the Agile practices we have followed over the past 10 years… that in some ways the Agile of last decade is just not “agile enough” for the years ahead. These trends include:
  • Hyper-segmentation of markets: such as the proliferation of social tools serving every conceivable niche community
  • Transiency of markets: It is not uncommon for a market need to come into being, but exist for two or three years only to be superseded by a new innovation
  • Value chains becoming value webs: Most value is derived in the interconnected world by the confluence of different synergistic services.. For example, a phone that is also a camera that integrates your phone contacts with a photo sharing service.

In response, we must tailor the processes which facilitate value delivery to match the speed and uncertainty of the market we operate within. Here are a few examples:

  • Replace pre-planned backlog silos with a shared backlog which is pull-based, allowing teams to self select from a prioritized order.
  • Begin to track capacity not as a function of estimation, but by measuring throughput (cycle time) on consistently sized units of work. This is also an Agile 2.0 way to predict delivery dates.
  • Instead of focusing on what features to add to a product, refocus efforts around customer development. This could include product features, but encompasses other areas such as in-product feedback mechanisms and processes to facilitate rapid bug resolution.
  • Replace sprint planning and intermittent grooming sessions with continuous grooming of the backlog in response to new market learnings.
  • Demonstrate and sign-off work in discrete functional units instead of arbitrary time boxes, such as Sprints.
Some of these are radical changes for an organization built around the heart-beat of sprints… In the past, the business itself has been subject to the rhythm of development. In Agile 2.0, we jettison many of these processes which have been rendered technologically obsolete, and free ourselves to focus on moving past value creation to value realization. We decouple the mechanisms of software creation from the requirements of the business to position and sell. It requires the bravery to recognize that the market is intrinsically uncertain, and to venture there.

Impressions from Jenkins User Conference, New York

May 17, 2012 § Leave a comment

It was just one day, but it was a packed one. The Jenkins Conference in Times Square NYC was probably the most densely informational conference I’ve been to this year. Frankly, I would have appreciated a two day schedule with some open space for hacking on plugins or un-scheduled talks. The community is passionate and invested in the success of Jenkins, which I already knew (they followed after the split w/ Hudson, after all), but there wasn’t enough opportunity to network as I would have liked.

We’re getting closer to settling on a code-review solution, and a talk by Monty Taylor (of Openstack project) on Gerrit was just what I was looking for. Gerrit is built in Java, so it’ll be an easy ride for my engineers. It’s flexible enough to absorb lots of different types of data. Best of all, it’s already integrated with Jenkins. I plan to present code coverage, performance, and test results to reviewers. Little concerned about the ugly UX, but that’s something we can tweak.

Image

Woof.

I was fortunate enough to participate on the panel discussion in the evening, where we discussed trends in the CI space, potential areas of focus for Jenkins development, and pros/cons of different approaches to deployment pipelines. Video cameras were present, so I’ll attach a link when I hear back.

In the meantime, I’ve added the slides from my talk on the slides page. Very enjoyable, well done Cloudbees. I’m already looking forward to next year.

Cloud Scale CI with Jenkins

April 27, 2012 § Leave a comment

I’m sitting on the tarmac at JFK, thinking about the next time I’ll be in town. The sponsors of Jenkins User Confence NYC have invited me to speak on Continuous Integration in the Cloud. This talk will be similar to what we shared in Armenia, but with a crowd of hard-core Jenkins hackers, I think we’ll enjoy diving into the weeds a little more.
 
One of the first things we did after forming a tiger team to tackle the CI problem, was evaluate the vendors in the space both commercial and open-source. We had been using TeamCity from Jetbrains because of its deep integration with IntelliJ (we are a java shop). TeamCity has a lot going for it: a slick UI, great claim/blame functionality, and a built in remote run feature which essentially tests every diff against a shadow branch before merging to mainline. Jenkins was adopted in our QA organization, but was used primarily as a job automation system. It wasn’t connected to our version control, and was running on a single virtual machine.
Comparing these two tools was tough. We could keep what we had been using and begin the process of building out integrations to stand up our vision of a cloud-scale CI pipeline, or we could switch to Jenkins, absorb the crappy UI, and leverage the efforts of the community to give us a head start.
In the end, we went with Jenkins, and I’m glad we did. Yes, we ended up having to write a few plugins ourselves, but the initial hacking required to connect with our chosen cloud vendor, Amazon EC2, both it’s single instance APIs and cloud formation endpoints, was largely finished by folks in the community. Jenkins still stinks at visualization, but we have created views which have increased adoption in our org, and which we are now sharing with the community.
I’m looking forward to joining the Jenkins guys at their conference in NYC, stay tuned for slides, photos, and other content from the show on May 17th!

Where Am I?

You are currently browsing the Technology category at The Continuous Deliverist.

%d bloggers like this: