Healthy creation of technology
After the last posting I received a challenge from a reader (Shane Simpson) who happens to be the hosting company I've worked with on a few project and continue to do so as well as recommend.
The tweet was this one, which made me think of words by Ben Harper, “what good is a critic with no better plan.", a valid comment I thought, so I tried to summarise (some of) my ideas.
Now this is going to take some thought, and answering .......
I think I will try and answer the question opposed to being too exploratory, so "what you feel is a better way of running a technical company" which to me infers, "how to be successful, happy and sustainable as an individual at work, as group of people (the team) and ultimately commercial organisation, after all there are bills to pay".
A short answer of the top of my head, is healthy relationships between people and a common purpose, the long answer on the other hand is a journey though systems analysis, conflict management, communication, finance, ergonomics, logistics and a host of other topics I fear.
Though as with any journey this (assumption and idea) is where I'm starting and I'll just have to see where I end up.
Opposed to trying to describe how I see the whole process & system in one go, I'll take the scientific reductionist method to being with and break things down before putting them back together again as more of holistic view. As with the integration after analysis done, it will be easier to see the important bits, how they interact (the social & technological relationships).
The point here being a thought or desire is being realised, be that in code, brick or a metal tube that whizzes along on tracks. For our answer, lets just call it, code. Though I include art and digital assets anything that was created that is going to pass though a network card to a client in 0s and 1s.
I think the hardest thing for people in this role from what I've seen is, trust.
Trusting the builders are capable, trusting the process over all (i.e. not micromanaging), trust in the truth that it's OK to make mistakes and to lead by example as that's where a lot of learning comes from. Sharing a mistake, learning from it and the working as a team to build on it in a trusted environment is an amazing experience and to be supported.
The other end of the scale is an experience I had in one organisation where a tester wanted to create a league table of which coders had the most bugs buy way of a punitive tool a "blame board" they called it; something I didn't allow at all, a very negative environment.
I suggest doing a course in group counselling or group facilitation, the things I learnt from Prof. Ross Laird at VCC when studying counselling were quite profound.
I try to never tell people what to do or "mark them" on the outcome, just communicate the goal of the project or desired outcome and then leave the builders to the task of translating that information into the end product. Though of course you observe and deal with the flow of the process in the moment, though you trust the builders.
Never tell someone to "take ownership" of something, firstly it's condescending and secondly what you are actually saying is "take the responsibility for the past failed decisions".
Trust is a huge topic within itself, though it's two way and built on respect (not demanded, i.e. authoritarian).
They have valid input, the are now a part of the system over all, they have a valid voice, and can & will walk away from negative relationships where they aren't heard (most of the time). Just look at the positive atmosphere and relationships between clients & builders (and facilitator, being Ashley) over on XenForo.com. It's basically a nice place to be, the trust and respect talked about above is evident and being earned by both sides.
At a previous games job I used to spend hours on the forums as Technical Director talking to the players, understanding their concerns and frustrations and communicating what was going on. While most of this effort wasn't able to be understood by "management" the outcome and following that built up in a short period of time was more that enough positive proof with in itself.
So the point here, is that clients become part of the group once the product is out and the communication between them and the inner team (lets call them) is tantamount to success.
The art of communication is listening, NOT talking non-stop, being the "leader" in a meeting and power point .....
In a perfect world, effort and energies would be balanced amongst the needed areas in a harmonious balance. As it is focus in a project usual varies depending on what stage it's at, to belittle builders about support or customers before a product is launched is so pointless it doesn't need commenting on.
So be aware of what it is your doing, when, and why. If you believe you are focused on one stage or group, then be so and accept that not all your energy is going to be available for other tasks.
So the point here is stay in the moment, be present, keep a focus on what is going on; Do less better, not more worse.
She also goes on to explain the importance of having all the sub systems (i.e. all the actors & tech systems) aware of what the ultimate goal is.
And it isn't “making 1 million dollars a month”, I can assure you, that's nothing more than the cry of green from short sighted management. Profit is a side effect our outcome of the system working to purpose and customers exchanging money for the output of that system (i.e. what ever it is the business makes or provides).
Ideally this behaviour in some form is ongoing throughout the life time of the company, though you can see when it shifts from one stage to another due to the amount of change and team consensus there is.
Here concepts start to be pulled out of the air and realised in 0's and 1's on a data store some where. This is where the facilitators have to put their ego to one side and let the people who actually build things get on with it, though typically this is where the most damage is done my suits with constant meetings, attempts to micro manage and constant changes (because the first step wasn't allowed to complete enough).
A lot of projects getting stalled here or held onto for too long as it's the “constant polishing stage”, no set goals or consensus in achievement is met. Which is the typical side of the builders, the opposite end of the spectrum is pushing out unfinished systems far too early, which is symptomatic of amateur and greed drive management. The pull between both forces is evident in most places I've observed.
Though when there is a common level of trust and it's seen as a constant process between professionals this is a a much more pleasant experience !
So points to remember here, is being aware of where you are on the time line and that builders who are supported naturally want to achieve and do well (aside from being a human trait)
So, the facilitators are responsible to the team, and take the responsibility for their choices.
The ideal compromise (in the analogy) is that of a spine, it's protective and flexible, though to a point.
Much is the same with projects and systems, having a vision and goal is good to start with, though all things change once they are in motion, and going with what is in the moment as long as it isn't destructive can be very worth while. It's also how a lot of scientific discoveries are made.
How many times have you done just enough to get the job done to get by because you're not really engage in it ?
What that engagement is, how it can be fostered, is a whole book in itself. Though it has to be authentic, you can't just demand that team members engage wholly.
Though without being honest about where you are, you'll be on the wrong path and confused at the outcome when you get any where.
A company that is constantly looking for “A players” …... when the company it self isn't an A place, because it doesn't embody that philosophy is going to be a poorly operating system over all.
And all that came from mutual trust within the group, we shared a common goal, felt supported, were flexible and honest about out abilities and expectations.
Ultimately be reasonable and see it as a something you get for a well functioning system, not the output of the system itself. This can be gauged by competition, the market and the usual supply and demand factors for the most part.
Pay as per the RSA clip pay people enough so it's not an issue, skimping on pay up front as a way to “save money” is about as counter productive as you can get, and once again a greed motive from management.
As for reward, I remember a meeting where developer reward was being discussed and it was being forced by management and peers that the bonuses to developers should be based on company profit “while they had no input to the way things were done or even what was being done”. So they were held hostage to the poor choices of management/producers/et al.
I think my initial short answer holds mostly true, it's about people and communication. Add to that awareness of the system as a whole to each part and a focus on the direction things are going in and it's a matter of being present and staying in the moment for decision making.
I've found that the quality of the output of a system, be it software, social, family, etc is a representation of the quality of the relationships within the system. Now there are some execptions and you can force good things out of a bad system by chance, though it isn't sustainable or at all enjoyable, so aware people won't stick with it.
Getting good people, focusing on communication (and quality of it not amount or volume !!) and capture of ideas, aligning them from a know starting point in a given direction, creating a trusted and safe environment (include ergonomics in there as well !) then getting out of their way and facilitating where it goes seems to be the best tactic I've found.
It typically comes back to one word that you can apply to any member in the team, or how they treat each other, or develop the communication and system interconnects, the system itself or ultimately the output, respect.
Any other questions find me on : twitter.com/jeremyhutchings
The tweet was this one, which made me think of words by Ben Harper, “what good is a critic with no better plan.", a valid comment I thought, so I tried to summarise (some of) my ideas.
Now this is going to take some thought, and answering .......
I think I will try and answer the question opposed to being too exploratory, so "what you feel is a better way of running a technical company" which to me infers, "how to be successful, happy and sustainable as an individual at work, as group of people (the team) and ultimately commercial organisation, after all there are bills to pay".
A short answer of the top of my head, is healthy relationships between people and a common purpose, the long answer on the other hand is a journey though systems analysis, conflict management, communication, finance, ergonomics, logistics and a host of other topics I fear.
Though as with any journey this (assumption and idea) is where I'm starting and I'll just have to see where I end up.
Opposed to trying to describe how I see the whole process & system in one go, I'll take the scientific reductionist method to being with and break things down before putting them back together again as more of holistic view. As with the integration after analysis done, it will be easier to see the important bits, how they interact (the social & technological relationships).
1. People
A vast topic that been talked about since the beginning of time (OK well nearly) and posted about by the likes of Richard Branson, who I think has a fair idea about building business and dealing with people.1.1 Which people
But whom ? Easy answer is everyone, though it depends on the role(s) people have, in UML it would be actors, and what point in time. To just simplify things for now down to builders, facilitators (which isn't a mutually exclusive role, I enjoy doing both) and clients (internal & external, as I also use the code I write, look at 37signals !).1.1.1 Builders
The people that put the bricks together and build the wall, the coders, the chefs, the architects who draw plans for the train, the welders that put it together, the electricians that wire it up, the people who have a conscious, deliberate and actual input into changing the essence of an idea into something tangible.The point here being a thought or desire is being realised, be that in code, brick or a metal tube that whizzes along on tracks. For our answer, lets just call it, code. Though I include art and digital assets anything that was created that is going to pass though a network card to a client in 0s and 1s.
1.1.2 Facilitators
Personally I'm not a fan of the term "management" I share the same thoughts on them as most experienced software engineers and professionals like Dr Paul Thomas. My recent employment history has given me enough evidence to see what happens to technology when people in that role forget what their tasks are (and not constant interruptions or making implementation choices). The tasks are quite simple :- Support the team
- Deal with paper work (licenses, formalities of business, road blocks, etc)
- Get the above annoyances out of the way of the builders
- Ultimately get yourself out of the way of the builders, you will slow them down and frustrate them.
- Facilitate communication between the people that need it.
- Observe from a distance.
I think the hardest thing for people in this role from what I've seen is, trust.
Trusting the builders are capable, trusting the process over all (i.e. not micromanaging), trust in the truth that it's OK to make mistakes and to lead by example as that's where a lot of learning comes from. Sharing a mistake, learning from it and the working as a team to build on it in a trusted environment is an amazing experience and to be supported.
The other end of the scale is an experience I had in one organisation where a tester wanted to create a league table of which coders had the most bugs buy way of a punitive tool a "blame board" they called it; something I didn't allow at all, a very negative environment.
I suggest doing a course in group counselling or group facilitation, the things I learnt from Prof. Ross Laird at VCC when studying counselling were quite profound.
I try to never tell people what to do or "mark them" on the outcome, just communicate the goal of the project or desired outcome and then leave the builders to the task of translating that information into the end product. Though of course you observe and deal with the flow of the process in the moment, though you trust the builders.
Never tell someone to "take ownership" of something, firstly it's condescending and secondly what you are actually saying is "take the responsibility for the past failed decisions".
Trust is a huge topic within itself, though it's two way and built on respect (not demanded, i.e. authoritarian).
1.1.3 Clients
The end users in most cases, the people with the cash ! What I've found in successful projects (e.g. the early days of vBulletin) is that the initial idea which the builders create once accepted and used by a growing base of clients, is in part given over to them.They have valid input, the are now a part of the system over all, they have a valid voice, and can & will walk away from negative relationships where they aren't heard (most of the time). Just look at the positive atmosphere and relationships between clients & builders (and facilitator, being Ashley) over on XenForo.com. It's basically a nice place to be, the trust and respect talked about above is evident and being earned by both sides.
At a previous games job I used to spend hours on the forums as Technical Director talking to the players, understanding their concerns and frustrations and communicating what was going on. While most of this effort wasn't able to be understood by "management" the outcome and following that built up in a short period of time was more that enough positive proof with in itself.
So the point here, is that clients become part of the group once the product is out and the communication between them and the inner team (lets call them) is tantamount to success.
The art of communication is listening, NOT talking non-stop, being the "leader" in a meeting and power point .....
1.2 Timely focus
In something of a rebuttal to “the customer is always right” or “the customer is at the centre of everything”, I'd say it depends on what is going on, what is the focus of the process and system at what time ?In a perfect world, effort and energies would be balanced amongst the needed areas in a harmonious balance. As it is focus in a project usual varies depending on what stage it's at, to belittle builders about support or customers before a product is launched is so pointless it doesn't need commenting on.
So be aware of what it is your doing, when, and why. If you believe you are focused on one stage or group, then be so and accept that not all your energy is going to be available for other tasks.
So the point here is stay in the moment, be present, keep a focus on what is going on; Do less better, not more worse.
2. Agreed outcome
In the book Thinking in Systems, Donella Meadows lists the top attributes of successful systems, one of the, is : “Goals – The purpose of function of a system”.She also goes on to explain the importance of having all the sub systems (i.e. all the actors & tech systems) aware of what the ultimate goal is.
And it isn't “making 1 million dollars a month”, I can assure you, that's nothing more than the cry of green from short sighted management. Profit is a side effect our outcome of the system working to purpose and customers exchanging money for the output of that system (i.e. what ever it is the business makes or provides).
2.1 Beginning
In the beginning stages there is the original concept(s) very broad based ideas and a hunt for direction or a market, this isn't the time to start coding trust me, this is the time to question, explore, play with ideas, observe others, play games with ideas/situations/outcomes.Ideally this behaviour in some form is ongoing throughout the life time of the company, though you can see when it shifts from one stage to another due to the amount of change and team consensus there is.
2.2 Middle
Stage 1 has given way to enough of a consensus to begin building. I'm not advocating water fall design methods (or any other) here, a method is a social tool or organisational one, I'm talking about a state and activity.Here concepts start to be pulled out of the air and realised in 0's and 1's on a data store some where. This is where the facilitators have to put their ego to one side and let the people who actually build things get on with it, though typically this is where the most damage is done my suits with constant meetings, attempts to micro manage and constant changes (because the first step wasn't allowed to complete enough).
2.3 End
Everything to now has been laying the foundations, getting the technology ready for clients input. That can either be beta testers, going live straight away, internal review or a combination of all. Though by End here all I mean is end of the internal team, as you're just about to include the external team.A lot of projects getting stalled here or held onto for too long as it's the “constant polishing stage”, no set goals or consensus in achievement is met. Which is the typical side of the builders, the opposite end of the spectrum is pushing out unfinished systems far too early, which is symptomatic of amateur and greed drive management. The pull between both forces is evident in most places I've observed.
Though when there is a common level of trust and it's seen as a constant process between professionals this is a a much more pleasant experience !
So points to remember here, is being aware of where you are on the time line and that builders who are supported naturally want to achieve and do well (aside from being a human trait)
3. Facilitation & Support
In one of my other posts I explain how support (in a typical hierarchy org) is top down and responsibility is bottom up, I have had a few experiences of it being forced the other way, where I was made to support the ineptitude of those “above me” and take responsibility for their choices (legacy issues in a project I didn't build, culminating in getting taken off a project which I was saving, and ultimately saved with my plans …. also being bad mouthed to the whole team in an ego speech, who luckily knew the real story, I walked away from that one instantly !!).So, the facilitators are responsible to the team, and take the responsibility for their choices.
4. Flexibility
There is an analogy used in parenting styles that explain being too rigid is like being a brick wall, and that being too loose is akin to being a jelly fish. So there is either far too much control or there is non what so ever, or in the case of teams and systems, boundaries.The ideal compromise (in the analogy) is that of a spine, it's protective and flexible, though to a point.
Much is the same with projects and systems, having a vision and goal is good to start with, though all things change once they are in motion, and going with what is in the moment as long as it isn't destructive can be very worth while. It's also how a lot of scientific discoveries are made.
5. Assessment
There is a fair amount of honesty that is needed when doing assessment, it can be uncomfortable to shine a light into corners of an organisation, though ultimately ourselves. Though to know where we want to be, we have to know where we first are. And that is as individuals before the rest of the team, if what you're doing isn't authentic to who and what you are, then your outcomes will be limited.How many times have you done just enough to get the job done to get by because you're not really engage in it ?
What that engagement is, how it can be fostered, is a whole book in itself. Though it has to be authentic, you can't just demand that team members engage wholly.
Though without being honest about where you are, you'll be on the wrong path and confused at the outcome when you get any where.
A company that is constantly looking for “A players” …... when the company it self isn't an A place, because it doesn't embody that philosophy is going to be a poorly operating system over all.
6. Trust
Likely one of the hardest things to do, to trust in yourself as well as others. Though in the most productive environments I had very high trust in not only the abilities of the people I was in a team with, though in their engagement and their openness to questions and learning as I was. I made mistakes, was supported, felt valued and ultimately safe.And all that came from mutual trust within the group, we shared a common goal, felt supported, were flexible and honest about out abilities and expectations.
7. Money
Oh the sordid topic of coin; be how it comes in, what it does and where it flows out.Ultimately be reasonable and see it as a something you get for a well functioning system, not the output of the system itself. This can be gauged by competition, the market and the usual supply and demand factors for the most part.
Pay as per the RSA clip pay people enough so it's not an issue, skimping on pay up front as a way to “save money” is about as counter productive as you can get, and once again a greed motive from management.
As for reward, I remember a meeting where developer reward was being discussed and it was being forced by management and peers that the bonuses to developers should be based on company profit “while they had no input to the way things were done or even what was being done”. So they were held hostage to the poor choices of management/producers/et al.
Putting it all together
Sorry, but there is no magic formula, “Agile” isn't a magic silver process bullet a lot think it is, it's just another organisational tool, it's not a guarantee of anything, as with any other method.I think my initial short answer holds mostly true, it's about people and communication. Add to that awareness of the system as a whole to each part and a focus on the direction things are going in and it's a matter of being present and staying in the moment for decision making.
I've found that the quality of the output of a system, be it software, social, family, etc is a representation of the quality of the relationships within the system. Now there are some execptions and you can force good things out of a bad system by chance, though it isn't sustainable or at all enjoyable, so aware people won't stick with it.
Getting good people, focusing on communication (and quality of it not amount or volume !!) and capture of ideas, aligning them from a know starting point in a given direction, creating a trusted and safe environment (include ergonomics in there as well !) then getting out of their way and facilitating where it goes seems to be the best tactic I've found.
It typically comes back to one word that you can apply to any member in the team, or how they treat each other, or develop the communication and system interconnects, the system itself or ultimately the output, respect.
Any other questions find me on : twitter.com/jeremyhutchings
Comments
Post a Comment