Questions to ask when building software engineering teams

Software development is brutally hard. Software engineers don't perform well, and are all the same. My business is slowed down by the development team. Let's hire lots of cheap developers. Let's put in strict processes, things will improve.

If this sounds like your mental voice, it's most likely you who is screwing up your business the most.

Your competitors will eat you alive even if just some parts of your business are weak.

So what can you do? Because you clearly have some critical issues at hand.Get into your stoic mode, and find the answer to these 3 questions:

• How do we create a high performance team?
• How do we make software development less complex?
• What do we measure and improve?

How do we create a high performance team?#

Software engineering is a relatively new field. We can almost say it's immature, but not really, because this will most likely never change.

The way we practice it is always changing, and changing at a pace much faster than other fields are.

But remember, you are ultimately dealing with people. No matter what process you choose, no matter how much you push, it's all about the human spirit.

You have to create the environment for people to thrive, and get out of the way.

So what are the characteristics of this kind of environment?

Autonomy#

First, you have to realize they are probably smarter than you are, even if they don't seem like it. Not in all areas, but in problem solving they most likely are.

So don't go telling them 'your solution', tell them your problem, and document the problem in the best possible way. Include all corner cases you can think of, include deep rooted relations and then get out of the way. It's a lot more simple said than done, and it's not going to work at first, but you have to keep refining your problem description skills.

On their side it's probably a new thing too, because they're not used to this way of doing things, but in the long run it will pay off.

Low pressure#

Most of the work engineers do is mental, and it doesn't happen when they write code. That's why being in a constantly stressful environment will most likely result in a negative impact on their output.

The "are you done yet?" type of environment will cause them to come up with half-baked solutions which will be good for the next month, but will drag you down in the long run. Remember, building your business is not a sprint, but a marathon.

Find a way to balance your need for features now with your need for stability and quality work. This will give you the competitive edge you're looking for.

That said, humans don't perform well in zero pressure environments either. That's a recipe for disaster. It's really hard but each of us has to find the balance which is most adequate for our businesses.

Low process#

Remember how everybody hates bureaucracy in government? Or big corporations who adapt very slowly and lose market share to the newcomer?

Most of the time, this is a result of process, or rules. The more process you have, the less output you'll get. Engineers as humans, can only tolerate a certain amount of rules. And those rules are accepted only if they understand the purpose of. Hire a consultant to teach your team 'the rules of new Agile Scrumfall', and see what happens when your team tries to implement.

Your solution here is to think from first principles.

Ask: What is the minimum process that works for us?

This means thinking about your current situation - people, product, customers. When you come up with an answer, remember this is not a permanent solution.

Re-do the thought process again next month, and next year when your situation changes. Next month you might need even less rules. Remember, the process is perfect when there's nothing left to remove.

How do we make software development less complex#

Most of the time, software development is not a linear process. It's not like when your factory builds sneakers and each worker can make between 20 and 30 speakers a day.

It becomes more challenging when you realize you can't reliably predict when features will be finished. After you eventually release to your customer, you'll get feedback, and even small changes can sometimes take an unexpectedly long time to develop.

When some of your developers leave your company and you hire new ones, they almost always say that the codebase is crappy. You should believe them, if you always pushed for having new features NOW.

When they get enough knowledge about your product to write useful code, it might take them too long to do it, and they might blame it on the code. Again, you should believe them. Give them the benefit of the doubt, and trust them. Always re-assess, but trust by default.

Sometimes, just accept that it's a complex process with many moving parts. Don't try to optimise too much. Remember, unnatural ways will hinder your team's output.

What do we measure and improve?#

Hours in the office, lines of code, story points, git changes, are all terrible metrics. This has been proven again and again. Some things you should measure that are more useful but still don't tell you the whole story are:

• how many times per day/week does your team release in production;
• how fast can code get from a developer's machine to production;
• how fast can your team address production bugs;
• how well your team's solutions addresses the problems your customers are facing;
• how well your team communicates internally and externally.

More frequency in releases means you have a well oiled machine, delivering more value incrementally to your customer.

When code moves quickly from local to qa to production environments, it also means that critical issues can be resolved fast, features can be shipped fast, and you'll be able to impress your customers with your agility.

Even if you have a well built QA team, it's a fact bugs get through, building software is hard. What really matters is if bugs are addressed quickly. If perfect software existed, it would most likely impress nobody. Having agility in solving problems impresses everybody, because they know how others handle it -- most of the time, slowly.

The most underrated thing to measure is customer experience and engagement. Does your team provide the correct solutions? Even if you have all of the above in check, does it matter if they deliver things nobody wants?

Another underrated thing to measure is how your SD team communicates with other teams or customers' teams. Are your engineers prepared? Do they speak fluently? Is everybody on the same page? Does everybody have the same knowledge? Often times, bad external communication means bad internal communication

Good internal communication is paramount to building a high performance team. All high performance teams are on another level when it comes to how they communicate. It's not about using Slack or even face to face communication. Using Slack for this is very naive, because often people communicate 1 to 1 and information becomes siloed. When they communicate useful knowledge on a Slack channel, it's really easy to have it buried in the mountains of messages.

It's how they communicate over time, asynchronously. It's how they pass on hard earned knowledge from one to the other. It's how fast they can onboard new developers. It's how good they are at communicating with juniors and training them. It's about how fast they can reach the information they need. High performance teams are always very good at these things!

This is where solutions like ours can help your team become badass.

Archbee Wiki provides an easy to adopt solution for internal knowledge sharing that is specifically tailored to software development teams. We've studied many teams and their workflows, we've identified common usecases and coded them into our software's DNA. When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.