Share
In the previous articles (part I and part II) we discussed the forces that lead to a need for more engineering talent, and the engineer’s mindset. In this article we will discuss a number of measures you need to take to create an environment where engineers will be able to excel, and will want to stay.
Start with the right metaphors
It’s easy to assume that more coders will automatically lead to more features. If only the world of engineering was this golden, there would be champagne and cocktails every day.
Software development can’t be approached from a factory metaphor where additional hands on the assembly line will automatically increase the amount of goods at the check-out. Actually, if the environment isn’t managed well, throwing more engineers trough a fixed pipeline will rather clog the system instead of increasing the magic output.
Let’s look at it from a making a movie point of view. There is a definite sense of business pressure to get a job done in a timely fashion. There are many aspects that are simply work to do and not that creative, but everybody intuitively understands that a big part of what makes a good movie is the creativity of the moment and the art of bringing many interlocking pieces together to make a great quality film. Engineering is like that.
With a better metaphor in mind we can see how we can set up a great engineering environment.
Teams are the atomic unit of an organization
In an organization of any size everything is created by people working together towards a common goal: in teams. These teams do not just consist of individuals, but more importantly teams are the set of relationships between these individuals. Building up these relationships takes time, and are the social capital of your organization. Many environments do not honor these relationships and keep moving people around, consistently destroying their social capital.
The indivisible atomic unit of an organization should be the team, not the individual. These teams create a common understanding and mindset around the issues and problems to be resolved, and they have gone through the usual forming, storming, norming and performing. Your “people capital” is not just the individuals. Just as important are the working relationships they form. Together this makes up your social capital. Failing to keep your teams stable is destruction of your social capital.
Bring the work to the people, not the people to the work. When there is a new project to be done, split it up into smaller pieces and place it on the backlog of stable teams.
Organize the physical environment around teams
It’s interesting to see extremes like cubicle farms and complete open plan offices around the globe. Cubicle farms helps team members concentrate, but at the same time it creates a barrier for easy team collaboration. An open plan office looks friendly, but due to the heavy chatter half of the team has noise canceling head phones on. Or how about flex desks where people have to wipe the whiteboards clean and find a new place to sit every single day?
A physical environment that is optimized for teamwork has the following characteristics. Imagine a large room surrounded with glass, a view and an open door. In this area the entire scrum team can sit close to each other, preferably with a huge whiteboard at arm’s length. Even better if there is a screen with build, bug, backlog and sprint status in a corner. The team is surrounded by walls full of posters and stickies, for example the roadmap, definition of done, metrics etc. The room has fun stuff, chosen by the engineers personally and the team can rearrange furniture as they wish.
Ideally the product owner, business analyst and UX person are in the same room. If this is too much of a stretch, at least try to get these folks on the same floor, with walkie talkies or a chat program that connects them with a simple press of a button.
Getting the team together in their own team space will make a huge difference in their productivity. The engineers will be able to pick up the chats that are relevant for them as the noise is contained. They can quickly take a look at each other’s screen for a review or a question. It’s just a turn of the head. The door is open, but when they need a meeting, they can just close it and start right away. There is no time wasted on searching for a meeting room, nor do they have to wait for the last person who had to grab a coffee on the way to the room.
Clarity of goals, freedom of execution
A team is only a team by grace of a common goal. This is provided by a role like Scrum’s Product Owner role. Correctly implemented, a Product Owner determines the goals and their priorities, and leaves it up to the team to self- organize towards those goals.
Giving engineers the autonomy, respect and trust to self-organize means that the right people are making the technical decisions and that they can take pride as makers in the solutions they’ve chosen. This also means that the autonomy of engineers in a team with respect to an overall architecture role should be implemented correctly. An overall architecture role should provide the guidance needed to ensure that the contributions of multiple teams fit together well, but should not be micromanage the internal decisions that are within the scope of the team itself.
Autonomy over Standardization
Most organizations default to standardization much too quickly. The myth that an organization works better if everybody works the same way looks nice in theory, but in practice there is a massive cost in the loss of autonomy. Autonomy is the single most important factor to reduce the complexity of managing a large organization. Standardization by its very nature breaks autonomy. Standardization definitely has its place, but an organization should go for autonomy first, and only standardize on what is really needed.
Create a Meritocracy culture
Since engineers live in a meritocracy, you’d better make one.
Start with assuming that every engineer is a problem solver with creative ideas. Regardless of title, any engineer that has a good idea should be allowed to follow up on it.
If there are levels of seniority, this is how it could be defined. A junior engineer is new to the role and needs guidance. An engineer at medio level can implement features independently. A senior should be able to solve complex problems while mentoring others. Leadership and communication skills are key to an engineering culture and should be developed along the coding skills. All coders should be encouraged to speak up, participate in architecture and to challenge each other’s solutions. When a problem is seen from different perspectives the solutions are usually more solid.
In a meritocracy, promotions are based on the level of craftmanship and the capacity to influence decisions rather than the amount of silver-gray hair on one’s head. Rewards are not only based on achievements, but also on how helpful you have been to others. For many in an engineering culture knowledge sharing happens organically. Knowing that you can contribute to somebody else’s development is a reward on its own.
Treat learning as direct business value
In an environment that is not just the production of things in a fully repeatable fashion there will be experimentation and trial and error. There is never a linear path from point A to point B when building a product. To overcome the inevitable obstacles that come with engineering we need to experiment and test hypotheses. The value that is created is knowledge value, and this should be an integral and normal part of day to day work. This means that there must be goals that are aimed at learning, not only production.
One of the most important cultural prerequisites for learning is how an organization deals with “failure” and how much fear there is of failure. Fear of failure kills an engineering culture. It’s much better to have a growth and learning mindset. A good example is the speech by orchestra conductor Benjamin Zander on possibility.
An organization with a good engineering culture invests heavily in a knowledge culture. This means no-discussion access to books and learning materials, opportunities to go to conferences and the organization and support for internal groups and meetings focused on exchanging knowledge.
Fix the System, Not the People
As an agile consultant I regularly get sent to a team to “fix them”. Through many assignments I have learned that in 95% of the cases it’s never the team itself. When they present a list of impediments holding them back they can maybe fix two of them: the other eighteen are due to dependencies and factors in their environment outside of their control.
In a good engineering culture the first assumption should be that if a team is slow, it’s due to factors and dependencies outside the team itself. These issues tend to be a lot harder to solve because they’re systemic, but they’re the only ones that will truly make the organization better.
Systemic impediments are also a great source of frustration for an engineering team. As a tech lead, I can still remember the disappointment on a project leader’s face when I was less than enthusiastic after he proudly told me he’d arranged for another team to help us out. “Why aren’t you happy about this? We got them to cooperate!”. “That’s because for you there’s a job done. I got nothing done. I can now finally get started...”.
So don’t go around fixing your teams. Collect their lists of impediments, and start fixing the system.
Enable creativity
Engineering is a creative job. Creativity is best served with a light heart and an open mind. This means that having fun is an important part of the process. And if my experience in most offices is any measure, there’s only one piece of advice I need to give: don’t take yourself so damn seriously. Any good organizational culture - not just an engineering culture - will be a lot better for it.
Conclusion
A good engineering culture is made up of a combination of physical, process and cultural aspects that combine to create a great environment for engineering work. Given the need for good engineering this will lead to a competitive advantage, but also simply to a better workplace. Especially if you don’t take yourself so damn seriously... :-)
Serge is a speaker @ EXPAND conference 2019! Start expanding your horizon and visit join us at the 6th of September in Amsterdam. The sky in no longer the limit! 