A picture of Antwerp got me pondering corporate structure. Well, that and some culture discussions my team has been having. Some companies are abandoning traditional, often bloated, corporate structures and strict hierarchies because they suck. We’re used to them, but we don’t like them.
Some companies are trying to build differently from the ground up. However, it has occurred to me that the answer isn’t to just throw the baby out with the bathwater.
I think the biggest challenges regarding alternatives are whether they’ll work and evolve long-term (since many being tried now remain quite new), and whether doing things differently (whatever form that takes) can scale.
The picture, above, was of Antwerp’s Grote Markt. Because I think the medieval era and the rise of guilds have a lot of wisdom to share about smart ways of developing people and companies. (Did guilds have TPS reports?)
I have seen various developers over time refer to themselves as craftspeople, and I concur. When writing is going well for me, it very much feels like crafting something. I think this is a reasonable definition for anyone who’s developed experience and expertise in a profession. Someone who couldn’t just be replaced tomorrow by someone else who technically has the same job-specific skill set.
As I’ve also mentioned before, techies tend to be meritocratic. We tend to chafe badly under arbitrary hierarchy, but are happy to listen to and learn from those who know their stuff. We can use this as a strong means of engagement.
Guild structure is based on experience and tenure. You generally didn’t get to just jump the queue to be the boss of anyone because you were the Duke of Snuffington’s nephew. You had to learn the craft and business and build relationships. You had to prove yourself.
Guilds were a means of developing and maintaining a skills pipeline, training, mentorship, quality control, management, leadership and ownership. They eventually served as a framework for the development of great universities, even more advanced institutions for developing people.
Tech could do worse than to follow their example. (I will note here that I am no expert and the minutiae of the medieval guild system are not the focal point of this piece.)
When new team members come on board, they are occasionally green recruits: new grads and the like, or someone switching to an entirely different career. If someone is that new and inexperienced in the trades, typically they have to begin with an apprenticeship.
The same makes sense in tech. You may arrive with relevant soft skills. But whether you’re writing code or keeping your customers happy, you have a lot to learn, and not all of it is going to come from the documentation and corporate systems. New people should come on board in a new role expecting to learn: a lot, and for an extended period of time.
Three- or six-month orientation/probation periods are useful, but mainly from a culture or HR perspective. Is the person fitting in, meshing with the team, and not committing any egregious offences?
But an actual apprenticeship-type orientation needs to be more fluid. For example, the other support person I work with most closely only started with the company in March, but she has worked for a number of years in the domains industry. I hadn’t before I joined the company. So our apprenticeships would focus on different things and likely be of different lengths. But the end goal is two competent, well-versed senior support staff.
There are milestones you hit as you move toward being a “journeyman” and gaining expertise and experience. Could be access to more complex systems, the freedom and responsibility to make decisions on your own, or the ability to directly talk to customers and prospects or push to production. It’s better to work toward those things over time and with mentorship than to be thrown into them, like if someone departs suddenly.
A guild-like system also helps make it clearer who works with whom. Some companies have a hard time refusing to diffuse authority, and so end up with endless “dotted line” arrangements and reporting structures. In my experience these are rarely helpful.
When you know that Person A is going to be apprenticing for Job X, that means they need to learn everything they can from Person B, the team Person B works for, and the systems Person B’s team manages. They can chat with Person X and her team from time to time, but that’s not central to Person A’s development. The textiles guild doesn’t get a say in how the woodworkers get stuff done.
In reverse, a guild structure makes it clearer where apprentices go with questions or concerns. When you work closely with a specific group, you learn quickly who has expertise in what. This saves time and confusion.
When things are really “open” it can be hard to know whom to ask. Or, sometimes, the chain of command dictates that you have a specific contact, but that person is no more than a gatekeeper to those with actual expertise. If this enables that person’s team to get work done better, that’s fine, but often it’s a waste of time and politics.
Letting people communicate directly to get things done doesn’t undermine one’s authority. It’s called delegation and trusting people to get stuff done and learn.
Another guild idea is that when you start off, you work with the least senior person able to properly instruct you. You don’t need to work with the master blacksmith in your first week, because you’re learning things a further-along apprentice can impart.
So you start there, then when you’ve mastered those skills and gained that experience, you move up to the Journeyperson and learn what they have to teach you. You only get access to the Guild Master when you’re ready for it and you’re not a complete newbie and waste of his/her time.
In this way you make the most efficient use of people’s time, learn things in the most efficient order, and build the full complement of team relationships you need in the process.
From a personal perspective, too, there’s an immense sense of satisfaction in tangibly learning and mastering a craft. That first day you committed work that was bug-free. Or didn’t have to assign a case to a supervisor, or whatever. Or when a new apprentice is assigned to you, because you’re no longer the greenest, and now have your own wisdom and experience to impart.
Few things will impart a stronger sense of engagement and reward in one’s work and company. Those who developed the guild system knew they were stronger by getting organized and working together. I couldn’t agree more.
M-Theory is an opinion column by Melanie Baker. Opinions expressed are those of the author and do not necessarily reflect the views of Communitech. Melle can be reached @melle or me@melle.ca.
