The *business* of software
Chaos vs factory
Startups are known for their high productivity - typically which comes from very talented people just getting on with what needs to be done. Its chaos, but in a good way and with strong leadership, you get the best out of everyone.
As the company grows, the board starts to want some more governance and demands things like scaleability in the team, repeatability, predictability, business continuance etc.
The easy solution is to start defining processes to achieve these and slowly you turn your team into a factory. New resources can come in and follow the set processes to deliver the desired outcomes etc.
The hard solution is to define some boundaries - things like security policies, privacy policies, release procedures, issue tracking etc and then provide good leadership to your team who continue to get things done. You then find other ways to measure and report to the board without introducing overheads and processes.
What I've described is very theoretical and 'chaos' and 'factory' are extremes, but I'm really keen to hear how people are dealing with issues like scaleability in the team, repeatability, predictability, business continuance etc without stifling the team?
As the company grows, the board starts to want some more governance and demands things like scaleability in the team, repeatability, predictability, business continuance etc.
The easy solution is to start defining processes to achieve these and slowly you turn your team into a factory. New resources can come in and follow the set processes to deliver the desired outcomes etc.
The hard solution is to define some boundaries - things like security policies, privacy policies, release procedures, issue tracking etc and then provide good leadership to your team who continue to get things done. You then find other ways to measure and report to the board without introducing overheads and processes.
What I've described is very theoretical and 'chaos' and 'factory' are extremes, but I'm really keen to hear how people are dealing with issues like scaleability in the team, repeatability, predictability, business continuance etc without stifling the team?
Views: 3
Replies to This Discussion
-
Permalink Reply by Mark Dalgarno on -
I've been down this road a few times at companies that grew to around 10 developers and 40 other staff.
One time we had to recruit someone into the team to focus on the discipline aspects. He really loved doing that and ran with it. Some noses were put out of joint but not too badly and the developers bought into the bigger vision as it helped them do what they wanted to do i.e. develop. I think this is the key issue really, anything that reduces the amount of time developers can develop is a losing idea.
Of course many developers (now) appreciate the value of code control, continuous integration, bug tracking, unit testing etc. When hiring new people make sure you ask about these things to see whether they fit into your new vision.
Another problem you could have is the chaos that is your senior management. Some of those guys just don't like 'factory' production and will break or bend any rules you set up - this leads to rapid loss of morale and undermining of the system by everyone else. Maybe you'll be lucky and they'll get promoted or reassigned or will go back to being a used car salesman :-)
Not a very coherent approach but it's a tough problem...
-
Permalink Reply by Corey Reid on -
Focus on people. Just like the Agile Manifesto says: individuals and interactions over processes and tools.
This means yeah, boundaries rather than instructions. It means each person needs to get individualized treatment, not be sent through a cookie-cutter process. We assign veterans to new people -- two vets per newbie -- to help them learn how things operate at FreshBooks and make sure they learn the culture, the business and the team. Folks spend their first two months answering the phone and handling support emails.
The question isn't really about maintaining chaos -- it's about building a community where each individual can contribute in their own way.
-
Permalink Reply by yadu tekale on -
I have seen the extreme end of chaos more than a few times; I have witnessed product knowledge being with just one person, the original developer, and entire companies being built around this person.
the management of a company have the responsibility for making sure product knowledge is devolved; what methodology you adopt for devolution is of less significance. scalability can happen when product knowledge and development processes are transparent.
-
Permalink Reply by Charles Kinnan on -
The problem I ran into recently when changing a startup to a more established software company seemed to be trust issues prevented the establishment of effective boundaries. It reminded me of the cash or king decision.
The development, design, IT, documentation and QA teams were more or less on the same page that boundaries needed to be established and each team (and/or manager) be given responsibility and accountability for their domains. Upper management never seemed to relinquish the control necessary to allow all of the units to function at their peak though.
A good example was that during brain storming meetings, one of the goals was to get everyone to come to a consensus on the feature design. Now I'm all for brainstorming to get ideas and issues of all perspectives on the table, but trying to get ten people from wide flung departments to agree on a design is difficult at best. Kudos on the communication in this case I suppose; shame on upper management for not trusting and empowering their designers and analysts to come up with the best design. During design, the details of every design had to be approved by a single individual which was a huge bottleneck. And at hand-off meetings, poorly defined, understood and/or supported boundaries led to 'spirited discussions' that could have been squelched by a simple, "That decision falls in the domain of x unit. They made the decision. We're backing it."
Basically, it seemed like upper management wanted to be in total control of all aspects of the process which prevented effective boundaries from getting established. Someone wanted to be king badly enough, there was no way the units could scale to bring in the cash. I guess I didn't mention process too much, but it is another issue with creating effective boundaries.
-
Permalink Reply by Andrew Butel on -
Eric's talk at BOS08 about being the parent of your product is a great analogy. Parents are the one who care the most and never stop caring and the product relies on them initially, but they have to gradually step back and let the product (and team) "grow up".
and the like.
Having boundaries instead of processes is interesting. I was thinking of external boundaries, between the team and the customers / rest of the world, but internal boundaries are also important - which I guess define outputs from different team members. Its also very easy to go over-board on processes here and end up with all communication happening via detailed documents, where what's really important is just defining the expectations so the team can hum.
Cory's example is great. I can think of a number of processes I've seen designed to share knowledge, but none work as well as just giving each newbie a couple of mentors. The question is, how do you measure this if you have a governance requirement to do so?
-
Permalink Reply by Thoglette on -
First question: does the problem you are trying to solve require a big team? Let me rephrase: are you building planes or running a successful Pâtisserie? In the first place you need a big team, moving as one. As your planes get more complex, the team gets larger. In the second case it is the hands-on nature of a small bakery that makes the bread good. So you may be better off with a franchise model
In either case you still need to facilitate (ie. fund) free and frank exchanges of ideas and opinions amongst peers. This is to advance best practice; keep a consistent language and, most importantly, avoid schisms or NIH syndrome within the organisation.
If you want to keep "that startup feel", keep your projects small enough to be dealt with by a dozen people. Add features by spinning of a "startup" to develop it as an add-on and avoid disturbing the stable, core product. I'd remind you that startups are "productive" by being small, not doing any planning or documentation, beta testing on their customers and working stupid hours.
Occasionally, you have a chasm to cross (such as refactoring from XP to Vista). This is not the time for startup genius - it's the time for MIL-STD planning, risk management, verification and hard grind. (Perhaps you can be a genius in automating the boring bits?)
As Mark Dalgarno pointed out, regardless of your model, decisions (including decisions to delegate) must be made. And stuck with. The biggest problem with the "collective" approach is that no-one is responsible - even the UN has problems making (and sticking to) decisions.
In my experience one of the major causes of inefficiency in major companies is that engineers/programmers spend a lot of time doing things other than engineering/programming. Hire some PAs, tech writers, draftsmen, travel planners, expense-form-fillers, dishwashers, coffee makers and mpp/primavera monkeys. Video technical presentations.
Polemic of the day: Want to some really productivity gains? Ban MSOffice from engineering desktops. Except Excel.
-
Permalink Reply by John E. Abram on -
Hi Andrew
There are a number organisational behavioral indicators that are recognized to influence innovation. You have mentioned a number of these in your post.
Processes, management reporting etc can not be ignored as the organisation grows; It is important though, these new requirements support the existing creative environment and not replace them. i.e. chaos can continue to survive within a factory.
Cheers
John
© 2012 Created by Neil Davidson.
Powered by 
.
