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: