The following section is from my forthcoming book, about midway through. This book is pivoting to be a fully realized academic textbook on Agile IT Management, from startup to enterprise. I work at a teaching university instructing a diverse student body, and need to communicate key principles with effective examples and a minimum of theory. I would appreciate feedback from anyone with experience in Agile and/or startups as to the accuracy and effectiveness of this section.
Note, this blog has had multiple drafts. Made major changes with 7/5 revision.
Complexity responds to competence, not authority.
So, you are getting bigger now.
Even as a cohesive, single team you had increasing complexity of support services. You needed legal and accounting advice to get the startup going. When you started hiring people, you needed HR and payroll, and at some point you need an internal person whose daily job is money (they’ll become the CFO someday).
You also are buying stuff and paying bills, and you’ve got sales people and marketing people and you need to support your customers and collect money they have promised to pay.
How are you going to organize? More importantly, how are you going to think about organizing? This is a hard question. It’s important to get organization right, and the question never goes away. There is a lot of theory, history, and advice available on to how to organize your company. There seems to be an emerging consensus on how Agile companies are best organized, as well.
This is not a general business school textbook, or even a textbook on startups and entrepreneurship. However, in the current environment, it is essential for technologists, no matter how specialized, to understand the general context they are operating in.
In one chapter, we cannot cover much, but there’s an increasing consensus that the choice of organizational form has a fundamental impact on the success of IT-based product delivery. (***cite Narayan) So we’re going to devote a chapter to this.
In keeping with our evolutionary approach, let’s assume you’ve been fairly ad-hoc in your organizational structure up to now, doing your best to avoid specialization. Perhaps you’ve even been working as a collective. Nevertheless, you’ve needed a variety of skills to get this far in your journey: you are certainly not all Java programmers!
Perhaps your organizational form at the end of Section 2 looks like this:
You have the following personnel:
- Lena, the visionary and product owner, who had the idea for the startup. Lena retains the overall vision for the product and is therefore the Chief Marketing Officer as well as CEO.
- Mohammed, the user experience specialist
- Aparna, the Java software engineer
- Sonya, who has a broad scope of platforms and tools, including the development pipeline, source control, and the product’s NoSQL database
- Tomas, the sales lead.
- Peter, the office manager, who is responsible for a range of operational, financial, and lightweight HR duties.
Because of your success, you need to go from one team to two. BE VERY CAREFUL. There are a few different ways in which this can occur, and the decisions you make at this particular point may have long term consequences!
Let’s assume you are going to break the product into two feature teams. One will focus on the existing market and the other will develop a new major feature for a new, distinct set of user value propositions.
In order to do this, you are going to bring in a new UX specialist, a new Java programmer, a new sales person, and someone to field customer support calls. Lena also intends to step back a bit from direct product ownership, so a new Chief Marketing Officer comes in. She talks with an organizational consultant and proposes the following new structure:
(click for larger)
Proposed structure #1
Callout: What’s the difference between Sales and Marketing? "Marketing tells a story that spreads. Sales overcomes the natural resistance to say yes." -Seth Godin (will need cite, quoted http://www.ehow.com/info_8088140_cons-combining-marketing-sales.html)
This may seem reasonable. Everyone agreed that there is no need to add more people to help Sonya and Andre; they can support both feature teams. Obviously, the new sales person comes in under Tomas.
Because Peter was the one receiving all the calls, and in the interest of giving him a clear career path, it was determined that the first product support person would come in under him, in what was anticipated to become a dedicated help desk/call center.
It was perceived that the engineering team would likely be receiving various requests and so a dotted line appears on the organization chart, indicating a service relationship. The new support person under Peter would also be shared across both teams, and their needed to be some means of communicating support requests to the feature teams when their support was needed. There was some question as to how the office Kanban boards might be reconfigured to support these relationships. Peter and Sonya, after some online research, started to become interested in something called ITIL.
But before that discussion continued, Lena retained another consultant as a cross-check. This consultant had worked with many Silicon Valley startups and had a very different opinion. This consultant was inspired by the “Spotify model” (https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf) and proposed the following scaled-down version of it:
The consultant also added something called “guilds” to the model:
The “guilds” are not formal reporting mechanisms, but rather a way for people doing similar work to share experiences, best practices, and so forth. Each tribe has a designated lead:
- Tomas leads the Sales guild
- Mohammed leads the UX guild
- Aparna leads the Software Development guild
- Sonya leads the Engineering guild
- TBD leads the support guild
The idea would be that the guilds would meet regularly (perhaps bi-weekly) and would have their own forums on the company’s social media channels. The head of each guild would meet with Lena monthly to discuss issues and concerns, and would have a direct channel of communication to her as needed for more time sensitive matters.
These two organizational structures were very different and were extensively discussed in the company (Lena preferring a transparent, open decision making process.) The following arguments pro and con were noted:
One fact everyone agreed on was that Sonya had to do more Linux and Andre has to learn some NoSQL and other platform technology. But this fact was not put into the matrix as there was not agreement as to whether this was a pro or a con. On one hand, it did seem a bit wasteful, but it was also recognized as a good thing in terms of cross training and deepening the bench. Sonya also felt that a Data guild would eventually be needed.
Ultimately, everyone agreed that the engineering guild in particular would need to be a very strong guild, to ensure consistency of approaches around key disciplines like source control, security, platform choices, build pipeline, and so forth. The other guilds could be a bit lighter weight, but the engineering guild leader could set binding technical policies across the product teams if need be (the expectation was that this would not be done lightly). It was recognized that eventually a distinct operations & engineering team might still be necessary, but probably not until another round of scaling, and that that team, per the Spotify model, would be more focused on setting up self-service tools for the product teams, and would avoid ticketed work as much as possible.
Another “neither pro nor con” but important was that the second option eliminated the new VP layer. Establishing an executive layer might still happen later, the consultant suggested, but it was premature to do so now.
After further discussion and benchmarking with other startups, the second option was chosen. The new support person for Feature Team 2 would be able to be hired without urgency, allowing time for a high quality search.
(callout?) Everyone in a startup wears many different hats. The first step in scaling your business is to list all the different hats you and your team members are wearing.
Furr, Nathan; Ahlstrom, Paul (2013-11-15). Nail It then Scale It: The Entrepreneur's Guide to Creating and Managing Breakthrough Innovation (p. 181). NISI Publishing. Kindle Edition.
(Students to discuss in breakout groups, with reference to their own experiences.)
Credit where due: this chapter was influenced by
Narayan, Sriram, Agile IT Organization Design: For Digital Transformation and Continuous Delivery
Henrik Kniberg on Spotify (https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf)
Henry Mintzberg, Structure in Fives: Designing Effective Organization
among diverse other sources. Full citations will appear in final publication.