Flattening Your Workflow: A Guide to “Flat” Style Project Management

As flat organizations become more popular so do the methods and processes that come along with them. This blog discusses not the flat organizational structure itself but how a flat organization functions within the project management arena. The principles of project management learned from a flat organization can be adopted in the flattest companies to the most hierarchically structured organizations.

Being “flat” is hip but why should I do it?

You may be asking the question, “why would I be interested in flat project management?” For the project manager, the answer is simple: less delegation, less pinging for status, and less oversight. This translates to more time for you to focus on the things you love… unless you really enjoy being a taskmaster (and if that’s the case you should stop reading here). For the one being managed, it’s also quite clear: why would you need to have an overlord constantly hound you for status and “advise” you on how to do your job correctly? Again, if you’re really into that then this may not be the right style for you. The idea here is that managers require less managing and everyone else has the autonomy and freedom to get their work done how they want it done without being pestered.

The Prerequisites

Before starting with the process itself there are three major prerequisites to really make this work: Trust, Transparency, and Communication.

HERE

Figure 1. Trust, Transparency, Communication

Trust: Trusting each other is key to a successful flat project structure

Transparency: The need for everyone to be completely open about what they’re doing. This can be done by communicating their work through some of the following mediums:

1. Code commits
2. Wiki pages
3. Issue tracking systems
4. Espresso machine (i.e. the new water cooler)

Communication: Everyone needs to have the ability to communicate with each other and should be encouraged to do so.

When there is trust there is transparency. When there is transparency people start to feel safe. When people feel safe and are encouraged to be open about their work, the communication just happens naturally.

Implementation

Now that we’ve covered the prerequisites we can discuss the implementation of flat project management.

The Project Lead: “But I thought no one is the boss in a flat structure?” While no one is truly needed to engage in “command and control” it is important to have a facilitator. Think of the project lead as a conductor who ensures that everyone is on key and playing to the same beat.

Clear Objectives and Goals: Project goals must be clearly communicated from the beginning of the project. Questions such as, “What’s our objective? What are we trying to achieve? Who wants this widget anyways?” need to be defined and a Wiki space is a perfect place to do that.

Requirements and accountability: Whether it’s the project lead or marketing, requirements need to be documented otherwise chaos can ensue in a flat project management style. Without a clear direction, the “boss” can easily swoop in and pick up the pieces in a normal environment. In a flat environment, people can easily get lost without clearly defined requirements. In an issue tracking system, such as Jira, these requirements can be captured as Tasks or Stories. The standard practice would be for the project lead to assign the tasks to individuals. In a flatter work environment, a list of unassigned tasks would be presented to the team where they could self-assign these tasks to themselves (or others). This system (i.e. where all the tasks are presented) can be as simple as a shared Excel worksheet or as hip as a Kanban board. Once this is set up everyone can view and track the status of the whole project without being the boss.

Centralized design repository: A centralized design repository is key to creating and maintaining this style of project management. There is no roll-up or constant statusing of each team member's design to a “boss.” If people are unable to view each other’s work then there are no checks and balances. Each team member is a check for the other. In the Software world, this formally done by creating a Pull Request and having your co-workers check your work via a code review (versus the boss acting as the gate). In schematic capture or layout, this can also be achieved by a similar process. This blog discusses committing your design to a Git repository (i.e. the new “SVN” or “CVS”). In this case, one would follow the same Software Engineering practice of committing to a development branch and then issuing a Pull Request. For more information on this topic, you can refer to Atlassian's Git tutorial on making pull requests.

Example: An Embedded System Widget

In this example, you can see that we have set up a small project containing different requirements that make up an embedded system widget. The project, in this case, is an Epic containing requirements to build a “Blinky LED” board.

Figure 2. An Epic containing the design requirements to build a “Fancy Blinky LED PCB”

In this project space we have mechanical, electrical, and software “components” in which each of those components are assigned to a component lead.

Figure 3. A view of all the components and component leads for the project

Figure 4. An example of a task containing multiple components

The electrical is using Altium and pushing his code to the Git server (Bitbucket in this case).

Figure 5. Git commits of the schematic design

The software and mechanical engineers do the same. In this particular project there are only three team members but it could contain countless team members, as long as there is a component lead (i.e. someone who is held accountable for that piece of the project).

This wiki space allows a conversation to occur between all the users who are participating in the product concept, implementation, or verification phases.

Figure 6. A wiki page containing information about the product (including tasks)

Whether it is a spreadsheet, tasklist, wiki page, or a stream of emails, it is important for the project facilitator and the rest of the team to have the ability to view everything that’s happening within the project. This allows everyone to be held accountable by each other and not by a single manager. Within our company we found the Kanban board to be the best way to visualize all the project activity.

Figure 7. A Kanban board containing the tasks of the example project

Finally, if a team member finds a hole they should feel empowered to create tasks and assign it to other teammates without any hesitation. Perhaps they found a bug or they just needed an extra piece of hardware to support their software implementation - regardless, they need to feel comfortable taking charge and initiating that request laterally versus top down.

Conclusion

Micromanagement has become so passé. Managing a project in a flat fashion versus top down has not only become hip but it also alleviates the pressure on everyone. The project manager focuses less on chasing status and the designers spend less time generating those status reports. This article laid out the principles behind a flat style approach to project management and what that implementation looks like. One need not flatten their whole corporate structure to adopt a flat style approach to project management - they only need to adopt the above-mentioned principles and dive right in.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium or continue reading about how Altium Designer’s comprehensive library of components interfaces directly with your design and simulation tools, to easily design embedded systems with the functionality you need.

Team Up and Save

Get Special Savings When You Add a New Altium Designer^® Seat