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.
Free to Grow: Transparency driven Accountability
April 25, 2013 § Leave a comment
What motivates you?
-
A crystal clear strategy
-
Established metrics (Key Indicators) that demonstrate the success of the strategy.
-
Tactical processes designed to improve Key Indicators
Telling our CI story
October 4, 2012 § Leave a comment
I’ll be speaking at the Better Software Conference in Orlando this November. One of the sponsors, techwell.com asked me to share a little more about what led AtTask to embrace a continuously integrated system. When it first came out, I thought our stuff was pretty novel. Now I think it’s just the cost of doing business if you’re selling software on the web.
You can read the whole interview here.
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:
- It must make something lots of people want
- 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:
- Design to maximize number of accounts sold
- 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.
- 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.
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.
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.
People work hard for money, harder for leaders… but hardest for a cause.
May 8, 2012 § 2 Comments
From my vantage, the Atlanta Scrum Gathering was largely a success. There were a few stand-out talks, but some duds as well. I was surprised by how light many of the presentations actually were–perhaps because agile methodologies tend to be pretty simple in the first place. That said, there were a couple of learnings that will stick with me as I move our organization forward.
Time boxing is not a pre-requisite for effective Agile. The closer we’ve moved to Continuous Delivery, the more the time-boxing of our Sprints has felt like an artificial construct. Lots of people have run into this problem when working on queue-driven activities. One person shared an example of an off-shore team whose entire job was to write regular expressions for website scraping. There was no reason to use a time-boxed release cadence. Instead, the team pulled work from a queue at a consistent pace, delivering the work as it was completed. The ER (Escalation Response) team at AtTask is already doing this, just without a mechanism for observability by external participants, or a formal improvement program. I believe that Kanban solves this problem in an elegant way, and would be a relatively painless model to explore.
“People work hard for money, and harder for leaders. People work hardest for a cause.” This quote was shared during this mornings keynote by a gentleman named Tanner Corbridge. He works with Partners in Leadership, the company behind The Oz Principle. He mentioned it almost as an aside, but it certainly resonated with me. The fire that we instill in our organization should not be about compensation, or about the charisma of those that lead our teams. It should be about building our culture around a common purpose. It’s something we should have laser like focus on in everything we do. I’m very proud of AtTask’s culture, and believe that our adoption of agile has helped us focus on our common cause. AtTask is about improving the work lives of knowledge workers across the world, and we can measure ourselves against that cause. I’m looking forward to discovering ways to accomplish that going forward.
