I have created my software program which is how I think a software organization should be organized. That program is based on the following fundamental principles.
Words don’t lie
Write something down to make it mean something. People may change their minds day to day, but written documents do not change unless intentional edits are made.
Everything important to the business or the organization should be written down either in English or in code. Documents should be accessible and should use standard formats whenever possible.
Engineers want to solve problems
Put a couple of engineers in a room with a puzzle for an hour and that puzzle will be completed. Nobody needs to tell them that they should complete the puzzle or how to complete the puzzle. In fact if someone told the engineers those things they would do a worse job and would enjoy it less. All that needs to be said is “We have a puzzle.” To the right type of person, solving engineering problems is not a means to an end, but the end itself.
Using engineers effectively is not complicated. Simply show them clear problems, give them access to necessary resources, and empower them to make decisions. The environment these ingredients create will bring out the best engineering the organization can produce.
Time is valuable
Meetings are very expensive, do not build processes that rely on them. Offline processes can work just as well as meetings and allow for each person to manage their time in the way that is most effective for them.
Daily standups are a common meeting that is built into software programs. I think daily standups are fine as long as they provide significant value to justify their cost. Meetings for specific purposes are also acceptable, but should typically have agendas.
We should not be satisfied with the status quo. Improving processes to use time more effectively will pay dividends.
Make the right mistakes
Moving fast is desirable, but the faster an organization moves, the greater the risk of mistakes. Move fast whenever possible, but make the decision deliberately.
Rushing a launch is a good way to permanently damage user trust and is rarely the right choice. Rushing a software design can cause a full rebuild to be necessary later. A full rebuild may or may not be an acceptable cost for the time saved.
A software organization needs to know when to move fast, when to move slow, how to move fast, and how to move slow.
Trust the organization
There is always a better engineer out there and there is always a better engineering solution possible. Luckily, businesses do not require perfection to succeed. Relax expectations, reduce agitation and be satisfied with the best the organization can offer. Increased pressure will not lead to better results.
Leave a Reply